原文地址:understand-plugin-framework
2015年是Android插件化技術突飛猛進的一年珠月，隨著業(yè)務的發(fā)展各大廠商都碰到了Android Native平臺的瓶頸：
從技術上講，業(yè)務邏輯的復雜導致代碼量急劇膨脹楔敌，各大廠商陸續(xù)出到65535方法數(shù)的天花板啤挎；同時，運營為王的時代對于模塊熱更新提出了更高的要求卵凑。
在業(yè)務層面上庆聘，功能模塊的解耦以及維護團隊的分離也是大勢所趨；各個團隊維護著同一個App的不同模塊勺卢，如果每個模塊升級新功能都需要對整個app進行升級伙判，那么發(fā)布流程不僅復雜而且效率低下；在講究小步快跑和持續(xù)迭代的移動互聯(lián)網(wǎng)必將遭到淘汰黑忱。
H5和Hybird可以解決這些問題宴抚，但是始終比不上native的用戶體驗；于是甫煞，國外的FaceBook推出了react-native菇曲；而國內(nèi)各大廠商幾乎都選擇純native的插件化技術∥Ｊ可以說羊娃，Android的未來必將是react-native和插件化的天下。
react-native資料很多埃跷，但是講述插件化的卻鳳毛菱角蕊玷；插件化技術聽起來高深莫測，實際上要解決的就是兩個問題：
代碼加載
資源加載
代碼加載
類的加載可以使用Java的ClassLoader機制弥雹，但是對于Android來說垃帅，并不是說類加載進來就可以用了，很多組件都是有“生命”的剪勿；因此對于這些有血有肉的類贸诚，必須給它們注入活力，也就是所謂的組件生命周期管理；
另外酱固，如何管理加載進來的類也是一個問題械念。假設多個插件依賴了相同的類，是抽取公共依賴進行管理還是插件單獨依賴龄减？這就是ClassLoader的管理問題；
資源加載
資源加載方案大家使用的原理都差不多班眯，都是用AssetManager的隱藏方法addAssetPath；但是署隘，不同插件的資源如何管理？是公用一套資源還是插件獨立資源磁餐？共用資源如何避免資源沖突？對于資源加載诊霹，有的方案共用一套資源并采用資源分段機制解決沖突（要么修改aapt要么添加編譯插件）亦歉；有的方案選擇獨立資源畅哑，不同插件管理自己的資源荠呐。
目前國內(nèi)開源的較成熟的插件方案有DL和DroidPlugin；但是DL方案僅僅對Frameworl的表層做了處理砂客，嚴重依賴that語法，編寫插件代碼和主程序代碼需單獨區(qū)分鞠值；而DroidPlugin通過Hook增強了Framework層的很多系統(tǒng)服務，開發(fā)插件就跟開發(fā)獨立app差不多彤恶；就拿Activity生命周期的管理來說，DL的代理方式就像是牽線木偶声离，插件只不過是操縱傀儡而已芒炼；而DroidPlugin則是借尸還魂术徊，插件是有血有肉的系統(tǒng)管理的真正組件本刽；DroidPlugin Hook了系統(tǒng)幾乎所有的Sevice，欺騙了大部分的系統(tǒng)API；掌握這個Hook過程需要掌握很多系統(tǒng)原理子寓，因此學習DroidPlugin對于整個Android FrameWork層大有裨益暗挑。
接下來的一系列文章將以DroidPlugin為例講解插件框架的原理，揭開插件化的神秘面紗斜友；同時還能幫助深入理解Android Framewrok炸裆；主要內(nèi)容如下：
插件的廣播機制，靜態(tài)廣播非靜態(tài)
Service組件的管理蝙寨，占坑和Hook
ContentProvider的管理
插件加載解析之自定義包管理服務(PackageManager)
插件進程管理機制（ActivityMAnager）
插件機制之資源管理
DroidPlugin插件通信機制
DroidPlugin框架缺陷
不同插件框架方案對比
插件化的未來
另外晒衩，對于每一章內(nèi)容都會有詳細的demo，具體見understand-plugin-framework墙歪；喜歡就點個關注吧～定期更新，敬請期待虹菲！
