接入热修复
接入热修复流程如下：
- 配置开发环境
- 在控制台创建应用
- 在客户端创建新工程
- 签名
- 配置加密信息
- 编写代码
- 发布带有热修复功能的客户端版本
配置开发环境
在控制台创建应用
在控制台创建 mPaaS 应用。此时，本地还没有带签名的 APK，因此在下载配置文件时，可以暂不上传 APK。
下载的配置文件的文件名示例：Ant-mpaas-4111111111005-default-Android.config。
在客户端创建新工程
接入流程 在客户端创建 基于 mPaaS 框架 的新工程，并确保使用 mPaaS > Build 成功构建工程。
说明
在添加 SDK 时，需要确保勾选了下图中的 HOTFIX 和 RPC。
签名
签名是为了下一步配置加密信息做准备。
在 Android Studio 中打开 Portal 工程，然后 Android 官网文档 给应用签名，并生成带签名的 APK。
签名步骤如下：
- 生成密钥和密钥库。若已有密钥库，则可忽略此步骤。
-
在 Android Studio 中打开 Portal 工程，点击 Build > Generate Signed APK，然后点击 Create new。
-
完善相关信息，然后点击 OK。您需要记住此处填写的信息，以便在后续操作中使用。
- 生成带签名的 APK。
-
选择密钥库，填写相关信息，然后点击 Next：
- 如下图完善相关信息，然后点击 Finish；等待片刻，即可生成带签名的 APK。 说明
- Signature Versions 中 V1(Jar Signature) 必须勾选，V2(Full APK Signature) 可按需勾选。
-
带签名的 APK 将保存在 {APK Destination Folder}/{Build Type} 目录下。在下图的示例中，保存目录为 /Users/archer.zb/AndroidStudioProjects/Tutorials/Hotpatch/app/debug/。
- 在代码中增加签名配置。配置完成后，build.gradle 示例如下： signingConfigs { release { keyAlias 'keyAlias' keyPassword 'keyPassword' storeFile file('/Users/archer.zb/Desktop/hotpatch/keystore.jks') storePassword 'storePassword' } debug { keyAlias 'keyAlias' keyPassword 'keyPassword' storeFile file('/Users/archer.zb/Desktop/hotpatch/keystore.jks') storePassword 'storePassword' } }
配置加密信息
为了保证客户端获取热修复包过程的安全，需要对网络内容进行加密。配置加密信息的步骤如下：
- 到控制台重新下载配置文件。 登录 mPaaS 控制台 后，进入 总览 > 下载 Android 代码配置 > 代码配置 页面，上传上一步生成的带签名 APK，并再次下载配置文件。此时，将下载到 .zip 压缩包。
-
解压 .zip 包，用其中的 Ant-mpaas-xxx-xxx-Android.config 文件替换 Portal 工程主 module 中的同名文件。 重要 替换后的 base64Code 的值一定非空。
-
删除 Portal 工程主 module src/main/res/drawable 中的 yw_1222.jpg 图片：
- 分别重新构建 Bundle、Portal 工程。
编写代码
至此，热修复就已经接入，您可以根据业务需求编写代码。
示例按钮
说明
下方示例为体验热修复功能的示例代码，以便您在发布前体验热修复功能。
为了体验热修复，您可以在 Bundle 工程的界面中增加两个按钮：
- Toast：该按钮对应的代码存在 Bug，点击会造成应用崩溃。
- Hotfix：在控制台发布热修复包后，点击该按钮，触发热修复；重启应用后，Toast 按钮对应的代码 Bug 将被修复。
示例代码
对应的布局代码如下：
<Button
android:id="@+id/toast"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:text="Toast" />
<Button
android:id="@+id/hotfix"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:text="Hotfix" />
对应的 Java 代码如下：
findViewById(R.id.toast).setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View view) {
// 按钮点击时，先做除法运算，再通过弹出框显示计算结果
int result = 1/0; // 除数为 0，是个 bug，会导致应用崩溃
Toast.makeText(getApplicationContext(), "result = " + result, Toast.LENGTH_SHORT).show();
}
});
findViewById(R.id.hotfix).setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View view) {
// 按钮点击时，触发热修复
// SDK 版本 ≥ 10.1.32 时，调用如下接口：
MPHotpatch.init();
}
});
加入示例代码后，重新构建 Bundle 与 Portal 生成的 APK 即可。体验热修复过程详见下方的 热修复 Bug 演示。
发布带有热修复功能的客户端版本
在编写完客户端代码后，即可将生成的 APK 发布至应用平台，以便 App 用户可下载更新。
热修复 Bug 演示
热修复 Bug 的示例流程如下：
- 备份 Bug 版本构建生成的 .jar 包
- 修改 Bug 代码，生成热修复包
- 在控制台添加并发布热修复包
- 客户端调用触发热修复的接口，进而获取热修复包
- 应用重启后，触发热修复，Bug 被修复
备份 Bug 版本构建生成的 .jar 包
生成热修复包时，需要新老版本（即 Bug 版本和修复后的版本）的构建结果。因此，首先需要备份 Bug 版本构建生成的 .jar 包。
.jar 包路径：
- 若构建 debug 包，则为 Bundle 主 module 下的 build/intermediates/bundle/xxxx-raw.jar。
-
若构建 release 包，则 .jar 包名称没有 -raw 后缀。示例：
修改 Bug 代码
修改 Bug 代码，并重新构建工程。对应上文示例，可将除数改成 1：
生成热修复包
在 Android Studio 中，使用 mPaaS > Generate Hotpatch 功能生成热修复包：
- New bundle：修改代码 Bug 后，重新构建生成的 .jar 包。
- Old bundle：备份的 Bug 版本构建生成的 .jar 包。详见上文 备份 Bug 版本构建生成的 .jar 包。
- 白名单（可选）：用于指定修复的类的配置文件，.txt 格式，该配置文件的编写规则见 白名单配置文件编写规则。使用原生 AAR 工程和 mPaaS Inside 工程时强烈推荐使用该功能。
-
Patch file dir：热修复包的保存路径。该路径下将会生成很多文件，后续有用的是 .jar 文件：
- 是否使用 DexPatch：建议勾选。
在控制台添加并发布热修复包
添加热修复包
- 进入mPaas 控制台 > 实时发布 > 热修复管理 页面。
-
点击 添加热修复，然后完善相关信息，并点击 确定。
创建发布
-
如下图，点击 创建发布。
- 选择发布类型等，然后点击 确定 即可完成发布。更多信息，参见 热修复管理。
App 触发热修复
-
打开 Android Studio Logcat，关键词填写 DynamicRelease，过滤器选择 No Filters。
-
确保手机连接 Android Studio，然后打开手机上安装的 Bug 版 App，点击 Hotfix 按钮，可以看到如下日志：
- 关闭应用进程、重启应用后，点击 Toast 按钮，可以正常看到弹出框，说明 Bug 已被修复。
说明
若热修复未生效，且日志中出现 RPCException [7001] 异常，则说明签名错误。重复 签名 步骤，并确保：
- Portal 工程主 module Ant-mpaas-xxx-xxx-Android.config 文件中的 base64Code 的值非空。
- Portal 工程主 module build.gradle 文件中 signingConfigs 配置正确。
以上就是有关热修复技术，在Android开发中这类的核心技术还有很多。更多技术学习参考；可前往《Android核心 技术手册》里面内容包含30多个技术模块并分别制作成PDF文档。供大家方便学习！
文末
热修复：让应用能够在无需重新安装的情况实现更新，帮助应用快速建立动态修复能力。
早期遇到Bug我们一般会紧急发布了一个版本。然而这个Bug可能就是简简单单的一行代码，为了这一行代码，进行全量或者增量更新迭代一个版本，未免有点大材小用了。而且新版本的普及需要时间，以Android用户的升级习惯，即使是相对活跃的微信也需要10天以上的时间去覆盖50%的用户。使用热修复技术，能做到1天覆盖70%以上。这也是基于补丁体积较小，可以直接使用移动网络下载更新。
网友评论