第一部分 預備知識

第1章 插件化技術的昨天、今天與明天

這是最好的時代，國內各大應用市場對插件化技術的態度是開放的，因此，國內各大互聯網App無一不有自己的插件化框架。有了開放的環境，才會有無數英雄大展身手，在Android插件化的領域中出現百家爭鳴、百花齊放的局面。

這是最壞的時代，隨著插件化技術在中國的普及，你會發現，去中國的各大互聯網公司面試，一般都會聊聊插件化的技術。這就使得開發人員要去了解Android底層的知識，這無形中增加了學習難度。

本章將介紹插件化的概念、歷史及應用，為后續學習插件化技術，提供基礎。

1.1 插件化技術是什么

一個游戲平臺，比如聯眾，支持上百種游戲，如象棋、橋牌、80分。一個包括所有游戲的游戲平臺往往有上百兆的體積，需要下載很卡時間，但是用戶往往只玩其中的1～2款游戲。讓用戶下載并不會去玩的上百款游戲，是不明智的做法。此外，任何一個游戲更新或者新上線一個游戲，都需要重新下載數百兆的安裝包，也會讓用戶抓狂。

所以，游戲平臺必然采用插件化技術。

通常的做法是，只讓用戶下載一個十幾兆大小的安裝包，其中只包括游戲大廳和一個全民類游戲，如“斗地主”。用戶進入游戲大廳，可以看到游戲清單，點擊“80分”就下載80分的游戲插件，點擊“中國象棋”就下載中國象棋的游戲插件，這稱為“按需下載”。這就需要插件化編程，不過這是基于電腦上的游戲平臺，是一個個exe可執行文件。

在Android領域，是沒有exe這種文件的。所有的文件都會被壓縮成一個apk文件，然后下載到本地。Android應用中所謂的安裝App的過程，其實就是把apk放到本地的一個目錄，然后使用PMS讀取其中的權限信息和四大組件信息。所以Android領域的插件化編程，與電腦上的軟件的插件化編程是不一樣的。

其實，在Android領域，對于游戲而言，用的還真不是插件化技術，而是從服務器動態下發腳本，根據腳本中的信息，修改人物屬性，增加道具和地圖。

Android插件化技術，主要用在新聞、電商、閱讀、出行、視頻、音樂等領域，比如說旅游類App，因為涉及下單和支付，所以算是電商的一個分支，旅游類App可以拆分出酒店、機票、火車票等完全獨立的插件。

1.2 為什么需要插件化

在那山的這邊海的那邊有一群程序員，

他們老實又胹腆，

他們聰明又有錢。

他們一天到晚坐在那里熬夜寫軟件，

餓了就咬一口方便面。

哦苦命的程序員，

哦苦命的程序員，

只要一改需求他們就要重新搞一遍，

但是期限只剩下兩天。

這首改編自《藍精靈》主題曲的《程序員之歌》，道出了中國互聯網行業的程序員現狀。

就在Android程序員瘋狂編寫新需求之際，自然會衍生出各種bug，甚至是崩潰。App有bug，會導致用戶下不了單，而一旦崩潰，那就連下單頁面都進不去，因此我們要在最短時間內修復這些問題，重新發版到Android各大市場已經來不及，每分每秒都在丟失生意，因此，Android插件化的意義就體現出來了，不需要用戶重新下載App，分分鐘就能享受到插件新的版本。

另一方面，如果要和競爭對手搶占市場，那么誰發布新功能越快越多，對市場對用戶的占有率就越高。如果隔三岔五就發布一個新版本到Android各大市場，那么用戶會不勝其煩，發版周期固定為半個月，又會導致新功能長期積壓，半個月后才能讓用戶見到，而競爭對手早就讓用戶在使用同樣的新功能了。這時候，如果有插件化技術支持，那么新功能就可以在做完之后立刻讓用戶看到，這可是讓競爭對手聞風喪膽的手段。

1.3 插件化技術的歷史

2012年7月27日，是Android插件化技術的第一個里程碑。大眾點評的屠毅敏（Github名為mmin18），發布了第一個Android插件化開源項目AndroidDynamicLoader，大眾點評的App就是基于這個框架來實現的。這是基于Fragment來實現的一個插件化框架。通過動態加載插件中的Fragement，來實現頁面的切換，而Activity作為Fragement的容器卻只有一個。我們也是在這個開源項目中第一次看到了如何通過反射調用AssetManger的addAssetPath方法來處理插件中的資源。

