移动H5首屏秒开优化计划

　　跟着移动设备功用不断增强，web 页面的功用体会逐步变得能够承受，又由于 web 开发方式的许多优点(跨渠道，动态更新，减体积，无限扩展)，APP 客户端里呈现越来越多内嵌 web 页面（为了配上当时盛行的说法，以下把全部网页都称为 H5 页面，尽管或许跟 H5 不要紧），许多 APP 把一些功用模块改成用 H5 完结。

　　尽管说 H5 页面功用变好了，但假如没针对性地做一些优化，体会仍是很糟糕的，首要两部分体会：

　　页面发动白屏时刻：翻开一个 H5 页面需求做一系列处理，会有一段白屏时刻，体会糟糕。

　　呼应流通度：由于 webkit 的烘托机制，单线程，前史包袱等原因，页面改写/交互的功用体会不如原生。

　　本文先不评论第二点，只评论第一点，怎样削减白屏时刻。对 APP 里的一些运用 H5 完结的功用模块，怎样加速它们的发动速度，让它们发动的体会挨近原生。

　　进程

　　为什么翻开一个 H5 页面会有一长段白屏时刻？由于它做了许多作业，大概是：

　　初始化 webview -> 恳求页面 -> 下载数据 -> 解析HTML -> 恳求 js/css 资源 -> dom 烘托 -> 解析 JS 履行 -> JS 恳求数据 -> 解析烘托 -> 下载烘托图片

　　一些简略的页面或许没有 JS 恳求数据 这一步，但大部分功用模块应该是有的，依据当时用户信息，JS 向后台恳求相关数据再烘托，是惯例开发办法。

　　一般页面在 dom 烘托后能显现雏形，在这之前用户看到的都是白屏，比及下载烘托图片后整个页面才完好显现，首屏秒开优化便是要削减这个进程的耗时。

　　BETWAY登录优化

　　上述翻开一个页面的进程有许多优化点，包括BETWAY登录和客户端，惯例的BETWAY登录和后端的功用优化在桌面年代现已有最佳实践，首要的是：

　　下降恳求量：兼并资源，削减 HTTP 恳求数，minify / gzip 紧缩，webP，lazyLoad。

　　加速恳求速度：预解析DNS，削减域名数，并行加载，CDN 分发。

　　缓存：HTTP 协议缓存恳求，离线缓存 manifest，离线数据缓存localStorage。

　　烘托：JS/CSS优化，加载次序，服务端烘托，pipeline。

　　其间对首屏发动速度影响最大的便是网络恳求，所以优化的要点便是缓存，这儿着重说一下BETWAY登录对恳求的缓存战略。咱们再细分一下，分红 HTML 的缓存，JS/CSS/image 资源的缓存，以及 json 数据的缓存。

　　HTML 和 JS/CSS/image 资源都归于静态文件，HTTP 自身供给了缓存协议，阅览器完结了这些协议，能够做到静态文件的缓存，详细能够参阅这儿，总的来说，便是两种缓存：

　　问询是否有更新：依据 If-Modified-Since / ETag 等协议向后端恳求问询是否有更新，没有更新回来304，阅览器运用本地缓存。

　　直接运用本地缓存：依据协议里的 Cache-Control / Expires 字段去确认多长时刻内能够不去发恳求问询更新，直接运用本地缓存。

　　BETWAY登录能做的最大极限的缓存战略是：HTML 文件每次都向服务器问询是否有更新，JS/CSS/Image资源文件则不恳求更新，直接运用本地缓存。那 JS/CSS 资源文件怎样更新？常见做法是在在构建进程中给每个资源文件一个版别号或hash值，若资源文件有更新，版别号和 hash 值改变，这个资源恳求的 URL 就改变了，一同对应的 HTML 页面更新，变成恳求新的资源URL，资源也就更新了。

　　json 数据的缓存能够用 localStorage 缓存恳求下来的数据，能够在初次显现时先用本地数据，再恳求更新，这都由BETWAY登录 JS 操控。

　　这些缓存战略能够完结 JS/CSS 等资源文件以及用户数据的缓存的全缓存，能够做到每次都直接运用本地缓存数据，不必等候网络恳求。但 HTML 文件的缓存做不到，关于 HTML 文件，假如把 Expires / max-age 时刻设长了，长时刻只运用本地缓存，那更新就不及时，假如设短了，每次翻开页面都要发网络恳求问询是否有更新，再确认是否运用本地资源，一般BETWAY登录在这儿的战略是每次都恳求，这在弱网状况下用户感受到的白屏时刻仍然会很长。所以 HTML 文件的“缓存”和跟“更新”间存在对立。

　　客户端优化

　　接着轮到客户端进场了，桌面年代受限于阅览器，H5 页面无法做更多的优化，现在 H5 页面是内嵌在客户端 APP 上，客户端有更多的权限，所以客户端上能够超出阅览器的规模，做更多的优化。

