热修复和动态加载

热修复

目前存在比较好的解决方案是热修复技术，即生成差一补丁包后，直接将更新补丁上传到云端，此时App从云端下拉补丁直接应用生效，即直接在用户已安装的程序中修复bug，准确而言它是一个亡羊补牢的措施。比较有代表性的的App是阿里系的优酷和支付宝，腾讯系的微信，两者使用的都是自行研发的方案。
可解决的典型问题：

• 刚发布的应用出现闪退、ANR等bug，及时修复 。

• 及时推送一些小的功能给用户使用
  优势：

• 无需重新发布，实时高效修复bug，修复成功率高，降低损失

• 用户无需操作，无需下载新的应用
  
  如上图，Sophix唯一明显不足的是不支持四大组件的修复，因为四大组件修复要求在AndroidManifest里预先插入代理组件，并且尽可能声明所有权限，这些操作会给原app添加很多臃肿代码，对app运行流程的侵入型很强

目前市场上热修复有两大主流方案，分别是阿里系的底层替换方案，腾讯系的类加载方案，优劣如下：

• 底层替换方案：从底层C的二进制来解决问题，这样做限制颇多，但时效性最好，加载轻快，立即见效；
• 类加载方案：从Java加载机制来解决问题，这样做时效性差，需要重新冷启动才能见效，但修复范围广，限制少；

底层替换方案
原理是直接在已加载类中替换掉原有方法，即在原来类基础上进行修改，因此无法实现增减原有类方法或字段，这样会破坏原有类的结构。一旦补丁中出现了方法的增加和减少，就会导致这个类以及整个dex的方法数的变化，方法数的变化伴随着方法索引的变化，这样在访问方法时就无法正常的索引到方法字段的增加减少。

同理传统的底层替换方式如Dexposed、Andfix及其他安全界的Hook方案都是直接依赖修改虚拟机方法实体的具体字段，例如修改Dalvik方法的jni函数指针、修改类或方法的访问权限等。这里埋藏着一个隐患，由于Android是开源的，各个手机厂商都可以对代码进行改造，而Andfix里ArtMethod结构体进行了修改，就和原先开源代码结构不同，导致在修改过了的设备上，通用性的替换机制会出问题，这就是不稳定的根源。
阿里andfix：
通过jni方法replaceMethod，反射到dalvik和art进行方法替换FromReflectedMethod反射art_method（定义在runtime/art_method.h） 然后把旧函数的所有成员变量替换为新的

类加载方案
在app重新启动后让Classloader加载新的类。因为当app运行到一半时，所需发生变更的类已经被加载过，而在Android上无法对一个类进行卸载操作，若不重启，原来的类还存储于虚拟机中，新类无法被加载。因此只有在下次重启时，在业务逻辑运行之前抢先加载补丁中的新类，这样后续访问此类时，才会Resolve为新类，从而达到热修复的目的。
BootClassLoader: 加载framework层的一些class文件
BaseDexClassLoader：父类
PathClassLoader：只能加载已安装到Android系统的APK文件；
DexClassLoader：支持加载外部的APK、Jar或dex文件；（限制：必须要在应用程序目录）

• 如何的两个类才算是相同的类呢？
  两个类的包名、类名相同而且必须是同一个ClassLoader加载
• 生成修改的dex：
  a. build/intermediates/classes/debug/pgk/DexFixTest.clas
  b. 在桌面随意建一个文件夹放置该文件，注意包名需对应文件夹名！
  c. dx --dex --output=/Users/lemon/Desktop/test/classes2.dex /Users/lemon/Desktop/test/
• dex文件合并：
  a. 首先获得加载应用程序dex文件的PathClassLoader，即通过Context上下文context.getClassLoader()获取的便是加载应用的PathClassLoader；
  b.然后获得加载制定路径下dex文件的DexClassLoader，这里的DexClassLoader需要自行创建，其构造方法中的四个参数分别是：指定要加载dex文件的路径dexPath、指定dex文件需要被写入的目录，一般是应用程序内部路径optimizedDirectory（不可以为null）、包含native库的目录列表librarySearchPath（可能为null）、父类加载器parent；
  c. 最后通过这两个加载器去重写 DexPathList类中的Element类型数组dexElements，即直接将已修复的dex放到dexElement数组中有bug类的dex前面,通过反射获取到BaseDexClassLoader类，再反射获取类中的DexPathList类，即可获取到dexElements数组

