应用研发平台EMAS 移动热修复补丁打包时间非常长像卡住了一样，该如何解决？

使用gradle plugin版本高于4.2时，可能会自动开启资源优化。开启资源优化后，资源名称被混淆，会导致补丁工具在生成补丁时一直卡在"开始构建补丁....."，无法正常解析apk包。

解决方案：在gradle.properties 中新增android.enableResourceOptimizations=false，重新生成基线包和修复包，然后再生成补丁。

移动热修复补丁加载流程示意图

应用补丁后没有生效的排查步骤。

您可以根据以下信息进行排查：

首先您可以按照文档中的测试方式进行测试，使用调试工具对补丁进行本地测试，详情请参见调试工具。注意此时初始化setEnableDebug值一定要为true，否则应用打不上补丁。然后将补丁上传到管理控制台，进行扫码测试，随后可以进行灰度发布测试。确认没问题后再进行全量发布。
如果拉取后参数有错误或解压失败，可以先检查各参数是否完全正确，然后在文档中详细查看各参数的使用说明，尤其是AesKey的使用。
在应用补丁后，提示“code=12”信息，这是冷启动生效，需要您结束App进程（注意是结束进程，不是退出App），使其重启即可。若您想了解补丁对应的状态码信息，请参见补丁常见状态码。
补丁应用成功后，可能出现崩溃问题，以下是几个常见的问题：
IOException异常，已经下载补丁却提示补丁找不到。
可能是由于在初始化的回调或者其他位置存在cleanPatches导致的，现在SDK已有对应删除补丁的机制，cleanPatches方法不需要自己写，可以注释掉重复的方法，然后进行测试。
找不到方法或类的崩溃。
检查修复包是否使用基线包的mapping文件进行混淆。
出现“java.lang.ClassNotFoundException”异常，或资源修改部分生效、部分未生效。
请先查看初始化前的代码，是否可以调用系统类而不可以调用自定义类（例如自定义的LogUtils类）。检查当前运行加载补丁的包是否为对应的旧包；如果是Android Studio打包的APK，必须关闭Instant Run，并建议使用Release的包进行测试。
如果热补丁在部分机型上加载后出现问题，将补丁工具勾选强制冷启动，重新打个补丁。
也可以直接查看日志进行排查，上述问题在日志中都有体现，在日志中过滤Sophix即可获取热修复的日志。

一个补丁的加载一般分为三个阶段：查询、预加载、加载，各个阶段的常见状态码如下：

调试工具