Http?報(bào)文格式：狀態(tài)行、請(qǐng)求頭（響應(yīng)頭）、請(qǐng)求正文（響應(yīng)正文）
10年積累的做網(wǎng)站、網(wǎng)站設(shè)計(jì)經(jīng)驗(yàn)，可以快速應(yīng)對(duì)客戶對(duì)網(wǎng)站的新想法和需求。提供各種問題對(duì)應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識(shí)你，你也不認(rèn)識(shí)我。但先網(wǎng)站設(shè)計(jì)后付款的網(wǎng)站建設(shè)流程，更有建陽免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。
狀態(tài)行：http版本，地址、請(qǐng)求方式，空格劃分
請(qǐng)求頭（響應(yīng)頭）:數(shù)據(jù)編碼格式信息，cookie信息
空白行
請(qǐng)求正文：如果是get方法則沒有，post則有
Http?是基于tcp的應(yīng)用層協(xié)議，只是一份協(xié)議，其實(shí)還是靠tcp傳輸，1.0版本無法復(fù)用，1.1版本修復(fù)了這個(gè)問題，keep-alive發(fā)送請(qǐng)求后保存一段時(shí)間，這樣可以復(fù)用
缺點(diǎn)：1.每次都需要重新建立連接
2.所有傳輸?shù)脙?nèi)容都是明文，無法驗(yàn)證對(duì)方得身份，保證數(shù)據(jù)安全性
3.header里攜帶得內(nèi)容過大，在一定程度上增加了傳輸?shù)贸杀?/p>
Https:?Http+SSL+TCP（應(yīng)用層、安全層、傳輸層）
Https請(qǐng)求流程：
第一步：客戶端和服務(wù)端確認(rèn)加密算法和協(xié)議。其實(shí)挺復(fù)雜的，會(huì)分為以下2部分
1.客戶端會(huì)將自身支持的秘鑰算法套件（Cipher?Suite）發(fā)送給服務(wù)器
2.服務(wù)器根據(jù)自身支持的秘鑰算法套件，選擇雙發(fā)都支持的加密算法套件，并告知客戶端。
Cipher?Suite的名字里包含了四部分信息:
a.密鑰交換算法:用于決定客戶端與服務(wù)器之間在握手的過程中如何認(rèn)證，用到的算法包括RSA，ECDH，PSK等
b.加密算法:用于加密消息流，該名稱后通常會(huì)帶有兩個(gè)數(shù)字，分別表示密鑰的長度和初始向量的長度，比如DES?56/56,?RC2?56/128,?RC4???????????????128/128,?AES?128/128,?AES?256/256
c.報(bào)文認(rèn)證信息碼（MAC）算法:用于創(chuàng)建報(bào)文摘要，確保消息的完整性（沒有被篡改），算法包括MD5，SHA等。
d.PRF（偽隨機(jī)數(shù)函數(shù)）:用于生成“master?secret”。
例如：TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
免費(fèi)的數(shù)字證書簽發(fā)機(jī)構(gòu)：Let's?Encrypt
SPDY:(HTTP、SPDY、SSL、TCP)
1.多路復(fù)用TCP通道，降低HTTP的高延時(shí)
2.允許請(qǐng)求設(shè)置優(yōu)先級(jí)
3.header數(shù)據(jù)壓縮
4.基于SSL的安全傳輸
Http2.0:
Http3.0:采用了UDP傳輸
Android歷屆大廠面試真題及答案
Android從零開始到精通
Android架構(gòu)師成長視頻
某機(jī)構(gòu)全套最新視頻
Tcp?ip協(xié)議全套書籍
NDK開發(fā)書本
Android10大開源框架刨析視頻
阿里Android面試題集及答案
Flutter快速入門
Java?最新Springboot2.0與spring?boot1.5學(xué)習(xí)視頻
還要需要iOS、或者是Java其他視頻的可以私聊我
鏈接：
提取碼：brx9
復(fù)制這段內(nèi)容后打開百度網(wǎng)盤手機(jī)App，操作更方便哦
將Flutter module 嵌入到原生做混合開發(fā)時(shí)，遇到一個(gè)奇怪現(xiàn)象，模擬器能正常跑起來，但一運(yùn)行到真機(jī)，進(jìn)入到flutter模塊就直接白屏。
通過查看控制臺(tái)打印的log，發(fā)現(xiàn)了如下錯(cuò)誤信息：
搜索最后一條信息 Could not launch engine with configuration 時(shí)看到網(wǎng)上給出了對(duì)應(yīng)的答案：
嘗試了對(duì)應(yīng)的方案，無果。
接著搜索第一條信息 Can't load Kernel binary: Invalid SDK hash ，總算是找到了對(duì)我有用的答案：
問題的根源就是在于我本地存在多個(gè)Flutter SDK版本，當(dāng)時(shí)同一個(gè)項(xiàng)目需要切換不同版本時(shí)，進(jìn)行對(duì)應(yīng)的套件安裝估計(jì)出了問題，所以就導(dǎo)致我在運(yùn)行項(xiàng)目時(shí)無法正常顯示。
前言
為什么跨平臺(tái)是發(fā)展趨勢？
同一個(gè)應(yīng)用，各個(gè)“端”獨(dú)立開發(fā)，不僅開發(fā)周期長，而且人員成本高。同時(shí)，作為技術(shù)人員，也不應(yīng)該滿足于這種重復(fù)、低能的工作狀態(tài)。在這樣的形勢下，跨平臺(tái)的技術(shù)方案也受到越來越多人和企業(yè)的關(guān)注。
本篇文章我將從原理、優(yōu)缺點(diǎn)等方面為大家分享跨平臺(tái)技術(shù)
一. H5
說到跨平臺(tái)，沒人不知道H5。不管是在Mac、Windows、Linux、iOS、Android還是其他平臺(tái)，只要給一個(gè)瀏覽器，連“月球”上它都能跑。
1.瀏覽器架構(gòu)
下面，我們來看看讓H5如此橫行霸道的瀏覽器的架構(gòu)：
瀏覽器由以上7個(gè)部分組成，而“渲染引擎”是性能優(yōu)化的重中之重，一起了解其中的渲染原理。
2.渲染引擎原理
不同的瀏覽器內(nèi)核不同，渲染過程會(huì)不太一樣，但主要流程還是一致的。
分為下面6步驟：
從以上6步，我們可以總結(jié)渲染優(yōu)化的要點(diǎn)：
以上就是瀏覽器端的內(nèi)容。但H5作為跨平臺(tái)技術(shù)的載體，是如何與不同平臺(tái)的App進(jìn)行交互的呢？這時(shí)候JSBridge就該出場了。
3.JSBridge原理
JSBridge，顧名思義，是JS和Native之間的橋梁，用來進(jìn)行JS和Native之間的通信。
通信分為以下兩個(gè)維度：
那么App內(nèi)加載H5的過程是什么樣的呢？
4.App打開H5過程
打開H5分為4個(gè)階段：
這四步，對(duì)應(yīng)的過程如上圖所以，我們可以針對(duì)性的做性能優(yōu)化。
5.優(yōu)缺點(diǎn)分析
下面，我們進(jìn)行H5的優(yōu)缺點(diǎn)分析：
優(yōu)點(diǎn)
缺點(diǎn)
雖然H5目前還存在不足，但隨著PWA、WebAssembly等技術(shù)的進(jìn)步，相信H5在未來能夠得到越來也好的發(fā)展。
二.小程序
2018年是微信小程序飛速發(fā)展的一年，19年，各大廠商快速跟進(jìn)，已經(jīng)有了很大的影響力。下面，我們以微信小程序?yàn)槔?，分析小程序的技術(shù)架構(gòu)。
小程序跟H5一樣，也是基于Webview實(shí)現(xiàn)。但它包含View視圖層、App Service邏輯層兩部分，分別獨(dú)立運(yùn)行在各自的WebView線程中。
1.View
可以理解為h5的頁面，提供UI渲染。由WAWebview.js來提供底層的功能,具體如下：
每個(gè)窗口都有一個(gè)獨(dú)立的WebView進(jìn)程，因此微信限制不能打開超過5個(gè)層級(jí)的頁面來保障用戶體驗(yàn)。
2. App Service
提供邏輯處理、數(shù)據(jù)請(qǐng)求、接口調(diào)用。由WAService.js來提供底層的功能,具體如下：
運(yùn)行環(huán)境：
僅有一個(gè)WebView進(jìn)程
3.View App Service通信
視圖層和邏輯層通過系統(tǒng)層的JSBridage進(jìn)行通信，邏輯層把數(shù)據(jù)變化通知到視圖層，觸發(fā)視圖層頁面更新，視圖層將觸發(fā)的事件通知到邏輯層進(jìn)行業(yè)務(wù)處理。
4. 優(yōu)缺點(diǎn)分析
優(yōu)點(diǎn)
缺點(diǎn)
既然WebView性能不佳，那有沒有更好的方案呢？下面我們看看React Native。
三.React Native
RN的理念是在不同平臺(tái)上編寫基于React的代碼，實(shí)現(xiàn)Learn once, write anywhere。
Virtual DOM在內(nèi)存中，可以通過不同的渲染引擎生成不同平臺(tái)下的UI，JS和Native之間通過Bridge通信
1.React Native 工作原理
在 React 框架中，JSX 源碼通過 React 框架最終渲染到了瀏覽器的真實(shí) DOM 中，而在 React Native 框架中，JSX 源碼通過 React Native 框架編譯后，與Native原生的UI組件進(jìn)行映射，用原生代替DOM元素來渲染，在UI渲染上非常接近Native App。
2.React Native 與Native平臺(tái)通信
3.優(yōu)缺點(diǎn)分析
優(yōu)點(diǎn)
缺點(diǎn)
4.RN展望
雖然RN還存在不足，但RN新版本已經(jīng)做了如下改進(jìn)，并且RN團(tuán)隊(duì)也在積極準(zhǔn)備大版本重構(gòu)，能否成為開發(fā)者們所信賴的跨平臺(tái)方案，讓我們拭目以待。
既然React Native在渲染方面還擺脫不了原生，那有沒有一種方案是直接操控GPU，自制引擎渲染呢，我們終于迎來了Flutter！
四.Flutter
Flutter是Google開發(fā)的一套全新的跨平臺(tái)、開源UI框架，支持iOS、Android系統(tǒng)開發(fā)，并且是未來新操作系統(tǒng)Fuchsia的默認(rèn)開發(fā)套件。渲染引擎依靠跨平臺(tái)的Skia圖形庫來實(shí)現(xiàn)，依賴系統(tǒng)的只有圖形繪制相關(guān)的接口，可以在最大程度上保證不同平臺(tái)、不同設(shè)備的體驗(yàn)一致性，邏輯處理使用支持AOT的Dart語言，執(zhí)行效率也比JavaScript高得多。
1.Flutter架構(gòu)原理
2.Dart優(yōu)勢
很多人會(huì)好奇，為什么Flutter要用Dart，而不是用JavaScript開發(fā)，這里列下Dart的優(yōu)勢
3.優(yōu)缺點(diǎn)分析
優(yōu)點(diǎn)
缺點(diǎn)
getx可以做到通過頁面的退出自動(dòng)控制controller的銷毀，那么他是怎么做到的呢
當(dāng)我們使用getx的路由套件時(shí)，可以看到，他的每個(gè)跳轉(zhuǎn)方法都使用了自定義的 GetPageRoute 。
在 GetPageRoute 中對(duì)于此次的問題，我們需要關(guān)注的是兩個(gè)方法
嗯，這里給傳了一個(gè) reference 給了 Get.reference ，這個(gè) reference 看一下是什么玩意。。
dispose ，route退出流程里調(diào)用的方法。在這里面Get做了兩件事，我們主要關(guān)注第一件事， removeDependencyByRoute() 參數(shù)是上面的頁面標(biāo)識(shí)。
這個(gè)方法里，我們可以看到調(diào)用了 GetInstance 的 delete 方法，這個(gè)方法就是銷毀controller的方法，但是為什么呢？為啥傳一個(gè)頁面標(biāo)識(shí)就能刪除到對(duì)應(yīng)的controller呢。我們接著看
我們都知道我們?cè)谑褂胓etx的controller時(shí)，一定會(huì)有兩個(gè)操作，一個(gè)是 Get.put() ，一個(gè)是 Get.find() 讓我們一個(gè)一個(gè)的看一下
Get.put 的本質(zhì)其實(shí)是將我們傳入的實(shí)例，根據(jù)類 S 和 tag 創(chuàng)建一個(gè) key ，然后以key和實(shí)例作為鍵值對(duì)存入了全局的map中（此處是簡單理解，看也看得出來不是直接傳實(shí)例了）
Get.find 方法很簡單的只是通過類 S 和 tag 去全局map中找一個(gè)實(shí)例返回出去， 但是 返回之前，還做了一步操作，即 _initDependencies 。
看到?jīng)]，就在下面Get.reference，之前在GetPageRoute的頁面構(gòu)建之前賦值了最近的頁面，然后在此處用來做routesKey的value和前面的controller的key值進(jìn)行綁定。
這也是得益于flutter是個(gè)單線程模型，才能這樣無腦的通過這種方式傳值。其實(shí)getx中有不少讓人覺得神奇的地方都是利用了單線程的優(yōu)勢，比如Obx的自動(dòng)刷新，也是在Obx的build方法和Rx的value的get方法之間通過一個(gè)全局指針來進(jìn)行傳值。
重慶分公司
重慶分公司
