android热更新,android热更新技术

解决：Bugly发布热更新时，提示未匹配到可用应用补丁包的App版本

在集成bugly热修复框架时，按照官方教程，《 Bugly Android热更新使用指南 》的bugly配置，发现当后期要发布热更新时，提示"未匹配到可应用补丁包的App版本，请确认补丁包的基线版本是否已发布"。

创新互联建站网站建设公司是一家服务多年做网站建设策划设计制作的公司,为广大用户提供了成都网站设计、成都网站制作、外贸网站建设，成都网站设计，一元广告，成都做网站选创新互联建站，贴合企业需求，高性价比，满足客户不同层次的需求一站式服务欢迎致电。

找了很久终于发现是因为官方使用指南上==少了配置项==，官方教程是这样的：

正确的应该是：

==注意官方教程是少了这个：==

另外，一般我们的MyApplication都不会直接继承自bugly要求的TinkerApplication，而是在自己的MyApplication中配置相关项，所以还需==注意==:

其他方面按照官方指南来就好啦~~~~

Android开发Tinker热更新的问题

通过阅读官方的技术文档，始终没有发现有对这个情况的相关配置项，所以只能从别处下手，最后发现，通过在 app module 的 “build.gradle” 文件中，注释掉依赖插件脚本，最终解决掉这个问题：

说两句：

目前运行调试一切正常，不过要始终留意后续是否会出现问题；重要的一点是，当要打包新版本时，一定要解开这个注释。

2、can’t the get signConfig for this build

问题：

执行 buildTinkerPatchRelease 打 Release 版本补丁包时报以下错误：

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

can't the get signConfig for this build

1

2

解决：

android {

...

// 签名配置【buildTypes中调用了signingConfigs，则signingConfigs{}要置于buildTypes{}前面】

signingConfigs {

release {

try {

storeFile file("MyProject.jks")

storePassword "111111"

keyAlias "zhangzeqiao"

keyPassword "111111"

} catch (ex) {

throw new InvalidUserDataException(ex.toString())

}

}

}

buildTypes {

release {

...

signingConfig signingConfigs.release

}

debug {

...

signingConfig signingConfigs.release

}

}

...

}

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

其中要特别注意，signingConfigs{} 方法体要置于 buildTypes{} 方法体前面，不然会报以下错误：

android热更新框架哪个好

一.基础知识

1.阿里的热更新框架已经开源 了。但已经很久没有更新过新版本了。当前的版本只支持到了 Android 4.4。由于 5.0 起新的 ART 虚拟机、更严格的 SELinux 策略以及对 64 位的支持之类的事，使得 Xposed 都在开发上做了很多调整。我不知道 Dexposed 现在是否支持，但至少阿里没有开源。

2.在本地动态执行远端下发的代码是极度危险的行为。利用此方法执行非法代码等或用于绕过 Google Play 等市场的审查是违反相关协议的，也是对用户极度不负责任的行为。

3.在一些访问非常密集的地方使用热更新可能会对效率产生相对比较大的影响，应该避免使用.

4.我们可以对 Java 的 ScriptEngine 进行一些封装成为一个 HotPatch 类使得它更适合做热更新的工作。

5.首先,检查热更新补丁的管道一定要建立在 https 上，因为下发代码是极其危险的，如果被劫持，后果是无法想象的。其次,请求时最好自动带上 Android 版本、手机型号、地区、版本号等信息，以方便更精确地下发，千万不能下发错。

6.Java在运行时加载对应的类是通过ClassLoader来实现的，ClassLoader本身是一个抽象来，Android中使用PathClassLoader类作为Android的默认的类加载器

7.我们的如果想做hotpatch，一定要保证我们的hotpacth dex文件出现在dexElements列表的前面。

二.常用的热更新技术框架:

基于QQ空间的HotFix →→ 要使用到android dex分包方案→拆分dex的项目的话，可以参考一下谷歌的multidex方案实现.

大众点评的NuWa←项目补丁自动化做的很完整

alibaba/AndFix

阿里巴巴的DexPosed

dalvik_patch实现multidex

使用React-Native实现app热部署的一次实践

alibaba/AndFix

三、常用的热更新技术框架比较

Advantage

disadavantage

NuWa

1，可以新增类和字段，

2，兼容到6.0系统

1，基本原理是classloader,类加载器

2，不能修改资源文件，如图片布局等（可通过动态布局实现）

AndFix

1， 支持Android2.3到6.0版本

2， 支持arm与x86系统架构

3， 支持dalvik和ART的runtime

4， 不需要重启App即可应用补丁

1，不能新增类和字段，

2，不能修改资源文件,

3，不能修改manifest文件

4，不能新增成员变量

5，不能使用加固后的apk制作pacth文件

四、github地址

百度的同学的实现 HotFix

点评的同学的实现 Nuwa

阿里的同学的实现 AndFix

另：AndFix对static的支持不太好，下面是试验的Demo:

添加了一个静态的字段addString：

通过AndFix来制作patch会直接报错：