在移动 App 开发领域，主流的开发模式可分为 Native、Hybrid、WebApp 三种方式。然而 2013 年，纯 WebApp 开发模式的发展受到一定挫折，以 Facebook 为代表的独立 App 转投 Native 阵营。但是开发者对 WebApp 更新速度快，跨平台优势的渴望却并未减弱，最终的结果是促成了 Hybrid App 在 2013 年数量的激增，并且增长的速率非常之快。 简单的说，Hybrid App是 Native App 和 Mobile Web 二者混合开发的产物，HTML5 的页面被嵌入到 Natvie App 的 webview 中。因此它综合了更新速度快，交互体验好，跨平台等优点。
本文分享的就是 HTML5 页面(尤其是被嵌入的 H5 应用) 借助 Hybrid 架构来提升自己的加载速度和性能的一种解决方案。该方案要求你对 Hybrid App 进行以下三步骤的改造：
一：模块化你的 H5 页面/应用，引入模块加载器（可选）
模块加载器不必多说，SeaJS、requireJS、kissy loader 等耳熟能详，任你挑选。使用模块化的方式来开发你的应用，不仅仅将有利于后期的代码维护，在 Hrbrid 的架构中，还将会有利于性能的提升。
或许你有疑问：模块开发粒度越细化，加载时请求的JS、CSS等静态资源的数量越多，页面的性能不会越差吗？我的回答是：如果你仅仅是使用了模块加 载器并异步加载各个模块，那么加载的性能一定很差，因为请求的数量太多。当然你肯定会想到在发布前打包合并静态资源，那么对这样的解决方案我只能给到 50 分，因为被打包合并的文件中只要有一个子文件发生变化，那么整个文件（JS或CSS）都要被重新下载，对移动带宽而言还是个负担。
怎么破？请继续进行步骤二：
二：启用 AppCache ，并引入增量更新机制
做过 WebApp 的同学应该会了解 mainfest 文件，Html5提供的应用缓存功能，开发者只要把需被缓存的静态资源文件名罗列在这个列表中即可保证二次访问时无需重新加载。看起来不错！这样前面说的 模块化开发造成的请求数量过多的问题，至少在二次访问时不会再发生了。嗯，这样的方案可以给到 70 分吧。其实，Html5 提供的 mainfest 缓存机制有个比较大的问题（兼容性就先不提了）：如果 mainfest 列表中的一个资源文件需要更新，那么整个 mainfest 中的其它文件也都需要被重新下载一遍。 也即是说二次访问没有问题了，但是 Html5 应用更新时还是会出现全量下载的问题。
别忘了，我们是 Hybrid App，还可以充分利用 Native 层的强大能力，所以抛弃mainfest吧，让 Native 来帮助 Html5 应用缓存静态资源文件。总体思路是：
1、Html5 应用首次启动时，调用 Native 提供的加载资源文件专用的 Device API 来请求所需的资源文件，由 Native 层发出真正的资源请求，并将请求结果缓存在手机的SD卡上。当然，这里完全可以优化为一次 zip 包请求，因为 native 能够提供强大的解压能力。
2、H5 应用再次启动时，所有的静态资源都是通过 Device API 读取本地缓存，无需再走网络。
3、H5 应用出现静态资源更新时，在应用启动时首先通过 Device API 加载需要更新的文件，并更新本地缓存，其它未变更文件继续走缓存。
流程看起来挺顺，其中有几个关键问题需要解决：
1、如何通过 Device API 加载资源文件？
这里使用模块加载器的优势就体现出来了，只需要在加载器中做点小修改，不直接走Http请求了，而直接调用 Native 提供的文件加载 DeviceAPI 即可。 如果你没有模块加载器，就需要写统一的函数来做加载资源的功能了。
其实 Native 也提供了拦截机制，能够拦截到 H5 应用发出的所有 Http 请求并进行自定义处理，可惜这样好的功能在 Andorid 4.0 以下版本不支持。 故现阶段还是主动调用 Device API 更靠谱。
2、何时需要进行静态资源的更新？
每次静态资源发布都会产生一个唯一的发布时间戳（或是所有资源内容的MD5编码），H5应用启动后，可将当前时间戳保存下来，等应用下次启动时，请求最新的发布时间戳并与本地时间戳进行对比，若不同，则首先进行静态资源的增量更新。
3、如何判断哪些是需要被增量更新替代的静态资源文件？
这个问题的回答会比较复杂些，核心思路是通过对前后两次资源文件（js、css、image等）发布的内容对比完成：
如此，H5 应用借助 Native 应用的能力完成了资源的缓存与增量更新，可以保证 H5 应用在启动与更新时的加载速度。当然也有方案借助 HTML5 的 localstorage 来替代 Native 的缓存更新策略，但是可能会受到两处限制：
1、若 Hybrid App 比较复杂，涉及多个子域甚至主域间的静态资源共享，则 localstorage 的方案首先要解决跨域访问的问题，并且在每个子域存储空间上存在上限，是 5M。
2、Native 能够支持更新包的 zip 打包下载，一次请求，然后解压并更新本地缓存。而 localstorage 无法实现。
若应用中以上两点不是问题，则使用 localstorage 缓存的策略完全 OK。
三：启用 spdy 协议
spdy 协议在移动开发上大有可为，它是HTTP协议的增强版本，能够通过一次TCP链接同时请求到多个资源文件，请求速度上的提升那是自然的了，非常强 大！chrome 等 webkit 内核浏览器都已经支持。 可惜若是借助浏览器自身使用 spdy 协议则要求静态资源服务（js、css、image）必须是 https 的域名服务，且后台server 能支持spdy协议。相信大多数静态服务器都还是http 服务，是无法通过浏览器来直接支持的。（最近有个好消息是集团的大部分静态CDN服务会提供 spdy 协议支持）
还是那句话，因为我们是 hybrid 应用，可以发挥native的优势！ native 层完全可以实现基于 spdy 协议请求的 device API，供 H5 应用（JS）来调用。这样就不需要 https 域名服务器也能使用 spdy了。
如果你的 Hybrid 应用已经支持了 spdy 协议，那么你可以考虑不再需要把增量更新的资源文件打包成 zip 下载了，直接 spdy 协议并行下载即可！
SPDY 与 HTTP 协议速度对比：
以上解决方案已应用在1688主客户端5.0版本的架构设计中，有改进之处，欢迎探讨~
评论