2013年，出現了23Code。23Code提供了一個殼，在這個殼里可以動態下載插件，然后動態運行。我們可以在殼外編寫各種各樣的控件，在這個框架下運行。這就是Android插件化技術。這個項目的作者和開源地址，我不是很清楚，如果作者恰巧讀到我這本書，請聯系我，咱們一起喝杯咖啡。

2013年3月27日，第16期阿里技術沙龍，淘寶客戶端的伯奎做了一個技術分享，專門講淘寶的Atlas插件化框架，包括ActivityThread那幾個類的Hook、增量更新、降級、兼容等技術。這個視頻，只是從宏觀來講插件化，具體怎么實現的并沒說，更沒有開源項目可以參考。時隔5年再看這個視頻，會覺得很簡單，但在2013年，這個思想還是很先進的，畢竟那時的我還處在Android入門階段。

2014年3月30日8點20分，是Android插件化的第二個里程碑。任玉剛開源了一個Android插件化項目dynamic-load-apk，這與后續介紹的很多插件化項目都不太一樣，它沒有對Android系統的底層方法進行Hook，而是從上層，也就是App應用層解決問題——通過創建一個ProxyActivity類，由它來進行分發，啟動相應的插件Activity。因為任玉剛在這個框架中發明了一個that關鍵字，所以我在本書中把它稱為that框架。其實作者不喜歡我給他的最愛起的這個外號，他一直稱之為DL。曾經和玉剛在一起吃飯聊天，他感慨當年如何舉步維艱地開發這個框架，因為2014年之前沒有太多的插件化技術資料可以參考。

that框架一開始只有Activity的插件化實現，后來隨著田嘯和宋思宇的加入，實現了Service的插件化。2015年4月that框架趨于穩定。那時我在途牛做App技術總監，無意中看到這個框架，毅然決定在途牛的App中引入that框架。具體實施的是汪亮亮和魏正斌，他們當時一個初為人父另一個即將為人父，還是咬牙把這個that框架移植到了途牛App中。that框架經受住了千萬級日活App的考驗，這是它落地的第一個實際項目。

與此同時，張濤也在研究插件化技術，并于2014年5月發布了他的第一個插件化框架CJFrameForAndroid。它的設計思想和that框架差不多，只是把ProxyActivity和ProxyService稱為托管所。此外，CJFrameFor-Android框架還給出了Activity的LaunchMode的解決方案，這是對插件化框架一個很重要的貢獻，可以直接移植到that框架中。

2014年11月，houkx在GitHub上發布了插件化項目android-pluginmgr，這個框架最早提出在AndroidManifest文件中注冊一個StubActivity來“欺騙AMS”，實際上卻打開插件中的ActivityA。但是作者并沒有使用對Instrumnetation和ActivityThread的技術進行Hook，而是通過dexmaker.jar這個工具動態生成StubActivity, StubActivity類繼承自插件中的ActivityA。現在看來，這種動態生成類的思想并不適用于插件化，但在當時能走到這一步已經很不容易了。

同時，houkx還發現，在插件中申請的權限無法生效，所以要事先在宿主App中申請所有的權限。android-pluginmgr有兩個分支——dev分支和master分支。作者的插件化思想位于dev分支。后來高中生Lody參與了這個開源項目，把android-pluginmgr設計為對Instrumnetation的思想進行Hook，體現在master分支上，但這已是2015年11月的事情了。

2014年12月8日有一個好消息，那就是Android Studio1.0版本出現了。Android開發人員開始逐步拋棄Eclipse，而投入Android Studio的懷抱。Android Studio借助于Gradle來編譯和打包，這就使插件化框架的設計變得簡單了許多，排除了之前Eclipse還要使用Ant來運行Android SDK的各種不便。

時間到了2015年。高中生Lody此刻還是高二學生。他是從初中開始研究Android系統源碼的。他的第一個著名的開源項目是TurboDex，能夠以迅雷不及掩耳之勢加載dex，這在插件化框架中尤其好用，因為首次加載所有的插件需要花很久的時間。

2015年3月底，Lody發布插件化項目Direct-Load-apk。這個框架結合了任玉剛的that框架的靜態代理思想和Houkx的pluginmgr框架的“欺騙AMS”的思想，并Hook了Instrumnetation。可惜Lody當時還是個學生，沒有花大力氣宣傳這個框架，以至于沒有太多的人知道這個框架的存在。Lody的傳奇還沒結束，后來他投身于VirtualApp，這是一個App，相當于Android系統之上的虛機，這是一個更深入的技術領域，我們稍后再提及。

