android插件化簡述

2015年是Android插件化技術日新月異的一年，隨着業務的發展各大廠商都碰到了Android Native平臺的瓶頸：

1. 從技術上講，業務邏輯的複雜致使代碼量急劇膨脹，各大廠商陸續出到65535方法數的天花板；同時，運營爲王的時代對於模塊熱更新提出了更高的要求。
2. 在業務層面上，功能模塊的解耦以及維護團隊的分離也是大勢所趨；各個團隊維護着同一個App的不一樣模塊，若是每一個模塊升級新功能都須要對整個app進行升級，那麼發佈流程不只複雜並且效率低下；在講究小步快跑和持續迭代的移動互聯網必將遭到淘汰。

H5和Hybird能夠解決這些問題，可是始終比不上native的用戶體驗；因而，國外的FaceBook推出了react-native；而國內各大廠商幾乎都選擇純native的插件化技術。能夠說，Android的將來必將是react-native和插件化的天下。

react-native資料不少，可是講述插件化的卻鳳毛菱角；插件化技術聽起來高深莫測，實際上要解決的就是兩個問題：

1. 代碼加載
2. 資源加載

代碼加載

類的加載可使用Java的ClassLoader機制，可是對於Android來講，並非說類加載進來就能夠用了，不少組件都是有「生命」的；所以對於這些有血有肉的類，必須給它們注入活力，也就是所謂的組件生命週期管理；

另外，如何管理加載進來的類也是一個問題。假設多個插件依賴了相同的類，是抽取公共依賴進行管理仍是插件單獨依賴？這就是ClassLoader的管理問題；

資源加載

資源加載方案你們使用的原理都差很少，都是用AssetManager的隱藏方法addAssetPath；可是，不一樣插件的資源如何管理？是公用一套資源仍是插件獨立資源？共用資源如何避免資源衝突？對於資源加載，有的方案共用一套資源並採用資源分段機制解決衝突（要麼修改aapt要麼添加編譯插件）；有的方案選擇獨立資源，不一樣插件管理本身的資源。

目前國內開源的較成熟的插件方案有DL和DroidPlugin；可是DL方案僅僅對Frameworl的表層作了處理，嚴重依賴that語法，編寫插件代碼和主程序代碼需單獨區分；而DroidPlugin經過Hook加強了Framework層的不少系統服務，開發插件就跟開發獨立app差很少；就拿Activity生命週期的管理來講，DL的代理方式就像是牽線木偶，插件只不過是操縱傀儡而已；而DroidPlugin則是借屍還魂，插件是有血有肉的系統管理的真正組件；DroidPlugin Hook了系統幾乎全部的Sevice，欺騙了大部分的系統API；掌握這個Hook過程須要掌握不少系統原理，所以學習DroidPlugin對於整個Android FrameWork層大有裨益。

接下來的一系列文章將以DroidPlugin爲例講解插件框架的原理，揭開插件化的神祕面紗；同時還能幫助深刻理解Android Framewrok；主要內容以下：

• Hook機制之動態代理
• Hook機制之Binder Hook
• Hook機制之AMS&PMS
• Activity生命週期管理
• 插件加載機制
• 廣播的管理方式
• Service的插件化
• ContentProvider的插件化
• DroidPlugin插件通訊機制
• 插件機制之資源管理
• 不一樣插件框架方案對比
• 插件化的將來