在Android开发中,插件化和热修复的话题越来越多的被大家提及,同时随着技术的迭代,各种框架的发展更新,插件化和热修复的框架似乎已经日趋成熟,许多开发者也把这两项技术运用到实际开发协作和正式的产品当中。因此,我们势必需要了解一下这两门技术。
首先需要明确的一点,插件化和热修复不是同一个概念,虽然站在技术实现的角度来说,他们都是从系统加载器的角度出发,无论是采用hook方式,亦或是代理方式或者是其他底层实现,都是通过“欺骗”Android 系统的方式来让宿主正常的加载和运行插件(补丁)中的内容;但是二者的出发点是不同的。插件化顾名思义,更多是想把需要实现的模块或功能当做一个独立的提取出来,减少宿主的规模,当需要使用到相应的功能时再去加载相应的模块。热修复则往往是从修复bug的角度出发,强调的是在不需要二次安装应用的前提下修复已知的bug。
为了方便叙述,做以下称谓约定:
宿主: 就是当前运行的APP
插件: 相对于插件化技术来说,就是要加载运行的apk类文件
补丁: 相对于热修复技术来说,就是要加载运行的.patch,.dex,*.apk等一系列包含dex修复内容的文件。
以下提到内容中的宿主和插件(补丁),均是上述含义,不再赘述。
Android插件化技术的典型应用上图就是对Android插件化和热修复之间关系的体现。据我所知,在某些开发团队中,会把热修复的技术,作为在APP端部署日常活动的功能来用。虽然,实际效果来看是没有问题的,但长期使用还是值得商榷的。
早期很多应用的动态换肤功能,就是参考了Android 插件化的技术,最早的新浪微博夜间模式就是通过下载一个夜间模式的apk文件完成,当时做为开发者的自己,感觉很高级。关于动态加载的应用,其实有很多可以扩展的思路,比如特定节日的促销活动,逃避审核机制的动态广告加载都是Android插件化技术可以考虑的实现,更多内容可以参考Android动态加载技术 简单易懂的介绍方式
下面就从插件化技术的发展源头,逐步叙述一下二者的发展历程及现状,了解一下时至今日,热修复框架的发展到了各种地步,总体梳理一下热修复的原理,对现有的框架有一个了解。
关于插件化技术的起源可以追溯到5年前
相较于插件化,热修复技术的使用更加的频繁,因为这项技术切实关切到我们实际开发的产品,能够更快速更便捷的修复线上bug,才能带来更好的用户体验。因此下面就结合热修复的原理了解一下热修复的使用及发展现状。
- public BaseDexClassLoader(String dexPath, File optimizedDirectory,
- String libraryPath, ClassLoader parent) {
- super(parent);
- this.pathList = new DexPathList(this, dexPath, libraryPath, optimizedDirectory);
- }
来源: https://juejin.im/entry/5a1d8d6351882546d71f1680