FAQ 1：HarmonyOS 如何分析应用JS Crash报错日志？

error_message: Inner error. Inner code is 12594048
Error code:14800000
stack_trace: Cannot get SourceMap info, dump raw stack:
  at anonymous (dcar|car_circle|1.0.0|src/main/ets/database/k3.ts:19:1)

【解决方案】：

场景一

【问题定位】

       该问题为自定义Error类，是由程序运行过程中开发人员自己抛出的异常。其中导致1480000问题的原因主要有以下几种：

   1. sql执行异常。

   2. 内部状态异常。

   3. 错误地使用接口。

   4. 系统错误，如空指针、内存不足、数据服务异常重启、I/O错误、IPC异常、JS引擎异常等。

【分析结论】

       该问题实际发生为偶现问题，结合开发者侧代码分析，错误出在getlong接口上。该接口支持的数据范围是：Number.MIN_SAFE_INTEGER ~ Number.MAX_SAFE_INTEGER，若超出该范围，建议使用getDouble。

【修改建议】

       请排查在使用getlong接口时的数据范围是否有超出，此外在getlong接口的参数也调用了getColumnIndex，也需要排查是否正确使用该接口。

场景二

Reason:TypeError
Error name:TypeError
Error message: is not callable
SourceCode:
  this.fonEachUpdateFunction(elntId, this.swiperItems, forEachItembenFunction, (item) => item.getbuid(), false, false);

【问题定位】

       该问题为TypeError类，异常信息是Error message:is not callable。根据SourceCode信息重点检查fonEachUpdateFunction方法中的变量是否已实例化。

【分析结论】

       item数据非实例化后的类对象，不能调用类上的方法。

【修改建议】

  • ForEach数组中的每个数据都new实例化一下；

  • 封装一个公共的方法根据传参key取对应的数据值。

场景三

Reason:SyntaxError
Error name:SyntaxError
Error message:Unexpected Text in JSON
Stacktrace:
  Cannot get SourceMap info, dump raw stack:
  at handleH5Request (entry|entry|1.0.0|src/main/ets/viewmodel/action/Action.ts:7:1)
  at anonymous (entry|entry|1.0.0|src/main/ets/viewmodel/web/CcbBridge.ts:40:1)
  at (entry/src/main/ets/pages/MainPage.ets:288:9)

【问题定位】

       该问题为SyntaxError类，异常信息是Error message:Unexpected Text in JSON。这种错误通常发生在调用JSON.parse函数时，JSON.parse函数用于解析JSON字符串生成对应ArkTS对象或null。

【分析结论】

       字符串的格式不符合JSON语法规范。

【修改建议】

       检查字符串是不是非JSON格式或者包含特殊字符。

场景四

Error name:ReferenceError
Error message:@Component 'ExamSettingDialog'[2505] missing @Provide property with name lightMode.
Fail to resolve @Consume(lightMode).

       @Provide和@Consume主要用于与后代组件的双向数据同步。从异常信息中可以看出，组件中只存在@Consumer修饰的变量，在父组件中查找不到对应的@Provide修饰的变量。

【问题定位】

       该问题为ReferenceError类，异常信息是@Component XXXX missing @Provide property with name XXXXXX。

【分析结论】

       初始化@Consume变量XXX时，没有定义对应key的@Provide变量，引用一个不存在的变量，框架抛出JS ERROR。

【修改建议】

       检查变量是否存在，若不存在则在父组件中定义@Provide变量并赋值。

FAQ 2：HarmonyOS 内存泄漏问题如何定位？

【解决方案】：

       HarmonyOS以应用进程平均动态峰值内存作为基线，60s一次轮询监控，当动态内存峰值超过基线值2倍会判定泄漏，同时触发管控。PC默认为1.5G，手机默认2G。

       当持续泄露到系统整体可用内存低于安全水位（通常剩余内存<10%）则会被系统杀进程。

       所以现象会是应用在泄露场景，过一段时间，超过安全内存值后，就自动关闭应用，看起来卡着不动然后闪退。解决该问题需要检测排查内存泄漏原因。

       内存泄漏可以参考官网指导：JSVM-API 内存泄漏问题定位指导 。

FAQ 3：项目内频繁使用ArkUI_AttributeItem，ArkUI_NodeHandle，其结构体对应的内存应该如何管理？

【解决方案】：

【背景知识】

       结构体ArkUI_AttributeItem：定义属性设置函数通用入参结构。各个属性设置接口可选择使用其中的成员变量来存储特定类型的参数数据。

       结构体指针ArkUI_NodeHandle：定义ArkUI native组件实例对象指针。

