移动端的动效设计主要分为两种：
页面跳转动画及加载动画
前者的作用是衔接页面间的切换
后者是为了减轻用户等待时的焦躁情绪。
同时，动效设计也是对设计师综合素质的挑战。
是你没看错，交互设计师和你聊动效，迎来职业第二春。
前些日子在给WPS邮件做新版本的交互设计，零零散散的工作结束后，看着测试机里APP的界面，发现邮件的加载与下拉动画还使用的是系统动画。
刹那间，使命感油然而生。
这次的设计流程如下：
了解需求-确定方向-着手设计-检验问题
Step1.了解需求
了解需求后我们可以在目标上和需求方达成共识，出发点一致，目标一致，避免出现不必要的麻烦。这点非常重要重要，效率第一。
有了这个想法就去和产品姐姐聊，没想到人家也是这么想的，五分钟友好的交流之后，我大概get到了她的想法：
需求：希望设计出新的下拉加载动画以代替系统默认动画。
期望值：动画内容契合列表的下拉刷新操作，与邮箱的线上设计风格一致，同时要求趣味性。
Step2.确定方向
当我设计动效时，我会想到什么？网上有很多炫酷的爆炸的旋转的3D的作品，我们如何在有限的时间里确定设计方向呢？下图是我的思考方式：
首先，设计本身是一个先做加法再做减法的过程。
加法：
关键词发散是我个人的设计方法，这个阶段，我联想到了现实世界中的很多与邮件相关的词，画了很多草图，也汲取了很多优秀作品的灵感，很多奇奇怪怪的点子在脑海中迸发。
减法：
在需求确定的情况下，可以更加轻松地缩小设计范围。
回想需求，动画内容契合列表的下拉刷新操作。下拉动画的内容需要与操作保持一致，用户在此页面下拉触发的是刷新行为，也就是收取新邮件，这我们需要用动画体现出来。
回想需求again，产品要求与邮箱的线上设计风格一致，WPS邮箱线上发送邮件的按钮样式是一架飞机：
依据以上思考我的结论是：
下拉刷新=收取新邮件
邮件=飞机
相应的，收取新邮件可以认为是飞机飞入，于是我延续飞机的设计，围绕着邮件与飞机的思路，以飞入邮箱的形式来展现“收取新邮件”的主题。自此动画的大体方向确定了：纸飞机与邮箱。
Step3.确定方向
到这里相信大家脑海中已经有了一个动画脚本：随着用户下拉列表至一定高度，触发动画，飞机飞入邮箱，下拉动画结束后列表收起，DEMO如下：
这里不讲技术问题，分享一些动画的思路:
飞行路线不用太复杂，看着累。
速率调整一下，注意透视，近大远小。
随着下拉手势，可以让邮箱门打开：
也可以在飞行的同时稍稍改变一下飞机的角度：
注意下图：较远的火车，看得比较清晰，较近的模糊，这个道理大家都懂。
Step3.1.立个flag
结合现实世界：立Flag是生活中存在的一个现实行为，在有邮件放入邮箱时，旗子会竖起来，用来提醒人们查看。于是我们在设计整个动画的时候着重的处理了这个部分，也就是说，这是动画的高潮呢（害羞脸）
看似观点对立，但文章内容详实，能够帮助大家把控移动端动效的设计原则。
翻回头看思考一下，面对需求，我们当然可以从别的作品中寻找灵感，但大概方向一旦确定，应该马上结合产品特征和需求方一起判断方案是否可行，用最短的时间做出最优的选择。
Step4.检验问题
动画制作完成后，感觉很开心
我们需要检视开发可行性，回想上面的动画，你有没有发现什么？
你会发现这个动画没有从交互设计的角度进行设计
加载时，我们要考虑很多问题，无网，弱网，加载时间过长等情况的发生。上面的动画，分为三段，我模拟的是流畅网络下的加载样式：
未触发加载时：用户下拉，但没有拉到触发位置的时候
加载时：飞机飞行时
加载完毕时 ：页面回弹结束
如果遇到长时间加载的情况，因为动画形式的制约,我们不可能设计成一架飞机不停向邮箱里飞，旗子立起来自己再放下去，非常不自然。这需要我们让“加载中的动画”和“结束加载的动画”无缝衔接，但实现起来太麻烦了，不仅会影响动画的大小，还需要开发做特殊判断。
留给中国队的时间不多了，怎么逆转局势呢！！！
方案如下：
现实世界中，收到信件的邮箱旗子会立起来，提醒别人收信，没有信件的时候旗子就会倒下，我们正好可以做一个飞入飞出的循环动画，一直播放，直到刷新成功。加载时间长的时候，就只是播放的时间长一点，短的时候，让开发限定最短加载时间，能够完整播放完一段飞机飞入的动画，这样既减少了开发的工作量，也保证了视觉效果。
最后的最后，说一下另一个重要的问题：
文件质量与大小
这里的下拉动画的尺寸为1080*210，质量和帧数不用太高，我的上线动画最终控制在22帧左右，所以类似上文说的模糊效果等等实际都不太看得出来，由于开发师傅一般不用gif格式，都用帧序列实现，这就要求我们控制好每一帧图片的大小，能够复用的图片一定要复用。一旦沟通不及时，你很可能会一直返工：