移动端本地 H5 秒开方案探索与实现

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 秒开方案探索与实现

四、细节优化

解决了上面的问题,本地 H5 确实可以达到秒开的加载速度,不过要达到和客户端一样的体验,还需要配上一些细节优化:

预加载 webView,预拉取数据

在联调本地 H5 页面过程中,发现首次加载页面时间比后续打开时间都慢很多,原因预计是 webView 首次初始化时候需要启动资源和服务较多,于是尝试客户端在预先初始化 webView 方案,果然这样第一次打开页面时候就变快了。同时为了 H5 在第一次打开时能直接展示数据,客户端在页面打开前就预拉取数据并缓存,这样来减少请求数据时间导致的白屏。

屏蔽webview HTML 内容自动识别

在 IOS webView 中默认会自动检测 HTML 中手机号、email、地址格式并标记。

解决方法:通过添加 meta 头来禁止默认行为

  

点击延迟

在WebView中,click通常会有大约300ms的延迟(同时包括链接的点击,表单的提交,控件的交互等任何用户点击行为)。

解决方法:使用fastclick/touchend一般可以解决这个问题。

国际化

客户端内的 H5 也需要国际化,前端国际化方案有很多,通常情况下都是根据项目框架选择相应的国际化插件,然而在本地 H5 的页面中,再引入额外插件会增加客户端打包大小,略显冗余。适合自己的才是最好的,这里采用了一种适合轻量级的国际化方案。

1.提取语言文案

2.页面和 js 中引用提取的文案

3.根据配置切换语言方案

 $('.i18n').each(function() {
var key = $(this).attr('name');
$(this).html(language[key]);
});
var language = getQueryVariable('en') ? i18n.en : i18n.zh

WKWebView 兼容

WKWebView 性能比 UIViewView 性能好很多,所以客户端开发一般都推荐使用 WKWebView。

但是使用 WKWebView 加载本地的 HTML 时也有一些兼容问题,在 iOS8 不能在 HTML 文件中引用本地的 css 或者 js 或者图片文件,IOS8 以上的是正常的,可以引用远程资源。为了兼顾兼容性和秒开体验,所以做降级方案,通过系统版本动态加载JS, IOS8 使用网络资源,IOS8 以上使用本地资源。

还有在iOS8中,使用一些远程的 cdn 的 css 或者 js 文件,必须注意在引用标签上加上 charset属性,不然 css 和 js 库将会乱码

五、最后

从前端优化,到客户端缓存,到离线包,到更多的细节优化,做到上述这些点,H5 页面在启动上差不多可以媲美原生的体验了。

总结起来,大体优化思路就是:减少一切网络请求,做好预加载和缓存,尽量在用户打开之前就加载好所有内容。这里有些优化手段也要根据项目和实际需求来评估,需要跟开发成本和效率权衡。上述讨论的仅针对功能模块类的单页面 H5 页面秒开的优化方案,其他一些交互较复杂的 H5 页面可能并不适用,还需要视实际情况和需求而定。

参考文献

WebView性能、体验分析与优化:https://tech.meituan.com/WebViewPerf.html


分享到:


相關文章: