一键接入Tinker
背景
Tinker开源挺长时间了,使用的开发者也越来越多,对于一些小白开发者来说对接Tinker的成本还是挺高的,其中主要因素还是不能理解为什么Application要修改成ApplicationLike,以及改造后对项目中使用Application的地方也要同步修改。
在上篇文章Android热补丁之Tinker原理解析中我们已经讲解了这样做的目的以及Tinker的加载补丁的流程,本篇文章主要讲一下一键接入Tinker的实现思路。
InstantRun
我们的目的是要实现不修改Application达到替换Application的效果,在这篇文章从Instant run谈Android替换Application和动态加载机制中,详细讲述了如何动态替换Application,总结起来就两步:
- 打包时替换Application标签,插入BootstrapApplication
- 运行时hook系统api,将BootstrapApplication换回MyApplication
那么,我们依然可以用这套方案来实现Tinker的一键接入,动态替换Application。
实现
有了思路我们就可以敲代码了。
打包
打包时我们要改变Manifest中Application的标签值,可以通过自定义Gradle插件来实现,关键代码
|
|
打包出的apk中的AndroidManifest.xml文件基本是这样的
|
|
其中的App是项目中原有的Application,BootstrapApplication是后期我们插入的Application。自定义Gradle插件时可以封装一个Extension配置参数,把Tinker的相关配置封装起来,一些不变的默认配置项都可以写到里面,这样项目的gradle配置可以更简洁。另外说一句,这个Gradle插件的顺序应该是打包工具生成Manifest之后,Tinker相关Task之前。
运行时替换Application
这一步的主要工作也是分两步,第一就是解析Manifest文件,拿到realApplication(App)和BootstrapApplication;然后hook 系统完成替换。
InstantRun中的替换实现
|
|
主要做了两件事:
- 替换Application
- baseContext.mPackageInfo.mApplication 代码3处
- baseContext.mPackageInfo.mActivityThread.mInitialApplication 代码2处
- baseContext.mPackageInfo.mActivityThread.mAllApplications 代码1处
- 替换mLoadedApk对象,代码4处
详细请查看从Instant run谈Android替换Application和动态加载机制
做完上面这两步这样就可以实现一键接入了。
兼容性
在上篇文章中我们提到,由于该方案大量hook系统api,在国内Android碎片化如此严重的市场环境下,该方案兼容性有一些问题,大概有 1/1w的概率会出现替换失败的问题,如果替换失败,那么在系统中运行的Application还是BootstrapApplication,而我们App中的Application已经没有了Application的生命周期和作用。
所以我们要在失败catch中调用下Application的生命周期方法以保证程序能够正常初始化启动起来。
|
|
这么做虽然能保证App能启动,但是实际上还会有隐性问题存在。比如App中有如下代码((App) getApplication()).xxx();
,那么在替换失败的情况下可能就会崩了, 因为getApplication()
得到的是BootstrapApplication,强转为App
类型肯定就挂了。
总结
整体思路大概讲清楚了,虽然这种方案接入成本低,但是兼容性问题是个很麻烦的事情,说不定啥时候就崩了。推荐大家还是使用Tinker自有的接入方案。
参考
从Instant run谈Android替换Application和动态加载机制
TinkerPatch
本文链接: http://w4lle.com/2017/01/05/one-key-for-tinker/
版权声明:本文为 w4lle 原创文章,可以随意转载,但必须在明确位置注明出处!
本文链接: http://w4lle.com/2017/01/05/one-key-for-tinker/