我们都知道混合应用的流畅性不如原生应用,除了不能像原生一样轻松驾驭各种狂拽酷炫的效果,混合应用还有一个难以消除的弱点在于页面打开速度上,如果有机会在同一台手机上直接对比的话,这种差距是肉眼都能直观感受到的,这主要是由于 web 页面每次打开前需要初始化,在那一瞬间需要完成 DOM 创建、资源下载、样式渲染、js 执行,这些时间消耗造成了按键按下与页面进场之间短暂的停顿,也造成了混合应用整体“不流畅,不跟手”的印象。
为了尽可能解决这个问题,最近想到了一种新的优化思路,优化后在测试机上空白页面的打开速度较之前提升 100ms 左右,对于大量依赖 js 运行的页面提速效果更明显。思路并不复杂,就是先移除页面中所有的 js 资源,加速页面渲染速度,当页面开始进场动画后,再开始加载执行 js,充分利用了进场动画的时间,以缩短整个页面展现的时间,核心代码就是选择时机动态插入 js 节点部分,该方案已经应用于 HybridStart 项目,详细过程点此了解。
应用该方案后同时还解决了混合应用的另一个问题,那就是打开不同 APP 页面不再有速度差别了,之前产生的速度差别,主要是因为 js 代码可能产生异步请求或者生成 DOM 节点,这些耗时都不可预估,长的甚至以秒计算,优化后的页面完全排除掉 js 资源的干扰,渲染速度的差别就仅在于 DOM 渲染量的差别,而这个基本上任何页面都不会差太多,因此不同页面的打开速度也就基本一致了。
最后安利一下HybridStart 项目,如果你也在用 apicloud 做混合应用,这一定是你的不二之选,很难想象开发体验能比这更好的了。另外 HybridStart 的开发原则之一是 UI 可剥离,我认为框架的 UI 跟功能绑定就是耍流氓,没错我说的就是 mui,没法想象怎么用 mui 做自定义风格的项目,这方面 HybridStart 是完胜的,使用 HybridStart 做项目完全不需要担心 UI 好不好改,因为你甚至可以一怒之下将自带 UI 删掉重写,完全不影响核心功能,当然了即便 UI 不是重点,HybridStart 的自带 UI 也足够满足普通 APP 项目需求了,而且附带 less 文件,只要是别太非主流的风格都能通过改变量实现。
最后,虽然目前 HybridStart 是基于 apicloud 平台,但未来还会跟进 dcloud 平台,因为 HybridStart 的初衷就是跨平台,最初一版是脱胎于古老的 appcan 平台,在饱尝 appcan 之坑后,决心将其打造成一款跨引擎的混合应用开发框架,目的就是抹平不同平台的引擎 api 差别,减少平台迁移成本,就目前来看,apicloud 跟 dcloud 相比,还是稍逊一筹的。
1
momoda1 2017-07-22 19:04:11 +08:00
额,你这个只是去优化了视觉层面的效果,你说的 js、css、异步请求都可以通过离线包,预加载,预请求,缓存,首屏加载,骨架预渲染等的方式解决,做到秒开
|