导读 ：目前是挪动互联网全面倒退的时代，随着产品迭代速度的一直晋升，网页在 App 开发中占据的比例也一劳永逸。网页开发不仅能够较低成本的实现 iOS、Android 和 Web 等多端复用节俭人力，还可能无效缩小程序安装包的体积，更重要的是能够冠冕堂皇的躲避 Apple 对 iOS 端热更新的封闭。但另一方面，挪动端网页相较于原生页面而言在加载速度方面仍有比拟显著的差距。如何最大水平的减小这种差距，为用户提供一个良好的交互体验就成了每一个挪动开发者都须要把握的能力。本文将联合百度爱番番前端团队在过来一段时间里的理论研发经验，为大家从体验、性能、平安等方面系统分析并优化解决挪动端网页开发所面临的一些问题，让用户在 App 中关上网页时可能做到秒开，如原生页面般晦涩。
全文 5800 字，预计浏览工夫 12 分钟。
一、明确问题：网页迟缓
现阶段挪动端设施相较于传统的桌面级电脑还有很多不足之处，“带宽低”、“速度慢”、“内存小”是三个最显著的瓶颈，而这些却恰好是网页所依赖的重点。
其中首当其冲的就是网络条件，只管近年来随同着 4G、5G 的遍及用户手机的网速一直晋升，然而挪动端的网络提早永远是不确定的，它会受到各种条件的限度，现实生活中依然会有很多状况下会导致用户的网速不佳。而这种制约对网页而言是非常重大的，它会使得网页加载过程变得更加漫长，甚至是失败。
另一个方面是处理器的速度，现今的网页承载的信息越来越多，界面交互和业务逻辑也越来越简单，过多的计算量会让网页的解决工夫减少。而用户设施的硬件配置又是多种多样的，这个问题在其中占大多数的中低端机型上会更加显著。
对于网页而言，设施的内存大小也很重要的，更大的内存代表能够反对更多的网页内容。反之内存缓和会让 APP 在解决网页时变得效率低下，频繁呈现卡顿问题，最致命的是会更容易引发 OOM（Out Of Memory）景象导致程序解体。
随着技术的倒退，挪动端交互体验的一直晋升，人们对网页加载迟缓的忍受度也越来越低。有考察表明，超过 2/3 的用户认为对于网页来说加载速度是影响浏览体验最大的一个因素。当挪动端的网页加载工夫超过 3 秒，过半的用户会抉择间接来到。所以一个疾速的加载过程，是咱们进步 APP 网页品质的重要一环。
二、剖析痛点：加载耗时
在探讨如何晋升网页加载速度前，须要先以数字的模式给出网页加载迟缓的定义，明确一个基准点——如何定义用户所感触到的网页加载耗时。这里有一个计算公式：
网页加载耗时 = 网页加载实现的工夫 – 页面开始加载的工夫
其中页面开始加载的工夫比拟容易判断，从用户的角度来看，当他在下级页面点击某处跳转网页的时候就能够了解为页面开始加载了。
要害是如何界定网页加载实现的工夫，从客户端开发的方向来说，不论是 iOS 还是 Android，作为承载网页的 WebView 控件，都有一个 loadFinish 回调示意网页加载实现，然而实际上它并不能实在反馈用户的理论感官体验。
这里咱们先来梳理一下挪动端加载一个一般网页大抵须要通过哪些步骤：
由此可见，用户在关上网页的整个过程中先后会经验 无反馈、白屏、loading 这几个阶段，而在 WebView 控件 loadFinish 后，页面基本上还停留在 loading 界面。所以下面公式里提到的网页加载实现个别能够了解为业务数据渲染实现的时候，因为只有在这之后用户才可能真正看见想要的内容。
换言之网页加载迟缓体现在数值上来说就是指用户点击开启网页到业务数据渲染实现这段时间差过大，那么如何升高这个时间差就是咱们亟待解决的问题。
三、提供计划：优化实际
针对挪动端网页加载时无反馈、白屏、loading 这三个阶段，爱番番前端团队从后面提到的网络条件、处理速度、内存占用这几个点进行切入，针对缓存零碎、网页渲染机制、浏览器内核、网络申请效率等方向，制订了一系列的优化计划。
首先是“独立组件打包散发”，其后在此基础之上先后进行了“页面按需事后渲染”、“网页容器预初始化”和“业务申请前置执行”等解决。
咱们的指标是使爱番番内各次要网页的加载耗时升高到 1s 以内。
3.1 独立组件打包散发
通常来说，加载网页时动态资源的下载是十分耗时的，而且这个过程也是最容易受到网络环境影响的。为了解决这个问题，咱们将一组独立网页的 HTML、JavaScript、CSS 等动态资源压缩打包，造成一个离线组件包，在 App 启动后事后下载并解压到手机本地，当用户关上指标网页时，间接从本地加载这些资源。
而且一个 App 中依据业务模块能够分为多个离线组件包，每个离线包都领有惟一的版本号，通过后端搭建的离线包平台进行治理和下发，客户端会在指定的机会和平台同步离线包的版本信息，当有版本更新的时候，会在后盾批量静默下载并更新本地文件，用户在失常操作 App 时根本处在一个无感知的状态。
通过独立组件打包散发的计划能够绕过耗时的动态资源下载环节，网页加载过程中的白屏工夫也可能失去大幅升高。
3.2 页面按需事后渲染
页面按需事后渲染是为了一次性解决网页加载过程中各个环节问题所制订的优化计划，它基于客户端渲染（NSR，Native Side Rending）的思维实现，而 NSR 又是由服务端渲染（SSR，Server Side Rendering）引申而来的，NSR 的实质是分布式的 SSR。
SSR 是指在服务端实现网页的渲染，在服务端实现页面模板、数据填充、页面排版等工作，而后将残缺的 HTML 内容返回给浏览器。因为所有的渲染工作都在服务端实现，因而网页加载耗时会有所升高。然而这种优化计划导致前端页面的渲染须要在服务端实现，并不能很好进行前后端职责拆散，而且页面加载过程中不可避免仍会有一段白屏工夫，同时对于服务端的负载要求也会比拟高。
所以这里咱们采纳了 NSR 的形式，在用户登录胜利后，借助 WebView 控件启用一个 JS-Runtime，在用户手动跳转指标网页之前提前在后盾加载本地离线组件包中的资源并发送网络申请获取业务数据，再进行排版和渲染，动静直出，最初将网页设置到内存级别的 MemoryCache 中，从而达到点开即看的成果。退一步说，即使用户在点开页面时以上流程并未全副执行结束，也会因为提前执行了其中局部流程，较传统模式升高一些用户感知工夫。
然而另一方面，事后渲染也是一柄双刃剑，它实质上是利用空间换取工夫，会占用大量额定的内存空间。但内存在一些较低端的挪动设施上是十分宝贵的，过高的内存占用会引发一系列的体验和稳定性的问题。所以如何在尽可能低的内存占用状况下实现事后渲染，是须要认真衡量的。最终咱们决定按需只对 App 内入口级的几个重要页面凋谢了此性能，尽量避免占用过高的内存空间。
页面按需事后渲染的收益是非常显著的，经数据统计，指标页面的均匀网页加载耗时 iOS 从 2500ms 升高到了 231ms，Android 从 2803ms 升高到了 628ms。
3.3 网页容器预初始化
挪动端和 Web 端网页的加载过程并不完全一致，当 App 启动时默认是不会主动初始化内嵌浏览器内核的，只有当作为网页容器的 WebView 初始化时才会执行。所以针对这一点咱们设计了网页容器预初始化的优化计划。
3.3.1 容器预加载
容器预加载是网页容器预初始化计划的外围，即在用户开启网页前事后进行 WebView 控件的初始化以及相干资源和框架的加载以升高网页加载耗时。
爱番番在下载和更新离线组件包后，会在后盾初始化 WebView 控件，并加载组件包内的一个两头态网页，提前加载相干资源和框架，两头页加载胜利后 WebView 会被搁置在容器池中，开始监听一个自定的 JS 办法并进行期待。
当用户点击开启指标网页时，会先依据所在离线组件包内的配置文件，判断该该页面是否开启了容器预加载的性能，如果开启了会向容器池申请获取初始化好的 WebView，获取胜利后调用自定的 JS 办法告诉 H5 端，最初 H5 端通过 Vue Router 跳转指标页面。
并且在容器池向外交付 WebView 时，会主动从新初始化一个新的 WebView 开始加载两头页，为下一次用户操作做筹备。
因为在容器池中获取的 WebView 曾经提前进行了初始化，并且实现了组件包内一些公共资源和框架的加载，所以在当用户开启网页时所见到的白屏阶段就会大幅缩短，网页加载耗时也会显著升高。具体体现在数据方面，应用该计划优化的网页在 iOS 和 Android 双端加载速度均晋升了 200~300ms。
3.3.2 微前端架构
在后面的“容器预加载”计划中，因为各业务离线组件包内的页面间是互相独立的，无奈通过 Vue Router 跳转至其余组件包内的页面，所以须要在容器池中为每个业务组件包都提供一个 WebView 控件，用于加载两头态网页。随着业务组件包数量的一直增多，容器池中的 WebView 也会同步增多，如此会大幅提高内存占用，而如前文所说，较高的内存占用可能会引发程序运行卡顿，甚至解体等问题，这在较低端的设施上是尤其致命的。
而微前端计划则很好的解决了这个难题，所谓的微前端次要是将原先的多个业务离线组件包聚合成为了一个零碎，实现零碎内的整体调度，实现组件包间的交互。爱番番采纳的是 Master-Slave 架构，即主 - 从式设计：
Master：公共组件包，负责加载其余组件包，并且提供公共资源；
Slave：各业务组件包，负责不同模块的具体业务代码。
其中 Master 和 Slave 之间的数据交互在本地次要依赖 Symbolic Link 实现，Native 端会为包含公共组件包在内的每个离线组件包提供一个对应所在本地门路的 Symbolic Link。容器池中仅为公共组件包提供一个 WebView 控件，而公共组件包能够通过 Symbolic Link 进行本地寻址，找到对应业务组件包内页面的门路，再应用 Vue Router 就能够实现“容器预加载”中的跳转逻辑。这样一来就在原有 n 个 组件包的条件下，将组件容器池中的 WebView 控件从 n 个缩减为了 1 个，内存占用也缩减到了原来的 1/n，无效升高了程序的卡顿率和解体率。
另一方面，公共组件包也将各业务组件包内的一些公共框架资源提取了进去，如 Vue Router 等，各业务组件包在应用它们时，同样能够通过 Symbolic Link 定位到公共组件包中的对应框架资源。这样做的益处在于能够对公共资源进行对立治理，并在肯定水平上升高了离线组件包整体的体积。
通过微前端架构的优化，使得咱们的 App 在展现网页时明显降低了内存占用，防止了很多高内存带来的问题，而且各业务离线组件包的体积也都有所放大。
3.3.3 预置离线包
因后面提到的“微前端架构”中采纳了主 - 从式设计，作为 Master 的公共离线组件包内蕴含了业务离线组件包（Slave）所须要的一些公共框架资源。当用户关上业务组件包的某个页面时，公共组件包的存在就成为了这个页面能失常运行的前提条件，而当用户首次装置启动 APP 时，必然有一个从离线包平台下载公共组件包的过程，如果下载过慢会导致期间其余所有业务组件包都无奈失常应用。
为了防止此类问题的呈现，咱们采纳了将公共离线组件包预置进 APP 安装包内的形式来确保其优先性，并且它会随着 App 发版进行更新。APP 在首次装置启动后，个别会跳过预置包的下载流程，将其间接从 APP 复制到本地沙盒中。
而且另一方面，预置离线组件包的计划不仅实用于公共组件包，也实用于业务组件包，尤其对于其中一些体积较大下载耗时较长的包，能够在 APP 首次装置启动时为用户提供更加良好的交互体验。
3.4 业务申请前置执行
网页大多须要依赖服务器提供业务数据驱动页面展现内容。在后面剖析网页加载耗时的过程中能够得悉，在传统模式下业务网络申请要在 WebView 容器 loadFinish 后才会执行，针对这一点咱们设计了业务申请前置执行的优化计划。
3.4.1 客户端申请
为了反对业务申请前置执行的计划，首先须要对网页中的网络申请进行客户端化革新，即由 Native 端来解决网页中的业务数据网络申请。并且用客户端申请和服务器进行交互，还能够解决原先应用 XHR 申请的一系列相干问题，比方跨域限度、测试联调时无奈直连后端，网络层配置逻辑不对立等。
具体步骤方面，在网页进行网络申请时，首先由 H5 端配置业务申请信息，如申请地址、接口入参、自定义申请头等，并通过 JS-Bridge 将这些内容发送到 Native 端，Native 端再执行一些网络层的对立配置和优化后发送申请，比方增加 Cookie 和一些必要的申请头数据等。最初在收到 response 后再次通过 JS-Bridge 将内容返回给 H5 端。
这样一方面使得前端开发人员在调试时不必做任何配置和代理即可直连服务器，防止了传统模式下耗时的发包流程，大幅晋升了迭代开发的效率。另一方面，iOS 端的 WKWebView 增强了安全性限度，在拜访本地网页时禁止跨域申请，应用客户端申请能够完满躲避这个限度。最初它还能够将网页中所有的申请都在 Native 端进行集中管理和对立优化，这也为之后的“网络预加载”的实现提供了前提条件。
3.4.2 网络预加载
优化前（图 1）：
优化后（图 2）：
网络预加载是业务申请前置执行计划的外围。一般来说，网页中的业务网络申请最早能够在在页面构建 DOM 实现后执行，即 图 1 中的 B 点当前，而在爱番番中，大部分网页的业务申请相干参数都依赖于一些页面级的入参，然而页面入参须要期待本地 JS 脚本（爱番番 App 内置的 JS 文件，其中蕴含 H5 端和 Native 端间交互的泛滥逻辑，是网页失常加载的前提条件）注入实现之后才能够获取，又因为本地 JS 脚本须要在 loadFinish（即 图 1 中的 B 点）之后才执行注入，所以对咱们的大多数网页来说，发送业务申请的最早机会在 图 1 中的 C 点 当前。并且按前文“客户端申请”的技术计划，网页发送网络申请须要先由 H5 端 配置申请信息，再通过 JS-Bridge 申请 Native 端来真正执行。所以在进行网络预加载优化以前，业务网络申请的发送机会为 图 1 中的 D 点。
这里总结一下，传统形式下网页加载耗时能够简略分为两个局部：
1、解析动态资源并构建 DOM 构造和本地 JS 脚本注入（即 A-D）：这里咱们将此局部称为 Part1，它的耗时次要取决于前端；
2、业务网络申请的具体执行过程（即 D-F）：这里咱们将此局部称为 Part2，它的耗时次要取决于用户的网络环境和后端；
Part1 和 Part2 二者之间是前后串行的关系。那么咱们为了尽可能的升高用户感知工夫，能够将 Part2 尽量前置，将其与 Part1 做并行处理。
网络预加载正是基于这种思维实现的，首先前端开发人员会先将要执行预加载的网络申请的相干信息写入对应离线组件包的配置文件当中，当用户关上该离线包的指定网页时，会在 Native 端间接从组件包的配置信息中读取信息并立刻开始发送网络申请。这个动作会在子线程中执行，简直和 WebView 控件的初始化同时开始。
而之后获取 response 的机会（即图 2 中的 I 点）依据 Part2 耗时的不同，大体可分为 2 种状况：
1、在 Part1 实现之前（即 I 点在 J 点之前、G 点之后，如图 2 所示）：这时 Native 端会将网络预加载获取到的 response 进行缓存并开始期待，当 Part1 实现后 Native 端会收到 H5 端以失常形式发来的同一申请的申请，此时立刻通过 JS-Bridge 将缓存的 response 交付给 H5 端应用，并销毁缓存。另一方面，若期待时长超过肯定工夫限度，Native 端也会销毁缓存，视作此次网络预加载行为失败。如果胜利，这种状况下的收益为整个 Part2 的耗时（D-F）；
2、在 Part1 实现之后（即 I 点在 J 点之后）：这种状况下，当网络预加载的申请仍在途中时，Native 端就收到了 H5 端失常形式发来的申请申请，此时 Native 端会拦挡本次的申请申请，持续期待后面网络预加载的申请返回，待返回后再通过 JS-Bridge 将 response 交付给 H5 端应用。这种状况下的收益为 Part1 的耗时（A-D）。
以上就是网络预加载的次要实现原理，通过这种优化计划，在用户关上挪动端网页时，能够很大水平的升高用户在开启网页时的可感知时长，体现在数据方面，爱番番内应用此计划的网页加载耗时升高了 300 ~ 600ms。
四、总结收益：继续摸索
除了以上提到的这些，百度爱番番前端团队为了升高网页加载耗时还做了许多工作，比方 iOS 降级 WKWebView、Android 降级 X5 内核等等，限于篇幅起因，在此就不做开展了。
通过这些优化伎俩，爱番番挪动端各一级外围页面的加载耗时从均匀 2- 3 秒 收敛到了 1 秒 以内，基本上达到了秒开的既定目标。
当然，咱们将来须要做的还有很多，后续也会继续推动挪动端网页的性能优化工作，让用户在应用爱番番时可能享受到靠近原生页面的体验。
本期作者 | 时恩宝贝，百度爱番番前端高级工程师，领有多年研发经验。善于 iOS、Android、Web 多端开发。
招聘信息 ：
无论你是后端，前端，大数据还是算法，这里有若干职位在等你，欢送投递简历，爱番番业务部期待你的退出！
简历投递邮箱：geektalk@baidu.com（投递备注【爱番番】）
举荐浏览：
|解密百 TB 数据分析如何跑进 45 秒
|从 Web 图标演进历史看最佳实际 | 文末送书
|百度内容风控词表那些事儿 | 文末送书
———- END ———-
百度 Geek 说
百度官网技术公众号上线啦！
技术干货 · 行业资讯 · 线上沙龙 · 行业大会
招聘信息 · 内推信息 · 技术书籍 · 百度周边
欢送各位同学关注