企业微信移动端项目中有需求要展示数据趋势的可视化图表，经过调研，最终决定以单页面 H5 来完成，对 APP 里的一些使用 H5 实现的功能模块，一般体验都比原生差，那么怎么提高h5加载速度？优化 h5 体验？
适用场景：需要快速迭代、客户端难实现的、用作展示的功能模块，例如可视化图表。
一、为什么 H5 体验糟糕为什么打开一个 H5 页面会有一长段白屏时间？因为它做了很多事情，大概是：
初始化 webview -> 请求页面 -> 下载数据 -> 解析HTML -> 请求 js/css 资源 -> dom 渲染 -> 解析 JS 执行 -> JS 请求数据 -> 解析渲染 -> 下载渲染图片
一般页面在 dom 渲染后才能展示，可以发现，H5 首屏渲染白屏问题的原因关键在于，如何优化减少从请求下载页面到渲染之间这段时间的耗时。
二、如何优化上述打开一个页面的过程有很多优化点，包括前端和客户端，常规的前端和后端的性能优化已有前辈们总结过最佳实践，主要的是：
降低请求量：合并资源，减少 HTTP 请求数，minify / gzip 压缩，webP，lazyLoad。
加快请求速度：预解析DNS，减少域名数，并行加载，CDN 分发。
缓存：HTTP 协议缓存请求，离线缓存 manifest，离线数据缓存 localStorage。
渲染：JS/CSS优化，加载顺序，服务端渲染模板直出。
一般情况下，我们只要对照这个列表，对比差异就基本能搞定绝大部分前端性能问题了。不过我们在里面仔细再分析下，对首屏启动速度影响最大的就是网络请求，包括请求 HTML、css、image 等静态资源和展示数据的请求。
那么将 H5 相关页面和资源打包到客户端中，然后客户端将展示数据传给页面，通过webView加载展示，这样几乎不需要网络请求，webview 只要渲染页面，执行js即可，这样体验岂不是很完美？
三、具体怎么实现？整体思路看起来比较清晰，但是其中有几个关键问题需要解决：
3.1 本地H5页面如何和native通信：本地 H5 页面如何和 native 通信的方式基本有三种：jsapi、URL Scheme 和 字符串替换。具体不同方式适合使用场景有所不同：
jsapi ：客户端提供接口，注入 API让 Javascript调用，直接执行相应Native代码，适用于需要通过交互，进行数据请求的场景
URL Scheme ： Web 端发送 URL Scheme 请求，之后 Native 拦截到请求并根据 URL Scheme 及所带的参数进行相关操作。适用于进行页面跳转的场景。
字符串替换： 客户端读取本地 H5后，通过对 H5 中的约定的标记位进行字符串替换，然后加载展示页面。适用于没有复杂交互，只通过页面渲染数据的场景。
3.2 如何开发调试和维护开发本地 H5 模块，很容易想到在本地通过模拟数据开发，然后将 H5 给到各客户端打包后进行联调。然而这样的方案实现起来十分繁琐，原因是 H5 资源给到客户端打包时很分散，不统一，管理困难。
那么我们改进一下，将使用本地 H5 实现模块的页面建立一个统一 git 仓库，IOS 和 android 客户端通过git submodule 将本地 H5 的git 外链到项目中，这样客户端中的资源就可以统一管理，解放了每次都手动繁琐的替换打包工作。
但是这种方法其实也并不完美，H5 代替原生实现的优势，一个在于开发成本低，另一个在于 H5 可以更加快捷的更新迭代，如果打包在客户端中的H5 页面就像客户端一样，没法快速更新了。很容易想到将 H5 资源给到后台，客户端按照业务模块预下载整个离线包，离线包根据版本做增量更新。这种的方案，就可以较好的解决上面的问题了。
解决了上面的问题，本地 H5 确实可以达到秒开的加载速度，不过要达到和客户端一样的体验，还需要配上一些细节优化：
预加载 webView，预拉取数据
在联调本地 H5 页面过程中，发现首次加载页面时间比后续打开时间都慢很多，原因预计是 webView 首次初始化时候需要启动资源和服务较多，于是尝试客户端在预先初始化 webView 方案，果然这样第一次打开页面时候就变快了。同时为了 H5 在第一次打开时能直接展示数据，客户端在页面打开前就预拉取数据并缓存，这样来减少请求数据时间导致的白屏。
屏蔽webview HTML 内容自动识别