滑屏 H5 开发实践九问

来源：网络编辑：佚名时间：2016-01-19人气：

大贝尔桥在哪个国家,海城市人才网,虐恋网

　　滑屏的交互形式自从在 H5 中流行起来，便广泛应用在产品宣传、广告、招聘和活动运营等场景中，作为微信朋友圈广告惯用的形式，其影响力更是得到了强化与放大。如今滑屏H5可谓玲琅满目，数不尽数。

　　作为一个 UI工程师，接过很多类似的项目，也曾写过滑屏的插件，在经历了不同的需求的“洗礼”并踩过若干个坑之后，不禁反问自己：应该如何面对每一次类似的需求，在已有的经验下如何做到体验更好?如何节省工作量提高效率?面对性能优秀的 iOS 与性能良莠不齐的 Android 平台，又如何做到体验统一与性能最优?

　　第一问：拖拽翻屏，还是滑动翻屏?

　　页面随手势拖拽后翻屏滑动后(touchend)后翻屏

　　如上面两个 Gif 图所示，两种方式的差异在于：

　　● 拖拽翻屏：页面随手指拖动而移动，手指松开(touchend)后翻页

　　● 滑动翻屏：页面不随手指拖动而移动，手指松开(touchend)后翻页

　　看似差别不大的两种交互，实现复杂度差别巨大，在 Android 中的体验更是不一样。前者需要在每个 touchmove 的时候进行计算与定位，计算量庞大(关注数字变化)：

　　而后者只需要在松开手指后再进行计算与翻页，性能大幅提升：

　　而且从第一种方案切换到第二种时，交互上的微妙改变并没有带来直观的影响。所以从性能角度上，滑动翻屏自然是最佳的选择。

　　第二问：滑屏技术的最佳实现方式是什么?

　　控制 wrapper 滑动控制每一屏滑动

　　如上 Gif 图所示，滑屏可以在 wrapper 上操作，也可以将每一屏作为独立的滑动元素。简单的滑动可能两者并无太大差异，但假如把多样的需求和场景考虑到，可以发现在滑屏上也会细化出很多功能点：

　　● 循环滑动

　　● 滑动禁用与开启

　　● 预加载 / 延时加载

　　● 初始化时显示某一页

　　● 滚动到某一页、跳过某一页

　　● 提供滑动前、滑动中、滑动后的接口

　　● 滑动时间、速度、缓动效果自定义

　　● 考虑动态增删页数而无差错

　　● 考虑页面缩放、横竖屏切换

　　在上述要求下，前者已显得分身乏术，而后者由于其元素间的自由性，可以满足上述的需求，且效果更佳，虽然实现复杂度会提高。

　　最关键的是，前者的实现方式在部分安卓上偶尔会出现卡在上一屏与下一屏中间的情况，一开始遇到时做了很多补救都无果，最终才无奈替换了整个滑动方案，采用第二种控制内部元素的方式，可谓血的教训。

　　什么是卡在上一屏与下一屏中间呢，类似这样：

　　简单分析下原因，整个页面都通过在 body 上监测 touchmove 时增加 event.preventDefault() 来阻止自然的页面滑动，但唯独安卓有时候在有动画的元素上移动时，body 会捕捉不到 touchmove 事件，页面可以滚动了，便出现上述可以滑动 wrapper 的情况，而方案二控制每一屏滑动，每屏最宽最高就只是屏幕的宽高，也就不会出现页面滑动了。

　　第三问：首屏需要 Loading 页吗?

　　需要吗?需要。不需要吗?不需要。

　　需不需要看需求对 H5 的定位，若是类似微信朋友圈广告的这种品牌运营 H5，有大量素材作为支撑的页面，是需要进入时 loading 页的，这一点希望提前跟产品经理达成共识;但假如页面是系列活动中比较重要的入口，需要多次进入，则不要有 loading 页，力求一进入就能直接看到。

　　针对有 loading 的情况，还需要考虑：

　　是否一次性将所有资源 load 完? no no no，即使有专门的 loading 页，都请分屏加载，否则这里将会流失大量用户。

　　那资源的体积跟时间之间应该形成一个怎样的认知呢? 看表(根据 Chrome 开发者工具 Network 换算数据)：