高仿腾讯QQ Xplan（X计划）的H5页面（2）：动画控制

上一篇知道如何制作threejs地球之后，就正式coding了，当然还是使用最心爱的Vue。本篇会有一些代码，但是都是十几行的独立片段，相信你不用担心。

布局

在进入本篇主题前，要简单看一下xplan中的自适应解决方案，即如何在不同尺寸设备中，都保证地球最合适的大小和位置，并且与其配套的一些图片（虚线的椭圆轨道、正中心白色的圆环等）都不会显示的错位。

xplan用的方式简单直接，固定大小内作布局，然后针对不同的设备尺寸进行缩放。

固定画布大小（375 * 600），所有和地球相关的元素都可以在这个范围内绝对定位，之后scale一下，保证在设备实际尺寸中是被包含（contain）的。这种方式比REM等其他的自适应方式更适合这个项目，毕竟threejs中不能使用REM单位。

感谢Vue，我得以将上面这个自行缩放的逻辑写成一个Page组件，之后再也不用操心布局问题了。

动画

xplan中的动画是最吸引我的地方，特别是地球放大，穿越云层的那一刻，想想还有点小激动。

其实之前看到过一些项目有做从外太空俯冲进地球表面的动画，但是那些基本都是纯图片制作的SpriteSheet Animation，动画的前进后退控制都很容易。但xplan项目中则不同，动画过程中需要控制多个动画对象，还要配合其他资源（音频和视频）。

分析

xplan中动画的逻辑是，在地球自转过程中，长按按钮，会依次发生：

地球旋转到目的坐标
地球放大（相机推进）到该坐标
到足够近的时候，播放云层穿越动画
云层穿越结束后，展示对应坐标的视频内容
任何时刻松开长按按钮，动画都会回退到地球自转的状态

为了方便讨论，将上面分析到的动画阶段命名一下：

地球自转过程：idle阶段
地球转动到指定坐标的过程：rotating阶段
地球距离被拉近拉远的过程：zooming阶段
穿越云层的过程：diving阶段
云层过后的视频展示：presenting阶段

具体分析几个过程：

在idle阶段，只要touchstart，就算你只长按了0.1s，那么rotating的动画就会完整的触发，然后状态跳回idle（rotating没有反向旋转）。如上示意图。

如果长按至了zooming阶段，松开手指之后，zooming动画会立刻反向播放，直至回到idle阶段。如上示意图。

如果zooming过程松开手指后，但是在离开zooming阶段前再次按下去，那么zooming动画会再一次正向播放。如上示意图。

diving阶段貌似又回到了和rotating类似的行为，就算中途结束，也会完成当前阶段的动画。但是和rotating不一样的是，diving阶段是有反向动画的。因此可以看到上面的示意图。

我在考虑的过程中，阴差阳错的误以为还有一个条件：即除了rotating阶段外，其他动画过程都可以随时进和退（上面的GIF就是我最终完成的动画控制）。这个给自己添加额外的难度，困扰了我很久。

分步实现：地球

我创建了一个Earth类，负责3D地球（包括光线，光晕，地表的云，浮动坐标点等）的创建和渲染，同时向外提供几个public方法：

setCameraPosition()
getCameraPosition()
startAutoRotation()
stopAutoRotation()

地球旋转到指定坐标点，其实就是设置camera的position来完成了。要有流畅动画的感觉，就使用tween去做position的更新。

new TWEEN.Tween(earth.getCameraPosition()
).to(targetCameraPosition,1000
).onUpdate(function () {earth.setCameraPosition(this.x, this.y, this.z)
})

关于tween和threejs动画，这里有教程。

其实最开始，这个Earth类没有这么纯粹，我在里面加了targetLocation代表当前要转到的目标地点；还将tween的逻辑写在了这个类里面，让earth知道自己的目的地，控制自己的旋转动画。但后面发现对于这个项目中动画可控制的灵活性，这样封装在内部的动画逻辑，将很难写成清晰的代码，让其能和后面的云层动画统一来控制起来。

分步实现：云层

决定使用SpriteSheet Animation类似的方法做云层动画。其实有这样的库，比如Film（这个好像也是qq下面的团队做的），但是我还是更想从npm中install一个，由于没有找到合适的，就索性自己写一个好了，于是就发布了一个小工具——image-sprite。

