概要
2015年是Android插件化技术突飞猛进的一年,随着业务的发展各大厂商都碰到了Android Native平台的瓶颈:
- 从技术上讲,业务逻辑的复杂导致代码量急剧膨胀,各大厂商陆续出到65535方法数的天花板;同时,运营为王的时代对于模块热更新提出了更高的要求。
- 在业务层面上,功能模块的解耦以及维护团队的分离也是大势所趋;各个团队维护着同一个App的不同模块,如果每个模块升级新功能都需要对整个app进行升级,那么发布流程不仅复杂而且效率低下;在讲究小步快跑和持续迭代的移动互联网必将遭到淘汰。
H5和Hybird可以解决这些问题,但是始终比不上native的用户体验;于是,国外的FaceBook推出了react-native;而国内各大厂商几乎都选择纯native的插件化技术。可以说,Android的未来必将是react-native和插件化的天下。
欢迎加入Android开发技术交流QQ群:862625886,本群可免费获取Gradle、RxJava、小程序、Hybrid、移动架构、NDK、React Native、性能优化等技术教程!
react-native资料很多,但是讲述插件化的却凤毛菱角;插件化技术听起来高深莫测,实际上要解决的就是两个问题:
- 代码加载
- 资源加载
代码加载
类的加载可以使用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层大有裨益。
为什么要插件化?
功能越来越多
代码、安装包越来越大
小的更新也需要重新发布
更新频繁,安装成本太大
用户无法选择性加载需要的模块
……
插件化的好处
主安装包较小
强制模块化,降低耦合度
减少整体更新的次数
插件可单独静默更新
用户可以有所选择
……
插件化的要求
没有独立运行的入口
主应用控制,下载、安装、删除、静默升级、打开和关闭
主应用和插件资源共享
需要安装的插件
对比一个安装包的组成,我们要处理的东西也就是很多:
1.主应用可以以Intent方式启动具体的插件,同时带入Map类型参数或者json串参数
2.使用相同的android:sharedUserId,资源数据共享
3.根据sharedUserId来查找插件
4.queryIntentActivities查找符合这个action的所有activity(或其它)即插件
5.query方式可以获得插件的路径以及实现接口类的类名
6.通过检索sharedUserId能够得到路径却无法获得到类名
7.通常可以使用一个描述文件(xml、json)描述插件结构
8.createPackageContext()
9.getResourcesForApplication()
欢迎加入Android开发技术交流QQ群:862625886,本群可免费获取Gradle、RxJava、小程序、Hybrid、移动架构、NDK、React Native、性能优化等技术教程!