　　HTML 缓存

　　先接着缓存说，在客户端有更自在的缓存战略，客户端能够阻拦 H5 页面的全部恳求，由自己办理缓存，针对上述 HTML 文件的“缓存”和“更新”之间的对立，咱们能够用这样的战略处理：

　　在客户端阻拦恳求，初次恳求 HTML 文件后缓存数据，第2次不发恳求，直接运用缓存数据。

　　什么时分去恳求更新？这个更新恳求能够客户端自在操控战略，能够在运用本地缓存翻开本地页面后再在后台建议恳求问询更新缓存，下次翻开时收效；也能够在 APP 发动时或某个机遇在后台去建议恳求预更新，提高用户拜访最新代码的几率。

　　这样看起来现已比较完美了，HTML 文件在用客户端的战略缓存，其他资源和数据沿袭上述BETWAY登录的缓存办法，这样一个 H5 页面第2次拜访从 HTML 到 JS/CSS/Image 资源，再到数据，都能够直接从本地读取，无需等候网络恳求，一同又能坚持尽或许的实时更新，处理了缓存问题，大大提高 H5 页面首屏发动速度。

　　问题

　　上述计划好像已完优点理缓存问题，但实践上还有许多问题：

　　没有预加载：第一次翻开的体会很差，全部数据都要从网络恳求。

　　缓存不可控：缓存的存取由体系 webview 操控，无法操控它的缓存逻辑，带来的问题包括： i. 整理逻辑不可控，缓存空间有限，或许缓存几张大图片后，重要的 HTML/JS/CSS 缓存就被铲除了。 ii.磁盘 IO 无法操控，无法从磁盘预加载数据到内存。

　　更新体会差：后台 HTML/JS/CSS 更新时全量下载，数据量大，弱网下载耗时长。

　　无法防绑架：若 HTML 页面被运营商或其他第三方绑架，将长时刻缓存绑架的页面。

　　这些问题在客户端上都是能够被处理的，只不过有点费事，简略描绘下：

　　能够装备一个预加载列表，在APP发动或某些机遇时提早去恳求，这个预加载列表需求包括所需 H5 模块的页面和资源，还需求考虑到一个H5模块有多个页面的状况，这个列表或许会很大，也需求东西生成和办理这个预加载列表。

　　客户端能够接收全部恳求的缓存，不走 webview 默许缓存逻辑，自行完结缓存机制，能够分缓存优先级以及缓存预加载。

　　能够针对每个 HTML 和资源文件做增量更新，仅仅完结和办理起来比较费事。

　　在客户端运用 httpdns + https 防绑架。

　　上面的处理计划完结起来非常繁琐，原因便是各个 HTML 和资源文件许多很涣散，办理困难，有个较好的计划能够处理这些问题，便是离线包。

　　离线包

　　已然许多问题都是文件涣散办理困难引起，而咱们这儿的运用场景是运用 H5 开发功用模块，那很简略想到把一个个功用模块的全部相关页面和资源打包下发，这个紧缩包能够称为功用模块的离线包。运用离线包的计划，能够相对较简略地处理上述几个问题：

　　能够预先下载整个离线包，只需求按事务模块装备，不需求按文件装备，离线包包括事务模块相关的全部页面，能够一次性预加载。

　　离线包中心文件和页面动态的图片资源文件缓存别离，能够更方便地办理缓存，离线包也能够全体提早加载进内存，削减磁盘 IO 耗时。

　　离线包能够很方便地依据版别做增量更新。

　　离线包以紧缩包的办法下发，一同会通过加密和校验，运营商和第三方无法对其绑架篡改。

　　到这儿，关于运用 H5 开发功用模块，离线包是一个挺不错的计划了，简略复述一下离线包的计划：

　　后端运用构建东西把同一个事务模块相关的页面和资源打包成一个文件，一同对文件加密/签名。

　　客户端依据装备表，在自定义机遇去把离线包拉下来，做解压/解密/校验等作业。

　　依据装备表，翻开某个事务时转接到翻开离线包的进口页面。

　　阻拦网络恳求，关于离线包现已有的文件，直接读取离线包数据回来，不然走 HTTP 协议缓存逻辑。

　　离线包更新时，依据版别号后台下发两个版别间的 diff 数据，客户端兼并，增量更新。

　　更多优化

　　离线包计划在缓存上现已做得差不多了，还能够再配上一些细节优化：

　　公共资源包

　　每个包都会运用相同的 JS 结构和 CSS 大局款式，这些资源重复在每一个离线包呈现太糟蹋，能够做一个公共资源包供给这些大局文件。

　　预加载 webview

　　无论是 iOS 仍是 Android，本地 webview 初始化都要不少时刻，能够预先初始化好 webview。这儿分两种预加载：

