随着Android生态,技术愈来愈成熟,目前市场不少Android的项目工程很大,团队人数多,慢慢衍生出了许多组件化插件化技术。android
同时也由于Android安装包apk也在逐渐增大,每次发布,用户更新apk环境复杂,若是全量更新下载apk的话在使用流量状况下,网络环境很差等等,对于用户体验是很是很差的。git
组件化 : 把经常使用的模块代码,抽取lib工程或者jar达到复用的效果。github
插件化:目的是把须要实现的模块或功能当作一个独立的提取出来,减小宿主的规模,当须要使用到相应的功能时再去加载相应的模块。涉及动态代理,ClassLoader,以及另外一个apk资源的加载。例如:360的DroidPlugin (推荐)服务器
热修复:每每是从修复bug的角度出发,强调的是在不须要二次安装应用的前提下修复已知的bug(涉及关键词:Hook技术、动态代理等)。例如:阿里 AndFix。网络
增量更新:APK增量更新是不少大厂APP采用的技术。bsdiff库生成补丁文件方式下载跟旧版本APK合成生成新版APK的原理(ligbspatch.so)。手机游戏app增量更新使用较多。例如:SmartAppUpdatesapp
bsdiff生成patch -> bzip2压缩 -> android下载patch -> bzip2解压patch -> bspatch合并patch -> 新的apk组件化
bsdiff并非专门为apk增量更新设计的,它能够对任何二进制文件进行差分和合并。编码
bzip2的功能是利用哈夫曼编码对文件进行无损压缩(将差分包进行压缩便于网络传输)和解压。spa
流程:.net
bsdiff 生成patch包 命令:bsdiff oldfile newfile patchfile
例如: bsdiff xx_v1.0.apk xx_v2.0.apk xx.patch
bspatch生成新的APK: 命令: bspatch oldfile newfile patchfile
例如: bsdiff xx_v1.0.apk xx_v2.0.apk xx.patch
增量升级并不是天衣无缝的升级方式,至少存在如下两点不足:
增量升级是以两个应用版本之间的差别来生成补丁的,你没法保证用户每次的及时升级到最新,因此你必须对你所发布的每个版本都和最新的版本做差分,以便使全部版本的用户均可以差分升级,这样操做相对于原来的整包升级较为繁琐,不过能够经过自动化的脚本批量生成。
增量升级成功的前提是,用户手机端必须有可以让你拷贝出来且与你服务器用于差分的版本一致的apk,这样就存在,例如,系统内置的apk没法获取到,没法进行增量升级;对于某些与你差分版本一致,可是内容有过修改的(好比破解版apk),这样也是没法进行增量升级的,为了防止合成补丁错误,最好经过md5 或者其余方式对patch包进行完整性的校验。