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): Promise<DisplayItem[]> { 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[]): Promise<DisplayItem[]> { 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 Promise<DisplayItem[]>(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(): Promise<void> { renderShell() void loadBasicData() void loadRecommendLater() void reportOpenEventLater() } async function loadBasicData(): Promise<void> { const list = await safeBuildList(await requestRows()) renderList(list) } async function loadRecommendLater(): Promise<void> { 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 排查，我不会只盯着某一次卡顿日志看。更可靠的做法是把问题拆成主线程阻塞、状态刷新、任务切片、超时兜底和回归验收几段。每段都有代码、有阈值、有日志，后面再出现卡顿时，团队知道从哪里查，也知道改完以后怎么证明真的好了。
