在接入Tinker时, 在Android N上出现补丁不生效的情况,这里主要讨论出现此状况的原因及解决方法.
一 初始方案
在接入Tinker的时候, 按照改动小的前提,根据Tinker及TinkerManager的README.md进行接入
1. 接入
- 在gradle中对Tinker热修复进行引入;
- 原Application直接继承TinkerApplication类;
- 在TinkerApplicationLike代理类中,对Tinker及TinkerManager进行初始化;查询补丁并对补丁进行安装;
2. 效果
在osVersion<24的手机上,补丁下载及应用成功.(魅族MX6)
在osVersion>=24的手机上,出现crash:
java.lang.ClassCastException: *Application cannot be cast to *Application
原因是在Activity中使用了此代码: (*Application) getApplication()
二 解决方案
此问题也有开发者遇到过: https://github.com/Tencent/tinker/issues/433
Tinker开发者回复的建议有两条:
- 按照文档完成改造
- 使用类似tinkerpatch的一键接入功能
三 按照文档完成改造
开发者建议的第一条方式, 对项目原有的Application进行改造.对其他引用Application或者它的静态对象与方法的地方，改成引用ApplicationLike的静态对象与方法.简单来说,就是将原Application中的所有逻辑迁移到继承DefaultApplicationLike的Application代理类中.
改造方案
- 将项目中对Application及ApplicationContext的引用全局替换.
- 测试发现,Dagger2的Activity/Fragment自动注入方式与Tinker改造不能很好兼容:
在Activity初始化时,会调用AndroidInjection.inject();方法, 会将getApplication()强转为HasActivityInjector接口,然后调用activityInjector()这个方法.
后果
改动量大, 需要废弃AndroidDagger注入.
四 使用类似tinkerpatch的一键接入功能
tinkerPatch的github中没有提供具体的实现类,都是些抽象类/接口类,它的核心代码没开源,以下方案参照TinkerPatch混淆后JAR包的实现.
1. 主要思路
- 通过插件修改AndroidManifest.xml,将入口Application改为代理Application类:
/**
* Tinker代理的Application类.
* <p>
* 用于对Tinker做初始化及代理真正Application的生命周期及主要公共方法.
*/
public class TinkerProxyApplication extends TinkerApplication
- 反射替换Application
在代理application中，反射替换真正的application。主要方法是monkeyPatchApplication:
/**
* 将当前APP的TinkerApplication通过反射替换成项目中实际用到的Application.
* <p>
* 难点就在于兼容性和找到所有TinkerApplication的引用处.
* <p>
* 与Instant Run的逻辑基本一致.具体代码
* See <a href="https://github.com/nuptboyzhb/AndroidInstantRun/blob/master/InstantRunSourceCode/src/com/android/tools/fd/runtime/MonkeyPatcher.java">MonkeyPatcher</a>
*/
public static void monkeyPatchApplication(Application bootstrap, Application realApplication) throws Throwable;</pre>
2. 结论
这种方式的优点在于接入容易,但是无法保证兼容性，特别在反射失败的情况，是无法回退的。
但是考虑到旧版InstantRun和TinkerPatch的机制都是如此,估计不会很差, 但crash风险难避免.
五 原理剖析
1. 为什么只在osVersion>=24的机器上才出现ClassCastException,而且是Application转Application?
1) 背景
Tinker没有使用parent classloader方案，而是使用Multidex插入dexPathList方式，这里主要考虑到分平台内部类可能存在校验classloader的问题。
若SDK>=24, 即Android N版本，当补丁存在时，将PathClassloader替换为AndroidNClassLoader, 但是它依然继承于PathClassLoader。我们依然可以像以往那样对它进行类似makeDexElements的操作。
若SDK<24, Tinker没有对classloader做处理，这里需要注意补丁的Dex是插入在dexElement的前方,这样加载类时,会优先找到修改后的补丁类.
2) 解释
Application是在应用启动时一定由原生PathClassloader去加载的.
在SDK>=24的情况下, 除Application及Tinker初始化相关的类外, 其余类都是由新建的AndroidNClassLoader加载,所以(*Application) getApplication()强转时, getApplication得到的对象是在原生PathClassloader中的, 和AndroidNClassLoader中的*Application是两个不同的对象,强转会发生异常ClasssCastExcepiton.
当SDK<24的情况, 又分为大于或等于23,大于或等于19和大于或等于14及小于14这四种情况,主要考虑到各版本修改dexElement的方式不同,思路一致.以下为Tinker使用classLoader加载dex的方法:
public static void installDexes(Application application, PathClassLoader loader, File dexOptDir, List<File> files) throws Throwable {
//...
ClassLoader classLoader = loader;
if (Build.VERSION.SDK_INT >= 24 && !checkIsProtectedApp(files)) {
classLoader = AndroidNClassLoader.inject(loader, application);
}
//because in dalvik, if inner class is not the same classloader with it wrapper class.
//it won't fail at dex2opt
if (Build.VERSION.SDK_INT >= 23) {
V23.install(classLoader, files, dexOptDir);
} else if (Build.VERSION.SDK_INT >= 19) {
V19.install(classLoader, files, dexOptDir);
} else if (Build.VERSION.SDK_INT >= 14) {
V14.install(classLoader, files, dexOptDir);
} else {
V4.install(classLoader, files, dexOptDir);
}
//...
}</pre>
可以看出,如果SDK>=24且没有使用加固,才会使用AndroidNClassLoader. 其余情况是使用原生的PathClassLoader,所以SDK<24时应用补丁是不会出问题的.
2. Tinker为什么对Android N做特殊处理?
AndoidN混合使用AOT编译，解释和JIT三种运行时，降低安装时间、内存占用, 提升系统与应用性能。
AOT: Ahead-Of-Time 预编译,在应用程序安装的过程中，ART就已经将所有的字节码重新编译成了机器码。运行过程中无需进行实时的编译工作，只需要进行直接调用。
解释: 在运行过程中才将编译生成的中间代码, 生成目标平台的成机器码.
JIT: Just-in-time 即时编译,一句一句编译源代码，但是会将翻译过的代码缓存起来以降低性能损耗.
1) 编译模式
Android N的编译模式有12种，在不同时机采用不同编译模式.主要介绍以下两种：
[speed]模式，即最大限度的编译机器码，它的表现与AOT编译一致,会占用比较多Rom空间
[speed-profile]模式，即只根据“热代码”的profile配置来编译。这也是Android N中混合编译的核心模式。
2) [speed-profile]模式的机制
在应用运行时分析运行过的代码以及“热代码”，并将profile配置存储下来。
在设备空闲与充电等时机，ART中的
BackgroundDexOptService会“渐进式编译”这份配置中的“热代码”，代码编译信息记录在base.art文件中.在APP启动时，一次性把“热代码”加载到缓存，将对应的class插入到
PathClassLoader的ClassTable中,将method更新到dexCache中.-
APP在加载类时，会优先从
ClassTable中查找，从而达到预先加载代替用时查找以提升应用的性能．
热代码工作机制
3) Tinker不支持
如果base.art文件在补丁前已经存在,它们都是无法通过热补丁更新的.
而且,如果补丁修改的类部分存在于base.art, 则只能更新一部分类,此时一部分类是新的，一部分是旧的，由于在dex2oat时fast*已经将类能确定的各个地址写死，新旧类互相调用时就可能出现地址错乱。
3. Tinker应对方案 - 运行时替换PathClassLoader
完全废弃掉PathClassloader, 采用新建PathClassloader来加载后续的所有类,即可达到将cache无用化的效果, 这样就避免了补丁无效或地址错乱的情况.
1) 新建的AndroidNClassLoader干了什么事情?
1.将原PathClassloader中的dexPathList信息反射赋值给AndroidNClassLoader.
2.在调用findClass查找class时,如果是在com.tencent.tinker.loader;这个pacakage中的类,则由原PathClassloader去加载,原因是这个包含AndroidNClassLoader及其他Tinker初始化类的package,已经由原PathClassloader加载过了, 其余类则由AndroidNClassLoader去加载.
简单来说, 此AndroidNClassLoader单纯只是去加载后续的类而已.
2) 项目如何改造?
由于Application类是通过PathClassloader加载的,为了实现Application类与应用程序的逻辑解耦，有两种方式：
A.采用类似InstantRun的实现；在代理application中，反射替换真正的application。
B.采用代理Application实现的方法；即Application的所有实现都会被代理到其他类，Application类不会再被使用到。
B方案就是前面第三节讲的按照文档完成改造, 这种方式没有兼容性的问题，但是会带来一定的接入成本。微信采用了B方案, 考虑到要应对Android数亿用户, 涉及到反射的框架往往都不能经受兼容性的考验.
4. 如何按照A方案改造?
A方案中, InstantRun的实现做了什么事?
1.利用Gradle提供的Transform API插桩.并修改AndroidManifest.xml文件,将原Application替换成代理Application.
2.将代理Application看作一个宿主程序，目的是将app作为资源dex加载起来. 代理Application会初始化原Application,代理原Application的生命周期, 并替换所有当前app的代理application为原Application,使得之后访问到的applicaiton仍然是原application.
InstantRun的主要原理是通过设置父ClassLoader, 优先加载所有发生改变的patch代码类. 如果资源发生变化,则反射替换AssetManager,将发生改变的资源路径添加进来. 然后根据改动情况,选择是热部署/温部署/冷部署使其生效.在最新gradle3.0中已经用ContentProvider去实现了.
1) 如何替换呢?
1.替换ActivityThread的mInitialApplication为原Application
2.替换mAllApplications 中所有的代理Application为原Application
3.替换ActivityThread的mPackages,mResourcePackages中的mLoaderApk中的application为原Application。
2) TinkerPatch是如何对原Application进行改造的呢?
可以发现前文第四节使用类似tinkerpatch的一键接入功能与InstantRun机制差不多. TinkerPatch中替换application的方法如下所示, 与InstantRun中替换的代码也几无二致.
3) 方案A的反射兼容问题有多大?
Tinker团队之前做过测试，100万人会有几十个在替换的时候出现问题.
4) 代理Application为什么要通过反射初始化ApplicationLike及原Application?
-
防止在Dalvik中抛出抛出unexpected DEX异常.
补丁前,代理类和它的直接引用类(ApplicationLike)在同一个dex文件中,所以被打上了preverify标志.
但是补丁后,代理类和它的直接引用类就不再同一个dex中了.
如果在代理类中new关键字去加载它的直接引用类的话.
dvmResolveClass会校验两个类在是否相同dex中,如果不在就会抛出unexpected DEX异常.而反射则不会走到校验preverify的方法中,所以不会抛异常. -
在Android N上, 补丁可能失效.
如果在启动Application中直接new构造Application及ApplicationLike, 会导致AndroidNClassLoader加载的Application及ApplicationLike仍是旧类.甚至会由于新旧类的相互引用导致地址错乱.
推测是因为加载启动Application时,已经将类能确定的各个地址(比如它的直接引用类) 写死，所以对原Application及ApplicationLike有修改会失效.
反射最直接的目的是为了隔离开这两个类,并使得补丁能对原Application及ApplicationLike生效.
5. Tinker应对方案的缺点及改进
这种方案的缺点是会废弃Android N上base.art这种混合编译的好处, 会给应用带来最高可达大约15%的性能损耗,且会占用更多的ROM空间.
针对上述Android N的问题, 且考虑到dex合成的ROM过大, OTA后存在黑屏等情况, Tinker根据平台区分dex合成方式. Dalvik平台合成完整dex; Art平台只合成需要的类,即下图的mini.dex.
然而, 不久后这种优先加载补丁dex方案遇到问题,主要是因为不能兼容ART环境下的方法内联策略.
原因：因为补丁dex只覆盖了旧dex的一部分类,一旦被覆盖的类被内联到了调用者里, 即使调用了覆盖类的方法,执行流程也并未调到新方法中. 因为调用者调用补丁类中的方法/成员/字符串查找都还是用的旧索引.
解决方案：ART平台下使用全量DEX,这样所有方法都在NewDex中就不怕内联了.所以又回到了之前的方案...
六 总结
在Android N上出现补丁不生效的原因,主要是因为Tinker针对N上混合编译的实施了折中方案.
目前有几种思路去选择:
-
将Application中的逻辑迁移到代理类中.
优点: 微信也是按这种方式适配,兼容性高.
缺点: 改动量较大.
-
类似InstantRun,反射替换成真正的application.
优点: 与InstantRun及TinkerPatch机制类似,较为成熟.
缺点: 兼容性问题难以避免, 当前线程在反射替换时是无法回退的.InstantRun在Gradle3.0之后已不使用此方案,后续维护成本高.
-
对Android N及以上系统不应用补丁.
优点: 改动小.按照上文的第一节的初始方案改动即可, 在7.0以下的系统可应用成功.
缺点: 不能对application类进行热修复, 在7.0及以上的系统中失效.
