AppFreeze 不是“偶发卡一下”这么简单。对用户来说它表现为点击没反应、页面停住、返回键延迟、列表突然不动对开发来说它往往不是某一行代码报错而是主线程被长任务、同步 IO、过重布局或连续状态刷新堵住了。HarmonyOS 7 / API 26 做应用稳定性优化时我会把 AppFreeze 当成一个可复现、可取证、可回归的问题来处理。不要只看一次日志也不要只把某个循环改短一点就结束。更稳的做法是先复现再定位阻塞点然后把任务切开最后补上降级和验收。先判断是不是主线程被堵住很多卡顿看起来像网络慢其实是主线程在忙。判断时先看三个信号信号表现优先怀疑点击后按钮没有按压反馈UI 事件来不及处理主线程长任务列表滑动突然停住布局、图片解码或同步计算太重UI 渲染链路数据已经返回但页面迟迟不变状态刷新太密或批量 diff 太重状态更新策略日志集中在某段循环前后中间没有输出同步循环或同步 IO我一般不会一上来就改代码而是先加一组轻量 trace把“卡住前后发生了什么”记录清楚。type FreezeTrace { name: string startedAt: number endedAt?: number costMs?: number } class FreezeTraceRecorder { private traces: FreezeTrace[] [] start(name: string): FreezeTrace { const trace: FreezeTrace { name, startedAt: Date.now() } this.traces.push(trace) return trace } end(trace: FreezeTrace): void { trace.endedAt Date.now() trace.costMs trace.endedAt - trace.startedAt console.info([freeze-trace], trace.name, trace.costMs ms) } dumpSlow(thresholdMs: number): FreezeTrace[] { return this.traces.filter(item (item.costMs || 0) thresholdMs) } }这段代码不是为了替代系统日志而是为了把业务链路切清楚哪段任务开始了、哪段任务结束了、中间花了多少时间。案例一同步处理大数组页面直接卡住先看一个很常见的写法。接口一次返回几千条数据页面为了方便直接同步清洗、分组、排序然后再刷新 UI。function buildDisplayList(raw: FoodItem[]): DisplayItem[] { return raw .filter(item item.enabled) .map(item ({ id: item.id, title: item.title.trim(), score: item.favoriteCount * 2 item.recentViewCount })) .sort((a, b) b.score - a.score) }数据少的时候没问题数据一多就容易把主线程堵住。更稳的方式是把任务切成小片让 UI 有机会喘口气。async function buildDisplayListInChunks(raw: FoodItem[], chunkSize: number): PromiseDisplayItem[] { const result: DisplayItem[] [] for (let start 0; start raw.length; start chunkSize) { const part raw.slice(start, start chunkSize) for (const item of part) { if (!item.enabled) { continue } result.push({ id: item.id, title: item.title.trim(), score: item.favoriteCount * 2 item.recentViewCount }) } await new Promise(resolve setTimeout(resolve, 0)) } return result.sort((a, b) b.score - a.score) }这里的关键不是setTimeout本身而是不要让一个大循环长时间占住 UI 线程。实际项目里可以进一步把排序、分组、索引生成移到后台任务或缓存层但第一步必须先避免首屏同步大计算。案例二状态刷新太密列表一直在重建第二类 AppFreeze 经常出现在状态更新里。比如每处理一条数据就更新一次页面async function loadListBad() { const rows await requestRows() for (const row of rows) { this.items.push(convertRow(row)) } }这种写法的问题是刷新太碎。数据越多UI 更新越密列表越容易反复重建。更好的做法是先在局部变量里完成转换再一次性替换状态。async function loadListBetter() { const rows await requestRows() const nextItems: DisplayItem[] [] for (const row of rows) { nextItems.push(convertRow(row)) } this.items nextItems }如果数据非常大还可以把状态分成“首屏数据”和“完整数据”两段async function loadListWithFirstScreen() { const rows await requestRows() const firstScreen rows.slice(0, 30).map(convertRow) this.items firstScreen const rest await buildDisplayListInChunks(rows.slice(30), 100) this.items firstScreen.concat(rest) }这样用户先看到能操作的首屏后面的数据再补齐。对体验来说能先滑动、能先点击比一次性等全部处理完更重要。本地复现脚本把卡顿压出来为了确认优化是不是有效我会先用一个可控脚本制造压力。type FoodItem { id: string title: string enabled: boolean favoriteCount: number recentViewCount: number } type DisplayItem { id: string title: string score: number } function mockRows(count: number): FoodItem[] { const rows: FoodItem[] [] for (let i 0; i count; i) { rows.push({ id: item- i, title: 菜谱 i , enabled: i % 5 ! 0, favoriteCount: i % 17, recentViewCount: i % 23 }) } return rows } async function verifyFreezeOptimization() { const rows mockRows(8000) const recorder new FreezeTraceRecorder() const syncTrace recorder.start(sync-build) buildDisplayList(rows) recorder.end(syncTrace) const chunkTrace recorder.start(chunk-build) await buildDisplayListInChunks(rows, 200) recorder.end(chunkTrace) console.info(slow traces, recorder.dumpSlow(80)) }我希望看到的不是“chunk 总耗时一定更短”而是它不会长时间霸占 UI。同步版本可能一次卡住很久切片版本总耗时可能差不多但页面中间有机会响应输入。降级恢复不能漏AppFreeze 排查只改性能还不够。还要考虑如果数据量突然暴涨或者某个处理任务超时页面应该怎么恢复。我的做法是给重任务加一个保护层。async function safeBuildList(raw: FoodItem[]): PromiseDisplayItem[] { const start Date.now() const fallback raw.slice(0, 30).filter(item item.enabled).map(item ({ id: item.id, title: item.title.trim(), score: 0 })) const result await Promise.race([ buildDisplayListInChunks(raw, 200), new PromiseDisplayItem[](resolve { setTimeout(() resolve(fallback), 1200) }) ]) console.info([freeze-guard] build list cost, Date.now() - start, ms) return result }这段保护层有一个明确目标数据处理不能无限占住页面。超过 1200ms 就先给首屏兜底数据后续可以提示“内容仍在加载”。这样用户不会被一个后台处理任务卡死。API 26 回归检查我会把回归标准写得非常明确检查项通过标准8000 条数据同步转换能复现明显耗时切片转换UI 中间可响应不出现长时间无反馈状态更新不按单条数据反复刷新超时保护1200ms 后有兜底结果日志取证能输出任务名、耗时、是否超阈值如果这些检查不过就不要说 AppFreeze 已经优化好了。真正的闭环是能复现、能定位、能解释、能回归。日志取证要分三层看只看一条慢日志很容易误判。我的习惯是分三层层级看什么目的入口日志页面进入、接口返回、列表开始构建确认卡顿发生在哪段流程任务日志每个重任务的开始、结束、耗时找出真正超过阈值的任务UI 日志首屏是否可见、列表是否可滑动、点击是否响应判断用户是否真的被卡住这三层缺一层都不够。只有入口日志知道不了循环里发生了什么只有任务日志判断不了用户是否能操作只有 UI 日志又不知道背后是谁慢。可以把日志统一成一个格式type FreezeLogLevel entry | task | ui type FreezeLog { level: FreezeLogLevel name: string costMs?: number blocked: boolean detail: string } function printFreezeLog(log: FreezeLog): void { console.info( [app-freeze], log.level, log.name, blocked log.blocked, cost (log.costMs ?? 0), log.detail ) }然后在关键位置落日志printFreezeLog({ level: entry, name: pageAppear, blocked: false, detail: page appeared }) printFreezeLog({ level: task, name: buildDisplayList, costMs: 1480, blocked: true, detail: exceeded 800ms threshold }) printFreezeLog({ level: ui, name: firstScreen, blocked: false, detail: shell visible, list can scroll })这样一看就知道页面能显示但列表构建超过阈值。修复方向就不是乱改 UI而是处理列表构建。任务分级以后代码评审会更直接我会把可能引起 AppFreeze 的任务分成四类类型示例处理策略必须同步创建页面外壳、默认空状态保持很小不做 IO可以异步拉配置、查缓存、请求列表首帧后执行可以切片大数组转换、排序、分组分批处理中间让出执行权应该后移预加载、上报、推荐计算不参与首屏如果评审里看到“必须同步”任务里出现请求、排序、图片处理、大文件读取就应该直接打回。不是因为这些代码一定错而是它们不应该出现在首帧关键路径里。一个比较稳的入口可以写成这样async function startPageSafely(): Promisevoid { renderShell() void loadBasicData() void loadRecommendLater() void reportOpenEventLater() } async function loadBasicData(): Promisevoid { const list await safeBuildList(await requestRows()) renderList(list) } async function loadRecommendLater(): Promisevoid { setTimeout(async () { const recommend await requestRecommend().catch(() []) renderRecommend(recommend) }, 300) } function reportOpenEventLater(): void { setTimeout(() { reportEvent(page_open).catch(() {}) }, 500) }这段代码的取舍很明确页面外壳先出来基础数据随后补推荐和上报都后移。用户打开页面时应用先保证“能看、能点、能滑”再处理增强功能。后续怎么避免我会把下面几条作为代码评审规则首屏前不要做大数组同步处理循环里不要逐条改页面状态重任务必须有 trace超过 800ms 的任务必须说明是否能后移超过 1200ms 的启动后任务必须有兜底列表数据要优先保证首屏可操作再补完整内容。这些规则看起来简单但能挡住很多后期问题。AppFreeze 很少是一次大改造成的更多是每天加一点同步逻辑、加一点状态刷新最后一起把页面拖死。小结HarmonyOS 7 / API 26 做 AppFreeze 排查我不会只盯着某一次卡顿日志看。更可靠的做法是把问题拆成主线程阻塞、状态刷新、任务切片、超时兜底和回归验收几段。每段都有代码、有阈值、有日志后面再出现卡顿时团队知道从哪里查也知道改完以后怎么证明真的好了。