热修复技术的实践之旅——微信TinkerPatch热修复结合Walle多渠道打包的详解

  • 时间:
  • 浏览:0
  • 来源:uu快3技巧_uu快3交流群_漏洞

image.png

image.png

image.png

Tinker 是两个开源项目(Github链接),它是微信官方的 Android 热补丁处理方案,它支持动态下发代码、So 库以及资源,让应用都都可不还可不能否 在需要重新安装的清况 下实现更新。

3、关于虚拟机Dalvik

Tinker is a hot-fix solution library for Android, it supports dex, library and resources update without reinstalling apk.

image.png

使用Tinker的是因为:

(4)执行多渠道打包命令(如gradlew clean assembleReleaseChannels)时,若提示如下BUILD FAILED的信息,Rebuild一下工程再执行打包命令即可正常打包。

2、Android JVM的运行过程

walle_build_apk_sucessful.png

image.png

ART模式与Dalvik模式最大的不同在于,在启用ART模式后,系统在安装应用的已经 会 进行一次预编译,在安装应用多多系统进程 时会 先将代码转换为机器语言存储在本地,另两个在运行多多系统进程 时就不需要每次都进行一次编译了,执行传输数率也大大提升。

(偷偷告诉你:我觉得现在最好的热修复方案,是阿里2017年6月份发布的新一代非侵入式Android热修复方案——Sophix,不过每个人是在去年上多日就现在开始使用热修复技术了,什么都那会市面上的热修复技术,相较而言,Tinker是最优的选用,已经 也经过了每个人实际项目中的使用,什么都我觉得大伙儿在项目中不可能 还这么使用过热修复,那Tinker是很不错的选用,毕竟Tinker 已运行在微信的数亿 Android 设备上。对于阿里的Sophix,有兴趣的研究的大伙儿们,推荐大伙儿能都可不还可不能否 去研读《Android热修复技术原理》)

project-structure.png

baseapk.png

②app的build.gradle中上加TinkerPatch的SDK依赖:

image.png

Walle(瓦力):是美团开源的Android Signature V2 Scheme 签名下的新一代渠道包打包神器,跟gradle打包不一样,walle是在APK Signature Block区块上加自定义的渠道信息来生成渠道包,从而提高了渠道包生成传输数率,能都可不还可不能否 作为单机工具来使用,都可不还可不能否 都可不还可不能否 部署在HTTP服务器上来实时处理渠道包Apk的升级网络请求。 ---Walle的介绍

配置基准包信息:

本文的核心内容介绍:

(1)对比当前市场上的热修复方案,对Tinker热修复方案进行了简单的介绍。

(2)删改讲解了微信Tinker的删改接入过程,文末提供了两个每个人写的非常轻量的Demo,能都可不还可不能否 帮助开发者很快了 了 实现每个人项目中热修复的接入,将热修复技术运用到真实的项目中,而不仅仅是Demo测试。

(3)加入了walle的多渠道打包方案,能很快了 了 打出什么都个渠道包。删改的介绍了真实项目上线时APK及补丁包的版本维护,要怎样通过单个补丁包,修复多个渠道,进行热修复的实现方案。

(4)文章末尾总结了接入过程中不可能 遇到的坑,及相应的处理方案,能帮助你无障碍的接入Tinker。以及简单的分享了一些关于热修复技术方面需要储备的一些技术知识。

①工程的根目录的build.gradle中配置:

(3)Demo打开运行时,不可能 提示下面现象图片, Rebuild一下工程不可能 将implementation 'com.android.support:appcompat-v7:26.1.0'改成 implementation 'com.android.support:appcompat-v7:27.1.1'即可:

如上图,随着移动端业务僵化 程度的增加,传统的APP更新流程显然无法满足业务和开发者的需求,无论是对于用户还是开发维护人员,过程过于繁琐,不够灵活。

主要指在以下有几次弊端:

适用于所有渠道的补丁包的位置如下:

本文参考:

Tinker源码TinkerPatch 接入及平台使用文档Android 热修复 Tinker接入及源码浅析—hongyangMultiDex与热修复实现原理Tinker加入Walle多渠道打包

④tinkerpatch.gradle将其放上跟build.gradle同一级目录即可,tinkerpatch.gradle中的删改配置如下。

Tinker热补丁方案不仅支持类、So 以及资源的替换,它还是2.X-7.X的全平台支持。利用Tinker大伙儿不仅能都可不还可不能否 用做 bugfix,甚至能都可不还可不能否 替代功能的发布。Tinker 已运行在微信的数亿 Android 设备上,这么为哪些你不使用 Tinker 呢?

apkOutputFolder:指定渠道包的输出路径, 默认值为new File("${project.buildDir}/outputs/apk")

(1)接入Tinker时,打包的已经 出现以下错误com.tencent.tinker.loader.TinkerRuntimeException: Tinker Exception:applicationLike must not be null.:是不可能 你的 tinkerPatch.gradle中配置 reflectApplication = false,已经 你又这么相应的改造你的Application类。本文介绍的是不改造大伙儿的 Application 类接入Tinker,什么都 配置应该为:reflectApplication = ture。

apkFileNameFormat:定制渠道包的APK的文件名称, 默认值为'${appName}-${buildType}-${channel}.apk'

可使用以下变量:

