
【HarmonyOS Next】鸿蒙应用故障处理思路详解 原创
【HarmonyOS Next】鸿蒙应用崩溃处理思路详解
一、崩溃问题发现后定位
1. 崩溃现象:
常见的崩溃问题表现为,应用操作后白屏闪退,或者应用显示无响应卡死。
2.定位问题:
发现崩溃后,我们首先需要了解复现步骤,精确定位复现步骤。因为提供复现步骤得人,可能是用户和测试,非开发人员,其中的步骤并非最短路径。
3.排查问题点
根据复现步骤,我们需要查看日志表现,鸿蒙的DevEco IDE提供了日志看板,根据HiLog和FaultLog,我们可以初步区分崩溃问题的类型。
根据日志看板的FaultLog,可以查看崩溃输出的
- JS Crash,一般是ArkTS原生逻辑的崩溃
- CppCrash,一般是NDK,C层的崩溃
JS Crash
点击进入JS Crash中,可以查看到崩溃信息,以下几种类型的错误:
可以根据JS Crash提示的错误行数,直接点击跳转到错误代码处,根据提示检查和修复问题。
CppCrash
根据日志提示,检查是否有以下错误情况:
AppFreeze
一般是由于耗时操作,导致堵塞主线程。此时用户操作时,会触发无响应。一般分为以下三种情况,超时时间一般在6s左右。
内存泄漏
这种问题排查起来是最麻烦的,所以保持良好的代码编程规范,不需要的对象该释放释放,不用的句柄也需要释放。
一般碰到内存泄漏,根据提供的复现步骤,很多情况下是非必现。(如果是必现,那最好了,修复该问题会很快。)我们需要操作复现步骤,使用鸿蒙DevEco IDE的ProFiler工具:
检测应用操作时的内存使用情况。
二、问题解决,检查类似错误情况一起修复
1.根据章节一问题定位清楚后,根据错误具体情况,思考修复方案
2.根据问题情况,检查其他代码是否有同类问题,一起修复后验证。
3.根据官网提供的材料进行学习,编码过程中进行规范和排查:
性能优化举例:
业务场景是:点击跳转下一页,直接加载Web页面。这是大多数三方应用的实现方式,其实应该在后台创建一个ArkWeb组件来预先启动用于渲染的Web渲染进程。这样跳转到web页面的时间就不会那么长:
三、思考如何避免问题再次发生,复盘
1.保持好的开发习惯创建踩坑文档,避免自己第二次再发生该问题
2.根据错误情况,分析是否为自己代码逻辑问题,逻辑bug不可避免,只能从开发经验和code review中尽量避免
3.代码容错分支问题,只保证了主流程,未考虑代码错误分支的覆盖情况。这种情况,需要自己吸取教训,避免再次发生。
4.使用检测工具对代码进行扫描,提前规避一些问题:
5.使用IDE提供的AppAnglyzer生成应用检测报告。根据报告提示,进行修改:
6.使用鸿蒙提供的DevEco Testing工具,进行稳定性和功耗等测试:
