该文章来自于阿里巴巴技术协会（ATA）精选文章。

IO 优化

今天 去啊 App 5.1.1 已经发布了，航旅 Hybrid 混合架构有了更进一步的落地，这轮优化目标是搞定H5真正的“无缝秒出”。

先来看效果，去啊App 2G 网络下购买国际机票，30秒完成，除了搜索入口页，列表往下到付款页的前端都是H5 Page，大家感受一下：

目测性能是可观的。尽管H5包的离线化隔绝了弱网对秒出的干扰，设备本地 IO 耗时也是不能忽视的，算上zip的解压缩，仅在设备本地 IO 完全一个 HTML（包含其携带的资源文件）也会达到秒级的耗时，在iphone5上也会有0.5秒左右的白屏时间。

另外，HTML 本身的优化依然无法绕过，WebView 里 JS 的运行效率通常是 Mobile Browser 里的四分之一。所以 JS 必须尽可能靠后的介入渲染，CSS 必须尽可能靠前的介入渲染。而在当下前端开发习惯来看，页面通常会至少阻塞加载一个种子文件（比如kissy），而在Mobile设备中，哪怕是无干扰Dom的JS阻塞运行都会带来0.3秒左右的白屏延时。

所以，H5容器的IO优化和HTML渲染提前是本期改造的重点，即：

1. H5 容器加载资源的 IO 优化：干掉zip包的即时解压，离线包更新后立即解压散列到SD卡，每次创建 View 时直接从设备读文件，本地文件管理依然基于标准的H5包规范。
2. HTML 本身的页面优化，CSS 提前，JS 置后。

“CSS 提前和JS置后”的动作是由来完成。即只要构建工具统一，开发者不需要关心如何摆放脚本最优，只需关注实现业务逻辑即可，举个例子，JS 置后的做法是这样：

其实无非是将同步的脚本改成异步。先保证带样式的页面框架秒出来，然后去执行 JS。从性能数据上甚至看不出差别，但从感官上的提升非常明显，我宁愿让你先看到界面，而不是白屏。

IO 优化（续）

从策略上，做到这两点足够应付大多数场景，能保证页面任何时候能秒出来。但在我们整个 Hybrid 架构中，我们设计了比较灵活的 H5 离线化，即用虚拟域来确保在线离线的一致，比如，浏览器扫码打开是一个在线页面，用去啊App扫码进来就是一个离线页面，同一份代码，一个走网络加载，一个走本地加载：

这样设计主要是为了做线上线下的开关切换，紧急问题可随时配置到线上页面，线上页面是可以随时部署的，离线页面则涉及到推包。为了做这层开关，就会带来判断文件是线上还是离线的问题。

因为H5容器虚拟域的代理层会引导 WebView 去本地而不是网络读文件。如果读不到本地文件，再创建一个HTTP请求去对应的线上请求文件。如果通过 IO 一次再判断本地是否存在文件，显然实际的 IO 次数依然降不下来（所有的资源文件请求都必须要 IO 一次手机硬盘），为了降低实际 IO 次数，我们针对每个 H5 离线包生成一个本地资源文件列表（cache_info.json），并同时将域名路径和文件路径做成了映射 Map，这个映射表读入内存后备用，涉及到H5的访问，用这个 Map 过滤下就能直接找到要读的文件位置，Map 匹配不上就直接创建HTTP从网上取文件了，这样可以避免无必要的 IO。

AngularJS 在移动端的加速

去啊 Hybrid 中存在大量的列表页，比如上面的团购和视频中国际机票的例子，AngularJS 是最适用于这种场景。但 AngularJS 目前没有专门针对 Mobile 做优化，而在 Mobile 设备里，hashchange带动数据模型data-model的变更，进而通过View来渲染。首次渲染稍慢，因为要等Model准备好才出视图，无论如何界面也秒不出来（从hashchange到出界面至少0.8 秒）数据结构在稍微复杂点，立即破1秒，当然这个时间是伴随着首次加载构建DOM的干扰。

几点改造：

1. AngularJS 种子文件异步载入
2. 非数据关联的HTML一律预装在页面
3. 首次加载干掉任何影响页面抖动的 HashChange
4. 基础数据的离线化（比如城市列表）

这几点无非是让首次渲染能尽快的展现，接下来 OPOA 中的编程就是 AngularJS 所擅长的了。

离线包里的 TMS 如何载入

我们知道  只支持静态 HTML 的发布，这没什么好解释的，毕竟，高性能要求更简单粗暴且有效的缓存，全静态就可以全缓存，尤其是在移动终端的破网里面，缓存尤其重要，但 TMS 动态内容如何生成？我们都知道 AWP 平台提供了一个<!--HTTP:url-->的标签（），TMS 变更后就重新生成一份HTML 推送到CDN上。

