过年后的第一个项目，做一个悦读周的推广活动。流程大致是H5动画 → 推荐页 → 上传分享 →登陆/注册 →领取积分。由于这个项目涉及到对方后台数据库及一些中转接口的对接，在整个项目中并没有使用单页面的架构，而是按照客户的流程分成了几个HTML文件，所以除了首页和推荐页，后面的页面我只负责输出模板，微信接口和数据库对接的工作全都交由我们后端处理。
项目地址：http://hh.qiaohu.com/
做这个项目最大的难点以及最有成就感的地方在于把一个比较复杂的动画用网页形势呈现了出来，并且在大部分的机型上运行也比较流畅。初次接触canvas的库以及第一次接触到spine动画，也让我感受到了现代浏览器的强大功能。
下面把几个开发过程中遇到的有意思的小bug罗列一下，方便以后记忆。
1.background-size 几个参数的含义：
根据W3C官方的解释，background-size可以填写如下几个参数：
<length> 值，指定背景图片大小，不能为负值。
<percentage>值，指定背景图片相对背景区（background positioning area）的百分比。背景区由background-origin设置，默认为盒模型的内容区与内边距，也可设置为只有内容区，或者还包括边框。如果attachment 为fixed
，背景区为浏览器可视区（即视口），不包括滚动条。不能为负值。
auto
以背景图片的比例缩放背景图片。
cover
缩放背景图片以完全覆盖背景区，可能背景图片部分看不见。
contain
缩放背景图片以完全装入背景区，可能背景区部分空白。
原本以为cover是单纯的视口平铺，实际在使用ali的sui-mobile框架的时候出现了背景拉伸的情况，导致了图案的不对称。当时的解决方案是用img标签模拟背景。今天在实践中发现，其实用contain这个属性更合适，还原图案本身的尺寸。
2.onhashchange
用到这个事件实属无奈之举，起因是我们原本承载H5的页面只有一个page（SUI中每一个页面可以对应一个有id的page），后来因为客户的需求变动，把loading单独做成了一个page，动画结束后有一个跳转的推荐内容的page。然后在动画执行过后，用户点返回重新进入到动画的时候，前面已经执行过的动画便不会再次执行，会给用户带来不太好的体验。因此尝试了各种方法无果之后，想到了onhashchange这个事件，原本担心这个事件可能会触及到SUI的核心，后来实际运行下来发现，只有人为的返回才会触发onhashchange这个事件。遂把这个不算小的bug解决了，但还是提醒大家，也提醒我自己，这个事件是需要慎用的。
另外，onhashchange的兼容性如下，基本上现代浏览器都通用：
3.loading加载的若干种做法
现在h5页面随处都是，有时候想给用户呈现更多东西的同时，又担心用户会在等待中流失。因此，loading页面也是非常有必要的，虽然有pace.js这样的神器，但是客户可能未必想要那样简单的loading图案。综合之前圣诞节的页面以及google到的各种方法，想到了以下这2个方案。
一种是：做成短的序列帧循环播放；另一种是以百分比形式展现给用户。
前一种方案实现起来比较容易，尤其是有了css3的step阶跃函数让这一切变得容易了不少。而且比较适合于那种有自主logo的，不用考虑加载问题，直接onload之后消失、或者内联跳转就行。
关于阶跃函数序列帧的实现代码片段如下:
@-webkit-keyframes load {
from{
background-position: top;
}
to{
background-position: bottom;
}
}
@keyframes load {
from{
background-position: top;
}
to{
background-position: bottom;
}
}
.upload-word{
width: 6.64rem;
height: 2.32rem;
margin: 3% auto;
background: url(../resources/images/upload_word.png) 0 0 no-repeat;
background-size: cover;
overflow: hidden;
}
.upload-word-blink{
transform: translateZ(0);
-webkit-transform: translateZ(0);
animation:load steps(2) 0.5s 12;
-webkit-animation:load steps(2) 0.5s 12;
}
后一种方案就要涉及到现在比较流行的伪进度条的做法就是在dom结构里找一个合适的位置插入一段js，改变进度条长度，给用户造成一种假象。当然啦，资源的问题永远是第一位的，能在有限的容量里呈现更多的内容也是每个互联网人所追求的。
PS:在清明上来的一次测试中发现一个iOS的bug，就是当使用类似淘宝flexible改变视口的适配时，在iOS最新版的微信里会出现识别区域偏移的情况。
具体的原理可以看下这篇文章
https://segmentfault.com/a/1190000005871183
在尝试了多种方法均无效后，最后针对那两张带二维码的页面单独重写了css样式，也是一个无奈之举。
每一个项目总会有新发现，保持着这种热忱继续奋斗，fighting！共勉。
