异步加载和性能优化，这两个词放在一起的时候，很多人第一反应是“不就是老生常谈吗”。但我在一线做了十多年，这两年又跨到 App 侧去优化启动性能，发现不少人对这两个词的认知还停留在“会用个 async/await、知道图片要懒加载”的层面。真正要把性能做上去，你得先理解异步加载的运行机制，明白它到底优化了什么、为什么能优化，然后再设计针对性方案。这篇文章脱胎于我前阵子整理的一份内部分享材料（编号就是标题里的 02-08，属于系列里的原理篇），我把原理重新梳理了一遍，重点讲清楚异步加载的底层机制，再结合前端和 Android 两端的具体案例，把性能优化的落地步骤和踩坑经验一并交代清楚。无论你是在做 Web 项目、跨端应用，还是原生 App，这份东西应该都能派上用场。
异步加载不是万能药，但它确实是绝大多数性能问题的解药。把机制吃透之后你会发现，所谓优化方案，本质上都是在“调度时间”和“减少浪费”这两件事上做文章。
1. 异步加载到底在解决什么问题
1.1 同步模型的核心矛盾：阻塞
很多人第一次接触异步加载时，会觉得它像是“奇技淫巧”，好像代码换个写法而已。但异步加载真正解决的，是同步模型下“阻塞”这个核心矛盾。拿浏览器举例，JavaScript 在浏览器主线程上运行，渲染、事件派发、HTTP 响应处理全部要排队在这一个线程上完成。如果你用同步方式去加载一段很大的脚本、或者同步等待一个网络请求返回，主线程就被占住了，用户点按钮没反应、页面滚动卡顿、甚至整个页面白屏。这种问题我在优化一些老项目时经常碰到——一个首屏请求从发起到返回要 2 秒，页面就干等着这两秒，用户早就走了。
为了讲清楚这个道理，我常跟团队用餐厅例子打比方：同步加载就像你到餐厅点完菜，然后自己跑到后厨去盯着厨师做，在这个过程中你什么都干不了。异步加载则是点完菜回到座位刷手机，厨房做好了自然会端上来通知你。第二种方式让“等待时间”变成了“可用时间”。这个类比虽然简单，但把异步的核心价值说透了——它并不是让网络请求变快，而是把阻塞期间浪费的时间重新利用起来。
1.2 事件循环和任务队列：异步的底层机制
接下来把底层机制讲透，否则后面写异步代码还是会踩坑。无论是浏览器还是 Node.js，JavaScript 的执行引擎都是单线程模型，这个“单线程”指的是同一时刻只有一段代码在运行。那为什么还能“同时”去发网络请求、处理定时器、响应用户输入？靠的是事件循环（Event Loop）和任务队列。
事件循环的基本流程可以概括为三步：取一个宏任务执行，执行期间产生的所有微任务清空，然后根据浏览器渲染更新时机决定要不要渲染页面，循环往复。宏任务包括 script 脚本的整体执行、setTimeout 和 setInterval 的回调、DOM 事件回调、I/O 操作回调；微任务包括 Promise 的 then/catch/finally 回调、queueMicrotask 注册的任务等。
为什么要区分宏任务和微任务？因为执行的优先级不同。当前宏任务结束后，会立刻把微任务队列全部执行完，然后才会进入下一个循环。这就造成了一个非常关键的现象：即使你写了Promise.resolve().then(() => { /* A */ })，又在后面用setTimeout(() => { /* B */ }, 0)注册零延迟任务，在这个宏任务结束后先执行的一定是 A，而不是 B。这些细节一旦搞错，排查异步顺序问题时就会一头雾水。
另外有个具体数值要提醒一下：在现代 Chrome 里，setTimeout 嵌套超过 5 层后，最小延迟会被强制限制为 4 毫秒。这就是为什么不能用 setTimeout 精确地在下一帧控制动画。想做逐帧控制，应该用 requestAnimationFrame 去跟渲染频率对齐。理解事件循环的调度次序，是异步性能优化最重要的前置知识。
1.3 异步带来的三重性能收益
把事件循环搞清楚后再来看性能，你就能理解异步加载带来的收益实际上来自三个层面。
第一个是“不阻塞主线程”。同步加载时，耗时操作占着主线程，页面渲染和交互全部让路；异步加载则把这些耗时操作塞进事件队列或者交给浏览器底层线程（比如网络线程），主线程可以继续处理渲染和事件。用户看到的结果是页面不卡、操作跟手。
第二个是“并行化”。浏览器在 HTTP/1.1 下对同一个域名默认只有 6 个左右的并发连接，一条连接上一次只能服务一个请求。如果资源是同步逐个加载，从第 1 个到第 N 个只能排队走；而异步加载可以同时发起多个请求，让它们并行下载。HTTP/2 的多路复用又在连接层面做了进一步优化，但应用层如果不用异步方式去发起请求，资源还是没法高效并行。
第三个是“关键路径缩短”。用户真正关心的是内容什么时候可见、能不能快点交互，而不是所有资源都加载完。异步加载允许我们把“决定首屏能否显示”的资源级别提上来，把次要资源往后排。一个典型的例子是首屏不依赖的统计脚本和第三方 SDK，完全可以在页面核心内容渲染完成后异步加载。从时间轴来看，首屏时间可能没变，但用户可交互时间和完全加载时间更早了。
这三重收益中，前两点偏工程，第三点偏产品。真正拉开项目性能差距的，往往是对关键路径的拆解能力，也就是后面几节要讲的落地方法。
2. 前端异步加载的常见实现与选型
2.1 从回调到 async/await：三种异步模式的取舍
前端异步编程经历了回调、Promise、async/await 三个阶段，很多团队到今天代码里还是三种风格混着写。倒不是非要统一，但你要清楚每种模式的边界。
回调风格最大的问题是嵌套地狱和错误处理缺失。我在维护一个三年前的旧项目时，见过一层套一层的回调，中间还夹杂着两个分支判断，改一处牵连三处。Promise 把状态管理和错误捕获统一了，但多个异步任务有依赖关系时，then 链仍然显得啰嗦。async/await 看起来是终极形态，代码和同步写法几乎一样，可读性和可维护性都明显好，它内部仍然是 Promise 和事件循环，只是语法糖。
// 回调风格 fetchUserData(userId, function (data) { renderUser(data); }); // Promise 风格 fetchUserData(userId).then(renderUser); // async/await 风格 async function init() { const data = await fetchUserData(userId); renderUser(data); }选择上的一个实用建议：新代码统一用 async/await，但对外暴露的库接口保持 Promise 风格，这样调用方无论是继续用 await 还是切回 then，都完全兼容。还有一个经常被忽略的点：async/await 里的错误处理一定要用 try/catch 包住，不然 unhandledrejection 会让错误连错误上报都进不来，线上查问题会非常难受。
2.2 资源加载的异步化：defer、动态 import、预加载
代码层面的异步只是第一步，浏览器加载资源时的异步化同样关键。脚本标签有两个容易混淆的属性：async 和 defer。async 脚本下载完立即执行，执行时阻塞渲染，所以多个 async 脚本的执行顺序不保证；defer 会在文档解析完成后按顺序执行，不阻塞解析过程。我的习惯是：如果脚本之间有依赖关系，必须用 defer；如果脚本之间完全独立、谁先谁后都无所谓，可以 async；没有必要的第三方统计脚本，直接动态插入到页面 body 尾部异步执行。
然后是 Webpack/Vite 场景下的动态 import。这是资源异步加载最核心的手段之一，配合代码分割按路由懒加载，能把首屏 bundle 从几百 KB 降到几十 KB。
// 按路由懒加载 // Vue 方式 const routes = [ { path: '/detail', component: () => import('./views/Detail.vue') } ]; // React 方式 const Detail = React.lazy(() => import('./views/Detail'));动态 import 返回的是 Promise，加载行为本身是异步的，浏览器会把它当成一个新的请求去下载独立的 chunk。这里提醒一下：切分粒度不能太细，否则会出现几十个 1KB 的 chunk 来回请求，耗时全花在握手和 Header 上。一般以路由页面为粒度，或者按业务模块聚合，比较合适。
预加载方面，<link rel="preload">用于提前加载当前页面肯定会用到的关键资源，<link rel="prefetch">用于加载下一个页面可能用到的资源。preload 的优先级很高，用错反而会挤占首屏关键资源。我见过团队把首屏用不到的字体文件 preload，结果字体解码任务直接拖慢了 LCP。记住原则：preload 只给首屏关键资源用，prefetch 才有资格给次要资源用。
2.3 懒加载与骨架屏：首屏体验的实战落地
图片懒加载是最常见、收益也最直观的优化方式。传统做法是监听 scroll 事件判断图片是否进入视口，现在直接用 IntersectionObserver，性能好得多，回调也是异步触发，不阻塞主线程。
const observer = new IntersectionObserver((entries) => { entries.forEach((entry) => { if (entry.isIntersecting) { const img = entry.target; img.src = img.dataset.src; observer.unobserve(img); } }); }, { rootMargin: '200px' }); document.querySelectorAll('img[data-src]').forEach((img) => observer.observe(img));注意 rootMargin 这里的 200px 表示提前 200px 加载，避免用户快速滚动时出现白屏等待。这个数值过大会导致视口外的图片也提前加载，内存和流量都会上去，一般我设 100px 到 300px 区间，具体看页面滚动速度。
骨架屏（Skeleton）值不值得上？我的判断标准是：如果首屏数据依赖的网络请求稳定超过 800ms，就值得上；低于这个值，直接显示真实内容反而更好。有些团队为了骨架屏把页面改得特别复杂，甚至要同步两份 UI 状态，这种过度优化不如不做。另外骨架屏要尽量模拟真实内容的形状，而不是随便放几个灰色色块，否则用户感知不强，还会被认为页面坏了。
3. 移动端场景下的异步加载实战
3.1 Android 启动性能优化：把同步初始化改成异步
前端之外，Android 启动优化是异步加载思想最典型的应用场景之一。冷启动从用户点击图标到看到第一帧画面，中间要经历 Application 创建、Activity 创建与布局、首帧渲染。Application 的onCreate()是最容易被塞满同步操作的地方——各种 SDK 初始化、数据库连接、埋点配置、图片库预初始化，全堆在这一个方法里，直接拖慢启动。
优化原则有三条：能异步不同步，非必要不上主线程，不得不错峰调度。第一点好理解，把耗时初始化丢到子线程执行。第二点是说有些 SDK 强制要求主线程初始化，这类就尽量延迟到业务真正需要时再初始化。第三点最容易被忽略：就算你把十个初始化任务全丢到子线程，它们同时启动也会抢 CPU，主线程一样被拖住。所以实践上要给任务排队，按优先级和耗时错开执行。
我实际优化过一个冷启动耗时 3.2 秒的项目，主要改动就是把这些步骤异步化：把即时通讯 SDK、推送 SDK、图片加载库的初始化丢到ExecutorService里执行，确需主线程的任务放到首帧渲染完成之后，用View.post()或者IdleHandler延迟调度。最终冷启动降到 1.4 秒，那段时间用户反馈“卡死打不开”的工单明显变少。
3.2 列表图片异步加载与内存控制
移动端列表页的流畅度，很大程度取决于图片异步加载做得怎么样。Glide、Coil、Fresco 这些库本身都是异步解码，默认在子线程做 Bitmap 解码，再回主线程更新 ImageView，这比自己手写AsyncTask加载图片要可靠得多。但我见过不少项目迁到图片库之后，仍然卡顿，仔细看是列表 item 里用了同步读取本地文件，或者在 Adapter 的getView里直接做了耗时的数据格式转换。
这里有个经验法则：列表 item 的bindViewHolder里只做 UI 绑定，任何磁盘读取、网络请求、Bitmap 处理、JSON 解析都不要出现在这里。要做就在数据层异步准备好，再一次性丢给 RecyclerView 渲染。RecyclerView 本身也支持预取（Prefetch），当它检测到用户正在快速滑动时，会提前在后台线程创建下一个 item 的 ViewHolder，这个默认开关建议保留。
图片内存控制上，大图一定要做采样压缩，按 ImageView 的实际尺寸来采样，而不是把原始分辨率整张解码。《Glide 的默认做法是计算屏幕尺寸和 Target 尺寸后自动压缩，但如果你直接加载一张 4000x3000 的图片到一个 400dp 宽的 ImageView 里，它也能处理，只是浪费内存和 CPU。更稳妥的做法是服务端先按需裁剪尺寸，客户端只加载对应的 URL。
3.3 数据预取与分层缓存
异步加载的另一个重要抓手是“数据预取”，核心思想是把未来必然要用的数据提前准备好。Android 里常见的做法是启动时在后台线程预取首页接口数据，等用户点进首页时数据已经在内存里了，展示无缝。
但预取要注意时机和流量成本。如果每次冷启动都预取三个接口，用户其实只点进一个页面，那白白浪费了 2/3 的网络流量。我的做法是：首屏接口必须预取，次屏接口按用户行为概率预取，比如电商 App 的用户进入首页后有 60% 概率点击商品详情，那详情页的静态资源和首屏数据可以预取；如果只是偶尔点击的页面，不做预取，等点击时加载。
缓存策略上，标准做法是三层：内存缓存放当前会话高频数据，磁盘缓存放过去 7 天内的数据，网络层做条件请求（ETag/Last-Modified）。分层缓存的关键不是“怎么存”，而是“怎么失效”。我在项目里见过最糟糕的缓存策略：磁盘缓存永不过期，版本升级后老数据还能被加载出来，结果线上出现大量机型适配错乱的问题。合理的做法是缓存里带版本号、时间戳、业务字段，每次读取先校验有效期，过期就回源更新。
4. 性能指标的度量与优化工具链
4.1 关键指标怎么解读
优化之前必须先量化，不然就是“感觉变快了”。前端 Web 性能指标目前看这几个比较实用：FP（First Paint）、FCP（First Contentful Paint）、LCP（Largest Contentful Paint）、TTI（Time to Interactive）、TBT（Total Blocking Time）、INP（Interaction to Next Paint）以及 TTFB（Time to First Byte）。
- LCP 衡量视觉加载速度，优秀标准是 2.5s 以内，超过 4s 算差。
- INP 衡量页面交互响应能力，优秀标准是 200ms 以内。
- TBT 衡量从 FCP 到 TTI 期间主线程被长任务阻塞的总时长，它直接反映主线程是否被异步任务占满。
- TTFB 反映服务器响应速度和网络链路的快慢，如果它本身就大于 1s，后面再怎么优化前端都没用。
指标不能单独看。我遇到过 LCP 很好看但 INP 一塌糊涂的页面，原因是首屏为了追求快把大图片全用异步加载，导致主线程同时在做解码和布局，用户点击按钮要等 500ms 才有反馈。正确姿势是看一组指标的组合，而不是只盯某一个。
实验室数据和真实用户监控（RUM）要区分对待。Lighthouse 跑出来的是固定机型、固定网络下的结果，只能做基准；用户在弱网慢机上体验是另一回事。团队里要建立 RUM 数据看板，按网络类型、机型、地区拆分，重点看 P75 以上的分位数，因为 P50 代表努力的用户，P75 才是真实大众。
4.2 性能分析工具的实操流程
工具方面我最常用的组合是 Chrome DevTools 的 Performance 和 Lighthouse，移动端再配 Android Studio 的 Profiler。
Chrome Performance 的用法我分享一下：选好设备模拟和网络限速（比如 Low-end mobile），点击 Record，然后在页面上完成一次完整操作（刷新首屏、点击跳转、滚动列表），录制 10 秒左右停止。接下来看主线程时间轴，找标红的 Long Task。点开某个 Long Task 能看到它的调用栈，是 JavaScript 执行、样式计算、布局、绘制还是合成？这一步直接定位瓶颈。举个例子，如果长任务集中在“Evaluate Script”，说明是某个 JS 文件执行耗时长，考虑加快代码分割和异步加载；如果集中在“Layout”，说明 DOM 改动触发大面积重排，考虑减少 DOM 操作或加content-visibility。
Lighthouse 操作更简单，跑一次得到 Performance、Accessibility、Best Practices、SEO 四类分数。但它给的优化建议并非全部值得做，比如它可能建议你给某个图片加预加载标记，但实际上这图片不在首屏关键路径内，加了反而有害。工具建议只能作为线索，最终判断要看关键路径分析。
Android 端用 Profiler 的 CPU 录制功能，启动后手动记录 5 秒冷启动过程，可以清晰看到主线程每个方法的耗时。常见套路是先看 Application 的 onCreate 上有没有长方法，有就拆异步；再看列表滚动时的 Jank 是不是持续出现，持续出现在哪个方法上，再进行针对性处理。
4.3 可复制的优化路线清单
根据这些年实操项目的经验，我总结出一条通用优化路线，照这个顺序走，基本不会跑偏：
- 先量基线：用 Lighthouse 或 Profiler 跑出当前各项指标，记录到表格。
- 定位瓶颈：按“网络->解析->执行->渲染”四段逐个排查，找出耗时最长的一段。
- 按收益排序：优化项排优先级，先做首屏关键路径，再做运行时体验。
- 实施迭代：一次只改一个优化点，改完立刻重新测量，确认指标变化再动下一个。
- 建立监控：把 RUM 指标可视化，长期观察优化是否被用户真实感知。
| 优化项 | 收益 | 成本 | 风险 |
|---|---|---|---|
| 代码分割按路由懒加载 | 高 | 低 | 低 |
| 图片懒加载 | 高 | 低 | 低 |
| 异步初始化 SDK | 高 | 中 | 中（SDK 兼容性） |
| 数据预取 | 中 | 中 | 中（流量成本） |
| 骨架屏 | 中 | 中 | 中（复杂度提升） |
| 过度拆分 chunk | 低 | 中 | 高（请求数膨胀） |
这套路线的好处是每一步都有据可查，不会靠感觉优化。我自己的经验是，按这个顺序做下来，大部分项目的首屏指标都能提升 30% 以上，前提是每一步测量都严格。
5. 异步加载的坑与排查技巧
5.1 几个经典的异步问题与排查思路
异步代码写多了，问题也会成倍增加，最常见的是这三类。
第一类是竞态条件。用户连续点击按钮发起两次请求，第一次请求后响应慢，第二次请求后响应快，结果后发先至，页面显示的数据反而是旧数据。解决思路是用请求序号或 AbortController 取消前一个请求。
let requestSeq = 0; async function fetchData(url) { const currentSeq = ++requestSeq; const response = await fetch(url); const data = await response.json(); if (currentSeq === requestSeq) { render(data); } }第二类是异常吞掉问题。async/await 配合 try/catch 时，catch 里只打日志但不做任何兜底，用户界面就会冷冰冰地空白。正确姿势是 catch 里至少渲染一个错误状态，并给用户重试入口。
第三类是加载顺序错乱。多个异步任务之间其实存在依赖关系时，不能一股脑并行。比如 A 接口拿到配置后，B 接口要根据配置参数去请求。这时用 Promise.all 会导致 B 拿不到最新参数，用嵌套又回到回调地狱。正确做法是把 A 的结果通过参数传给 B，或者写成一个串行异步函数。
排查这类问题的通用思路是“复现+记录”。线上环境难排查时，一定要在代码里给每次异步请求打上唯一标识，不仅包含 URL 和参数，还包含发起时间、当前页面路由、用户操作轨迹。这样出问题时通过日志能还原现场，不用盲猜。
5.2 性能优化容易踩的误区
性能优化做到后面，很多人会陷入一些误区。第一个是过度优化。我看到有人把一个只有 20KB 的 JS 文件拆成 8 个 chunk，结果请求数量多了 7 个，TTFB 时间反而涨了。优化要平衡体积和请求数，不是越小越好。
第二个误区是只优化启动不优化运行时。团队大会汇报时都喜欢晒“冷启动降低 40%”，但日常体验更多取决于列表滑动流畅度、页面切换响应速度。如果启动优化牺牲了运行时性能，比如把所有初始化全丢到首屏后，结果用户开始滑动时才大量创建对象，卡顿反而被推迟了。
第三个误区是优化方案不回归验证。异步改造完成后，必须重新跑一次完整的量化测试。我见过团队把加载方式改完之后，发现首屏时间没变，原因是被优化掉的脚本只是被搬了个位置，没减少实际执行量。性能优化必须拿数据说话，数字没变就是没优化。
5.3 实操速查表
最后整理一份排查速查表，遇到问题直接对照：
| 症状 | 可能原因 | 排查建议 |
|---|---|---|
| 白屏时间过长 | 首屏 JS 过大或同步请求阻塞 | 看 TTFB 和资源加载瀑布图，做代码分割 |
| 页面卡顿无法响应 | 主线程长任务阻塞 | Performance 录制，定位长任务调用栈 |
| 图片加载闪烁 | 懒加载阈值过小 | 调整 IntersectionObserver 的 rootMargin |
| 列表滚动掉帧 | item 绑定阶段做了耗时操作 | 检查 ViewHolder 内有无磁盘/JSON/解码操作 |
| 异步顺序错乱 | 依赖关系没处理 | 用事件循环机制分析，串行还是并行明确区分 |
| 指标没提升 | 只是搬运了代码位置 | 确认资源加载总量和执行量是否真正减少 |
我平时优化项目，都会把这张表贴在代码评审规范里。代码评审时如果新增的异步代码可能踩中某一行，直接按表里的排查建议去验证，省下不少沟通成本。
回看这些年的优化经历，我最大的体会是：异步加载和性能优化没有银弹，也不可能照着某个模板套一遍就万事大吉。每一条优化策略能生效，前提都是你确实理解了底层机制，并且用数据验证了改动收益。工程上解决问题的方式从来不是一步到位，而是不断量化、定位、修改、再量化。把这套动作变成习惯，你会发现所谓的性能问题其实都很常规。
