从0到1创建一个Android工程，并使用热修复功能

热修复是什么？

一般的bug修复，都是等下一个版本解决，然后发布新的apk。
热修复：可以直接在客户已经安装的程序当中修复bug。

bug一般会出现在某个类的某个方法地方。
如果我们能够动态地将客户手机里面的apk里面的某个类给替换成我们已经修复好的类。

在这里插入图片描述

热修复应用于那些场景

每一次热修复，都是一次 紧急发布。因此，mPaaS 限定了热修复的使用范围是：在来不及发布版本的情况下，需要立刻解决线上客户端问题。

根据最佳实践，热修复只用于修复严重的、影响面大的、具有高可复现性的问题。包括但不仅限于以下情况：

高概率的闪退
严重的 UI 问题
可能造成资损与用户投诉的故障
客户端某些功能不能使用
监管审查导致的紧急修改

热修复优点

当线上应用出现紧急BUG，为了避免重新发版，并且保证修复的及时性而进行的一项在线推送补丁的修复方案。

无需重新发版
用户无感知修复,无需下载最新的应用,代价小
修复成功率高，把损失降到最低

热修复对于我们来说只是一种亡羊补牢的手段，市面上现有的热修复框架都有一定的兼容性问题，不到万不得已也不会去使用的。

热修复使用

接入热修复

接入热修复流程如下：

配置开发环境
在控制台创建应用
在客户端创建新工程
签名
配置加密信息
编写代码
发布带有热修复功能的客户端版本

配置开发环境

参考文档配置开发环境及Android进阶技术。

在控制台创建应用

参考在控制台创建 mPaaS 应用。此时，本地还没有带签名的 APK，因此在下载配置文件时，可以暂不上传 APK。

阿里云配置

下载的配置文件的文件名示例：Ant-mpaas-4111111111005-default-Android.config。

在客户端创建新工程

在客户端创建 基于 mPaaS 框架 的新工程，并确保使用 mPaaS > Build 成功构建工程。

说明

在添加 SDK 时，需要确保勾选了下图中的 HOTFIX 和 RPC。

签名

签名是为了下一步配置加密信息做准备。

在 Android Studio 中打开 Portal 工程，然后参考 Android 官网文档给应用签名，并生成带签名的 APK。

签名步骤如下：

生成密钥和密钥库。若已有密钥库，则可忽略此步骤。
1. 在 Android Studio 中打开 Portal 工程，点击 Build > Generate Signed APK，然后点击 Create new。
2. 完善相关信息，然后点击 OK。您需要记住此处填写的信息，以便在后续操作中使用。
生成带签名的 APK。
1. 选择密钥库，填写相关信息，然后点击 Next：
2. 如下图完善相关信息，然后点击 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/。

参考 Android 官网文档，在代码中增加签名配置。配置完成后，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 工程的界面中增加两个按钮：

add_buttons

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();
  }
});

MainActivity.java

加入示例代码后，重新构建 Bundle 与 Portal 生成的 APK 即可。

发布带有热修复功能的客户端版本

在编写完客户端代码后，即可将生成的 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：

fix_code

生成热修复包

在 Android Studio 中，使用 mPaaS > Generate Hotpatch 功能生成热修复包：

gen_hotpatch_file

New bundle：修改代码 Bug 后，重新构建生成的 .jar 包。
Old bundle：备份的 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核心技术进阶手册、实战笔记

不推荐重复造轮子，当然如果你能造出更好的轮子，前面那句话当我没说。