[移动开发]Android热更新，Android面试题整理

3.热修复的实现原理

安卓的类加载器在加载一个类时会先从自身DexPathList对象中的Element数组中获取（Element[] dexElements）到对应的类，之后再加载。采用的是数组遍历的方式，不过注意，遍历出来的是一个个的dex文件。

在for循环中，首先遍历出来的是dex文件，然后再是从dex文件中获取class，所以，我们只要让修复好的class打包成一个dex文件，放于Element数组的第一个元素，这样就能保证获取到的class是最新修复好的class了

三.热更新优点

=================================================================

1. 正常开发流程：

新版本上线，发现问题或用户反馈bug，紧急修复，上线版本，用户重新安装。

存着如下问题：

l 周期长

l 用户下载成本高，app推广成本高昂

l 修复不及时，用户体验差，用户遇到奔溃时失去耐心后直接卸载。

2. 热修复流程：

新版本上线，发现问题或用户反馈，紧急修复，上线补丁，自动修复

存着如下优点：

l 无需重新发版，及时修复问题

l 用户无感知修复，无需下载新应用，代价小

l 修复成功率高，把损失降到最低

但热修复因为大量涉及android底层知识，又因为android本身开源，华为vivo小米几大厂商都可能修改底层相关代码，兼容性困难，所以热修复技术开发维护难度巨大，人力和时间投入不菲。目前主要有腾讯，阿里等几家互联网大厂因自身刚性需求，实现此功能。

两者实现对比：

各种热修复技术对比：

为什么要做热更新

当一个App发布之后，突然发现了一个严重bug需要进行紧急修复，这时候公司各方就会忙得焦头烂额：重新打包App、测试、向各个应用市场和渠道换包、提示用户升级、用户下载、覆盖安装。

重点是还会有原来的版本遗留，无论你怎么提示都有人放弃治疗，不愿意升级，强制不能使用体验又足够糟糕到让人不能启齿。

如果这是一个影响公司收入或者体验影响极其不好的Bug，那完蛋了，可能公司老板会对整个技术团队的技术能力丧失信心，其对技术人员的伤害是致命的。

最后最致命的是：

有时候仅仅是因为不小心写错了一行代码，就让所有的工作都付之东流。

而热更新的出现正是解决了这些问题

四.热更新使用

=================================================================

以bugly技术为例：

bugly优点：

1. 无需关注补锅匠是如何合成补丁的

2. 无需自己搭建补丁管理后台

3. 无需考虑后台下发补丁策略的任何事情

4. 无需考虑补丁下载合成的时机，处理后台下发的策略

5. 提供了更加方便集成补锅匠的方式

6. 我们通过HTTPS及签名校验等机制保障补丁下发的安全性

7. 丰富的下发维度控制，有效控制补丁影响范围

8. 提供了应用升级一站式解决方案

1.添加插件依赖

工程根目录下“的build.gradle”文件中添加：

buildscript {

repositories {

jcenter()

}

dependencies {

// tinkersupport插件, 其中lastest.release指拉取最新版本，也可以指定明确版本号，例如1.0.4

classpath “com.tencent.bugly:tinker-support:1.1.2”

}

}

2.集成SDK

gradle这个配置

在app module的“build.gradle”文件中添加（示例配置）：

android {

defaultConfig {

ndk {

//设置支持的SO库架构

abiFilters ‘armeabi’ //, ‘x86’, ‘armeabi-v7a’, ‘x86_64’, ‘arm64-v8a’

}

}

}

dependencies {

compile “com.android.support:multidex:1.0.1” // 多dex配置

//注释掉原有bugly的仓库

//compile ‘com.tencent.bugly:crashreport:latest.release’//其中latest.release指代最新版本号，也可以指定明确的版本号，例如1.3.4

compile ‘com.tencent.bugly:crashreport_upgrade:1.3.5’

// 指定tinker依赖版本（注：应用升级1.3.5版本起，不再内置tinker）

compile ‘com.tencent.tinker:tinker-android-lib:1.9.6’

compile ‘com.tencent.bugly:nativecrashreport:latest.release’ //其中latest.release指代最新版本号，也可以指定明确的版本号，例如2.2.0

}

后续更新升级SDK时，只需变更配置脚本中的版本号即可。

在app module的“build.gradle”文件中添加：

// 依赖插件脚本

apply from: ‘tinker-support.gradle’

修补匠-support.gradle内容如下所示：

apply plugin: ‘com.tencent.bugly.tinker-support’

def bakPath = file("${buildDir}/bakApk/")

/**

• 此处填写每次构建生成的基准包目录

*/

def baseApkDir = “app-0208-15-10-00”

/**

• 对于插件各参数的详细解析请参考

*/

tinkerSupport {

// 开启tinker-support插件，默认值true

enable = true

// 指定归档目录，默认值当前module的子目录tinker

autoBackupApkDir = “${bakPath}”

// 是否启用覆盖tinkerPatch配置功能，默认值false

// 开启后tinkerPatch配置不生效，即无需添加tinkerPatch

overrideTinkerPatchConfiguration = true

// 编译补丁包时，必需指定基线版本的apk，默认值为空

// 如果为空，则表示不是进行补丁包的编译

// @{link tinkerPatch.oldApk }

baseApk = “$bakPath/${baseApkDir}/app-release.apk”

// 对应tinker插件applyMapping

baseApkProguardMapping = “$bakPath/${baseApkDir}/app-release-mapping.txt”

// 对应tinker插件applyResourceMapping

baseApkResourceMapping = “$bakPath/${baseApkDir}/app-release-R.txt”

// 构建基准包和补丁包都要指定不同的tinkerId，并且必须保证唯一性

tinkerId = “base-1.0.1”

// 构建多渠道补丁时使用

// buildAllFlavorsDir = “$bakPath/${baseApkDir}”

// 是否启用加固模式，默认为false.(tinker-spport 1.0.7起支持）

// isProtectedApp = true

// 是否开启反射Application模式

enableProxyApplication = false

// 是否支持新增非export的Activity（注意：设置为true才能修改AndroidManifest文件）

supportHotplugComponent = true

}

