一、常见的稳定性问题

1.1 有哪些稳定性问题
一般有cppcrash、jscrash、appfreeze、功耗问题。本文主要介绍前三种。
1.2 不同问题的特征
（1）cppcrash
即应用崩溃，发生在Native代码上，在未处理崩溃异常信号时生成崩溃日志。日志结构如下：

Generated by HiviewDFX@HarmonyOS
================================================================
Device info:HarmonyOS 3.2   <- 设备信息
Build info:HarmonyOS 5.1.0.101 <- 版本信息
DeviceDebuggable:No <- 设备的系统版本是否可调试
Fingerprint:67bc4e29d8af56b6c0cbda154095949e83f3f1d6afe05bfc06c6cbb9f5591bb0 <- 标识故障特征
Module name:com.example.myapplication <- 模块名
ReleaseType:debug <- 应用的版本类型
CpuAbi:arm64-v8a <- 二进制接口类型
Version:1.0.0 <- 应用版本号(点分格式)
VersionCode:1000000 <- 应用版本号(整数格式)
IsSystemApp:No <- 应用是否为系统应用
PreInstalled:No <- 是否预制应用
Foreground:Yes <- 前后台状态
Page switch history: <- 页面切换轨迹
  11:43:21.840 :enters foreground
  11:43:17.317 :leaves foreground
  11:42:46.780 :enters foreground
