网站手机版方案,程序员软件开发,微端网站开发,wordpress侧栏弹窗登录[TOC]## 页面加载为什么打开一个 H5 页面会有一长段白屏时间#xff1f;因为它做了很多事情#xff0c;大概是#xff1a;~~~初始化 webview - 请求页面 - 下载数据 - 解析HTML - 请求 js/css 资源 - dom 渲染 - 解析 JS 执行 - JS 请求数据 -因为它做了很多事情大概是~~~初始化 webview - 请求页面 - 下载数据 - 解析HTML - 请求 js/css 资源 - dom 渲染 - 解析 JS 执行 - JS 请求数据 - 解析渲染 - 下载渲染图片~~~一些简单的页面可能没有 JS 请求数据 这一步但大部分功能模块应该是有的根据当前用户信息JS 向后台请求相关数据再渲染是常规开发方式。一般页面在 dom 渲染后能显示雏形在这之前用户看到的都是白屏等到下载渲染图片后整个页面才完整显示首屏秒开优化就是要减少这个过程的耗时。## 前端优化上述打开一个页面的过程有很多优化点包括前端和客户端常规的前端和后端的性能优化在桌面时代已经有最佳实践主要的是* 降低请求量合并资源减少 HTTP 请求数minify / gzip 压缩webPlazyLoad。* 加快请求速度预解析DNS减少域名数并行加载CDN 分发。* 缓存HTTP 协议缓存请求离线缓存 manifest离线数据缓存localStorage。* 渲染JS/CSS优化加载顺序服务端渲染pipeline。其中对首屏启动速度影响最大的就是网络请求所以优化的重点就是缓存这里着重说一下前端对请求的缓存策略。我们再细分一下分成 HTML 的缓存JS/CSS/image 资源的缓存以及 json 数据的缓存。HTML 和 JS/CSS/image 资源都属于静态文件HTTP 本身提供了缓存协议浏览器实现了这些协议可以做到静态文件的缓存具体可以参考[这里](https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching)总的来说就是两种缓存* 询问是否有更新根据 If-Modified-Since / ETag 等协议向后端请求询问是否有更新没有更新返回304浏览器使用本地缓存。* 直接使用本地缓存根据协议里的 Cache-Control / Expires 字段去确定多长时间内可以不去发请求询问更新直接使用本地缓存。前端能做的最大限度的缓存策略是HTML 文件每次都向服务器询问是否有更新JS/CSS/Image资源文件则不请求更新直接使用本地缓存。那 JS/CSS 资源文件如何更新常见做法是在在构建过程中给每个资源文件一个版本号或hash值若资源文件有更新版本号和 hash 值变化这个资源请求的 URL 就变化了同时对应的 HTML 页面更新变成请求新的资源URL资源也就更新了。json 数据的缓存可以用 localStorage 缓存请求下来的数据可以在首次显示时先用本地数据再请求更新这都由前端 JS 控制。这些缓存策略可以实现 JS/CSS 等资源文件以及用户数据的缓存的全缓存可以做到每次都直接使用本地缓存数据不用等待网络请求。但 HTML 文件的缓存做不到对于 HTML 文件如果把 Expires / max-age 时间设长了长时间只使用本地缓存那更新就不及时如果设短了每次打开页面都要发网络请求询问是否有更新再确定是否使用本地资源一般前端在这里的策略是每次都请求这在弱网情况下用户感受到的白屏时间仍然会很长。所以 HTML 文件的“缓存”和跟“更新”间存在矛盾。## 客户端优化### HTML 缓存先接着缓存说在客户端有更自由的缓存策略客户端可以拦截 H5 页面的所有请求由自己管理缓存针对上述 HTML 文件的“缓存”和“更新”之间的矛盾我们可以用这样的策略解决在客户端拦截请求首次请求 HTML 文件后缓存数据第二次不发请求直接使用缓存数据。什么时候去请求更新这个更新请求可以客户端自由控制策略可以在使用本地缓存打开本地页面后再在后台发起请求询问更新缓存下次打开时生效也可以在 APP 启动时或某个时机在后台去发起请求预更新提升用户访问最新代码的几率。这样看起来已经比较完美了HTML 文件在用客户端的策略缓存其余资源和数据沿用上述前端的缓存方式这样一个 H5 页面第二次访问从 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 数据客户端合并增量更新。### 预加载 webview无论是 iOS 还是 Android本地 webview 初始化都要不少时间可以预先初始化好 webview。这里分两种预加载* 首次预加载在一个进程内首次初始化 webview 与第二次初始化不同首次会比第二次慢很多。原因预计是 webview 首次初始化后即使 webview 已经释放但一些多 webview 共用的全局服务或资源对象仍没有释放第二次初始化时不需要再生成这些对象从而变快。我们可以在 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的部分页面就是使用服务端渲染的方式称为动态直出见文章。参考资料[移动 H5 首屏秒开优化方案探讨](https://mp.weixin.qq.com/s/i035lEHc2w2K-TBhbDtaLQ)[WebView性能、体验分析与优化](https://tech.meituan.com/WebViewPerf.html)
