目錄：
一：背景介紹
二：Web體系下構(gòu)建小程序所帶來的頑疾
三：多進程運用
四：離線包技術(shù)
五：視圖層技術(shù)的演進--同層渲染
六：邏輯層技術(shù)的演進—雙線程模型
一：背景介紹
1.1、小程序的定義
??? 無需下載安裝即可使用的應用熔酷，它實現(xiàn)了應用觸手可及的夢想豺裆，用戶掃一掃或者搜索一下即可打開應用臭猜，也體現(xiàn)了用完即走的理念，用戶不用關(guān)心是否安裝太多應用的問題羹应，應用將無處不在量愧，隨時可用帅矗，但又無需安裝卸載。
??? 總結(jié)為：無需下載安裝累颂、觸手可及紊馏、用完即走蒲犬。
1.2原叮、手Q充當?shù)慕巧?/h4>
???? 手Q中可以運行各個第三開發(fā)商提供的小程序，在這個過程中擂送，手Q主要是充當宿主唯欣、容器境氢、載體的角色碰纬，提供給各個不同的小程序運行的環(huán)境嘀趟，手Q小程序功能模塊應該最大限度的保證各個小程序開發(fā)者只需要關(guān)注業(yè)務本身的功能她按，而涉及各個小程序的加載炕柔、更新、性能陵刹、啟動速度等體驗問題衰琐，這是需要手Q宿主重點解決的問題炼蹦。
1.3掐隐、小程序的運行機制
??? 小程序是基于WEB規(guī)范，采用HTML匿刮，CSS和JS等搭建的一套框架熟丸，但本質(zhì)上還是在整個WEB體系之下構(gòu)建的伪节。
二：Web體系下構(gòu)建小程序所帶來的頑疾
??? 在Android系統(tǒng)的開發(fā)中架馋，通常需要系統(tǒng)控件WebView實現(xiàn)前端頁面的加載，那小程序在基于web體系下構(gòu)建可能會產(chǎn)生什么問題，下面就匯總一下：
問題一：頁面加載速度慢
問題二：交互體驗沒有原生界面好
問題三：WebView控件加載小程序界面時屏鳍，占用內(nèi)存大
問題四：小程序的內(nèi)存泄露與小程序的相關(guān)Crash會影響手Q主進程
問題五：加載頁面依賴網(wǎng)絡钓瞭，網(wǎng)絡狀態(tài)差或弱網(wǎng)情況下，容易發(fā)生白屏堤结、卡頓等問題
問題六：加載頁面后鸭丛，無法有效規(guī)范鳞溉、約束和監(jiān)控頁面的行為（管控性和安全性）
? ? ? ?上面的列表匯總了在Web體系下構(gòu)建小程序所帶來的問題，那下面我們就來了解小程序SDK是如何通過技術(shù)手段最大限度的解決和優(yōu)化以上問題的看政。
三：多進程運用
3.1允蚣、手Q主進程對小程序的管理：預加載呆贿、分配榨崩、創(chuàng)建、銷毀翩剪、管控等
概述：由于進程之間的內(nèi)存無法共享彩郊，小程序的生命周期需要在某一個進程中維護前弯，不然無法做到動態(tài)分配進程和棧，而這個進程選擇手Q主進程最為合適秫逝，因此需要創(chuàng)建一個管理器恕出，這個管理器負責以下幾件事：
1、在空閑時預加載進程违帆。
2浙巫、根據(jù)設(shè)置的可開啟的最大小程序數(shù)量，對進程進行新建、銷毀等操作的畴。
3、合理的為接收到的請求分配空閑的進程丧裁。
4护桦、接收外界開啟、關(guān)閉等對小程序的操作煎娇。
5二庵、接收遠程小程序的生命周期回調(diào)并通過某個uuid進行維護。
6缓呛、所有這些管理和維護的操作催享，對小程序接入者都應是透明的，無需關(guān)心具體實現(xiàn)流程强经，僅在需要時開啟小程序即可睡陪。
3.2、進程間的通信
手Q宿主進程與小程序進程間通信圖解：
四：離線包技術(shù)
4.1匿情、離線包技術(shù)的引入
背景：在為什么要使用離線包之前兰迫，我們需要先了解一下加載一個前端頁面的過程：初始化webview
-> 請求頁面 -> 下載數(shù)據(jù) -> 解析HTML -> 請求js/css資源
-> dom渲染 -> 解析js執(zhí)行 -> js請求數(shù)據(jù) -> 解析渲染 -> 下載渲染圖片。
離線包的實現(xiàn)與優(yōu)勢：
解析：離線包是將包括HTML炬称，JavaScript汁果，css等頁面的內(nèi)置靜態(tài)資源打包到一個壓縮包內(nèi)，預先下載該離線包到本地, 然后客戶端將數(shù)據(jù)傳遞給頁面玲躯，通過webView加載展示据德，不需要網(wǎng)絡請求，webView只要渲染頁面跷车，執(zhí)行js即可棘利，解決html本身加載需要的時間問題，離線包基本思路通過webview統(tǒng)一攔截url,
將資源映射到本地離線包朽缴。
帶來的優(yōu)勢也是顯而易見的：
提升用戶體驗:
通過離線包的方式把頁面內(nèi)置靜態(tài)資源嵌入到應用中并發(fā)布善玫，當用戶第一次開啟應用的時候, 就無需以網(wǎng)絡環(huán)境下載該資源，而是馬上開始使用密强。
實現(xiàn)動態(tài)更新:
在推出新版本或是緊急發(fā)布的時候, 可以把修改的資源放入離線包, 通過更新配置讓應用自動下載更新茅郎，無需通過應用商店審核, 就讓用戶及時接收更新。
備注：離線包機制或渤，本質(zhì)上是通過空間換時間的技術(shù)實現(xiàn)用戶體驗的優(yōu)化系冗。
官方說明
概述：某些情況下，開發(fā)者需要將小程序劃分成不同的子包薪鹦，在構(gòu)建時打包成不同的分包掌敬，用戶在使用時按需進行加載。
??? 在構(gòu)建小程序分包項目時，構(gòu)建會輸出一個或多個分包涝开。每個使用分包小程序必定含有一個主包循帐。所謂的主包框仔，即放置默認啟動頁面/TabBar頁面舀武，以及一些所有分包都需用到公共資源/JS腳本；而分包則是根據(jù)開發(fā)者的配置進行劃分离斩。
???在小程序啟動時银舱，默認會下載主包并啟動主包內(nèi)頁面，當用戶用戶進入分包內(nèi)某個頁面時跛梗，客戶端會把對應分包下載下來寻馏，下載完成后再進行展示。
目前小程序分包大小有以下限制：
1核偿、整個小程序所有分包大小不超過24M
2诚欠、單個分包/主包大小不能超過2M
圖解：
備注：對小程序進行分包，可以優(yōu)化小程序首次啟動的下載時間漾岳，以及在多團隊共同開發(fā)時可以更好的解耦協(xié)作轰绵。
小程序更新機制
未啟動時更新
??? 客戶端運行時，會定期檢查最近使用的小程序是否有更新尼荆。如果有更新左腔，下次小程序啟動時會同步進行更新，更新到最新版本后再打開小程序捅儒，盡可能保證用戶能夠盡快使用小程序的最新版本液样，總的來說，開發(fā)者在后臺發(fā)布新版本之后巧还，無法立刻影響到所有現(xiàn)網(wǎng)用戶鞭莽，但最差情況下，也在發(fā)布之后24小時之內(nèi)覆蓋絕大多數(shù)用戶麸祷。
啟動時更新
??? 即使啟動前未發(fā)現(xiàn)更新澎怒，小程序每次冷啟動時，都會異步檢查是否有更新版本摇锋。如果發(fā)現(xiàn)有新版本丹拯，將會異步下載新版本的代碼包，但當次啟動仍會使用客戶端本地的舊版本代碼荸恕，即新版本的小程序需要等下一次冷啟動才會應用上乖酬，如果需要馬上應用最新版本，可以使用getUpdateManager相關(guān)API進行處理融求，圖例如下：
五：視圖層技術(shù)的演進--同層渲染
小程序視圖技術(shù)演進圖：
優(yōu)勢互補
???webview渲染的那一層和Native同時存在于一層咬像，優(yōu)勢互補，小程序則主要由成熟的Web技術(shù)渲染，輔之以大量的接口提供豐富的客戶端原生能力县昂，就是通過一定的技術(shù)手段把原生組件直接渲染到WebView層級上肮柜，此時原生組件層已經(jīng)不存在，原生組件此時已被直接掛載到WebView節(jié)點上倒彰，如下圖所示：
六：邏輯層技術(shù)的演進—雙線程模型
小程序邏輯層技術(shù)演進圖：
雙線程模型的引入???
???小程序應該像Web技術(shù)那樣审洞，有一份隨時可更新的資源包放在云端，通過下載到本地待讳，動態(tài)執(zhí)行后即可渲染出界面芒澜。但是，如果用純Web技術(shù)來渲染小程序创淡，在一些有復雜交互的頁面上可能會面臨一些性能問題痴晦，這是因為在Web技術(shù)中，UI渲染跟JavaScript的腳本執(zhí)行都在一個單線程中執(zhí)行琳彩，這就容易導致一些邏輯任務搶占UI渲染的資源誊酌。
??? 最終，小程序采用類似于微信JSSDK這樣的Hybrid技術(shù)露乏，即界面主要由成熟的Web技術(shù)渲染碧浊，輔之以大量的接口提供豐富的客戶端原生能力。同時施无，每個小程序頁面都是用不同的WebView 去渲染辉词，這樣可以提供更好的交互體驗，更貼近原生體驗猾骡，也避免了單個WebView的任務過于繁重瑞躺，小程序的雙線程模型示意圖：
