1. 为什么异步加载成了性能优化的第一张牌先从一个很实际的现象说起。我在过去几年接触过不少移动端项目其中印象最深的是一个H5活动页——首屏只有一个背景图、一个按钮、一段视频逻辑简单到不行但上线后用户反馈打开特别慢。当时第一反应是接口慢结果一查接口返回才80毫秒问题出在渲染主线程被同步任务卡死了。这事特别典型。很多人一说性能优化第一反应是压缩图片、合并请求、启用CDN这些都对但都属于把货搬得更快。真正决定用户体感的不是货多快能到而是货到了之后你的页面能不能立刻用起来。只要主线程还在处理同步脚本、同步请求、同步渲染用户的手指就得一直等着。异步加载解决的不是资源多快到达而是资源到达后如何不打断用户的交互节奏。还有一点容易被忽略异步加载不是单纯的技术手段它是一种资源的调度策略。就好比做饭不是所有菜都得下锅才能开饭主菜先下锅汤可以慢慢熬凉菜甚至可以在上桌前的空档随手拌。放到网页和App场景里首屏渲染是主菜第三方统计脚本、长列表图片、广告SDK、用户行为上报这些都是凉菜和汤完全没必要让它们挡住开饭的时间。所以本文的核心思路基本可以概括为三件事第一从原理上把异步加载这件事拆透搞清楚它到底优化了什么、能优化到什么程度第二按场景梳理主流的异步加载方案明确各自的适用边界第三聊一下移动端和游戏场景里性能优化的特殊取舍以及如何用数据判断异步优化是否真的有效。2. 异步加载的底层逻辑I/O链路与渲染阻塞的本质2.1 一次资源加载到底走了多远要理解异步加载绕不开一个基础问题浏览器或移动端运行时从请求一个资源到真正把内容画出来中间发生了什么。以Web页面为例加载一段脚本大致经过这几个阶段DNS解析把域名换成IP地址通常需要几十毫秒到几百毫秒。TCP连接建立连接的过程HTTPS还要加上TLS握手这里的时间成本往往被人低估。发送HTTP请求服务端处理后返回资源。浏览器拿到资源后开始解析、编译、执行脚本。脚本执行过程中如果操作了DOM浏览器还要重新计算样式、布局然后绘制。这五步里前三步属于纯网络耗时后两步属于解析执行耗时。同步加载的意思就是页面解析到这里必须等这一整套流程全部走完才能继续读后面的HTML。你可以想象成一条流水线上一个工位卡住了所有后续工位全部停工等待。最典型的例子是script src.../script放在head里。这个标签一旦被解析到浏览器会立即发起请求并且在脚本下载和执行完成之前暂停对后续HTML的解析。如果这个脚本本身逻辑复杂或者所在服务器响应慢白屏时间就会肉眼可见地拉长。这里要特别强调一点阻塞的不只是脚本自身的加载时间而是整个页面的首屏可用时间——用户看到的不只是慢了一步而是页面一片空白点了没反应。2.2 事件循环里的两个队列为什么异步任务可以插队异步加载之所以能解决问题核心在于运行时环境的事件循环机制。简单解释一下JavaScript是单线程的但它不是只有一个队列而是把任务分成了同步任务和异步任务两类。所有同步任务按照顺序在调用栈里执行而异步任务比如网络请求的回调、定时器、事件回调会先被挂到任务队列里等调用栈空了才轮到它们执行。这里的关键点是异步任务并不会让整个页面卡住等它完成。页面会先继续解析、继续渲染等网络数据返回之后再通过回调把内容更新到界面上。这个过程就是异步加载存在的技术根基——不是加载本身变快了而是加载过程中用户不再被强制等待。在Web Worker或者移动端游戏引擎里这个机制更是被运用到了极致。比如小程序里常见的wx.request它本质上就是异步API请求发出去之后UI线程立刻释放又比如Unity手游里的AssetBundle异步加载接口加载资源时主线程可以先渲染场景、播放动画等资源准备完毕再注入当前画面。可以说凡是需要和时间赛跑的地方异步都是一个绕不开的杠杆。2.3 一个容易被忽略的成本同步执行期的CPU占用很多人会把异步加载和延迟加载混为一谈其实不完全一样。延迟加载往往是晚一点开始干活但异步加载更微妙的地方在于它能把一个大活儿拆成小碎片插在空闲时间段里执行从而避免某个瞬间CPU占用率飙升。这一点在手游场景里尤其重要。手游的渲染线程和逻辑线程往往是独立运行的但JavaScript或C#逻辑线程一旦出现长时间阻塞就会出现掉帧。游戏里UI面板、地图区块、角色模型往往都是异步加载的就是为了防止点击某个按钮后整个游戏卡半秒的情况出现。和网页场景相比游戏对异步加载的实时性要求更高因为每一帧渲染的时间窗口只有16毫秒左右60帧率下任何超过这个窗口的同步操作直接体现为肉眼可感知的卡顿。3. 常见的异步加载姿势与它们各自的适用场景3.1 图片懒加载门槛最低的收益来源以Web前端为例最经典的异步加载实践就是图片懒加载。原理不复杂把img标签的真实地址先存在>