image.png

image.png

watch.png

add_patch_version.png

什么都我今天要介绍的假如官方推荐的并都有方案:使用walle实现多渠道打包。

4、关于ART模式

ART模式英文全称为:Android runtime,谷歌Android 4.4系统新增的并都有应用运行模式,与传统的Dalvik模式不同,ART模式能都可不还可不能否 实现更为流畅的安卓系统体验。

Android系统是以Linux系统为底层构建的。谷歌为了降低应用的开发难度在Linux底层之上构筑了两个名为“Dalvik”的虚拟机。

不可能 Dalvik虚拟机的指在,Android系统的开发者只需使用谷歌提供的SDK(软件开发工具包)即可较为轻松的按照一套“规则”创建APP,不需要顾忌硬件、驱动等现象图片,在每次执行应用的已经 Dalvik虚拟机时会 将多多系统进程 的语言由高级语言编译为机器语言,另两个当前设备才都都可不还可不能否 运行你这人应用。

Tinker将old.apk(也假如下面要讲到的基准包,上线发布时的APK)和new.apk,进行对比,得到patch.dex,已经 应用多多系统进程 通过在代码中加入初始化tinker的代码,能都可不还可不能否 实现在多多系统进程 运行的已经 加载patch.dex(补丁文件),已经 patch.dex与本机APK的classex.dex合并,生成新的classes.dex。运行时通过反射将合并后的dex文件放置在加载的dexElements数组的前面。运行时替代的原理,我觉得和Qzone的方案差这么来太少,都有去反射修改dexElements。

本文删改Demo GitHub下载地址请戳:TinkerPatchDemo

image.png

image.png

image.png

bug修复不及时,用户体验差。

(2) 再看看热修复的开发流程,明显更加灵活。

到此,接入Tinker就完成了。实际项目中,咱们的应用肯定是要在各大应用市场上线的,这么肯定要打多个渠道包,按照常规,大伙儿是采用productFlavors实现的。假设项目要打10个渠道包,这么得针对每个渠道包,分开打10个补丁包,这显然是不合理的。针对你这人需求,Tinker官方给大伙儿提供了多渠道打包的方案,如下图:

1、关于Dex

Dex是Android平台上可执行文件的类型,是能都可不还可不能否 在Dalvik虚拟机上直接运行的文件格式。Java源代码经过ADT的僵化 编译后转上加Dex文件,这是两个逐步优化的过程。Dex文件的指令码假如Dalvik虚拟机专有的一套指令集,相比标准java的.class文件,它体积小,运行传输数率高。

当前市面的热补丁方案有什么都,其中比较出名的有阿里的 AndFix、美团的 Robust 以及 QZone 的超级补丁方案。但它们都指在无法处理的现象图片。其中AndFix不可能 接入是最简单的两个(和Tinker命令行接入办法差这么来太少),不过兼容性还是是有一定的现象图片的;QZone方案对性能会有一定的影响,且在Art模式下出现内存错乱的现象图片;美团提出的思想方案主假如基于Instant Run的原理,兼容性比较好,但目前尚未开源。

Build成功后的效果如下图:

image.png

Error:Execution failed for task ':app:preDebugAndroidTestBuild'.

Conflict with dependency 'com.android.support:support-annotations' in project ':app'. Resolved versions for app (26.1.0) and test app (27.1.1) differ. See https://d.android.com/r/tools/test-apk-dependency-conflicts.html for details.

realease_patch.png

image.png

生成的多渠道包的目录如下图:

③为了简单方便,大伙儿将 TinkerPatch 相关的配置都放于tinkerpatch.gradle中, 大伙儿需要在app的build.gradle中将其引入:

(1) 看看传统的App升级更新流程:

①生成所有渠道的渠道: gradlew clean assembleReleaseChannels

②生成某两个渠道:gradlew clean assembleReleaseChannels -PchannelList=baidu

③生成指定的多个渠道包 ./gradlew clean assembleReleaseChannels -PchannelList=baidu,xiaomi

(2)多渠道打包时,出现下面错误

logcat.png

你这人错误是不可能 在安装JDK时,会安装两次,一次安装JDK,一次安装jre,不可能 第一次JDK的安装就不可能 安装了两个jre,而安装时的提示会再次安装两个jre。什么都在第二次安装jre时,先暂停,你需要将第一次安装JDK的目录下的两个/jre文件夹删掉,已经 在安装另两个jre,另两个就能都可不还可不能否 了。再重新执行walle打包的命令,就能成功打出多渠道包了。

(1)多渠道APK的发布:

每次上线时,只需要执行上面生成渠道包的命令,打出多个渠道的APK即可,将各个渠道下发到各个应用市场即可。根据项目需求,能都可不还可不能否 通过获取渠道信息,进行渠道统计。切记每次发布新版本时,一定要备份好bacApk目录的文件,发布补丁的已经 需要。不可能 一旦丢失,就失去了基准包的信息了,就无法打出相应基准包的补丁包了。

(2)补丁包的发布:

当线上APK出现bug需要修复时,在tinkerPatch.gradle中配置好你线上发布的基准包的信息(已经 备份的基准包),使用tinkerPatchRelease打出补丁包,在TinkerPatch管理后台下发补丁。具体如上步骤6.

热修复的几大优势:

image.png