企业官网建设流程全解析

HarmonyOS 7 / API 26 做性能优化时，冷启动不是只看页面最后能不能打开。真正影响体验的是首帧什么时候出来、首帧出来以后能不能马上点、后台恢复时会不会被旧任务拖住。

我更愿意把冷启动问题拆成三段看：第一段是页面骨架能不能先出来；第二段是首屏必须数据有没有阻塞；第三段是非关键任务有没有抢主线程和生命周期。这样排查比一句“启动慢”更具体，也更容易落到代码上。

先把问题说具体

一个页面启动慢，通常不是单点故障，而是几类动作挤在一起：

• 页面创建时同步读配置、读数据库、预热图片；
• 首屏还没出来就开始做曝光统计、推荐计算、缓存清理；
• 后台恢复时旧请求结果回来，把新状态覆盖掉；
• 异步任务没有批次号，页面销毁后还在回写 UI；
• 异常兜底只处理了网络失败，没有处理慢任务和超时。

如果只靠肉眼看“页面能打开”，这些问题很容易漏掉。更稳的做法是给启动链路设规则：哪些任务必须在首帧前完成，哪些任务必须首帧后执行，哪些任务回写前必须确认页面还有效。

案例一：首帧前塞了太多同步任务

下面这种写法很常见，代码看着整齐，但首帧压力很大：

aboutToAppear() { this.loadLocalConfig() this.queryHomeList() this.preloadCoverImages() this.reportPageExposure() }

问题在于这四个动作的重要程度不一样。配置和首屏数据可能是关键任务，图片预热和曝光统计明显不应该抢首帧时间。它们放在一起执行，最后用户看到的就是白屏时间变长。

我会先改成任务分层：

type LaunchTask = { name: string critical: boolean timeoutMs: number run: () => Promise<void> } class FirstFrameScheduler { async run(tasks: LaunchTask[]) { const criticalTasks = tasks.filter(task => task.critical) const deferredTasks = tasks.filter(task => !task.critical) await Promise.all(criticalTasks.map(task => this.runWithTimeout(task))) setTimeout(() => { deferredTasks.forEach(task => { this.runWithTimeout(task).catch(err => { console.error(`[launch] ${task.name} failed`, err) }) }) }, 0) } private async runWithTimeout(task: LaunchTask) { let timer = 0 const timeout = new Promise<never>((_, reject) => { timer = setTimeout(() => reject(new Error(`${task.name} timeout`)), task.timeoutMs) }) try { await Promise.race([task.run(), timeout]) } finally { clearTimeout(timer) } } }

页面里接入时就很清楚：

aboutToAppear() { this.scheduler.run([ { name: 'load-shell-data', critical: true, timeoutMs: 120, run: () => this.loadShellData(), }, { name: 'preload-cover-images', critical: false, timeoutMs: 800, run: () => this.preloadCoverImages(), }, { name: 'report-exposure', critical: false, timeoutMs: 500, run: () => this.reportExposure(), }, ]) }

这段代码解决的不是“写法好看”问题，而是职责边界问题。首帧前只保留必须任务，非关键任务后置，并且每个任务都有超时兜底。

案例二：后台恢复后旧请求覆盖新状态

冷启动之外，后台恢复也容易出现卡顿和状态错乱。比如页面第一次进入时发了一个请求，用户切后台后又回来，页面重新拉了一次数据。如果旧请求最后才返回，就可能把新数据覆盖掉。

可以用批次号挡住旧结果：

class RequestBatchGuard { private currentBatch = 0 next(): number { this.currentBatch += 1 return this.currentBatch } valid(batch: number): boolean { return batch === this.currentBatch } }

页面请求这样写：

async reloadAfterResume() { const batch = this.guard.next() const result = await this.repository.loadHomeData() if (!this.guard.valid(batch)) { return } this.homeData = result this.renderState = 'ready' }

这个封装很小，但效果直接：旧请求回来以后不能再改页面，新请求结果才有资格更新 UI。对列表页、首页、搜索页、后台恢复页都适用。

用脚本先扫一遍启动链路

下面这个脚本可以放在本地跑，用来检查启动任务是否分层合理。它不替代真机性能测试，但能提前拦住明显风险。

const tasks = [ { name: 'load-shell-data', phase: 'critical', costMs: 45, sync: false, canDefer: false }, { name: 'query-rdb-home-list', phase: 'critical', costMs: 128, sync: false, canDefer: false }, { name: 'preload-large-images', phase: 'deferred', costMs: 210, sync: false, canDefer: true }, { name: 'report-exposure', phase: 'deferred', costMs: 38, sync: true, canDefer: true }, { name: 'cleanup-cache', phase: 'deferred', costMs: 180, sync: true, canDefer: true }, ] function inspectLaunch(tasks) { return tasks.map(task => { const problems = [] if (task.phase === 'critical' && task.costMs > 100) { problems.push('首帧关键任务耗时偏高，需要拆分、缓存或后置') } if (task.phase === 'deferred' && task.sync) { problems.push('后置任务仍然是同步任务，可能抢主线程') } if (task.phase === 'deferred' && !task.canDefer) { problems.push('任务标成后置，但业务上不能延后，需要重新分类') } return { name: task.name, passed: problems.length === 0, problems, } }) } const result = inspectLaunch(tasks) console.log(JSON.stringify({ total: result.length, failed: result.filter(item => !item.passed).length, result, }, null, 2))

这段脚本会发现三个风险：

{ "total": 5, "failed": 3 }

`query-rdb-home-list` 作为首帧关键任务耗时偏高，应该缓存或拆小；`report-exposure` 和 `cleanup-cache` 虽然后置了，但还是同步任务，容易在首帧后马上造成卡顿。

三种处理方式怎么选

我更倾向第三种，但前提是缓存策略要清楚。缓存不是为了偷懒，而是为了让用户先看到可用内容，再用后台刷新补齐最新状态。

发布前我会验哪些点

后面怎么避免

我会把冷启动治理当成页面开发的固定检查项，而不是最后压测时才补救：

• 新页面先列启动任务清单；
• 给每个任务标记 critical 或 deferred；
• 关键任务必须有超时兜底；
• 异步请求必须有批次号；
• 后置任务不能继续同步抢主线程；
• 真机上至少看一次首帧、后台恢复和弱网表现。

真正有效的性能优化不是把代码写得更复杂，而是把任务优先级分清楚。首帧先稳住，非关键任务后置，旧请求不回写，页面启动体验就会稳很多。