滑屏 H5 开发实践九问[页4]

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

速贝seo实战培训,黑道王子与冰山公主,张耐山的博客

　　上述是理想数值，实际上根据腾讯云统计到的 2G/3G 的下载速率，远未达到理想的速度：

　　根据《工信部及三大运营商发布11月用户发展情况》可得知：中国移动用户 2G 用户占 41.4%，3G 用户占 31.3%，4G 用户占 27.3%。现状远远没有长期处于 WiFi 环境下的我们想象的那么美好，虽然这些用户并非长期使用 2G/3G，但是页面必须确保在 2/3G 环境下有一个顺畅的浏览体验，避免用户流失。建议首屏资源在 300KB 左右(大概加载时间为 2~3s 左右)，并设置缓存。

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

　　假如页面有比较丰富的动画，需要先加载资源才能被正常播放呢? 要么去掉动画，要么用 CSS 或 JS 来实现动画，必须要做出取舍。

　　既然是无 loading 的页面，自然对速度有要求，还能提高加载速度吗? 可以，请分屏加载。若希望做到体验无缝，请在前一屏加载后一屏的资源。

　　第四问：内部滚动怎么办?

　　内部滚动即某屏内部还有滚动(但实际上系统的滚动跟滑屏的滚动是冲突对立的)，如果这一屏不涉及复杂的 DOM，我还是觉得可以使用 iScroll，虽然它在安卓上的性能一直被诟病，但经过非常多安卓机的检验，效果还是在可接收范围内的，但别忘了前提：DOM 不复杂(如活动规则页)。

　　那是否有更好的解决方案呢?不妨回看之前滑屏的最佳实现方式：

　　可以看到，在每一屏上进行操作，当上一屏或下一屏滑动到当前屏时，之前的那一屏会去掉 translate 属性，回归到最初的状态(被当前屏盖在下面，即 position:absolute; left:0; top:0)，这个时候，将当前屏的 position:absolute; height:100% 去掉，使其回归文档流，那么 body 将会被撑开，页面可以被正常滑动，是不是连 iScroll 都省了?

　　尝试着写了个 Demo：

　　正如你体验到的那样，理想很丰满，现实很骨感，在 PC 上的体验这个Demo是没有问题的(请在 Chrome 下模拟手机滑动)，然而因为 iOS 和 Android 中很多浏览器都自带 bounce 回弹效果，而 iOS 和 Android 的大部分浏览器中，页面滚动时是会阻止页面重绘的(JS 的执行也无法立刻生效在页面中)，所以Demo 里看到的效果就是回弹后才翻屏。所以目前这个方案页仅限于某些场景使用。

　　第五问：背景音乐是默认开启或是关闭?

　　之前在做一个宣传活动 H5 的时候，默认开启过音乐，发现 28w 曝光只有 800 个人主动关闭音乐。所以默认开启还是最优的，在制作音频的时候注意体积最好在 100~200k 范围，并且默认音量不应该太高，收尾渐入渐出，还得注意版权。

　　然而目前不管是手 Q 或是微信，都存在一个偶现的 bug：在手机中切换页面或者回到主屏幕，H5 的背景音乐依旧在播放，除非杀掉进程。初步猜测为 Webview 未正确得到释放。

　　第六问：H5 页面需要兼顾 PC 平台吗?

　　很多 H5 页面都只针对移动设备展示，但如果分享的链接被人在 PC 中打开呢?比如分享到微博或QQ 空间的链接，被正在电脑上浏览的人打开，看到的是一个显示不正常的页面，这样的体验是非常不好的。所以最好的做法就是准备一个 PC 的扫码页面或将内容搬到 PC，打通回路，为 H5 页面引流。

　　正如之前做过的 QQ 时光机项目：

　　第七问：动画如何做低版本退化?

　　移动端对 CSS3、Canvas、SVG 动画的支持已经不错了，目前兼容性较差的系统主要有 Android 2.3，它不支持 animtion-fill-mode 属性，这会导致动画播放完后无法保持在最后状态;不支持 before/after 伪元素的动画;不支持 animation-timing-function: steps，所以也无法玩转图片序列帧;所以可以特别针对这个版本进行差异化处理，通过判断 UA 对其展示静态页面。

　　然而最佳的退化方式不应该是版本检测，而是能力检测，可以通过 Modernizr 这个组件判断设备具备的能力。

　　第八问：如何做好适配?

　　适配的核心就是确保内容在不同的屏幕分辨率下显示正常，经常采用的方式有 REM、Media Query 和 JS+CSS，没有一套永恒不变的适配方案，往往需要多种结合。如果是比较简单的展示类H5，可以参考如下的代码：