导读｜H5开屏龟速常是令开发者头疼的问题。腾讯企业微信团队对该现象进行剖析优化，终究H5开屏耗时130ms，到达秒开作用！企微前端开发工程师陈智仁将共享可用可扩展的Hybird H5秒开计划。该团队运用离线包处理了资源恳求耗时的问题，在这个根底上经过耗时剖析找到瓶颈环节，进一步选用“预热”进行优化提速以处理了WebView初始化、数据预拉取、js履行（app初始化）耗时的问题。期望这些通用办法对你有协助。
背景
服务端烘托（SSR）是Web干流的功能优化手法。SSR直出相比传统的SPA运用加载烘托躲避了首屏拉取数据和资源恳求的网络往复耗时。团队针对Web开发也现已支持了SSR才能。近期出于动态化运营的考虑，咱们挑选了Web开发，一起咱们也接到了进步体会的诉求。
以企业微信要开发的页面为例：选用SSR计划，从用户点击到首屏烘托的耗时均值约600ms，白屏时刻的存在是能够感知到的。为了尽或许消除白屏到达秒开作用，咱们尝试做更多探究。
计划思路
1) 计划选型
怎么完成页面秒开呢？从最直观的烘托链路来下手剖析。下图列出了从用户点击到看到首屏烘托可交互，一个SPA运用首要环节的加载流程。咱们调研了业内相关计划，从烘托链路的视角来看下常见计划的优化思路。
- 传统离线包
在加载烘托过程中，网络IO是很明显的一个耗时瓶颈。传统的离线包计划思路很直接，假如网络耗时那就将资源离线，很好地处理了资源恳求的耗时。用Service Worker也能到达离线包的作用，一起也是Web标准。初次烘托优化一般需求结合客户端装备预发动脚原本到达缓存资源的作用。
- SSR
SSR则从别的的视点动身，在恳求页面的时分就进行服务端数据拉取和页面直出，首屏得以在一个网络往复就能够展现，有用地躲避了后续需求等候css/js资源加载、数据拉取的时刻。功能体会有比较大的进步，在BFF普及的状况下开发形式简略，很受欢迎。
- 公司内相关作业
考虑到WebView的初始化（冷发动/ 二次发动）、页面网络恳求、首屏数据接口的耗时，白屏时刻仍是可感知地存在的。以咱们要开发的页面为例选用SSR首屏耗时均值600ms，可交互时刻均值1100ms。怎么进一步消除白屏？这儿为各位介绍公司表里针对h5首屏功能优化的优秀计划。
手Q团队的VasSonic是集大成者，首要思路是选用WebView和数据预拉取并行的办法。这套计划需求客户端和服务端选用指定协议改造接入，开发时也有必定的改造作业。
微信游戏团队首要思路是利用jsCore做客户端预烘托，用户点击后直接上屏。这个办法也到达了很好的作用，首屏FCP时刻从1664ms下降到了411ms。
咱们做了一个扼要的计划比照，能够看到每个计划都针对烘托链路的某个或多个环节做了优化，其间VasSonic的作用比较显著。不过结合企业微信事务实践状况，咱们列出了如下几点考虑：
首要，接入对客户端和服务端有必定的改造本钱，事务开发也有必定的改造作业。其次，咱们现已有一套的一致发布平台，期望能复用这套发布才能。终究，功能上有没有进一步优化的空间呢？事务需求对体会上的要求是期望到达更好的功能作用或许说尽或许彻底地消除白屏。
根据以上考虑，咱们在上述计划的根底上做了进一步的实践探究，以期望到达更好的功能作用。
| 离线包 | SSR | VasSonic | CSR | |
| 资源加载 |
 |
|
|
|
| 数据拉取 |
|
 |
