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插件通讯机制
• 插件机制之资源管理
• 不一样插件框架方案对比
• 插件化的将来