Timestamp:2026-01-21 11:43:35.140 <- 故障发生时间戳
Pid:11941 <- 进程号
Uid:20020205 <- 用户ID
HiTraceId:a92ab1c7eae68fa <- HiTraceChain唯一跟踪标识(非必选，故障线程无HiTraceId不打印)
Process name:com.example.myapplication <- 故障进程名
Process life time:50s <- 故障进程存活时间
Process Memory(kB): 185430(Rss) <- 故障进程内存占用
Device Memory(kB): Total 11688288, Free 2427804, Available 5592064 <- 整机内存状态（非必选）
Reason:Signal:SIGSEGV(SI_USER)@0x000000000000303e from:12350:0 <- 故障原因，详见信号值说明
Fault thread info:           <- 故障线程信息
Tid:11941, Name:.hiappeventtest  <- 故障线程号，线程名
#00 pc 00000000001843f0 /system/lib/ld-musl-aarch64.so.1(epoll_wait+80)(6c643df40fcfff22745e25b37e2ca85b) <- 调用栈，调用顺序#06->#05->...->#00，最终在#00的函数中发生崩溃
#01 pc 0000000000021b74 /system/lib64/chipset-sdk-sp/libeventhandler.z.so(OHOS::AppExecFwk::EpollIoWaiter::WaitFor(std::__h::unique_lock<std::__h::mutex>&, long, bool)+232)(ed7ae4e867a4ab26cb8c67afc737116c)
#02 pc 00000000000273f8 /system/lib64/chipset-sdk-sp/libeventhandler.z.so(OHOS::AppExecFwk::EventQueue::WaitUntilLocked(std::__h::chrono::time_point<std::__h::chrono::steady_clock, std::__h::chrono::duration<long long, std::__h::ratio<1l, 1000000000l>>> const&, std::__h::unique_lock<std::__h::mutex>&, bool)+112)(ed7ae4e867a4ab26cb8c67afc737116c)
#03 pc 000000000002c358 /system/lib64/chipset-sdk-sp/libeventhandler.z.so(OHOS::AppExecFwk::EventQueueBase::GetEvent()+168)(ed7ae4e867a4ab26cb8c67afc737116c)
#04 pc 000000000001b148 /system/lib64/chipset-sdk-sp/libeventhandler.z.so(OHOS::AppExecFwk::(anonymous namespace)::EventRunnerImpl::Run()+808)(ed7ae4e867a4ab26cb8c67afc737116c)
#05 pc 000000000001fa04 /system/lib64/chipset-sdk-sp/libeventhandler.z.so(OHOS::AppExecFwk::EventRunner::Run()+356)(ed7ae4e867a4ab26cb8c67afc737116c)
#06 pc 00000000000f3a4c /system/lib64/platformsdk/libappkit_native.z.so(OHOS::AppExecFwk::MainThread::Start()+240)(e30f6c7f026034c7d6fa1692a05d3d69)
Registers:  <- 故障现场寄存器
x0:fffffffffffffffc x1:0000007e5420ad60 x2:0000000000000008 x3:000000007fffffff
x4:0000000000000000 x5:0000000000000008 x6:575f45524f464542 x7:474e49544941575f
x8:0000000000000016 x9:0000000000000008 x10:0000007e5420ad60 x11:e18b0e5877a00005
x12:000000003b9ac9ff x13:007070632e72656e x14:2f72656c646e6168 x15:8f94b1d6208ca9b4
x16:0000005afeafe7d0 x17:0000005afb7f83a0 x18:000000000000000d x19:0000005b1b4dde10
x20:0000005b0c5fcf20 x21:0000005b1b4ddda0 x22:7fffffafde60b8cc x23:0000005b1b4ddda0
x24:0000007e5420af40 x25:0000000000000000 x26:0000000000000000 x27:00000055a511d354
x28:0000005b1a937bc8 x29:0000007e5420ad20
lr:0000005afeae1b78 sp:0000007e5420ad20 pc:0000005afb7f83f0
pstate:0000000020001000 esr:0000000000000000          <-  状态寄存器值（arm32架构为cpsr，aarch64架构为pstate和esr）
Other thread info:      <- 其他线程信息
Tid:12006, Name:OS_IPC_0_120064 <- 线程号，线程名
#00 pc 00000000001a4524 /system/lib/ld-musl-aarch64.so.1(ioctl+200)(6c643df40fcfff22745e25b37e2ca85b)
#01 pc 0000000000012044 /system/lib64/platformsdk/libipc_common.z.so(OHOS::BinderConnector::WriteBinder(unsigned long, void*)+120)(036a4c254e8f85b2af1c2a4f4d540e45)
#02 pc 0000000000070ae8 /system/lib64/platformsdk/libipc_single.z.so(OHOS::BinderInvoker::TransactWithDriver(bool)+284)(f9c345696cb6cee8d986e176f59f003d)
#03 pc 0000000000070ed8 /system/lib64/platformsdk/libipc_single.z.so(OHOS::BinderInvoker::StartWorkLoop()+100)(f9c345696cb6cee8d986e176f59f003d)
Memory near registers:  <-  故障现场寄存器的地址（地址必须在有效内存中）附近内存值，括号表示寄存器里的地址是在哪一段内存中
x1([stack]):         <- 故障现场r1寄存器的地址附近内存值
    0000007e5420ad50 0000000000000000
    0000007e5420ad58 0000005afeaec828
    0000007e5420ad60 0000000000000000
    0000007e5420ad68 0000000000000000
    ...
x10([stack]):
    0000007e5420ad50 0000000000000000
    0000007e5420ad58 0000005afeaec828
    0000007e5420ad60 0000000000000000
    0000007e5420ad68 0000000000000000
    0000007e5420ad70 0000000000000000
    ...
fp([stack]):
    0000007e5420ad10 7fffffafde60b8cc
    0000007e5420ad18 0000005b1b4ddda0
    0000007e5420ad20 0000007e5420ae70
    0000007e5420ad28 0000005afeae1b78
    ...
sp([stack]):
    0000007e5420ad10 7fffffafde60b8cc
    0000007e5420ad18 0000005b1b4ddda0
    0000007e5420ad20 0000007e5420ae70
    0000007e5420ad28 0000005afeae1b78
    ...
lr(/system/lib64/chipset-sdk-sp/libeventhandler.z.so):
    0000005afeae1a80 2a1f03e0940067e8
    0000005afeae1a88 b00000ef17ffff7c
    0000005afeae1a90 ca1d01eff945a5ef
    0000005afeae1a98 d503237fca1e01ef
    ...