|
|
| JS履行 | ||||
| WebView发动优化 |
|
|||
| 首屏FCP |
|
|
|
|
| 可交互(取决于JS履行) |
2）计划架构
为了到达尽或许彻底消除白屏，咱们仍是从初始问题动身，结合烘托链路进行剖析，思路上针对每个环节采纳对应的优化办法。
每个环节的优化在详细落地时会存在着计划的利害取舍。比方预拉取数据一般的思路是交给客户端来做，可是存在着客户端恳求和h5恳求两套机制（鉴权、恳求通道等方面）怎么和谐的问题。在烘托链路剖析时，假如事务的js履行也贡献了不少耗时，有没有或许从通用根底计划的视点来处理这个问题，一起也能削减事务对功能优化的重视？这是个值得各位考虑探究的问题。详细的内容会在后面打开来说。
如图展现了计划的优化思路和干流程。计划运用离线包处理了资源恳求耗时的问题，在这个根底上经过耗时剖析找到瓶颈环节，进一步选用预热的思路进行优化提速，处理了WebView初始化、数据预拉取、js履行（app初始化）耗时的问题，终究到达了抱负的功能体会。
图1 上屏流程
图2 计划架构
下面咱们详细介绍下计划，包括：离线包技能、预热提速和进一步的优化作业。
离线包加快
为了躲避资源恳求耗时，咱们运用了离线包技能。离线包技能是比较老练的计划，相关打包、发布拉取的计划这儿不多说了，首要说下计划中一些规划上的考量。
1）加载流程
咱们经过offid作为离线包运用的标识，fallback机制确保离线资源不可达时用户也能够正常拜访页面，经过离线包预拉取和异步检测更新机制进步了离线包命中率，尽或许消除了网络资源加载的耗时。
2）fallback机制
由于用户网络状况的不确认性，离线包加载或许存在失利的状况。**为了确保可用性，咱们确认了离线包加载不堵塞烘托的思路。**当用户点击进口url，对应offid离线包在本地不存在时，会fallback恳求现网页面，一起异步加载离线包。所以咱们针对离线包的打包结构，按照现网URL path来安排资源途径。这样客户端恳求阻拦处理也会比较便利，不需求理解映射规矩。当发现离线包不匹配资源时，放过恳求透到现网即可。如图展现了咱们的离线包结构示例。
3. 离线包生命周期
为了进步离线包命中率，咱们会装备一些机遇（e.g.进口曝光）来预拉取离线包。
离线包的更新机制：客户端加载时根据offid检测到本地离线包的存在，则直接运用拉起，一起发动异步版别检测和更新。假如新包版别号大于本地版别号则更新缓存，一起发布平台也支持区别测验环境、正式环境以及按条件灰度。
上了离线包后，能够看到页面的首屏耗时均值从基准无优化的1340ms降到了963ms，离线包的预拉取和更新策略则使离线包命中率到达了95%。首屏耗时得到了必定的下降，但也还有比较大的优化空间，需求更一步的剖析优化。
预热提速
经过离线包的加快，咱们处理了资源恳求耗时的问题，不过从整个烘托链路来看还有很大的优化空间，咱们做了详细的耗时剖析，找出耗时瓶颈，针对耗时环节做了进一步的优化提速。
1）耗时剖析
离线包技能躲避了资源恳求耗时，可是从整个烘托链路来看还有很大的优化空间，咱们做了耗时剖析如下。
Hybird运用中，WebView初始化是比较耗时的环节，这儿咱们针对iOS WebView做了测验。
| 初次冷发动/ms | 二次打开/ms | |
| iOS（WKWebView） | 480ms | 90ms |
数据拉取方面，不同进口页面的耗时不一，某些进口页面比较重的接口耗时超过了1s。
此外，咱们发现js履行也贡献了不少耗时。以某进口页面为例，框架初始化时刻～10ms，app初始化时刻～440ms。
2）烘托链路预热提速
-
预热流程
咱们的方针是消除白屏，这儿抱负的计划是找到一种和事务无关的通用解法。计划的首要思路是预热，把能提早做的都做了。预热是不是便是把WebView提早创立出来就好了呢？不是的，这儿的预热涉及到多个烘托环节的优化组合。如图展现了预热的全体流程，下面一个个来解。
2）WebView预创立
为了消除WebView的耗时，咱们采纳了大局的预创立WebView，机遇为装备进口曝光。不过大局复用预热WebView不可避免地会引入或许的事务内存泄露问题，下文会介绍对应的躲避计划。
-
数据预拉取
数据拉取是页面烘托的一个耗时环节。为了消除数据预拉取耗时，在预创立WebView阶段咱们一起进行了数据预拉取。
数据预拉取常见的思路是交给客户端来做，可是存在着客户端恳求和h5恳求两套机制怎么和谐的问题，以恳求鉴权为例，存在以下的问题：
第一，Web团队自身有一层node BFF，完成了相应的数据拉取事务逻辑，而客户端则走的私有协议通道恳求C++后台，二者是不同的鉴权机制。
第二，假如交给客户端来做，能够接入HTTP恳求这套机制，改造本钱比较大，假如复用原有通道，则一份数据事务逻辑需求两套完成。
怎么规划一套通用可扩展的计划？咱们期望做到客户端只重视容器的才能（预热、资源阻拦等），屏蔽掉更深入的对Web的感知，这样的解耦能够有用操控计划的复杂度。因此，这儿咱们针对离线包装备项增加了preUrl字段，使客户端保护更通用的才能，数据预拉取交给事务团队来做，详细如下：
第一，客户端：拉取某个离线包装备项时会读取该字段，一起针对当前曝光的进口url或许存在多个有着不同的数据需求，这儿会进行搜集，将曝光url中的事务key参数拼接到preUrl来初始化WebView，这些作为通用才能。
第二，事务：preUrl页面在加载时会拉取相应的事务数据存到localStorage，实践的数据预拉取恳求放到事务方建议，也能够很好地兼容已有的技能栈。
-
JS预履行
很挨近方针了，终究js履行的耗时能不能消除呢？首要来看下440ms的耗时详细在哪里，经过剖析看到，框架初始化仅需求不到10ms的时刻，而真正的大头在事务代码的履行，其间代码编译耗时～80ms，其余的都是事务app初始化履行时刻，这个是事务自身复杂度形成的。
咱们首要考虑了创立两个WebView的计划，一个担任加载preUrl预拉取数据，另一个担任loadUrl上屏，这样规划上比较简洁强健，不过实践下来发现作用不抱负，如图展现了该计划的作用，烘托不稳定能够感知到白屏的存在。在现已有了预拉取数据和离线资源的状况下，理论上用户点击后需求等候的就只有烘托这块的耗时，实践咱们发现在复杂运用初始化时存在js履行耗时较大的问题。
终究咱们做了一个预履行的解法。结合SPA的特点，将preUrl作为SPA的一个子页面，不需求UI展现，只担任预拉取数据，这姿态页面加载完结的一起也完结了app提早初始化。而相应的不同进口切换页面时，不同于复用预热WebView从头reload页面，为了保存app初始化的作用，咱们采纳了一套Native告诉Web SDK，页面切换交给WebView操控的计划。其间，Native告诉则以调用SDK大局办法的办法。经过这种办法，进口页面间切换其实只是hashchange触发的子页面烘托，到达了不错的作用。流程图即预热计划的上屏部分。
该计划履行后咱们到达了预期方针作用，最大限度地消除了白屏挨近Native体会。需求上线后经过监控数据能够看到在命中预热和离线包逻辑的状况下，从用户点击到页面上屏可交互耗时均值约130ms。
进一步优化
1）离线包安全
在离线包安全方面，为了防止包篡改，每咱们次打包发布时都会生成包签名和文件md5。客户端在运用解析离线包时会校验完整性，在回来离线资源时会校验文件完整性。
2）稳定性
全体计划在功能上现已到达方针了，确保稳定性对产品体会也很重要。**咱们为了消除js履行的耗时，采纳了Native告诉Web SDK操控页面切换的办法。虽然比较灵敏可是也带来了稳定性的问题。**详细来说，假如SDK在做页面切换时反常，之后用户打开每个进口url都会看到相同的页面。进口页面的事务在用户运用过程中假如跳转了非SPA的链接一起没有注入SDK，之后的页面切换也会失效。
怎么确保预热容器的可用性呢？咱们规划了一套告诉机制确保客户端感知到预热容器的可用状况，并在不可用时得以恢复，如图。预热容器会保护isInit和isInvokedSuc两个状况。只有当preUrl成功加载和SDK履行成功上屏时，两个状况才会置true，此刻的预热WebView才是可用的，否则会回退到一般容器形式进行load url来加载页面。
此外，在每次进口url曝光时，已有的预热容器也会毁掉重建，也有用确保了容器的稳定性。
3）内存泄露
运用大局的预创立WebView，不可避免的会引入或许的事务内存泄露问题。在测验过程中，咱们也发现了这种例子。能够看到当点开运用了预热容器的页面后放置一段时刻，整个内存在不断上涨，终究会导致PC端页面的白屏或许移动端的Crash，这个状况终究归因是事务逻辑的完成存在缺点。
不过在根底技能的视点而言，开发者也需求采纳措施来尽或许躲避内存泄露的状况。首要思路是削减同一个预热容器的常驻，也便是对存活的容器设置有用期，在适当的机遇查看并整理过期容器，咱们挑选的机遇是App前后台切换时。
4）处理副作用
出于功能考虑，咱们挑选了经过Web SDK操控页面的计划，一起运用了大局的预创立WebView。这带来了副作用——当页面临容器做了大局的设置，或许会影响到下一个页面的体现。比方：设置document.title、经过私有JSAPI设置了WebView导航栏的表……
当履行这些操作时，在下一个页面也复用预热容器的状况下，大局设置没有得到整理重置或许掩盖，用户会看到上个页面的体现。
为了处理上述问题，事务能够在每个页面自动声明需求的体现来掩盖上个页面的设置，抱负的办法仍是根底技能来躲避这个问题来确保事务开发的一致性。咱们在SDK操控切换页面时，进行了一系列的重置操作。
此外，在Windows和Mac端，咱们也规划了双预热WebView的计划来彻底处理这个问题。每次运用时一起创立新容器，得以确保每次打开进口页面都是运用新创立的容器。当然，计划的另一面则是会带来App内存的上涨。
总结
咱们从烘托链路下手，针对每个环节进行剖析优化，终究沉淀了一套可用可扩展的Hybird H5秒开计划。从烘托链路的视点来看，计划经过离线包和预热一系列优化，将用户从点击到可交互的时刻缩短到了一个SPA路由切换上屏步骤的耗时。
上线后咱们监控发现，命中了预热离线逻辑的页面首屏耗时～130ms，相比于离线包、SSR都有优势，一起预热离线容器命中率也到达了97%，到达了抱负的体会作用。期望本篇对你有协助。
腾讯工程师技能干货直达：
1、算法工程师深度解构ChatGPT技能
2、10分钟！从架构视角读懂K8s
3、探秘微信事务优化：DDD从入门到实践
4、耗时减半？腾讯云OCR只做了3件事
阅览原文