/**

• 一般来说,我们无需对下面的参数做任何的修改

• 对于各参数的详细介绍请参考:

• https://github.com/Tencent/tinker/wiki/Tinker-%E6%8E%A5%E5%85%A5%E6%8C%87%E5%8D%97

*/

tinkerPatch {

//oldApk ="$bakPath/${appName}/app-release.apk"

ignoreWarning = false

useSign = true

dex {

dexMode = “jar”

pattern = [“classes*.dex”]

loader = []

}

lib {

pattern = [“lib//.so”]

}

res {

pattern = [“res/", "r/”, “assets/*”, “resources.arsc”, “AndroidManifest.xml”]

ignoreChange = []

largeModSize = 100

}

packageConfig {

}

sevenZip {

zipArtifact = “com.tencent.mm:SevenZip:1.1.10”

// path = “/usr/local/bin/7za”

}

buildConfig {

keepDexApply = false

//tinkerId = “1.0.1-base”

//applyMapping = “$bakPath/${appName}/app-release-mapping.txt” // 可选，设置mapping文件，建议保持旧apk的proguard混淆方式

//applyResourceMapping = “$bakPath/${appName}/app-release-R.txt” // 可选，设置R.txt文件，通过旧apk文件保持ResId的分配

}

}

3.初始化SDK

enableProxyApplication = false的情况

集成Bugly升级SDK之后，我们需要按照以下方式自定义ApplicationLike来实现的应用的代码（以下是示例）：

自定义应用程序

public class SampleApplication extends TinkerApplication {

public SampleApplication() {

super(ShareConstants.TINKER_ENABLE_ALL, “xxx.xxx.SampleApplicationLike”,

“com.tencent.tinker.loader.TinkerLoader”, false);

}

}

参数1：tinkerFlags表示Tinker支持的类型dex only，仅库或所有suuport，默认：TINKER_ENABLE_ALL

参数2：delegateClassName Application代理类这里填写你自定义的ApplicationLike

参数3：loaderClassName Tinker的加载器，使用默认即可

参数4：tinkerLoadVerifyFlag加载dex或者lib是否验证md5，默认为false

需要一个应用配置为继承TinkerApplication的类：

自定义ApplicationLike：

public class SampleApplicationLike extends DefaultApplicationLike {

public static final String TAG = “Tinker.SampleApplicationLike”;

public SampleApplicationLike(Application applicat

《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》

【docs.qq.com/doc/DSkNLaERkbnFoS0ZF】 完整内容开源分享

ion, int tinkerFlags,

boolean tinkerLoadVerifyFlag, long applicationStartElapsedTime,

long applicationStartMillisTime, Intent tinkerResultIntent) {

super(application, tinkerFlags, tinkerLoadVerifyFlag, applicationStartElapsedTime, applicationStartMillisTime, tinkerResultIntent);

}

@Override

public void onCreate() {

super.onCreate();

// 这里实现SDK初始化，appId替换成你的在Bugly平台申请的appId

// 调试时，将第三个参数改为true

Bugly.init(getApplication(), “900029763”, false);

}

@TargetApi(Build.VERSION_CODES.ICE_CREAM_SANDWICH)

@Override

public void onBaseContextAttached(Context base) {

super.onBaseContextAttached(base);

// you must install multiDex whatever tinker is installed!

MultiDex.install(base);

// 安装tinker

// TinkerManager.installTinker(this); 替换成下面Bugly提供的方法

Beta.installTinker(this);

}

@TargetApi(Build.VERSION_CODES.ICE_CREAM_SANDWICH)

public void registerActivityLifecycleCallback(Application.ActivityLifecycleCallbacks callbacks) {

getApplication().registerActivityLifecycleCallbacks(callbacks);

}

}

enableProxyApplication = true的情况：

public class MyApplication extends Application {

@Override

public void onCreate() {

super.onCreate();

// 这里实现SDK初始化，appId替换成你的在Bugly平台申请的appId

// 调试时，将第三个参数改为true

Bugly.init(this, “900029763”, false);

}

@Override

protected void attachBaseContext(Context base) {

super.attachBaseContext(base);

// you must install multiDex whatever tinker is installed!

MultiDex.install(base);

// 安装tinker

Beta.installTinker();

}

}

4.Androidmanifest.xml配置
isterActivityLifecycleCallbacks(callbacks);

}

}

enableProxyApplication = true的情况：

public class MyApplication extends Application {

@Override

public void onCreate() {

super.onCreate();

// 这里实现SDK初始化，appId替换成你的在Bugly平台申请的appId

// 调试时，将第三个参数改为true

Bugly.init(this, “900029763”, false);

}

@Override

protected void attachBaseContext(Context base) {

super.attachBaseContext(base);

// you must install multiDex whatever tinker is installed!

MultiDex.install(base);

// 安装tinker

Beta.installTinker();

}

}

4.Androidmanifest.xml配置