pc(/system/lib/ld-musl-aarch64.so.1):
    0000005afb7f82f8 f9000bf3a9be7bfd
    0000005afb7f8300 f0001bc8910003fd
    0000005afb7f8308 aa0103eaaa0403e5
    0000005afb7f8310 93407c4993407c01
    ...
FaultStack: <- 崩溃线程的栈地址空间
    0000007e5420ac20 0000007e00000072
    0000007e5420ac28 73615474736f5010
    0000007e5420ac30 0000007e5420006b
    0000007e5420ac38 ffffff80fffffff8
    ...
sp0:0000007e5420ad20 0000007e5420ae70 <- #00层栈帧顶部位置
    0000007e5420ad28 0000005afeae1b78
    ...
sp1:0000007e5420ad40 0000007e5420aed0
    0000007e5420ad48 815c005afeaec858
    ...
sp2:0000007e5420aee0 0000007e5420af50
    0000007e5420aee8 7835005afeaec35c
    ...
sp3:0000007e5420af20 00000050219e3694
    0000007e5420af28 0000000000000000
    ...

Maps: <- 故障时进程的内存空间
55a511d000-55a5128000 r--p 00000000 /system/bin/appspawn
55a5128000-55a513b000 r-xp 0000a000 /system/bin/appspawn
55a513b000-55a513c000 r--p 0001c000 /system/bin/appspawn
55a513c000-55a513e000 rw-p 0001c000 /system/bin/appspawn
...
5b0c3cf000-5b0c64f000 rw-p 00000000 [anon:native_heap:jemalloc]
5b19605000-5b1d505000 rw-p 00000000 [anon:native_heap:jemalloc]
5b20100000-5b20107000 r--p 00000000 /system/lib64/platformsdk/libhdc_register.z.so
5b20107000-5b20110000 r-xp 00006000 /system/lib64/platformsdk/libhdc_register.z.so
5b20110000-5b20112000 r--p 0000e000 /system/lib64/platformsdk/libhdc_register.z.so
5b20112000-5b20113000 rw-p 0000f000 /system/lib64/platformsdk/libhdc_register.z.so
7e53a0d000-7e5420c000 rw-p 00000000 [stack]
7e55b92000-7e55b93000 rw-p 00000000 [anon:libark_tooling.so.bss]
OpenFiles: <- 故障时进程持有文件句柄信息
0->/dev/null native object of unknown type 0
1->/dev/null native object of unknown type 0
2->/dev/null native object of unknown type 0
3->socket:[2671] native object of unknown type 218115328
6->socket:[2793] native object of unknown type 0
36->/dev/urandom native object of unknown type 0

HiLog: <- 故障之前进程打印的流水日志
01-21 11:43:35.140 11941 11941 I C02D11/DfxSignalHandler: DFX_SigchainHandler :: signo(11), si_code(0), pid(11941), tid(11941).
01-21 11:43:35.140 11941 11941 I C02D11/DfxSignalHandler: DFX_SigchainHandler :: signo(11), pid(11941), processName(com.example.hiappeventtest), threadName(.hiappeventtest).

MergeLog: <- 应用提供的拼接日志
Last Modified: 2026-03-18 10:10:10 <- 应用提供的拼接日志的最后修改时间戳
app crash log. <- 应用生成用于拼接的日志

（2）jscrash
从现象上看，cppcrash和jscrash一样，都是应用发生了闪退。JS/ArkTS 代码未处理异常时生成的崩溃日志 ，发生在ArkTS/JS 业务层。日志结构如下：

