Android插件化与热修复(一)

Android插件化与热修复简介

第一部分概述
1.概述
2.技术难点
第二部分插件化
3.DynamicApk-携程
4.DroidPlugin-360手机助手
第三部分热修复
5.HotFix-QQ空间
6.AndFix-支付宝
7.Tinker-微信

1.概述

• android插件化技术在14年的时候就已经开始有人研究和使用了，客户端这种插件化的技术也不是在Android端才兴起的，这个在PC客户端时代就已经有很成熟的思想和思路。android客户端的技术有很多都可以从PC客户端中吸取和吸纳过来。来增强android客户端的开发技术和思路。
• 研究热补丁技术目前国内的技术处于领先的地位，其他国家还没有对这方面进行研究。当然与Google市场在中国网络不通是有一定关系的。国内的应用市场有很多家，对app的管理上也没有google那边那么严格。热补丁和插件化技术在两三年的时间就从技术难点攻克到趋于成熟，大部分用户量大的APP都会考虑使用热补丁或者插件化技术。或者用于不发版修复线上问题，或者在线上发布增量功能，或者改进多部门协作，或者对app架构进行改造，都有其用武之地。新技术的研究和使用，会花费很多的人力和财力去研究去推广，代价是很大的，当然收益也是成倍增长的。
• 一般将这个技术分为两种使用方式，一种是热修复技术，修复线上bug，并不能动态添加功能。例如Tinker。还有另外一种就是插件化技术，可以动态的添加功能到客户端，例如DroidPlugin。当然还有其他的变种形式，综合两种技术适用自己的APP开发。
• 热修复的方式一般有两种：方法级别的替换，如：Andfix就是典型的例子。还有类级别的替换，如：Hotfix就是典型的例子。
• 热补丁和插件化技术是有很多技术难点的。例如：如何将程序代码加入到已经安装在用户手机中的APP运行，如何加载图片、布局文件等资源文件，如何加载so文件，还有AndroidManifest.xml在安装到客户手机中之后就无法在往这里边加入东西的问题。这些技术在不断的演进过程中被逐个攻破。

下面就介绍几个主流的插件化和热修复方案。这篇文章只做简要的概述，后续会有针对360DroidPlugin和微信Tinker的介绍。

参考：

热补丁技术解析： http://blog.csdn.net/jiangwei0910410003/article/details/48104581

2.技术难点

• 从最初的开发功能，每次都需要全量发布APK开始。很多人都会去想android发布程序是否可以不发布版本，动态的加入一些功能，像web一样在线更新。最开始想到的方法是，用Fragment增加功能，自己照着系统的获取资源的方法，自己实现一套获取资源的方式。这样就形成了最早的插件化的技术，实现了可以动态增加功能。
• 当然，程序员们不甘于此，又想到了能否用系统的资源加载器去加载资源，能否用Activity添加功能，能否在原来写错的地方，重改原来错误的代码。经过研究以及framework源码的学习，就研究出了ClassLoader去加载代码，并修改代码的加载顺序，研究出了hook 系统源码来使用系统的资源加载器来加载资源。在加载Activity的时候是需要系统注册的，也找到了代理的方式加载Activity或者欺上瞒下的形式欺骗系统来加载Activity的功能。
• 除了这种java层处理外，还有另外一种技术就是使用native hook的方式将方法替换，这种方式是在C++层去替换程序中的方法，已达到修改代码修复bug的问题。

3.DynamicApk-携程

携程无线团队是属于较早开源插件化技术的团队。有人说这个是抄袭了一部分别人的技术，不管怎么样还是推动了插件化技术的前进。携程无线团队使用插件化技术对系统进行了架构拆分。DynamicApk分享出来的技术有：支持类的加载、用代理的方式加载Activity、反射方式加载资源。其中对资源加载做了一些特殊处理，没有像DroidPlugin那样是资源独立的，而是采用同一套资源，用资源名称去区分不同的资源，针对资源的id也做修改。Activity的加载方式是采用代理的方式让系统识别的。

修改aapt工具 第一字节代表了Package，第二字节为分类，三四字节为类内ID。
android.jar中的资源，其PackageID为0x01 public static final int cancel = 0x01040000;
用户app中的资源，PackageID总是0x7F public static final int zip_code = 0x7f090f2e;

参考：
文章地址：http://www.infoq.com/cn/articles/ctrip-android-dynamic-loading/
github地址： https://github.com/CtripMobile/DynamicAPK

4.DroidPlugin-360手机助手