【处理方案】

       使用NDK的CAPI能力开发时，会有两种类型的结构体，分别以上述ArkUI_AttributeItem、ArkUI_NodeHandle举例：

   • ArkUI_AttributeItem为结构体形式，其使用方式为开发者直接进行创建并维护，针对此类结构体，需要开发者在作用域结束时主动删除并置空结构体。

   • ArkUI_NodeHandle为结构体指针形式，两者的区别主要是此类指针的创建方为系统，开发者无法直接感知到实际内存地址。

       因此结构体指针形式的类都会伴有dispose相关接口，比如ArkUI_NodeHandle的dispose接口为disposeNode。

       同样需要开发者在页面销毁或对应节点需销毁的时机主动调用接口，销毁并置空结构体来释放内存。

FAQ 4：HarmonyOS 使用uv_queue_work方法将任务抛到js线程上面执行的时候出现内存泄漏的问题如何解决？

【解决方案】：

       当使用uv_queue_work方法将任务抛到js线程上面执行的时候，需对js线程的回调方法加上napi_handle_scope来管理回调方法创建的napi_value的生命周期。

FAQ 5：app无响应卡死后如何解决？

【解决方案】：

       在HarmonyOS应用开发中，应用无响应（AppFreeze）卡死问题通常由以下核心原因引起：

场景一、主线程耗时操作阻塞

1.同步任务堆积

       主线程执行复杂计算（如大数据处理）、未优化的循环逻辑或同步I/O操作，导致任务队列无法及时处理。

案例：通过HiTraceMeter测量发现主线程单个任务耗时超过6秒（THREAD_BLOCK_6S检测机制）。

2.JS死循环

       ArkTS代码中因逻辑错误导致循环无法退出，例如：

while (true) { /* 未设置退出条件 */ }

       检测特征：故障日志中EVENTNAME=THREAD_BLOCK_6S且堆栈显示libark_jsruntime.so相关调用。

场景二、输入事件处理延迟

1.主线程阻塞输入响应

       用户点击或滑动事件在主线程中被耗时逻辑拦截，超过5秒未响应（APP_INPUT_BLOCK类型）。

       典型场景：点击登录按钮后执行数据库同步查询未使用异步线程。

2.组件关联异常

       组件未正确初始化导致事件处理失败，例如：

       WebviewController未与Web组件关联。

场景三、生命周期操作超时

1.Ability生命周期切换卡顿

       页面跳转、前后台切换时执行耗时操作（如大量数据加载），超出系统检测阈值（通常前台6秒，后台21秒）。

       日志特征：LIFECYCLE_TIMEOUT事件类型，MSG字段标明具体生命周期阶段。

2.资源释放延迟

       未及时释放占用的系统资源（如文件句柄、数据库连接），导致后续生命周期操作阻塞。

场景四、线程竞争与死锁

1.锁竞争

       多线程环境下错误使用同步锁（如Mutex），导致主线程等待子线程释放锁。

       定位方法：查看故障日志中的主线程堆栈，存在pthread_mutex_lock等系统调用。

2.跨进程通信阻塞

       分布式场景下跨设备调用未设置合理超时，导致主线程挂起。

场景五、第三方库或系统服务异常

1.Native层崩溃

       C++代码（如NDK模块）内存越界、空指针访问引发主线程崩溃。

       定位方法：检查faultlogger目录下cppcrash日志。

2.系统服务响应失败

       调用系统API时未处理异常（如网络请求未捕获错误），导致主线程挂起。

排查与优化建议

3.日志分析优先级

       检查appfreeze日志中的EVENTNAME字段，优先处理THREAD_BLOCK_6S和APP_INPUT_BLOCK类型问题。

通过mainHandler dump信息对比3秒与6秒任务队列。

4.线程策略优化

       使用TaskPool或Worker线程执行耗时任务：

 import taskpool from '@kit.TaskPoolKit';
taskpool.execute(() => { /* 异步逻辑 */ });

5.性能监控工具

• 集成Performance Analysis Kit采集渲染帧率、CPU占用率，结合运维平台分析趋势。

       通过上述原因分类与工具配合，可系统化解决应用卡死问题，具体案例需结合HiLog日志和DevEco Studio调试工具深入分析。

———————————————————————————————————-

🔗 官网开发者学堂视频：https://developer.huawei.com/consumer/cn/training/result?type2List=201783644516849879&orderBy=1&courseType=5

🔗 社区DFX专题文章：  https://developer.huawei.com/consumer/cn/forum/subject/2101218731402391001

【扫码加入 HarmonyOS DFX 技术交流群】