冷启动类加载原理:
冷启动重启生效。apk第一次安装时候，会对原dex执行dexopt，执行dalvik/opt/OptMain.cpp->verifyAndOptimizeClass->dimVerifyCLass->dvmOptimizeClass
dvmVerifyClass: 类校验，目的是为了防止类被篡改，此时会对类的每个方法进行校验，如果类的所有方法中直接应用到的类（不会进行递归搜索）和当前类都在同一个dex中的话，dvmVerifyClass就返回true。
dvmOptimizeClass：类优化，此过程会把部分指令油画城虚拟机内部指令，比如方法调用指令：invoke-指定变成invoke--quick,quick指令会从类的vtable表中直接取，vtable是类的所有方法（包括继承自父类的方法）的一张函数表，从而加快了方法的执行效率

两者结合方案
阿里的Sophix技术结合了两种方案，可灵活地根据实际情况切换。在补丁生成阶段，补丁工具会根据实际代码变动情况进行自动选择，针对一些在底层替换方案限制范围内的小修改，就直接采用底层替换方案，便于修复即时生效；而对于代码修复超出底层替换限制的，采用类加载方案，虽然及时性不太好，但可达到热修复的目的。
不仅如此，Sophix在运行时阶段，还会判断所运行机型是否支持热修复，防止部分机型底层虚拟机构造不支持情况，可以执行类加载方案，从而达到最好的兼容性

资源修复
获取资源的时候是用Resource类来得到的，一个程序一个Context对应一个Resource对象，但是我们加载apk的时候，插件apk没有得到对应的Context。因为动态加载不像正常的运行一个程序，没有Context，所以只能通过反射调用AssetManager中的addAssetPath方法，然后再通过AssetManager来创建一个新的Resources对象。
Google官方Instant Run方案资源修复原理：
a. 首先构造一个新的AssetManager，并通过反射调用addAssetPath方法，把这个完整的新资源包加入到AssetManager中，这样就获得了一个含有所有新资源的AssetManager。
b. 找到所有之前引用到原有AssetManager的地方，通过反射将引用处替换成新AssetManager

addAssetPath最终调用JNI层，通过传入的资源包路径，先得到apk中的resources.arsc。然后解析他的格式，存放到底层AssetManager的ResTable
mResources成员中,一个进程只包含一个ResTable，ResTable的mPackageGroups就是解析过的资源包集合，任何一个资源包都包含有resource.arsc，资源ID及资源中字符串以二进制存放，由AssetManager负责解析并存放到mPackageGroups

阿里实现资源修复原理:
构造一个package id为0x66的资源包，该包只包含修改了的资源项，然后直接在原有AssetManager中调用addAssetPath 方法添加此包即可。由于补丁包的package id 为0x66，不与目前已经加载的0x7f冲突，因此直接加入到已有的AssetManager中就可以使用了。补丁包中的资源只包含原有包里没有的新增资源，以及原有内容发生改变的资源，并且采用的替换方式是直接在原有的AssetManager对象上进行析构和重构，这样所有原先对AssetManager对象的引用是没有改变的，因此无需像Instant Run那样繁琐修改引用了

相较于Google官方研制的Instant Run方案，优势如下：

• 不需要修改AssetManager的引用处，替换更快更完全。
• 不必下发完整包，补丁包中只包含有变动的资源.不需要在运行时合成完整包，
• 不占用运行时计算和内存资源

默认由android sdk编译出来的apk，是由aapt工具进行打包的，其资源包的package
id是0x7f，系统的资源包（framework-res.jar）的package id为0x01

SO修复
阿里采用的是类似类修复反射注入方式，即把补丁so库的路径插入到nativeLibraryDirectories数组的最前面，就能够达到加载so库时的是补丁库，并非原来so库的目录，从而达到修复的目的。Sophix是在启动期间反射注入patch中的so库，对开发者依然透明，而其他方案则需要手动替换系统的System.load来实现替换目的。

插件：

插件式机制，一种免安装的运行机制，目前做的比较好的是360的DroidPlugin
优点：

• 免安装（就是如果只要从网上下载一个apk，不用安装apk，在插件机制下，就能运行）
• 无需修改源码（因为大量反射，代理，Binder相关，这些足以骗过framework层）
• 二进制级别隔离
• 插件之间可以相互调用
• 静默安装，就是前面说的不用安装，就可在插件机制中运行apk  崩溃隔离，插件崩溃，对主应用来说，不会有明显影响
• 还原插件自己的多进程机制，适配性
• 模块隔离，如可以把UI和控制逻辑进行隔离，控制逻辑可用插件化的方式

缺点：

