上一篇知道如何制作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知道自己的目的地，控制自己的旋转动画。但后面发现对于这个项目中动画可控制的灵活性，这样封装在内部的动画逻辑，将很难写成清晰的代码，让其能和后面的云层动画统一来控制起来。
其实最开始，这个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 = true if (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 = null this.imageElement = null this.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 = imageSprite this.context = null } drawImage () { this.context.drawImage() } } class DomRenderer { constructor (imageSprite) { this.imageSprite = imageSprite this.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 = earth this.cloud = cloud this.touchDown = false this.state = new IdleState(this) // 初始状态为IdleState this._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.cloud if (cloud.currentFrame is last frame) { // 最后一帧时，进入下一个状态 this.controller.state = new PresentingState(this.controller) } else { cloud.next() // 播放下一帧 } } backward () { let cloud = this.controller.cloud if (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 = controller this.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点个赞！