那么问题来了，离线包里怎么做？

我们团队的同学写了模块，会将<!--HTTP:url-->标签构建：

构建为：

这样，在离线包里的 TMS 内容就和 H5 页面完全分开了，毕竟 TMS 由于变更频繁，是没办法直接做离线化的。但上面这段脚本显然会阻塞页面渲染，所以offline-tms-parser提供了异步的版本，即将：

构建为：

然后在 H5 页面顶部塞一个get_tms_fragment的实现即可。

如此，基于 AWP 平台开发业务将不受任何影响，工具帮我们处理好 TMS 和 H5 页面的百分百解耦，离线包里也可以大量使用 TMS 了。

尽管如此，也必须不能滥用 TMS，代码逻辑层面的 View 和 Data 的解耦仍然是必须要做的。

让人期待的 grunt-kmb

本期优化面向 H5 离线容器的代码改造的重点是上面这几项，但还有一项激动人心的变化： ，没错，构建流程也需要瘦身和简化了。

grunt-kmb是团队另一位同学正在开发的  的替代方案。相比于 grunt-kmc 基于正则匹配的模块解析，grunt-kmc 完全基于 uglify-js 提供的 JavaScript 语法解析树（AST），先看对比：

grunt-kmc 的速度：

grunt-kmb 的速度：

整整一倍的提速，太让人垂涎期待了。

What's Next

本期的优化没有多少高科技的东西，大都是体力活，将技术做透。好的体验真的是靠点滴的积累，需要花时间去磨。

其实从去啊App Hybrid 刚开始设计并做第一版优化到现在已经有半年多时间，这期间离不开客户端同学的全心投入，因为 H5 的优化必须借助高性能的 WebView 容器，但靠 H5 或者 Web 技术本身无论如何是无法做到秒出的。再配上《》里零碎的优化技巧，H5 在 Hybrid 中完全可以做到秒出，再配备离线包动态推送和埋点采集等基础设施，Web 技术的瓶颈在 Mobile 中就能获得一定的突破。

我在这次集团前端技术峰会上的汇报里，提到过我们面临的挑战：

去啊 App 是介于工具化的钱包App和运营化的手淘App之间，既有营销活动，也有工具化、流程化的 PageFlow。将标准化的 PageFlow 的性能做到极致，接下来的挑战就是如何将运营活动也做到智能的推送，完成这类页面的离线部署。

当然，活动页面的离线化部署目前来看不是我们面临最急迫的难题，最棘手的是数据打通的问题：

看这个场景，在钱包App做了一个引流的入口，唤起了去啊App，并定位到机票搜索结果页：

目前我们很难跟踪唤起的效果，手机里的App是信息孤岛，很难通过简单的传参来把跨 App 的 PageFlow 串联起来。即使参数能带过来，但身份信息、登陆状态和账号关联能否也能带过来呢，每一项都是很有挑战。

我在前两天给航旅的新人培训上，分享了我理解的《Mobile First》，这段话是值得分享给大家一起共勉的：

内聚的 App 和散列的 Web 似乎是一个不可调和的矛盾。企业倾向于认为只有提供越来越多地功能，才能满足用户不断膨胀的需求，但又会打破原有应用的简便易用。当两者无法调和，信息膨胀到必须散列到不同的端时，通过 Web 技术将这些信息孤岛关联起来就显得至关重要。

所以，我们之前所做的所有技术的优化，都是在为构建无线“前端/终端”技术体系夯实根基，所以这一轮无线All In 从某种意义上看是一种原始积累，第二轮无线All In才会迎来真正的非标商品的个性化、多元化时代。这时我们的技术体系将着重解决这几类问题：

1. 千人千面，重点解决面向不同人群做手机里的定制化功能的问题
2. 无线大数据，重点解决打破App间的信息孤岛，让跨端的数据化运营更加高效、可靠
3. 无线开源，让 B 商家参与进来，像手淘一个（Native）商品详情页通吃所有商品的时代很快就会被更个性、多彩的非标商品打破，这时，大量垂直领域的产品模式设计更多要靠商家参与，而不是我们自己那几个产品经理，所以，更开源、更自由的手机店铺，闭环服务才是王道。

说到闭环，去啊的机票购买流程，是无线端闭环的经典案例：

这个例子是从钱包的入口开始购机票流程，通过短信、Push、下载、唤起等操作，将用户捣腾到去啊App里（整个过程体验流畅，估计你也很难分清楚哪些Page是H5的、哪些是Native的吧）。

So，开源 + 闭环，是我理想中的无线 Hybrid 技术的终极状态，去啊 Hybrid 技术积累也才刚刚开始。