操作由ImageSprite类创建云层对象，只用到了两个public方法，主要控制播放前一帧和后一帧：

imageSprite.next()
imageSprite.prev()

其实应该使用自动播放（play）和暂停（pause）应该也能完成，anyway

云层动画功能单一，想把它写的不纯粹也难。个人觉得coding的艺术就在于如何去划分这个纯粹。

第一印象

上面两个关键动画对象都实现了，用户的行为也很简单，只有touchstart和touchend，那么用一个touchDown标志位记录一下就可以了。所以可以有一个中控器（controller），根据用户产生的状态，来调用不同的动画对象播放动画。

最先开始，脑子里面第一印象是下面这样的解决方案：

function handleTouchDown () {touchDown = trueif (currentState is idle) {playRotatingForwardAnimation(handleAnimationComplete)} else if (currentState is rotating) {playZoomingForwardAnimation(handleAnimationComplete)} else if (currentState is zooming) {playDivingForwardAnimation(handleAnimationComplete)} else if (currentState is diving) {playPresentingForwardAnimation(handleAnimationComplete)} else if (currentState is presenting) {// nothing to do}
}function handleTouchEnd () {touchDown = false
}function handleAnimationComplete () {if (touchDown) {// 找到下一个阶段，正向播放动画findNextState()play<nextstate>ForwardAnimation(handleAnimationComplete)} else {// 找到上一个阶段，反向播放动画 findPrevState()play<prevstate>BackwardAnimation(handleAnimationComplete)}
}

这样的方案能解决动画的大方向，即动画阶段之间的前进和后退，无法控制阶段内的每一帧的方向。而且也能看到，上面有太多的if判断，handleTouchDown函数中的那种if情况，一定要避免，否则大项目中代码很难维护。这样的情况使用有限状态机模式或者策略模式都是很容易解决的。

第一印象告诉我：

要使用状态机设计模式
要从帧级别去做控制

状态机

写代码过程中肯定会遇到状态，最常见的状态会被记录成布尔值或者字符串常量，然后在做某个行为的时候对状态变量进行if-else判断。如果只有2个状态，还行，但是状态如果会变多，那么这样的代码就很难维护，将在主体中引入越来越多的if-else，越来越多的与特定状态相关的变量和逻辑。

个人非常喜欢状态机模式或者策略模式，它们本质都一样，都是使用组合代替继承，完成统一接口下的行为的多样性。最开心的是，这个模式将混杂在主体中的状态量和行为抽离出来，单独封装，让主体变的清清爽爽；还有，在JS中，你甚至连接口类都不用写！

举个简单的例子，上一篇中谈到的ImageSprite，用来将一系列图片进行播放，本质上就是绘制图片而已。但是我这里提供两种模式，一种绘制在canvas里，一种绘制在dom里（即image展示）。

不使用模式，可以简单的写成这样：

class ImageSprite {constructor () {this.renderMode = 'canvas'this.context = nullthis.imageElement = nullthis.images = []}drawImage () {if (this.renderMode === 'canvas') {this.context.drawImage()} else if (this.rendererMode === 'dom') {this.imageElement.src = '...'}}
}

使用了状态机模式（这里的场景来看，叫策略模式更贴切，渲染策略不同）：

class ImageSprite {constructor () {this.renderer = new CanvasRenderer(this)this.images = []}drawImage () {this.renderer.drawImage()}
}class CanvasRenderer {constructor (imageSprite) {this.imageSprite = imageSpritethis.context = null}drawImage () {this.context.drawImage()}
}class DomRenderer {constructor (imageSprite) {this.imageSprite = imageSpritethis.imageElement = null}drawImage () {this.imageElement.src = '...'}
}

可以看到使用了模式之后，context和imageElement这样的和状态相关的变量，还有绘制canvas图片和绘制dom图片的不同代码，都从主体ImageSprite中抽离出去，单独的封装到了不同的状态对象中去了。

想想一下如果有第三种渲染模式，比如渲染在webgl中去，在不使用模式的代码中，要添加变量，要修改drawImage函数；但是在使用了模式的代码中，现有代码都不用改变，只需要添加一个新类WebglRenderer就可以了。这就是代码的可扩展性和可维护性的体现。（在Java中，还能省去代码的重新编译的过程）

整合

回到xplan的动画中去。在前面分析动画阶段的时候，其实就得到了每个状态，这些状态的统一接口就是向前帧动画（forward）和向后帧动画（backward）。

先不管每个state中逻辑该怎样，有了约定的接口，就可以把我们的中控器（Controller）写个基本框架了：

class Controller {constructor (earth, cloud) {this.earth = earththis.cloud = cloudthis.touchDown = falsethis.state = new IdleState(this) // 初始状态为IdleStatethis._init()}_loop () {requestAnimationFrame(this._loop.bind(this))if (this.touchDown) { // 如果touchDown，则向前一帧this.state.forward()} else { // 否则，向后一帧this.state.backward()}handleTouchStart () {this.touchDown = true}handleTouchEnd () {this.touchDown = false}// ...
}

因为要做到帧级别的控制，因此这里用到requestAnimationFrame来制作渲染循环。代码是不是很清晰简单！在渲染循环中，根本不在乎动画逻辑怎么执行，只知道touchDown了，就做向前动画，否则做向后动画，其他的都在各自的状态类里去实现。

下面拿两个状态类举例，其他的请移步这里。

IdleState

class IdleState {constructor (controller) {this.controller = controller}forward () {this.controller.state = new RotatingState(this.controller)}backward () {// do nothing}
}

这里IdleState没有向后的动画，因此backward()里面是空的；而该状态下的touchDown都会让earth开始旋转到指定坐标，而这个过程我们知道是RotatingState该做的，所以在RotatingState的‘forward()`里会去实现旋转控制。

DivingState

class DivingState {constructor (controller) {this.controller = controller}forward () {let cloud = this.controller.cloudif (cloud.currentFrame is last frame) {  // 最后一帧时，进入下一个状态this.controller.state = new PresentingState(this.controller)} else {cloud.next() // 播放下一帧}}backward () {let cloud = this.controller.cloudif (cloud.currentFrame is first frame) {  // 回退到第一帧时，进入上一个状态this.controller.state = new ZoomingState(this.controller)} else {cloud.prev() // 播放前一帧}}
}

还记得么，diving是指穿越云层的那个过程。因此它往前（forward）是presenting，往后（backward）是zooming。而什么时候切换到下一个或者前一个状态，和往前或者往后的每一帧动画该如何执行，都只有这个DivingState知道，完美的逻辑封装。

完整的动画逻辑里，还包含着一些音频和视频的控制逻辑。比如地球自转时播放背景音乐，动画一旦开始则停止；穿越云层后播放视频，其他时候视频是停止的。这些逻辑，能够很容易的添加到上面的状态中去。比如在IdleState的contructor中播放音乐，在RotatingState的contructor中停止播放音乐；在PresentingState的constructor中播放视频，在DivingState的contructor中停止视频。

所以，一旦逻辑清晰了，代码清晰了，添加功能时显得很容易。

意外收获

完成上面的所有动画状态之后，我发现地球其实还有一个动画，那就是开场的逆向旋转并放大的入场动画。在上面做动画分析的时候，是把这个开场动画分开来设想的，但是上面的controller用上状态机之后，意外的发现这个入场动画可以以另外一个state放进来。

入场动画状态类：

class EnteringState {constructor (controller) {this.controller = controllerthis.tween = new TWEEN.Tween({// 起点位置}).to({// 终点位置}, 1600).onUpdate(function () {// 设置earth的缩放和旋转}).onComplete(function () {this.controller.state = new IdleState(this.controller) // 完成后进入IdleState}).easing(TWEEN.Easing.Cubic.Out).start()}forward () {TWEEN.update()}backward () {// do nothing}
}

最后将Controller初始化时的第一个state赋值改为EnteringState即可。这真算是一个意外的收获，本来是打算单独（在controller之外）去实现的。

小结

到这里就差不多了，xplan主要的东西都讲到了，高（shan）仿（zhai）的过程还不错，了解了three，顺便还publish了几个小的工具库；有不足、也有超越。这个h5看似复杂，但是技术也没有多高深，主要还是创意，还是要给xplan点个赞！

最后，个人接h5，有没有个人或者公司啊，不要不好意思联系我~