App开发：Hybrid架构下的HTML5应用加速方案

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