Device info:XXX <- 设备信息
Build info:XXX-XXXX X.X.X.XX(XXXXXXXX) <- 版本信息
DeviceDebuggable:No <- 设备的系统版本是否可调试
Fingerprint:ed1811f3f5ae13c7262b51aab73ddd01df95b2c64466a204e0d70e6461cf1697 <- 故障特征
Timestamp:XXXX-XX-XX XX:XX:XX.XXX <- 时间戳
Module name:com.example.myapplication <- 包名
ReleaseType:release <- 应用的版本类型
CpuAbi:arm64-v8a <- 二进制接口类型
Version:1.0.0 <- hap版本
VersionCode:1000000 <- 版本编码
IsSystemApp:No <- 应用是否为系统应用
Pid:579 <- 故障进程号
Uid:0 <- 用户ID
Process name:com.example.myapplication <- 进程名
App running unique id:124500628566978194 <- 应用运行时唯一关联的id
Process life time:1s  <- 进程存活时间
Process Memory(kB): 1897(Rss) <- 进程占用内存
Device Memory(kB): Total 1935820, Free 482136, Available 1204216  <- 整机内存信息（非必选）
Page switch history: <- 页面切换轨迹
  14:08:30:327 /ets/pages/Index:JsError
  14:08:28:986 /ets/pages/Index
  14:08:07:606 :leaves foreground
  14:08:06:246 /ets/pages/Index:AppFreeze
  14:08:01:955 :enters foreground
Reason:TypeError <- 故障原因
Error name:TypeError <- 故障类型
Error message:Cannot read property c of undefined <- 异常信息
Cannot get SourceMap info, dump raw stack: <- 应用安装包为release包安装时不包含sourcemap文件，JS栈通过sourcemap行列号解析会失败
Stacktrace:
    at onPageShow entry (entry/src/main/ets/pages/Index.ets:7:13)  <-异常代码调用堆栈
           ^        ^                              ^
         函数名   模块的包名                   文件行列号位置
HybridStack: <- CPP和JS之间跨语言的代码调用栈
#00 pc 00000000004a814c /system/lib64/platformsdk/libark_jsruntime.so(173710293c3751dc676d24264bfac393)
#01 pc 00000000004a6460 /system/lib64/platformsdk/libark_jsruntime.so(173710293c3751dc676d24264bfac393)
#02 pc 00000000006a94e0 /system/lib64/platformsdk/libark_jsruntime.so(173710293c3751dc676d24264bfac393)
#03 pc 0000000000334d38 /system/lib64/platformsdk/libark_jsruntime.so(173710293c3751dc676d24264bfac393)
#04 pc 0000000000253da8 /system/lib64/platformsdk/libark_jsruntime.so(panda::ecmascript::ObjectFactory::GetJSError(panda::ecmascript::base::ErrorType const&, char const*, panda::ecmascript::StackCheck)+292)(173710293c3751dc676d24264bfac393)
#05 pc 00000000005c25d4 /system/lib64/platformsdk/libark_jsruntime.so(173710293c3751dc676d24264bfac393)
#06 pc 0000000000de3efc /system/lib64/module/arkcompiler/stub.an(RTStub_PushCallArgsAndDispatchNative+44)
#07 pc 000000000044843c /system/lib64/module/arkcompiler/stub.an(BCStub_HandleCallarg1Imm8V8StwCopy+340)
#08 at onPageShow entry (entry/src/main/ets/pages/Index.ets:7:13) <- 异常发生时执行的JS代码
#09 pc 00000000001e620c /system/lib64/platformsdk/libark_jsruntime.so(173710293c3751dc676d24264bfac393)
#10 pc 00000000009ad560 /system/lib64/platformsdk/libark_jsruntime.so(panda::FunctionRef::Call(panda::ecmascript::EcmaVM const*, panda::Local<panda::JSValueRef>, panda::Local<panda::JSValueRef> const*, int)+456)(173710293c3751dc676d24264bfac393)
#11 pc 0000000000a63f14 /system/lib64/platformsdk/libace_compatible.z.so(e236e26a38ac303814f43a3c8fc9b0a6)
#12 pc 0000000000d836bc /system/lib64/platformsdk/libace_compatible.z.so(e236e26a38ac303814f43a3c8fc9b0a6)
#13 pc 000000000111f338 /system/lib64/platformsdk/libace_compatible.z.so(e236e26a38ac303814f43a3c8fc9b0a6)
...

