案例教材TikTok 出现弹窗报错现象偶现 TikTok 弹窗报错机型/单号背景A681L / NPS 性能主观你手上的包A681LOS16-434里的A681L第 0 课新手先建立正确心态看性能单不是一上来找“哪行代码坏了”而是先证明“弹窗到底是什么”→ 再找到发生时间→ 再看当时系统/App在干什么→ 最后才下结论App问题 or 系统资源问题这一单最后结论是系统 ANR 弹窗无响应不是 Crash也不是 TikTok 业务错误页。新手如果先去挖crash_log就会走弯路。第 1 步先认目录日志在什么地方你的关键路径c:\Users\Administrator\Desktop\性能问题附件\A681LOS16-434\A681L\里面重点看A681L\├─ 2026-07-08-20-57-17.log ← Perfetto 抓取记录辅助├─ 2026-07-08-20-57-17.pftrace ← 性能 trace进阶再看└─ debuglogger\└─ mobilelog\└─ APLog_2026_0708_205559__41\ ← ★本次主战场├─ events_log_2026_0708_205600.curf ★先看├─ sys_log_2026_0708_205600.curf ★第二看├─ main_log_2026_0708_205600.curf ★第三看├─ kernel_log_2026_0708_205600.curf ★第四看├─ crash_log_2026_0708_205600.curf ★用来排除 Crash└─ bsp_log_... ← 进阶辅助新手记忆法顺序文件一句话作用1events_log找“出事了没、是什么事”2sys_log看系统怎么判定 ANR、压力多大3main_log看 TikTok 启动/卡顿细节4kernel_log看内存/换页/kswapd5crash_log排除是不是崩溃后bsp_log/ pftrace深挖时再用包名要记住TikTok 海外版 com.zhiliaoapp.musically进程名常被截成aoapp.musically第 2 步先定性——弹窗是 ANR 还是 Crash你怎么做动手打开...\APLog_2026_0708_205559__41\events_log_2026_0708_205600.curf搜索这些词任选编辑器 CtrlFam_anram_crashmusicallyApplication Not Responding这一单你会看到什么证据 AANR 事件20:54:26 am_anr com.zhiliaoapp.musicallyReason: executing service ...RedBadgePushProcessService, waited 30127ms20:57:07 am_anr com.zhiliaoapp.musically (pid 8165)Reason: 同一个 RedBadgePushProcessService, waited 30242ms证据 B弹窗窗口名Application Not Responding: com.zhiliaoapp.musically证据 C用户点了关闭20:54:56 am_kill ... user request after error新手结论模板先写这一句这不是 Crash是 ANR应用无响应系统弹窗。证据events_log有am_anr并且有Application Not Responding窗口。到这里方向就定了按 ANR 路径学不按 Crash 路径挖。第 3 步画时间线新手最该练的能力不要东看一句西看一句。把关键事件按时间排成一条线。这一单的时间线精简版20:54:26 第1次 ANRpid 4999Service 超时约30s20:54:52 弹出 “Application Not Responding”20:54:56 用户点关闭 → 进程被 kill20:56:09 再次冷启动 TikTokpid 816520:56:14 LMK 因 swap is low 杀后台TikTok 开始 GC/掉帧20:56:19 冷启动性能事件超时约10s还没正常结束20:56:22~47 主线程 Skipped 几十到几百帧非常卡20:57:06 再次 Service 超时约30s20:57:07 第2次 am_anr20:57:32 AnrManager 打出完整 ANR 报告Load/PSI/CPU20:57:35 再次弹出 ANR 对话框20:57:41 又出现 Input dispatching timed out连带学习点新手看单时间线画清楚了结论就容易写。这一步建议你自己再抄一遍练“还原现场”。第 4 步看 sys_log——系统为什么判 ANR打开哪里...\sys_log_2026_0708_205600.curf搜索ANR in com.zhiliaoapp.musicallyAnrManagerRedBadgePushProcessServiceApplication Not Responding这一单关键段第二次证据最全你会看到类似ANR in com.zhiliaoapp.musicallyReason: executing service ...RedBadgePushProcessService, waited 30242msLoad: 33.58 / 31.47 / 27.34PSI memory: some avg1028.12, full14.36PSI cpu: some avg1036.25PSI io: some avg1062.83, full14.22CPU usage:129% Google Files 大量 major faults36% TikTok major faults 111739 ← 很关键48% kswapd039% system_server major faults 很多稍后还有Changing focus ... to Window{... Application Not Responding: com.zhiliaoapp.musically}这就是用户看到的弹窗。新手怎么读这些数别怕看到什么怎么理解Reason Service waited ~30s表面原因某个 Service 没在时限内执行完Load 20整机很忙、很卡PSI io 很高60%很多时间卡在 IOPSI memory 高内存吃紧major faults 很多进程在疯狂从磁盘换页典型内存不够kswapd0 占用高内核一直在回收内存Application Not Responding 窗口用户可见弹窗坐实学习口诀Reason 是“直接原因”PSI/major fault/kswapd 是“深层原因”。新手常只抄 Reason高手会继续问为什么 Service 会超时这一单深层答案是整机内存/IO 压力太大TikTok 被换页拖死所以 Service 跑不完。第 5 步看 main_log——App 当时有多卡打开哪里...\main_log_2026_0708_205600.curf搜索zhiliaoapp.musicallyStart proc 8165Skippedlowmemorykillerswap is lowSuspending all threadsGC freed这一单你会串起来的现象冷启动20:56:09 Start proc 8165:com.zhiliaoapp.musically内存告急LMK 杀后台lowmemorykiller ... reason: ... swap is lowTikTok 自己也在抖GC 频繁Suspending all threads took: xx msChoreographer: Skipped 82/384/307/738 frames掉帧越多主线程越卡新手理解ANR 弹窗出现前App 已经“卡了很久”。所以弹窗不是突然来的是卡顿累积后的结果。第 6 步看 kernel_log——确认是系统内存病灶打开哪里...\kernel_log_2026_0708_205600.curf搜索aoapp.musicallykswapdpage allocation failureMem-InfoFree swapTranMemoryInfo这一单关键信号page allocation failure连页都不好申请了Mem-Info里 free 很低kswapdCPU 很高TikTok 的 rss/swap 抖动大内存被挤来挤去学习点events/sys告诉你“发生了 ANR”kernel帮你确认“是不是整机内存出问题”。这一单两边对得上 → 深层偏平台资源压力。第 7 步看 crash_log——排除“崩了”打开哪里...\crash_log_2026_0708_205600.curf搜索musicallyFATAL EXCEPTIONFatal signalAndroidRuntime这一单结果没有 TikTok 的典型 Crash 主证据。所以不要写成“TikTok 崩溃弹窗”。bsp_log里可能有sig7SIGBUS之类信号新手先记一句有信号 ≠ 用户看到的就是 crash 弹窗。用户弹窗以Application Not Responding/am_anr为准。第 8 步把结论按新手格式写出来套这个模板【现象】TikTok 弹窗报错偶现【定性】系统 ANR 弹窗非 Crash【证据】events: am_anrsys: Application Not Responding【直接原因】RedBadgePushProcessService 执行超时约 30s【深层原因】低内存 swap 紧张 IO/换页严重PSI io/mem 高major fault 多kswapd 高【伴随】冷启动慢、Skipped frames 很多、LMK 杀后台【倾向】平台内存/性能压力为主TikTok 是受害进程Service 是超时点【还缺】anr_*.txt 堆栈可进一步看主线程是否锁死第 9 步新手学习路线按这个练方式方法一单三练每一单都强制做三件事定性ANR / Crash / 仅卡顿只靠 events 也能做时间线不少于 8 个时间点结论三句直接原因 / 深层原因 / 责任倾向学习顺序别跳第1天只会搜 events分清 am_anr 和 am_crash第2天会画时间线只会抄时间戳也行第3天会读 sys 里 ANR 报告的 Reason Load PSI第4天会把 main 的 Skipped / LMK 接到时间线上第5天会看 kernel 的 kswapd / Mem-Info 做印证第6天练习写结论模板第7天再找一单自己独立走一遍不看答案必背 10 个词对着这一单记am_anrApplication Not RespondingReason: executing serviceLoadPSI memory/io/cpumajor faultskswapd0lowmemorykiller/swap is lowSkipped framesuser request after error每个词你都要能答在哪个文件、长什么样、说明什么。第 10 步这一单教你的“核心思维方式”弹窗 ≠ 一定是 App 写坏了先问弹窗是 ANR 还是 Crash再问Reason 是什么再问当时系统是否已经内存/IO 崩了如果系统已经崩了App 超时往往是结果不是唯一根因。这一单的经典范式症状在 TikTokService ANR病灶在系统资源内存/Swap/IO新手把这个范式学会以后看很多 NPS“偶现卡/弹窗”都会快很多。你可以马上做的练习就用这份 log按顺序自己操作一遍打开events_log标出两次am_anr行号/时间打开sys_log把ANR in ...那段 Load/PSI 抄下来打开main_log找出Skipped 738 frames和一次swap is low打开kernel_log找一次page allocation failure用上面的结论模板自己写一版不要照抄尽量用自己的话写完后你可以发我我按新手标准帮你批哪里对、哪里还缺、下一步该补哪块知识。如果你要我下一条可以继续只讲一块“怎么从零读懂 ANR 报告里的 PSI 和 major fault”仍然结合这一单数字逐步拆。events_log找 ANR 精准时间、画时间线sys_log查系统判定原因、整机资源压力main_log回溯前置卡顿看 APP 内部恶化细节kernel_log深挖内核底层内存、换页根源crash_log排除闪退混淆bsp/pftrace疑难问题深度挖掘。