• DroidPlugin这个是跟360安全的产品密切相关的，也非常适合360手机助手。DroidPlugin的目标是使任何一个APP都可以在DroidPlugin的宿主应用中直接运行。而不是将APP安装到手机中，再去体验APP。这是DroidPlugin努力追求的目标。但是在同一个APP上有多个部门协作开发，每个部门都独立开发一些业务，最终集成到一个APP中，每个业务可以独立更新自己的模块，不用一起发版，是可以实现的。

• DroidPlugin中使用了大量的hook相关的技术，特别是在Activity的注册上，做了预先注册一些Activity，然后在新的Activity启动时欺骗系统是预先注册过的Activity。DroidPlugin代码是开源的，可以下载来学习一下，跑一遍demo对hook技术进行深入的分析和学习。通过对DroidPlugIn的学习，使得我们在自己的应用开发过程中，对于一些原生系统不支持、需要Hook的功能，得以实现。以及你的应用中需要集成多个第三方功能，或者开放平台的形式给第三方接入。这个框架是一个不错的学习和借鉴的框架。除此以外，DroidPlugin对于大型APP架构的改造也可以学习其中的一些思想。DroidPlugIn最精华的就是hook技术，研究其中的hook技术可以对后续实现一些复杂的效果或者框架增加一些新的思路和启发，也增加了框架实现的手段。

• 下面是官方的一些介绍：

1.DroidPlugin 是360手机助手在Android系统上实现了一种新的插件机制:它可以在无需安装、修改的情况下运行APK文件,此机制对改进大型APP的架构，实现多团队协作开发具有一定的好处。
2.AndroidManifest.xml中动态注册组件Activity、Service、BroadcastReceiver、ContentProvider
3.资源完全隔离：插件之间、与Host之间实现了资源完全隔离，不会出现资源窜用的情况.

参考：

github地址： https://github.com/Qihoo360/DroidPlugin/tree/master
张勇专访： http://www.infoq.com/cn/news/2015/09/droidplugin-zhangyong-interview?from=timeline
DroidPlugin解析讲解 ： http://weishu.me/2016/01/28/understand-plugin-framework-overview/

5.HotFix-QQ空间热补丁技术

QQ空间团队是比较早期研究热补丁并分享出来的团队。研究出APP在客户端动态加载Dex文件以及动态调整Dex文件加载顺序。其中也碰到了一些问题，他们最终找到了产生问题的原因，并找到了合适的解决办法。
QQ空间hotfix的主要技术是：系统在安装app的时候会在类加载器中加载apk中的默认classes.dex文件 。这个类加载器可以加载后续的补丁Dex文件,而且可以调整Dex文件的加载顺序。这样就可以用同名的类去替换掉原始的含有bug的类，已达到修复bug的目的。

hotfix.jpg

参考：

https://mp.weixin.qq.com/s?__biz=MzI1MTA1MzM2Nw==&mid=400118620&idx=1&sn=b4fdd5055731290eef12ad0d17f39d4a

6.AndFix-阿里支付宝

• AndFix的原理就是方法的替换，把有bug的方法替换成补丁文件中的方法。在Native层使用指针替换的方式替换bug方法，已达到修复bug的目的。
  下面是补丁的加载和处理过程。
  
  

  andfix
  
  另外：阿里除了这个AndFix之外还有另外一个Dexposed框架，已经不更新了。
  参考：
  github地址： https://github.com/alibaba/AndFix
  Andfix原理： http://blog.csdn.net/qxs965266509/article/details/49816007
  Dexposed原理： http://www.jianshu.com/p/14edcb444c51#
  github地址： https://github.com/alibaba/dexposed

7.Tinker-微信

在客户端将补丁文件和APP原始文件进行合并，用客户端的存储空间换取网络传输的流量和APP的运行效率。Tinker目前开源支持的比较好，网上资料相对多一些。在编译时通过新旧两个Dex文件生成差异的patch.dex文件。在APP中，将差异的patch.dex文件重新跟原始安装包的原始的Dex文件生成为新的Dex文件。
这个过程会耗费APP的运行时间和内存，所以Tinker将其单独放在一个后台进程:patch中。为了将补丁包尽量的小，Tinker自研了DexDiff算法，它深度利用Dex的格式 来减少差异文件的大小。

Tingker.png

文章地址 ：https://github.com/WeMobileDev/article
github地址：https://github.com/Tencent/tinker
Instant Run App server 实现代码替换：
http://www.jianshu.com/p/2e23ba9ff14b