　　初次预加载：在一个进程内初次初始化 webview 与第2次初始化不同，初次会比第2次慢许多。原因估计是 webview 初次初始化后，即便 webview 现已开释，但一些多 webview 共用的大局服务或资源目标仍没有开释，第2次初始化时不需求再生成这些目标然后变快。咱们能够在 APP 发动时预先初始化一个 webview 然后开释，这样等用户实在走到 H5 模块去加载 webview时就变快了。

　　webview 池：能够用两个或多个 webview 重复运用，而不是每次翻开 H5 都新建 webview。不过这种办法要处理页面跳转时清空上一个页面，别的若一个 H5 页面上 JS 呈现内存走漏，就影响到其他页面，在 APP 运转期间都无法开释了。

　　能够参阅美团点评的这篇文章。

　　预加载数据

　　抱负状况下离线包的计划第一次翻开时全部 HTML/JS/CSS 都运用本地缓存，无需等候网络恳求，但页面上的用户数据仍是需求实时拉，这儿能够做个优化，在 webview 初始化的一同并行去恳求数据，webview 初始化是需求一些时刻的，这段时刻没有任何网络恳求，在这个机遇并行恳求能够节约不少时刻。

　　详细完结上，首要能够在装备表注明某个离线包需求预加载的 URL，客户端在 webview 初始化一同建议恳求，恳求由一个办理器办理，恳求完结时缓存成果，然后 webview 在初始化完毕后开端恳求方才预加载的 URL，客户端阻拦到恳求，转接到方才说到的恳求办理器，若预加载已完结就直接回来内容，若未完结则等候。

　　Fallback

　　假如用户拜访某个离线包模块时，这个离线包还没有下载，或装备表检测到已有新版别但本地是旧版别的状况怎样处理？几种计划：

　　简略的计划是假如本地离线包没有或不是最新，就同步堵塞等候下载最新离线包。这种用户翻开的体会更差了，由于离线包体积相对较大。

　　也能够是假如本地有旧包，用户本次就直接运用旧包，假如没有再同步堵塞等候，这种会导致更新不及时，无法确保用户运用最新版别。

　　还能够对离线包做一个线上版别，离线包里的文件在服务端有一一对应的拜访地址，在本地没有离线包时，直接拜访对应的线上地址，跟传统翻开一个在线页面相同，这种体会相对等候下载整个离线包较好，也能确保用户拜访到最新。

　　第三种 Fallback 的办法还带来兜底的优点，在一些意外状况离线包犯错的时分能够直接拜访线上版别，功用不受影响，此外像公共资源包更新不及时导致版别没有对应上时也能够直接拜访线上版别，是个不错的兜底计划。

　　上述几种计划战略也能够混着运用，看事务需求。

　　运用客户端接口

　　网路和存储接口假如运用 webkit 的 ajax 和 localStorage 会有不少约束，难以优化，能够在客户端供给这些接口给 JS，客户端能够在网络恳求上做像 DNS 预解析/IP直连/长衔接/并行恳求等更详尽的优化，存储也运用客户端接口也能做读写并发/用户阻隔等针对性优化。

　　服务端烘托

　　前期 web 页面里，JS 仅仅担任交互，全部内容都是直接在 HTML 里，到现代 H5 页面，许多内容现已依靠 JS 逻辑去决议烘托什么，例如等候 JS 恳求 JSON 数据，再拼接成 HTML 生成 DOM 烘托到页面上，所以页面的烘托展示就要等候这一整个进程，这儿有一个耗时，削减这儿的耗时也是白屏优化的规模之内。

　　优化办法能够是人为削减 JS 烘托逻辑，也能够是更彻底地，回归到原始，全部内容都由服务端回来的 HTML 决议，无需等候 JS 逻辑，称之为服务端烘托。是否做这种优化视事务状况而定，究竟这种会带来开发方式改变/流量增大/服务端开支增大这些负面影响。手Q的部分页面便是运用服务端烘托的办法，称为动态直出，见文章。

　　最终

　　从BETWAY登录优化，到客户端缓存，到离线包，到更多的细节优化，做到上述这些点，H5 页面在发动上差不多能够比美原生的体会了。

　　总结起来，大体优化思路便是：缓存/预加载/并行，缓存全部网络恳求，尽量在用户翻开之前就加载好全部内容，能并行做的事不串行做。这儿有些优化手法需求做好一整套东西和流程支撑，需求跟开发功率权衡，视实践需求优化。

　　别的上述评论的是针对功用模块类的 H5 页面秒开的优化计划，客户端 APP 上除了功用模块，其他一些像营销活动/外部接入的 H5 页面或许有些优化点就不适用，还需求视实践状况和需求而定。别的微信小程序便是归于功用模块的类别，差不多是这个套路。

　　这儿评论了 H5 页面首屏发动时刻的优化，上述优化往后，基本上耗时只剩 webview 自身的发动/烘托机制问题了，这个问题跟后续的呼应流通度的问题一同归于另一个优化规模，便是类 RN / Weex 这样的计划，有时机再讨论。