2015年5月，limpoxe發布插件化框架Android-Plugin-Framework。

2015年7月，kaedea發布插件化框架android-dynamical-loading。

2015年8月27日，是Android插件化技術的第三個里程碑。張勇的DroidPlugin問世了。張勇當時在360的手機助手團隊，DroidPlugin就是手機助手使用的插件化框架。這個框架的神奇在于，能把任意的App都加載到宿主里面去。你可以基于這個框架寫一個宿主App，然后就可以把別人寫的App都當作插件來加載。

DroidPlugin的功能很強大，但強大的代價就是要Hook很多Android系統的底層代碼，而且張勇沒有給DroidPlugin項目加任何說明文檔，導致這個框架不太容易理解。網上有很多人寫文章研究DroidPlugin，但其中寫得最好的是田維術。他當時就在360，剛剛畢業轉正，寫出一系列介紹DroidPlugin思想的文章，包括Binder和AIDL的原理、Hook機制、四大組件的插件化機制等。

2015年是Android插件化蓬勃發展的一年，不光有that框架和DroidPlugin，很多插件化框架也在這個時候誕生。

OpenAtlas這個項目是2015年5月發布在Github上的，后來改名為ACDD。里面提出了通過修改并重新生成aapt命令，使得插件apk的資源id不再是固定的0x7f，可以修改為0x71這樣的值。這就解決了把插件資源合并到宿主HostApp資源后資源id沖突的問題。

OpenAtlas也是基于Hook Android底層Instrumentation的execStartActivity方法，來實現Activity的插件化。此外，OpenAltas還Hook了ContextWrapper，在其中重寫了getResource等方法，因為Activity是ContextWrapper的“孫子”，所以插件Activity就會繼承這些getResource方法，從而取到插件中的資源——這種做法現在已經不用了，我們是通過為插件Activity創建一個基類BasePluginActivity并在其中重寫getResource方法來實現插件資源加載的。

攜程于2015年10月開源了他們的插件化框架DynamicAPK，這是基于OpenAltas框架基礎之上，融入了攜程自己特殊的業務邏輯。

2015年12月底，林光亮的Small框架發布，他當時在福建一家二手車交易平臺，這個框架是為這個二手車平臺的App量身打造的，主要特點如下：

□ Small把插件的ClassLoader對應的dex文件，塞入到宿主HostApp的ClassLoader中，從而HostApp可以加載任意插件的任意類。

□ Small框架通過Hook Instrumentation來啟動插件的Activity，這一點和DroidPlugin相同，那么自然也會在AndroidManifest中聲明一個StubActivity，來“欺騙AMS”。

□ Small框架對其他三大組件的支持，需要提前在宿主HostApp的AndroidManifest中聲明插件的Service、Receiver和ContentProvider。

□ Small對資源的解決方案獨樹一幟。使用AssetManager的addAssetPath方法，把所有插件的資源都合并到宿主的資源中，這時候就會發生資源id沖突的問題。Small沒有采用Atlas修改AAPT的思路，而是在生成插件R.java和resources.arsc這兩個文件后，把插件R.java中所有資源的前綴從0x7f改為0x71這樣的值，同時也把resources.arsc中出現0x7f的地方也改為0x71。

隨著2015年的落幕，插件化技術所涉及的各種技術難點都已經有了一種甚至多種解決方案。在這一年，插件化技術領域呈現了百家爭鳴的繁榮態勢。這一時期以個人主導發明的插件化框架為主，基本上分為兩類——以張勇的DroidPlugin為代表的動態替換方案，以任玉剛的that框架為代表的靜態代理方案。

就在2015年，Android熱修復技術和React Native開始進入開發者的視線，與Android插件化技術平分秋色。Android插件化技術不再是開發人員唯一的選擇。

從2016年起，國內各大互聯網公司陸續開源了自己研發的插件化框架。這時候已經沒有什么新技術出現了，因為插件化所有的解決方案都已經在2015年由個人開發者給出來了。互聯網公司是驗證這些插件化技術是否可行的最好的平臺，因為他們的App擁有動輒千萬用戶的日活。

按時間順序列舉插件化框架如下：

2016年8月，掌閱推出Zeus。

2017年3月，阿里推出Atlas。

2017年6月26日，360手機衛士的RePlugin。

2017年6月29日，滴滴推出VisualApk。

仔細讀這些框架的源碼會發現，互聯網公司開源的這些框架更多關注于：

