Android tinker升级之路分析

最新推荐文章于 2024-09-26 13:56:30 发布

许进进

最新推荐文章于 2024-09-26 13:56:30 发布

阅读量807

点赞数 1

分类专栏： Android 文章标签： android

本文链接：https://blog.csdn.net/lucasxu01/article/details/132870250

版权

99 篇文章 5 订阅

订阅专栏

前言

目前app线上的tinker版本为 1.9.14.19，在最近的几个版本技术需求中，我们希望对tinker尝试进行升级，并对内部封装的tinker的包装sdk进行升级。升级过程中的一些热修流程和记录如下。

测试中，所有测试热修基本均可生效，但是对补丁合成生效时间有要求。耗时具体体现在：

测试结果发现除了parallel optimize dex这一步，其他步骤耗时对比几乎不变，且耗时时长集中在parallel optimize dex这一环节。

start to parallel optimize dex的时间对比（oat耗时）

华为荣耀系统tinker会通过registerDexModule方法注册dex，不会进行重试步骤（1.9.14.25.2版本重试10次，1.9.14.19版本重试3次）；
android8.0 之下直接使用DexFile.loadDex加载补丁触发dex2oat；
android8 ~ android10，通过NewClassLoaderInjector.triggerDex2Oat进行dex2oat；
android10以后不再支持从应用进程调用dex2oat，仅接受系统生成的OAT文件（TinkerDexOptimizer.triggerPMDexOptOnDemand方法）；
重试的逻辑发生在TinkerDexOptimizer.triggerPMDexOptOnDemand方法中，DexFile.loadDex和进程内通过NewClassLoaderInjector.triggerDex2Oat进行dex2oat不会走该逻辑；该重试的逻辑会增加30s耗时。
在老旧手机上步骤二recover dex耗时明显比新设备耗时长，这个和机型性能有关，升级的差异不在步骤二。

相关逻辑请参考版本tinker源码TinkerDexOptimizer.OptimizeWorker类的run方法。

目前热修是肯定需要重启app的，但是在app拉取热修配置，下载patch包，然后重启app之前的这个时间节点上，tinker需要对patch包进行合成生效的操作，这部分会有耗时。

tinker核心代码：

TinkerPatchService 
         -  doApplyPatch(this, intent);

tinker issue上已经有人反馈了：

这个问题tinker *v1.9.14.25* 已经做了优化：

**1、**base包更新或有新 patch 合成成功后删除老 patch 的逻辑改为异步实现以降低启动耗时。

**2、**dexopt 触发重试次数缩减到 10 次，避免部分机型 apply patch 耗时太长。

但是从tinker目前的反馈来看，最新的几个版本会出现合成时间变长的case，目前还处于open状态。为了验证升级之后的tinker，在合成生效时间上与之前版本的差异，进行了线上tinker版本（1.9.14.19）的对照测试。测试见下。

优化了判断 resources.apk 被意外修改导致资源 patch 失效的检测逻辑。
修复了连续两次 patch 中间更新了 base 包时可能导致最后一次 patch 失效的问题。
在 Patch 加载不成功时 installNativeLibraryABIWithoutTinkerInstalled() 方法不再注入 patch so 路径，避免 dex 和 so 不一致的问题。

修复了 R8 生成的特殊 DebugInfo 导致编译失败的问题。
增加 performSecondaryDexOpt 的重试次数，在重试失败后再尝试 registerDexModule，以尽量减小 Android R 上 odex 没有生成导致的性能开销。
在 performSecondaryDexOpt 重试无效前不在 OPPO、VIVO、XIAOMI、REDMI 的 Android S 或更新的系统上调 registerDexModule，规避已知的性能问题。
更新 *getProcessName* 的实现，在 *Android P* 及更新的系统上优先尝试 *Application.getProcessName()* 方法。