鸿蒙HarmonyOS NEXT应用崩溃分析及修复

如何保证应用的健壮性，其中一个指标就是看崩溃率，如何降低崩溃率，就需要知道存在哪些崩溃，然后对症下药，解决崩溃。那么鸿蒙应用中存在哪些崩溃类型呢？又改如何解决呢？

故障类型

目前鸿蒙中存在的崩溃主要分为CPP_CRASH、JS_ERROR、OOM、PROCESS_KILL、APP_FREEZE、RESOURCE_LEAK6大类型。

CPP_CRASH类型

主要是进程崩溃指C/C++运行时崩溃，主要体现在so相关的sdk上。

1.空指针解引用 NULL pointer dereference
形如SIGSEGV(SEGV_MAPERR)@0x00000000或r0 r1等传参寄存器的值为0时应首先考虑调用时是否传入了空指针

2.结构体/类未初始化指针
形如SIGSEGV(SEGV_MAPERR)@0x0000000c或 r1等传参寄存器的值为一个很小的值时应考虑调用入参的结构体成员是否包含空指针

3.程序主动终止SIGABRT
一般为用户/框架/C库主动触发，大部分场景下跳过C库/abort发起的框架库的第一帧即为崩溃原因
这里主要检测的是资源使用类的问题，如线程创建，文件描述符使用，接口调用时序等

4.栈溢出
如递归调用，析构函数相互调用，特殊的栈(信号栈)中使用大块栈内存

5.多线程操作集合
std的集合为非线程安全，如果多线程添加删除，容易出现SIGSEGV, 如果使用addr2line后的代码行与集合相关，可以考虑这个原因

6.不匹配的对象生命周期
如使用裸指针保存sptr类型以及shared_ptr类型

7.返回临时变量、野指针
如返回栈变量的引用，释放后未置空继续访问

具体可参考官方
https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/fault-analysis

JS_ERROR类型

当未处理的JS异常导致应用意外退出时，应用会在抛出未处理的异常时崩溃并且会生成对应的JS Crash崩溃日志文件。

JS Crash异常根据不同的异常场景，在 Reason 字段进行了分类，分为Error、TypeError、SyntaxError、RangeError等错误类型。

自定义 Error 类：Error 是最基本的错误类型，其他的错误类型都继承自该类型。Error 对象主要有两个重要属性 message 和 name 分别表示错误信息和错误名称。程序运行过程中抛出的异常一般都有具体的类型，Error 类型一般都是开发人员自己抛出的异常。

TypeError（类型错误）类：运行时最常见的异常，表示变量或参数不是预期类型。

SyntaxError（语法错误）类：语法错误也称为解析错误。语法错误在任何编程语言中都是最常见的错误类型，表示不符合编程语言的语法规范。

RangeError（边界错误）类：表示超出有效范围时发生的异常，主要的有以下几种情况：
数组长度为负数或超长。
数字类型的方法参数超出预定义范围。
函数堆栈调用超过最大值。

ReferenceError - 引用错误：引用一个不存在的变量时发生的错误。每当我们创建一个变量时，变量名称都会写入一个变量存储中心中。这个变量存储中心就像键值存储一样，每当我们引用变量时，它都去存储中找到 key并提取并返回 value。如果我们要找的变量不在存储中，就会抛出 ReferenceError。

URI Error - URL错误：在调用 URI 相关的方法中 URL 无效时抛出的异常，主要包括 encodeURI()、decodeURI()、encodeURIComponent()、decodeURIComponent()、escape() 和 unescape() 几个函数。

其中这一类型的bug是最容易修复的，因为这些往往就是业务侧的一些不严谨代码导致的，异常也暴漏在业务层代码。

PROCESS_KILL类型

SWAP_FULL：系统交换分区空间不足，系统清理；
LowMemoryKill:系统整机可用内存较低，系统清理；
CAMERA_QUICK_Kll:相机场景内存需求较大，需要查杀应用清理内存；
这个不是异常，如果想规避可以通过降低自身内存占用，降低被清理的优先级。

APP_FREEZE类型

主要对应Appfreeze事件：
THREAD_BLOCK_6S 应用主线程卡死超时。
APP_INPUT_BLOCK 用户输入响应超时。
LIFECYCLE_TIMEOUT Ability生命周期切换超时。

主线程Watchdog(3S/6S)