□ 插件的兼容性，包括Android系統的升級對插件化框架的影響，各個手機ROM的不同而對插件化的影響。

□ 插件的穩定性，比如各種奇葩的崩潰。

□ 對插件的管理，包括安裝和卸載。

斗轉星移，時光荏苒，雖然只有幾年時間，但各個插件化框架已經漸趨穩定，現在做插件化技術的開發人員，只需要關注每年Android系統版本的升級對自身框架的影響，以及如果消除這種影響。

隨著插件化領域的技術基本成型，我身邊很多做插件化的朋友都開始轉行，有的人還在Android這個領域，比如張勇基于他的DroidPlugin框架，在做他的創業項目閃電盒子；有的人轉入區塊鏈，每天沉浸于用GO語言寫智能合約。

謹以此文獻給那些在插件化領域中做出過貢獻的朋友們，包括開源框架的作者，以及寫文章傳經布道的作者。我的見識有限，有些人、有些框架、有些文章可能會沒有提及，歡迎廣大讀者多多指正。

1.4 插件化技術的用途到底是什么

我們曾經天真地認為，Android插件化是為了增加新功能，或者增加一個完整的模塊。費了不少時間和精力，等項目實施了插件化后，我們才發現，插件化80%的使用場景，是為了修復線上bug。在這一點上，插件化與Tinker、Robust這類熱修復工具擁有相同的能力，甚至比熱修復工具做得更好。

App每半個月發一次版，新功能上線，一般都會等這個時間點。另一方面，很多公司的Android發版策略是受iPhone新版本影響的，新功能要等兩個版本一起面世，那就只有等Apple Store審核通過iPhone的版本，Android才能發版。所以，真的不是那么著急。

在沒有插件化的年代，我們做開發都是戰戰兢兢的，生怕寫出什么bug，非常嚴重的話就要重新發版本。有了插件化框架，開發人員沒有了后顧之憂，于是App上線后，每個插件化，每天都會有一到兩個新版本發布。Android插件化框架，已經淪落為bug修復的工具。這是我們不愿看到的場景。

其實，插件化框架更適合于游戲領域。比如王者榮耀，經常都會有新皮膚，或者隔幾天上線一個新英雄，調整一下英雄的數據，這些都不需要重新發版。

插件化還有一種很好的使用場景，那就是ABTest，只是沒有深入人心罷了。當產品經理為兩種風格的設計舉棋不定時，那么把這兩種策略做成兩個插件包，讓50%的用戶下載A策略，另外50%的用戶下載B策略，一周后看數據，比如說頁面轉化率，就知道哪種策略更優了。這就是數據驅動產品。

隨著業務線的獨立，Android和iOS團隊拆分到各自的業務線，有各自的匯報關系，因此有必要把酒店機票火車票這些不同的業務拆分成不同的模塊。在Android組件化中，模塊之間還是以aar的方式進行依賴的，所以我們可以借助Maven來管理這些aar。

Android的這種組件化模型，僅適用于開發階段，一旦線上有了bug，或者要發布新功能，那就需要將所有模塊重新打包一起發布新版本。

Android組件化再往前走一步，就是插件化。此時，各個業務模塊提供的就不再是aar了，而是一個打包好的apk文件，放在宿主App的assets目錄下。這樣，發版后，某個模塊有更新，只需重新打包這個模塊的代碼，生成增量包，放到服務器上供用戶下載就可以了。這才是Android插件化在企業級開發中的價值所在。一般的小公司只做了Android組件化，沒有做插件化，所以體會不到這個好處，這是因為插件化開發成本很高，投入產出比很低。

1.5 更好的替代品：React Native

2015年，React Native（RN）橫空出世，當時并沒有多少人關注它，因為它還很不成熟，甚至連基本的控件都沒幾個。后來隨著RN項目的迭代，功能日趨完善，雖然迄今為止還沒有一個1.0的release版本，我們還是欣喜地發現，這個東西就是Android和iOS的插件化啊。

外國人和中國人的思路不一樣。就好像國際象棋與中國象棋不一樣。當我們投入大量人力去鉆研怎么Hook Android系統源碼的時候，外國人走的是另一條路，那就是映射，讓Android或iOS中的每個控件，在RN中都能找到相對應的控件。RN是基于JavaScript代碼來編寫的，打包后放到服務器，供Android和iOS的App下載并使用。

RN比Android插件化更好的地方在于它還支持iOS，因此最大程度地實現了跨平臺。于是當我們一廂情愿地以為Android插件化多么好用，而對iOS如何發布新功能一籌莫展時，便有了RN這個更好的選擇。至于性能，二者差別不大，RN在iOS和Android上都很流暢，這一點不用擔心。

