全部产品
云市场

使用热修复

更新时间:2020-05-20 17:10:05

前置条件

  1. 需要框架来接管Application,在 AndroidManifest 中声明框架中的定义的 Application,可以参考 获取代码示例 中热修复部分的 demo。
  2. 您已经使用 mPaaS 插件生成加密图片。具体内容,查看 图片加密功能

操作步骤

在当前 App 的基础上集成 mPaaS 提供的 Hotpatch 热修复功能,主要分为以下两大模块:

  • 线下集成:为 App 集成热修复能力,包括以下步骤:
    1. 添加 SDK
    2. 配置工程
    3. 触发热部署
  • 线上发布:当线上 App 出现问题后,通过 mPaaS 插件生成热修复包,并上传到发布平台,进行线上问题修复。要了解 mPaaS 插件中热修复包相关功能,查看 热修复包功能

添加 SDK

基于 mpaas 框架接入

使用 mPaaS 插件,分别在 Portal 和 Bundle 工程中添加 RPCHOTFIX 模块依赖。更多信息,请参考 管理组件依赖

基于 aar 接入

使用 mPaaS 插件,引入 aar的依赖,请参考 原生接入方式

配置工程

客户端在不同的场景下会去发布平台实时检查是否有新的热修复包,如果有,就会下载到客户端安装。为保证能获取到发布平台下发的热修复包,您需要把发布平台的地址等信息添加到配置文件中,以下两种方式二选一

第一种方式:自动配置(推荐)

  1. 将您已经签名过的 APK 上传到控制台。
  2. 从 mPaaS 控制台中下载配置信息:
    • 配置信息示例:
    • 将您下载的 Ant-mpaas-xxxxx.config 文件复制到您工程目录下,具体路径在 app module 的工程下:
    • 注意在您的引入插件的 build.gradle 中引入相关依赖:
      1. classpath 'com.android.boost.easyconfig:easyconfig:2.2.17'
  3. 在您的 app 工程中,确认使用了这个插件:
    1. apply plugin: 'com.alipay.apollo.baseline.update'

第二种方式:手动配置应用信息

  1. AndroidManifest 中配置以下内容,其中 %s 标识的占位符为需要配置的具体数据。
    1. <!--这里是hotpatch、检测更新等的网关-->
    2. <meta-data
    3. android:name="mpaasapi"
    4. android:value="http://%s/mgw.htm"/>
    5. <!-- rpc -->
    6. <meta-data
    7. android:name="mobilegw.url"
    8. android:value="http://%s/mgw.htm"/>
    9. <!-- rpc version-->
    10. <meta-data
    11. android:name="mobilegw.rpcVersion"
    12. android:value="V2"/>
    13. <!--无线保镖 appkey, used for encrypt-->
    14. <meta-data
    15. android:name="appkey"
    16. android:value="%s"/>
    17. <!-- work space id -->
    18. <meta-data
    19. android:name="workspaceId"
    20. android:value="%s"/>
  2. Assets 目录下创建 mpaas.properties 文件,内容如下:
    1. WorkspaceId=%s
    2. AppId=%s
    3. Platform=ANDROID

生成热修复补丁

参见 生成热修复包

触发热部署

触发热部署方法为:

  1. MPHotpatch.init()
说明:建议在应用启动时调用 MPHotpatch.init();

查看触发是否生效

您可通过过滤日志 DynamicRelease 来判断触发是否生效。

说明:日志过滤时需要选择 No Filters
  1. 正常的下载日志内容如下:
  2. 检查热修复补丁是否合并成功。
    如果查看到已经下载成功,请继续检查日志,搜索或者过滤以下关键字:
    1. monitorDexPatchSuccess()
    如果出现了这一行,表示热修复合并成功,此时可以在后台杀死您的 App,重启查看热修复是否生效。
    合并成功

合并成功后热修复依旧不生效

请使用 jadx 等工具反编译您的热修复补丁包,查看里面是否有相应的热修复代码。如果没有热修复代码,可能是您生成热修复的方式不对,可能的情况如下:

  • 白名单指定的类不对,并不是需要被修复的类。
  • 签名不正确,没有生成热修复补丁。

线上发布

通过线下集成的操作后,您的应用就拥有了热修复能力,当您发现线上应用的 bug 后,可以使用 Hotpatch 将线上的错误代码替换掉,执行正确逻辑。然后通过发布平台推送给用户进行修复。整个发布过程可以分为以下三步:

  1. 准备两个包:一个是有 bug 的包,一个是修复之后打出来的包。如果是基于 mPaaS Android 开发框架的工程,需要准备两个 bundle 包。在之后生成热修复包的时候,会比较这两个包的差异得到最终的热修复包。
  2. 生成热修复包,参考 热修复功能
  3. 发布热修复包,参考 热修复管理

热修复示例

本节结合 代码示例 中的 热修复 示例,对热修复过程进行详细的说明介绍。

该代码示例中的修复内容是弹出的 toast 中的内容。

  1. 修复前点击 模拟需要被热修复的点击事件 按钮,弹出如下图所示的 toast。
    异常,当前点击事件未被热修复

  2. 进行修复点击 触发热修复部署检测 按钮,触发热修复的下载。在下载完成后,彻底关闭 Demo 应用并重新启动。

  3. 修复后点击 模拟需要被热修复的点击事件 按钮,会弹出 “当前点击事件已被热修复” 的 toast。
    当前点击事件已被热修复