本文的读者需要有一定的 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 可以实现的具体业务场景。
- 文中所述的方案，是公司内部场景下剥离了业务的技术实现阐述。会有不尽合理的地方，欢迎讨论。
