本文的读者需要有一定的 Hybrid 基础,相关的概念已经有很多优秀的文章进行过讲解,这里不再赘述。本文的重点在于如何基于 Hybrid 框架,在移动端(不限于具体平台)完成一个 wap 页面的完整下载。这个页面会包含丰富的媒体资源,包括图片、音频、视频等。下载完成之后,我们在离线时依然能够流畅阅读该页面的完整内容。
场景分析
在移动端使用 wap 页面展示内容有非常多的应用场景,比如常见的新闻资讯阅读、简书或掘金的文章展示。客户端提供 webview 容器,配套一系列前端与客户端交互的能力,前端使用模板批量生成不同的内容后下发,发挥着前端极高灵活性的同时又可以享受到客户端原生的许多能力。
前面说的场景,用户很少有缓存的需求。不过对于某些产品中用户可能会反复查看的内容,提供页面的下载以供离线查看就很有必要了。wap 页面不仅可以展示文本,还经常出现图片,有的页面中还会包含音频甚至视频,该采用什么方式完成下载,需要根据不同的场景具体分析。
方案选择
一般而言,提供了下载功能的 wap 页面,它将展示的内容形式必然是有限制的。如果任何一个页面丢过来都要求缓存,我们很难保证离线情况下的展示效果。
利用 NSURLProtocol 实现缓存
对于简单的页面,比如它只包含文本和图片,那么不依赖 Hybrid 也可以实现。NSURLProtocol 就是一个可选方案,并且它的覆盖范围可以更广。使用 NSURLProtocol 对网络请求进行过滤,如果是特定的 html、css、js 等请求和图片请求,就在本地缓存数据中进行查找,命中缓存则使用本地数据包装成网络请求的响应数据进行回传,否则才执行对应的网络请求。这样即使在网络可用的情况下,也会优先使用本地缓存数据,不仅可以完成页面的离线展示,还有效地加快了网络可用时页面的加载速度。自然想到,这也是很多 wap 页面加速方案会采用的方式。
基于 Hybrid 的 wap 页面
而对于包含了音频、视频等内容的 wap 页面,出于用户体验等目的,客户端往往会将这些资源的展示进行接管。比如页面中包含音乐时,用户进行点击会发现是客户端的播放器在进行播放,这便是 Hybrid 应用的例子。它的一个常见实现方案是:客户端为前端提供了播放音频的接口,对于 wap 页面中的所有音频,放弃前端的原生写法,采用客户端提供的接口。而客户端中这个接口的实现,自然是调起客户端音频播放器,播放对应的音频,这个过程中又会涉及到是否成功的回调、客户端播放器和 wap 页中播放状态的同步等诸多问题,不过这不是本文关注的重点。本文讨论的需要完整下载的 wap 页面的场景,就是基于这种方案。
具体实现
页面的展示方案
通过上面的例子可以看到,基于 Hybrid 方案展示的 wap 页面,不仅需要客户端提供面向前端调用的各种能力,也需要前端在编写代码时进行相应的调用。两端相互配合,完成高度定制化的 wap 页面。对于上面的例子,客户端提供出来图片、音频、视频的接口,这样 wap 页面中对应内容的交互,便都交由客户端的原生实现。而客户端接口的实现,自然就是首先在本地缓存数据中进行查找,若该数据已下载,则使用本地数据,否则进行对应的网络获取,以此兼容有网和离线的情况。
交由客户端接管的好处,除了上述离线缓存的应用,还有一点是能够让 webview 中的内容也可以享受到客户端原生的处理方式。比如图片接口的客户端实现,就可以交由项目中使用的网络图片异步加载工具(SDWebImage 或 YYWebImage 等),这样 webview 中的图片加载和原生场景下的图片加载可以共享缓存数据,原生场景加载过的图片,在 webview 中展示时便无需重复网络获取,反过来也如此。基于局部性原理,这样可以在一定程度上达到图片加载加速的效果(减少了重复网络请求)。
进一步优化
事实上,在高度定制的 wap 页面场景下,我们对于 webview 中可能出现的页面类型会进行严格控制。可以通过内容的控制,避免 wap 页中出现外部页面的跳转,也可以通过 webview 的对应代理方法,禁掉我们不希望出现的跳转类型,或者同时使用,双重保护来确保当前 webview 容器中只会出现我们定制过的内容。既然 wap 页的类型是有限的,自然想到,同类型页面大都由前端采用模板生成,页面所使用的 html、css、js 的资源很可能是同一份,或者是有限的几份,把它们直接随客户端打包在本地也就变得可行。加载对应的 url 时,直接 load 本地的资源。
对于 webview 中的网络请求,其实也可以交由客户端接管,比如在你所采用的 Hybrid 框架中,为前端注册一个发起网络请求的接口。wap 页中的所有网络请求,都通过这个接口来发送。这样客户端可以做的事情就非常多了,举个例子,NSURLProtocol 无法拦截 WKWebview 发起的网络请求,采用 Hybrid 方式交由客户端来发送,便可以实现对应的拦截。
基于上面的方案,我们的 wap 页的完整展示流程是这样:客户端在 webview 中加载某个 url,判断符合规则,load 本地的模板 html,该页面的内部实现是通过客户端提供的网络请求接口,发起获取具体页面内容的网络请求,获得填充的数据从而完成展示。
下载时如何确定具体需要下载的资源
客户端如何确定某个具体 wap 页中会包含的资源,我们没有找到很高效的办法。所幸这种场景下的页面多是内部生产、高度定制的,这也就为后端提供资源统计提供了可能(页面数据本来就是后端生产的~),所以我们采用了后端提供对应接口支持的方案,根据 wap 页的 id,可以获取该页面包含的具体资源。执行用户的下载行为时,使用对应页面 id 调用资源统计接口,获得该页面包含的资源。这其中包括 JSON 格式的页面填充数据,也包括媒体文件的 url。对于 JSON 数据,可以采用简单的缓存框架进行缓存(YYCache 等),图片采用场景的图片缓存框架,音频、视频等可以处理成常规的文件下载任务。
结语
- 本文并没有关注具体的 Hybrid 框架如何实现,重点在于提供一个基于 Hybrid 可以实现的具体业务场景。
- 文中所述的方案,是公司内部场景下剥离了业务的技术实现阐述。会有不尽合理的地方,欢迎讨论。
网友评论