起点课堂会员权益
职业体系课特权
线下行业大会特权
个人IP打造特权
30+门专项技能课
1300+专题课程
12场职场软技能直播
12场求职辅导直播
12场专业技能直播
会员专属社群
荣耀标识
HarmonyOS开发常见问题及解答（二）
本原创文章帖发布在华为开发者联盟社区，欢迎开发者前往访问评论交流，更多与该内容相关讨论，请点击原帖查看：
HarmonyOS开发常见问题及解答（二）-华为开发者话题 |...
最新
推荐
应用卡死后借助AppRecovery优雅重生
相信不少开发者都遇到过这样的场景：用户正在应用中填写一份重要的表单，或者正在进行一笔关键的支付操作，突然应用画面定格、触控无响应——这就是常说的"应用卡死"（AppFreeze）。对于用户而言，这意味着正在进行的工作可能付诸东流；对于开发者而言，这往往意味着用户流失和差评。
告别应用卡死焦虑：鸿蒙系统冻屏回调能力重磅上线
应用使用过程中，点击屏幕后毫无反应是件让人抓狂的事。手指点在屏幕上，界面却像凝固了一样，既不知道应用是在认真处理，还是已经彻底卡死。这种情况有个专门的名字：AppFreeze（应用冻屏）。
对开发者来说，冻屏问题一直是个麻烦事。系统检测到冻屏后生成的日志，常常缺少足够的上下文。看到日志只知道"线程卡住了"，却不知道"为什么卡住"，定位问题像在雾里摸索。
ErrorManager助力高效应对AppFreeze问题
做鸿蒙开发的朋友，大概都收到过这类用户反馈："点了没反应，但App没闪退"。界面像被定格了一样，应用还活着，就是不响应。这种卡住但不崩溃的情况，就是AppFreeze（应用冻屏）。
AppFreeze案例：FFRT 与 std::mutex 混用导致的死锁分析
近期，某三方应用在鸿蒙系统上发生了多例 AppFreeze（应用无响应）事件。系统检测到主线程超时阻塞，强制终止了应用。通过抓取 AppFreeze 日志并结合 FFRT（Function Flow Runtime Kit）的基础理论，我们定位到了导致这一现象的根本原因：在 FFRT 并发模型中错误地使用了 C++ 标准库同步原语（std::mutex 和 std::condition_variable），导致 FFRT Worker 线程陷入内核态阻塞，进而引发任务堆积和死锁。
AppFreeze依靠3s和6s堆栈“热点函数”定位主线程繁忙型卡死
本系列实战第七篇，我们将分析一个更具有挑战性的场景：3s/6s栈不一致且没有增强采样日志，如何定位Appfreeze问题。
AppFreeze采样栈定位“循环处理计算任务”，解决鸿蒙主线程超时问题
前文我们分享了“锁竞争”、“UI渲染过载”及“主线程同步IO阻塞”引发无响应问题的分析方法。这一篇，我们将介绍另一种无响应故障模式：“主线程执行耗时循环计算”。
ArkTS 九种泄漏模式的排查指南（下）
上篇我们认识了五种内存泄漏模式，今天继续揭晓剩下的四种"内存刺客"。如果你还没看上篇，建议先回顾一下——因为下篇的排查方法论总结，会把九种模式串成一条完整的排查链路。
ArkTS 九种泄漏模式的排查指南（上）
你有没有这样的经历？辛辛苦苦写好的鸿蒙应用，在测试环境跑得好好的，一上现网就开始"抽风"——搜索页面偶尔闪退、联系人列表越用越卡、签到功能用久了直接崩溃。你打开日志一看，满屏的 raw stack，文件名和行号倒是有了，可到底是谁在背后搞鬼？一头雾水。
线上崩溃的「元凶」找到了：如何快速识别HarmonyOS应用里的符号冲突
在鸿蒙应用开发中，你有没有遇到过这种让人头皮发麻的"灵异事件"：
本地调试明明一切正常，测试环境也稳稳当当，一上线却开始随机崩溃。用户怨声载道，日志里却只有一堆冷冰冰的十六进制地址。排查了三天三夜，最后发现——问题竟然出在第三方 SDK 依赖的 C++ 运行库版本和你的应用不兼容。