對于中小型公司和創業公司而言，缺少人力和財力自己研制一套插件化框架，一般就采用國內比較穩定的、開源的、持續更新的插件化框架。但iOS沒有這方面的技術框架，尤其是在jsPatch熱修復被AppStore明令禁止了之后，最好的選擇就是RN。只要招聘做JavaScript前端的技術人員，就能快速迭代、快速上線了，完全不受發版的限制。我是從研發的崗位走出來，在國內做了兩年培訓，全國各地走了上百家公司，包括大型國企、二三線互聯網公司、傳統行業，我發現國內90%的公司都屬于這種類型，國內對RN的需求遠大于Android插件化。

關于RN的話題，至少要一本書才能說清楚。本書主要介紹Android插件化，這里只指出Android插件化不如RN的地方。

1.6 只有中國這么玩嗎

有讀者會問，Android插件化在中國如火如荼，為什么在國外卻悄無聲息？打開硅谷那些獨角獸的App，都沒有發現插件化的影子。

一方面原因是，國外人都使用Google Play，這個官方市場不允許插件化App的存在，審核會不通過，這就很像Apple Store了。

另一方面原因是，國外沒有這樣的需求。所以當你發現國外某款App顯示數據錯誤了，或者莫名其妙崩潰了，就算你反饋給他們，得到的也是一副坐看閑云、寵辱不驚的回復——下個版本再修復吧。下個版本什么時候？一個月后。

這就和中國國內的App境遇不同了。在互聯網公司，特別是有銷售業務的公司，任何數據顯示的錯誤或者崩潰，都會導致訂單數量的下降，直接影響的是錢啊。所以，我經常半夜被叫醒去修bug，然后快速出新版本的插件包，避免更多訂單的損失。

國內的一二線互聯網公司，會花很多錢雇傭一群做插件化框架的人，框架設計完，他們一般會比較閑。在Android每年發布新版本的時候，他們會很忙，去研究新版本改動了哪些Android系統源碼，會對自家公司的插件化框架有什么影響。從長期來看，公司花的這些錢是劃算的，基本等于沒有插件化而損失的訂單數量的價值。

而國內的中小型公司以及創業公司，沒有額外的財力來做自己的插件化框架，一般就采用國內比較穩定的、開源插件化框架。后來有了RN，就轉投RN的懷抱了。

就在中國的各路牛人紛紛推出自家的Android插件化框架之際，國外的技術人員在研究些什么呢？

國外的技術人員比較關注用戶體驗，所以在國外Material Design大行其道，而在中國，基本是設計師只設計出iOS的樣稿，Android保持做的一樣就夠了。國外的技術人員比較關注函數式編程，追求代碼的優雅、實用、健壯、復用，而不像國內的App，為了趕進度超越競爭對手，純靠人力堆砌代碼，甚至帶bug上線，以后有時間了再進行重構，而那時當初寫代碼的人也許已經離職了。

所以，當硅谷那邊層出不窮地推出ButterKnife、Dagger、OKHttp、Retrofit、RxJava的時候，國內能拿出來與之媲美的只有各種插件化框架和熱修復框架，以及雙開技術。

1.7 四大組件都需要插件化技術嗎

在Android中，Activity、Service、ContentProvider和BroadcastReceiver并稱為四大組件。四大組件都需要插件化嗎？這些年，我是一直帶著這個問題做插件化技術的。

我所工作過的幾家公司都屬于OTA（在線旅游）行業。這類App類似于電商，包括完整的一套下單支付流程，用得最多的是Activity，達數百個；Service和Receiver用得很少，屈指可數；ContentProvider根本就沒用過。

國內大部分App都是如此。根據技術棧來劃分App行業：

□ 游戲類App，有一套自己的在線更新流程，很多用的是Lua之類的腳本。

□ 手機助手、手機衛士，這類App對Service、Receiver、ContentProvider的使用比較多。所以四大組件的插件化都必須實現。

□ 音樂類、視頻類、直播類App，除了使用比較多的Activity，對Service和Receiver的依賴很強。

□ 電商類、社交類、新聞類、閱讀類App，基本是Activity，其他三大組件使用不是很多，可以只考慮對Activity插件化的支持。

我們應該根據App對四大組件的依賴程度，來選擇合適的插件化技術。四大組件全都實現插件化固然是最好的，但是如果App中主要是Activity，那么選擇靜態代理that框架就夠了。

