混合应用页面打开速度优化

我们都知道混合应用的流畅性不如原生应用，除了不能像原生一样轻松驾驭各种狂拽酷炫的效果，混合应用还有一个难以消除的弱点在于页面打开速度上，如果有机会在同一台手机上直接对比的话，这种差距是普通人都能直观感受到的，这主要是由于web页面每次打开前需要初始化，在那一瞬间需要完成DOM创建、资源下载、样式渲染、js执行，这些时间消耗造成了按键按下与页面进场之间短暂的停顿，也造成了混合应用整体“不流畅，不跟手”的印象，HybridStart 1.1.1版本针对性的优化了页面打开速度，下面就介绍一下具体是怎么做的。

怎么做优化

混合应用乃至所有前端项目的优化工作，总结起来其实都是在试图消除延迟感，消除延迟感要从两方面着手，一是提升绝对速度，做到不慢；二是增加过度效果，填充停顿，让用户无瑕感知到慢；这两方面是做好优化的关键。

提升绝对速度

在混合应用中打开一个页面，会发生如下几个事件：

1 2	渲染完成 => 加载完成 => runtime就绪

这三个事件是依次发生的，apicloud为了保证页面打开即是显示完整的，所以会在页面加载完成之后开始进场动画，这里是优化的关键，我们分析一下加载完成之前都发生了什么：

载入DOM节点
加载css/js/img
页面渲染
运行js
js运行时创建DOM节点并渲染
资源加载完成
页面加载完成

以上所有事情都发生在页面初始化，其中远程图片的加载是最耗时的，所以图片较多的页面建议使用懒加载插件，懒加载并不是简单的减少了第一批图片加载数量，而是将所有图片加载从初始化队列中移除，在页面打开后才开始加载，这能有效提高初始化速度，但代价是用户有大概率会看到图片加载过程，这里的取舍就需要分情况讨论了，我的建议是优先提升页面打开速度，多数情况下的图片加载过程不会造成很坏的用户体验。

排除掉图片之后，通常意义上讲已经没什么可优化的地方了，但在混合应用场景下，仍然有一部分提速空间可以被压榨，那就是js资源的加载和执行，与js相关的操作有这么几项：

载入js
执行js
js运行时创建DOM节点并渲染

载入和执行本地js在桌面端可以被认为是实时的，但移动端的计算能力和IO能力都远差于桌面端，HybridStart中的每个页面需要加载一个配置文件和一个核心类库，核心类库运行后再异步获取页面脚本并执行，经过对比测试这些操作平均耗时在100ms左右，如果页面脚本中还有其他插件的引用或者同步创建DOM操作，那么耗时还会延长，并且会导致不同的页面打开速度差别很大。

我们知道混合应用页面打开后通常有一个进场动画，这个动画的时长默认300ms，所以我们可以想办法利用这300ms，将js相关操作从初始化队列中移除，转而在动画过程中进行，多数情况下所有的js加载和执行都可以在页面动画结束前完成，对用户体验的影响几乎为零，却可以提高页面初始化的速度。

具体实施过程是：先将页面底部脚本链接移除，写一段代码创建脚本节点，在合适的时机将脚本节点插入页面。关键是插入时机的选择，apicloud会监听页面加载完成事件，我们必须跳过这个时间节点，所以同步插入脚本是不行的，测试发现apiready事件可以跳过加载完成，而且耗时很少，完全可以被动画过程覆盖，因此就选择在apiready之后插入节点，可以满足需求，而且还带来一个不大不小的副产品，那就是业务代码不再需要app.ready()回调函数了，因为所有js的加载执行都在runtime就绪之后发生的。

优化后在测试机上普通页面的打开速度较之前至少提升100ms，对于大量依赖js运行的页面提速效果更明显。

增加过度效果

绝对速度的提升有明确的瓶颈，而且跟手机性能有很大关系，即使排除了图片和js的加载，页面初始化仍然需要处理DOM节点的创建和样式的渲染，为了保证用户体验这部分是无论如何都不能动的，但这部分操作的耗时多数情况下仍然能被用户感知到，这时我们只能使用障眼法，增加一些过度效果，减缓用户等待的焦虑感，v1.1.1中实验性的为列表组件添加了触摸状态波纹效果，具体实现在sdk/common.js中，效果参见v1.1.1示例APP。

过渡效果更多的还是需要根据业务场景自定义，这个内置效果就当抛砖引玉了。