做者 苍王 日期 2018.8.14java
近来创建了两个小专栏,将会其中发布如今的区块链通信项目所应用到的技术,以及进程化技术,有兴趣能够关注一下(不必定需订阅,推广期价钱也便宜)。android
[Android IM技术指南] 里面介绍的是加密IM的技术应用和指南git
[Android 进程化架构] 里面介绍的是进程化的方案。github
在上一节中介绍了一些Android App Bundle的特性和须要注意的地方,属于组件化开发技术,这节要介绍的是AAB插件化技术。json
这是将来的倾向,极可能将会国内大厂提供这样的服务来引导插件升级流程。 对比一下普通组件化架构和AAB的架构。 架构
能够看出,AAB的架构比普通组件化架构少了应用层,原来在应用层的逻辑被转移到基础层中了。 在基础层作dex加载,res加载,lib加载,以及Activity启动跳转分发等功能。app
以前咱们说过AAB的架构很是适合作热修复热补丁的功能,是由于其包体细小,而且功能单一,而且google已经规划了升级流程了。框架
那么有没办法使用AAB作热更新的功能呢? 画黑板的时间到了。 上一节中说起到若是模块数量变动以及四大组件有变动的时候将须要从新将大版本更新到google市场。 其实正确的说是,模块数量变化,以及AndroidMainfest有变动的时候(四大组件,权限申请变动)须要从新更新到google市场。 而咱们的目标是不须要从新更新整个包体到google市场,要求用户强制升级整个包体,而是作到部分静默升级(这才是热更新)。 为了规避这些限制,那么就创建module的时候规范规则。ide
2.Common层,有一个到两个module应该就足够了,放一些公用资源和View,小型的so文件,公用信息类和通讯框架,应该是足够的。组件化
3.一个module只有一个Activity或以Fragment为基础,再也不新增Activity页面,若是新增Activity至关于新增一个module的业务。 若是一个业务有多个页面,那就选用Fragment显示,很早之前就有大神提出单Activity多Fragment方案(Fragmentation),google今年发布新的组件Navigattion组件,这个亲测能用,可是fragment必定要声明全路径(包名+类名),还不是正式版,因此你们懂的。也能够选用单Activity多View架构(Conductor)
4.权限的声明,基础组件的权限仍是放到Common层中申请和处理。可是添加权限声明,至关于更改AndroidManifest,那么将须要从新发版,若是埋点的时候请慎重。
5.dynamic module和 application module的包名请使用同一个,否则会出现类引用不到的问题(估计是有验证)
6.请尽可能在Application初始化的时候使用SplitInstallManagerFactory加载dynamic module,若是页面中有使用Activity或者View没在初始化的状态会由于引用不到而奔溃的。请必定要保证加载dynamic module,再去跳转,加载module后有success的回调的。
7.主页固然是放到Application module中,保证必定能加载主页显示。资源使用反射,activity、service跳转前请必定要使用判空,由于一旦跳转不到就会崩溃。
8.dynamic module生成的apk,请尽可能保证在10M一下,升级能够作到静默升级,超过10M,须要提示下载。dynamic module是支持应用内移除和添加的,应用跳转前能够加入loading,保持友好的响应。
9.若是使用ARouter,应该能够正常跳转,可是移除跳转类,那么将会出现ARouter的toast提示。
10.dynamic module,只是延迟下载。如何配置动态加载,那么就须要经过修改common中的配置了,你可使用json脚本配置,也能使用SharePreference来记录开关状态来完成。
11.能够提早创建多个module做为埋点,只要使用同样的架构来填充业务代码就能够运行。固然代码更改,请尽可能有效的控制,通常的交互尽可能控制在一两个module中,这样更新量将会减小,否则静默升级将不稳定。
12.需不须要每一个module都申请Service呢?其实这里能够折中的方法,先使用common module中预先埋一两个service,必要时做为代码填写处理。而后发新版的时候,再将代码转移到对应的业务中。contentProvider也如此。
13.还有一个须要考究的问题,就是混淆保持的问题。
天星技术团QQ:557247785。