1.8 雙開和虛擬機

既然插件化會慢慢被RN所取代，那么插件化的未來是什么？答案是，虛擬機技術。

各位讀者應該有過在PC機上安裝虛擬機的經歷。只要電腦的內存足夠大，那么就可以同時打開多個虛擬機，在每個虛擬機上都安裝QQ軟件，使用不同的賬號登錄，然后自己跟自己聊天。

在Android系統上，是否也能支持安裝一個或多個虛擬機呢？國內已經有人在做了，我所知道的，一個是高中生Lody（當你閱讀這本書的時候，他應該已經是大學生了吧），他有一個很著名的開源項目VirtualApp，這個項目現在已經商業化運作了。另一個是DroidPlugin的作者張勇，他現在創業專職做這個，在DroidPlugin的基礎上研發了閃電盒子，可以極速加載各種apk。

有了這樣一個虛擬機系統，我們就可以在手機上打開兩個不同賬號的QQ，自己和自己聊天了。

我們稱同時打開一個App的多個分身的技術叫“雙開”。現在國內有些手機系統已經支持雙開技術了，可以在設置中看到這一選項。

關于雙開和虛擬機的技術，我們就介紹這么多，畢竟這已經不是本書所涉及的技術范疇了。

1.9 從原生頁面到HTML 5的過渡

無線技術越來越成熟，已經從2012年時的初步開荒，發展到現在的蔚為壯觀。對于國人來說，我們比較關注的是：熱修復、性能、開發效率、App體積、數據驅動產品。這些點目前都已經有了很好的解決方案，也涌現出RxJava、LeakCanary這樣優秀的框架。這個話題很大，本文就不展開說了。

由App技術的無比繁榮，回想起我2004年剛工作的時候，IT行業正從CS（Service-Client）轉型為BS（Browser-Server）。2004年之前大都是CS這樣的軟件，比如Windows上安裝一個聯眾的客戶端就可以和網友斗地主了，后來互聯網的技術成熟起來了，就把原先的系統都搬到網站上，這就是BS。

后來BS做多了，大家覺得BS太“單薄”，很多功能不支持，不如CS，于是就提出SmartClient的概念，也就是智能客戶端，Outlook就是一個很好的例子，你可以脫機讀和寫郵件，沒網絡也可以，什么時候有網絡了，再將寫好的郵件發送出去。

再后來Flash火起來了，這個本來是網頁制作工具三劍客之一，卻陰差陽錯地成為了網頁富客戶端的鼻祖。在此基礎上便有了Flex，現在還有些公司在使用。微軟這時候提出了Silverlight，是搭載在網頁上的。與此同時，JavaScript也在發力，并逐漸取代前者，成為富客戶端的最后贏家，那時候《JavaScript設計模式》一書非常暢銷。

JavaScript在2004年僅是用來做網頁特效的。時至今日，我們發現，JavaScript經歷了Ajax、jQuery、ECMAScript從1到6、Webpack打包，以及Angular、React、Vue三大主流框架，已經變得無比強大，被封裝成一門“面向對象”的語言了。

前面鋪墊了那么多，就是想說明App也在走同樣的發展道路，先沉淀幾年，把網站的很多技術都搬到App上，也就是目前的發展階段，差不多該有的也都有了。下一個階段就是從CS過渡到BS, Hybird技術就類似于BS，但是有很多缺陷，尤其是Web Browser性能很差，然后便出現了React Native, HTML 5很慢，但可以把HTML 5翻譯成原生的代碼啊。再往前發展是什么樣，我不知道，但是這個發展方向是很清晰的。一方面，Android和iOS技術不會消亡；另一方面HTML 5將慢慢成為App開發的主流。

1.10 本章小結

本章回顧了Android插件化技術的發展歷史，基本上分為兩大流派：靜態代理和動態替換，所有的插件化框架都基于此。看完這段歷史你會發現，這門技術也不是一蹴而就的，期間也經歷了從無到有，以及逐步完善的過程。

插件化技術不僅僅用于修復bug和動態發布新功能，我們在研究插件化技術的過程中，順帶開發出了Android虛擬機和雙開技術，這是一個新的技術領域，可以擺脫Android原生系統的束縛，更快地運行App。

本章還談到了ReactNative，它也能修復bug和動態發布新功能，和Android插件化有異曲同工之妙。具體該采用哪門技術，取決于研發團隊以H5為主還是以Android為主，取決于是否要發布到Google Play。