• 通知栏限制（无法在插件中发送具有自定义资源的Notification，例如： 1.带自定义RemoteLayout的Notification 2.图标通过R.drawable.XXX指定的通知（插件系统会自动将其转化为Bitmap）
• 安全性担忧（可以修改，hook一些重要信息）
• 机型适配（不是所有机器上都能行，因为大量用反射相关，如果rom厂商深度定制了framework层，反射的方法或者类不在，容易插件运用失败）
• 需要预先注册权限（在Library中申请了原生系统所有的权限）
• 无法在插件中注册一些具有特殊Intent Filter的Service、Activity、BroadcastReceiver、ContentProvider等组件以供Android系统、已经安装的其他APP调用。
• 缺乏对Native层的Hook，对某些带native代码的apk支持不好，可能无法运行。比如一部分游戏无法当作插件运行。

目前国内开源的较成熟的插件方案有dynamic-load和DroidPlugin，但是DL方案仅仅对Framework的表层做了处理，严重依赖that语法，编写插件代码和主程序代码需单独区分；而DroidPlugin通过Hook增强了Framework层的很多系统服务，开发插件就跟开发独立app差不多；就拿Activity生命周期的管理来说，DL的代理方式就像是牵线木偶，插件只不过是操纵傀儡而已；而DroidPlugin则是借尸还魂，插件是有血有肉的系统管理的真正组件；DroidPlugin Hook了系统几乎所有的Sevice，欺骗了大部分的系统API；掌握这个Hook过程需要掌握很多系统原理，因此学习DroidPlugin对于整个Android FrameWork层大有裨益。
DroidPlugin的基本原理:
a.共享进程：为android提供一个进程运行多个apk的机制，通过API欺骗机制瞒过系统
b. 占坑：通过预先占坑的方式实现不用在mainfest注册，通过一带多的方式实现服务管理
c.Hook机制：动态代理实现函数hook，Binder代理绕过部分系统服务限制，IO重定向（先获取原始Object–>Read,然后动态代理Hook Object后–>Write回去，达到瞒天过海的目的）
插件Host的程序架构:

DroidPlugin通过Hook拦截的方式替换掉系统的服务。要达到修改系统服务的目的，我们需要如下两步：

• 首先肯定需要伪造一个系统服务对象，接下来就要想办法让asInterface能够返回我们的这个伪造对象而不是原始的系统服务对象。
• 只要让getService返回IBinder对象的queryLocalInterface方法直接返回我们伪造过的系统服务对象就能达到目的。所以，我们需要伪造一个IBinder对象，主要是修改它的queryLocalInterface方法，让它返回我们伪造的系统服务对象；然后把这个伪造对象放置在ServiceManager的缓存map里面即可

下面以activity的启动为例介绍hook原理：
activity的启动流程：
ActivityManagerService::startActivity->ActivityStackSupervisor::startActivityMayWait->ActivityStackSupervisor::startActivityLocked(内部进行了一系列重要的检查：比如权限检查，Activity的exported属性检查等等,如果启动没有在Manifestfest中显示声明的Activity抛异常)->ActivityStackSupervisor::realStartActivityLocked->ApplicationThread::scheduleLaunchActivity(App所在server端的Binder对象存在于ActivityThread的内部类ApplicationThread；AMS所在client通过持有IApplicationThread的代理对象完成对于App进程的通信)->ActivityThread::handleLaunchActivity->ActivityThread::performLaunchActivity
App进程内部的ApplicationThread内部有Binder线程池，它与App主线程的通信通过ActivityThread::Handler完成
Manifest中注册了8个进程，加上主进程共9个，然后第每个进程下面又有26个Activity注册，一个service，一个contentprovider，可以假装启动一个已经在AndroidManifest.xml里面声明过的替身Activity，让这个Activity进入AMS进程接受检验；最后在handleLaunchActivity阶段换成我们真正需要启动的Activity
1.hook到ActivityManagerNative::startActivity替换intent中ComponentName为StubActivity，把原始要启动的TargetActivity的Intent信息保存到intent中
2. 权限检查完之后，ApplicationThread,通过ActivityThread::Handler分发消息，把这个H类的mCallback替换为我们的自定义实现，这样dispathMessage就会首先使用这个自定义的mCallback，然后看情况使用H重载的handleMessage，在自定义callback中，获取intent，并替换EXTRA_TARGET_INTENT为真正要启动的activity
AMS与ActivityThread之间对于Activity的生命周期的交互，使用Activity的mToken完成，这个token是binder对象,唯一的标识这个activity对象，它在Activity的attach方法里面初始化
AMS进程里面的token对应的是StubActivity，但是在我们App进程里面，token对应的却是TargetActivity！因此，在ActivityThread执行回调的时候，能正确地回调到TargetActivity相应的方法,ActivityThread::performLaunchActivity通过classloader加载了TargetActivity，然后把activity以tocken为key添加到mActivities