HiLog:
 ^
 在生成的崩溃日志文件中追加产生故障之前的流水日志，最多1000行

（3）appfreeze
于前两种可能不同，有时appfreeze是卡顿。所以我们一般要结合freeze日志、trace一同分析。日志结构如下：

Generated by HiviewDFX@HarmonyOS
================================================================
Device info:HUAWEI Mate 60 Pro
Build info:ALN-AL00 6.0.0.328(C00E1R4P3DEVDUlog)
DeviceDebuggable:No
Fingerprint:e18a33c12e1361173ec9ac1c93f2bd0c2daa88f03c7f76b228cca14bdc6a21b1
Module name:com.samples.freezedebug
ReleaseType:release
CpuAbi:arm64-v8a
Version:1.0.0
VersionCode:1000000
IsSystemApp:No
PreInstalled:No
Foreground:Yes
Pid:13680
Uid:20020177
App running unique id:124500628566978194
Process life time:18s
Process Memory(kB):163819(Rss)
Device Memory(kB):Total 11679272, Free 3697424, Available 5814272
Reason:THREAD_BLOCK_6S
appfreeze: com.samples.freezedebug THREAD_BLOCK_6S at 20250628140837
DisplayPowerInfo:powerState:UNKNOWN
HitraceIdInfo: hitrace_id: a92ab27238f409a, span_id: 1cd61c9, parent_span_id: 3072e, trace_flag: 0
Page switch history:
  14:08:30:327 /ets/pages/Index:Appfreeze
  14:08:28:986 /ets/pages/Index
  14:08:26:502 :enters foreground
  14:08:07:606 :leaves foreground
  14:08:06:246 /ets/pages/Index:Appfreeze
  14:08:01:955 :enters foreground
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
DOMAIN:AAFWK
STRINGID:THREAD_BLOCK_6S
TIMESTAMP:2025/06/28-14:08:37:360
PID:13680
UID:20020177
PACKAGE_NAME:com.samples.freezedebug
PROCESS_NAME:com.samples.freezedebug
NOTE: Current fault may be caused by the system's low memory or thermal throttling, you may ignore it and analysis other faults.Current process has encountered fd leak which may lead to appfreeze, you may refer to resource overlimit event from hiAppEvent for further analysis.
***

二、处理方法

2.1 CPPCRASH
（1）首先观察栈顶以及报错信息
（2）跳过libc等C库so、以及musl的so（因为一般这些so是基础库）
（3）一般应用的so开头是/data（除了web也是/data），系统的so是/system开头，如果是应用的so建议应用优先自行排查
（4）反编译，需要拉取设备版本的镜像，从中取出so还原现场
（5）判断是否为踩内存问题。这种情况特征有二，一是在高概率场景或者是必现场景下，每次复现堆栈不同；二是在不可能出现崩溃（如做了保护的地方）发生崩溃。踩内存时，堆栈会被污染、被踩飞，所以此时堆栈没有参考意义，需要开启ASAN或者HWASAN再次压测并复现问题

2.2 JSCRASH
该类型的崩溃，通常根据报错信息与栈顶，结合业务代码定位问题即可。

2.3 APPFREEZE
一般要结合freeze日志、trace一同分析。首先看freeze日志，查看3s栈和6s栈的堆栈是否相同，如果相同，则表示该freeze是由堆栈上的so引发的，因此从栈顶开始向下排查即可。如果不同，则需要抓取trace，trace可参考：trace分析工具profiler

三、其他求助途径

3.1 指导文档
可参考：CppCrash案例分析、APPFEEZE分析、JSCRASH问题分析

3.2 开发者联盟
如上述指导未能解决问题，且开发者也没有头绪，可以向开发者联盟提工单，一般在数个工作日内会有工作人员进行回复。