用户输入事件超时5S
用户输入超时

生命周期切换超时分为Ability生命周期切换超时和PageAbility生命周期切换超时。

该故障出现在生命周期切换的过程中，影响当前应用内Ability的切换或者不同PageAbility之间的切换。
生命周期超时

OOM类型

内存溢出(Out Of Memory，简称OOM)是指应用系统中存在无法回收的内存或使用的内存过多，最终使得程序运行要用到的内存大于能提供的最大内存。此时程序就运行不了，系统会提示内存溢出。

RESOURCE_LEAK

资源泄漏是指句柄/线程/内存等资源超过系统设定上限，部分资源甚至失去了管控能力，此时系统可能出现卡死/重启等异常情况。LeakDetector模块提供资源泄漏检测、判决、维测日志抓取、日志上报的能力，为开发者提供详细的维测日志以辅助故障定位。

资源泄漏检测能力

故障恢复

代码定位

TypeError类问题在实际应用开发调试运行过程中是最常见的JS Crash类型，其表示为变量不是预期类型，在代码层面则为对变量的使用未进行事先的校验，在错误日志中报错多表现为如下：

Error name:TypeError
Error message:Cannot read property xxx of undefined

通过Error message很清除可以明白报错原因。

JS调用栈可直接通过超链接跳转到对应错误代码行，栈顶即为问题第一现场，如下样例所示。

Device info:xxx
Build info:xxx-xxx x.x.x.xxx(xxxx)
Fingerprint:ed1811f3f5ae13c7262b51aab73ddd01df95b2c64466a204e0d70e6461cf1697
Module name:com.xxx.xxx
Version:1.0.0
VersionCode:1000000
PreInstalled:No
Foreground:Yes
Pid:31255
Uid:20020145
Reason:Error
Error name:Error
Error message:JSERROR
Sourcecode:throw new ErrOr("JSERROR");^
Stacktrace:at anonymous (entry/src/main/ets/pages/Index.ets:13:19)

异常代码调用栈包含 SourceMap is not initialized yet ，表示因SourceMap转换非常耗时，改为通过异步线程去进行初始化，导致会出现SourceMap没初始化完成就有异常产生的情况。针对这种情况增加这行日志来提示开发者。eTS栈对应编译后产物中代码行号，可通过超链接跳转到对应错误代码行。

Generated by HiviewDFX@HarmonyOS
================================================================
Device info:xxxx
Build info:xxxx
Fingerprint:9851196f9fed7fd818170303296ae7a5767c9ab11f38fd8b0072f0e32c42ea39
Module name:com.xxx.xxx
Version:1.0.0.29
VersionCode:10000029
PreInstalled:Yes
Foreground:No
Pid:2780
Uid:20020018
Reason:TypeError
Error name:TypeError
Error message:Cannot read property needRenderTranslate of undefined
Stacktrace:
Cannot get SourceMap info, dump raw stack:at updateGestureValue (phone/src/main/ets/SceneBoard/recent/scenepanel/recentpanel/RecentGesture.ts:51:51)at onRecentGestureActionBegin (phone/src/main/ets/SceneBoard/scenemanager/SCBScenePanel.ts:5609:5609)at anonymous (phone/src/main/ets/SceneBoard/scenemanager/SCBScenePanel.ts:555:555)at anonymous (phone/src/main/ets/SceneBoard/recent/RecentEventView.ts:183:183)

Cannot get SourceMap info, dump raw stack 信息表示该应用为release包安装，JS栈转换eTS行列号失败，可考虑使用应用堆栈解析来解析行号。

应用堆栈解析

将报错信息直接使用ide查看，选择DevEco Studio底部log选择AnalyzeStackTrace，选择Source map、So、Name cache，点击start，右侧就会把ts对应的ets代码映射关系出来。
ide解析行号
或者使用三方网站 https://www.murzwin.com/base64vlq.html，将BaseEncode的报错，decode解析出来，效果是这样的，把ts的行列信息映射到ets中。
解析结果

sourceMaps和nameCache分别在下面的勾对号和红框里面的，文件是一样的，可能是针对不同使用方使用的。所以在打APP包产物的时候要备份sourceMaps和nameCache文件，就是为了转换报错信息使用的。sourceMaps是解决行列信息，nameCache主要是为了解混淆文件使用的。
在这里插入图片描述