SVG的动态之美-搜狗地铁图重构散记

为什么使用SVG

不论是从业务类型还是操作方式的角度考虑，地铁图都可以被视为一种微型或者简易的地图。我们可以先回想一下手机地图的一些基本操作，举几个简单的例子：

• 可以缩放地图查看微观或者宏观的内容；
• 可以点击地图上的一个POI点展示其信息，同时此POI点居中；
• 可以通过搜索查看某个地点的完整轮廓，同时地图缩放到适合展示此地点完整轮廓的等级。

以上几种操作的技术实现需要遵循以下几个基本原则：

• 缩放后的地图不能展示模糊的内容，必须看上去是清晰的。也就是说，地图必须是“矢量的”[注]；
• 居中某一个点则必须知道此点的坐标信息，然后结合浏览器坐标体系和viewport尺寸计算出正确的展示内容；
• 完整展示某个轮廓则必须知道此轮廓的尺寸以及坐标，然后结合浏览器坐标体系和viewport尺寸计算出正确的展示内容；

注：之所以将“矢量”加引号是因为地图的实现包括栅格瓦片和矢量瓦片两种不同的技术方案。顾名思义，矢量瓦片是真正意义上的矢量地图，由OpenGL或者WebGL实现；而由栅格瓦片实现的地图并不是矢量的，缩放时会看到明显的模糊效果，但是缩放动作完成后会展示对应等级的栅格图片，也就是说缩放后的内容是清晰的，只是缩放过程中存在模糊效果。随着WebGL的普及，栅格瓦片技术逐渐退出了历史舞台。

简单概括，地图必须是：

• 矢量的；
• 动态的。

即使是栅格瓦片地图，POI点也是动态绘制的，感兴趣的读者可以自行查阅相关信息。

地铁图同样如此，而Web展示矢量内容只有两种方案：WebGL和SVG。虽然WebGL更富有视觉表现力，但是地铁图业务的体量较小，并没有达到值得用WebGL实现的程度，所以SVG便成了唯一的选择。

旧版地铁图的核心问题

旧版的搜狗地铁图虽然也是使用SVG绘制UI，但是并没有将SVG的动态优势发挥出来，而是将其视为静态的图片。图1是旧版地铁的DOM结构：

蓝色框的svg是地铁图的UI内容，除了尺寸以外没有任何其他的属性。红色框是地铁图外层容器，可以看到所有的偏移、缩放等交互都是借由外层容器的transform实现。黑色框的各个DOM节点包括了定位、求路、信息气泡等内容，这些DOM往往需要跟随用户操作被改动，而且某些操作可能需要同时操作多个DOM。

接下来我们看看这样的DOM结构存在什么问题。

定位、求路、信息气泡等内容是与地铁图强耦合的，假设我选中了某个地铁站，如图2：

红色框内的信息气泡对应到上图的container3节点，地铁底图对应container1节点。如果此时我们拖拽地铁图，底图和信息气泡都会随着手势而改变位置，那么就需要同时改变container1和container3的位置。

我们把同样的问题带入到求路，如图3：

我并没有画出每个UI对应的节点，因为实在是太多了。上图中包括了2个转乘节点、2个起终节点和3个气泡节点，拖拽过程中这7个DOM节点全部需要被操作。并且不仅仅是改写DOM属性那么简单，而是需要先获取每个节点的坐标然后再进行计算，而我们都知道，获取DOM的offset是非常消耗性能的。此外，求路状态下的地铁图必须缩放到完整展示求路路线的等级，那么就需要计算求路路线的轮廓尺寸，其中也会涉及到大量的计算和DOM操作。

其实拖拽是非常基本的操作，如果是缩放呢？抛开大量的计算和DOM操作不谈，从视觉上表现如图4所示：

• handler节点负责直接响应手势操作，拖拽、缩放等操作首先会改变handler的transform样式；
• container节点是svg容器，负责以浏览器窗口为参考将地铁图居中；
• view节点是所有与地铁图展示相关内容的容器，包括底图、定位、气泡、求路等等等等。同时，手势操作最终会修改view的transform属性，以实现地铁图本身的缩放。

以上说明可能有些难以理解，我们用具象的图形加以说明。分层的结构大致如图6所示，从外到里分别是handler/container/view：

此时如果用户进行了手势操作，以pan-拖动为例：

1. panstart事件触发后记录拖动的初始坐标，不影响分层结构中的任何一层，也就是说不改变任何一层的任何属性或样式；
2. panmove事件频繁触发，即拖动过程中，映射为handler层transform的改动，container和View无任何变化。如下图7：

　　3. pancancel/panend事件触发后修正handler合理的偏移量（详情请阅读下文的边界控制），同时将修正后的transform属性值换算为view的transform，最后将handler的transform归零。如图8：

代码如下：

 1 /**
 2    * @constant PrevOffset 前一次拖拽的坐标偏移量
 3    * @type {Object}
 4    */
 5   const PrevOffset = {
 6     x: undefined,
 7     y: undefined
 8   };
 9 
10   EventRuntime.on(‘panstart panmove pancancel panend‘, e => {
11     e.preventDefault();
12     e.srcEvent.stopPropagation();
13     // panstart事件记录初始坐标
14     if (e.type === ‘panstart‘) {
15       PrevOffset.x = e.deltaX;
16       PrevOffset.y = e.deltaY;
17     } else if (e.type === ‘panmove‘) {
18       // handler位移设置增量
19       subway.setTranslate(e.deltaX - PrevOffset.x, e.deltaY - PrevOffset.y);
20       PrevOffset.x = e.deltaX;
21       PrevOffset.y = e.deltaY;
22     } else {
23       // 拖拽结束后换算hander和view的transform，同时修正合理偏移量
24       subway.adjustTransform(‘translate‘);
25     }
26   });

GPU加速

我们都知道CSS的3Dtransform可以强制启用GPU加速以优化动画的表现，自然会想到SVG可不可以使用GPU加速呢？很可惜，答案是否定的。SVG是一种表现2D矢量图形的技术，它在设计之初便没有考虑3D的场景，所以SVG并没有3Dtransform，也无法借助GPU对动画进行加速。

那么我们便得出了handler存在必要性的第二个证明：GPU加速。

其实业内对于借助GPU加速动画的方案褒贬不一，即便是启用GPU加速也有方案的优劣。我们此次重构只是第一步，后续仍旧会不断探索进一步的优化方案。

transform-origin

SVG没有transform-origin概念，transform的原点永远都是自身的左上角，即(0,0)。

大家可以想象一下在手机上用两根手指缩放地铁图的场景，我们需要知道地铁图应该以屏幕上的哪一点作为中心进行缩放。从技术角度来讲，我们需要知道两个触控点的中心位置坐标。不论是IOS系统原生的gesture事件，还是通过touch事件模拟的pinch事件（如HammerJS）使用的都是浏览器坐标系，也就是CSS坐标系。

如果一定要把中心点坐标映射到SVG坐标系，则需要一定的计算量（下文详述）。在缩放操作过程中需要频繁地改变被缩放DOM的transform从而引起重绘（re-render），这期间浏览器本身就进行着大量计算，所以在应用程序层面应该尽可能减少计算量。

关于重绘和重排，可以参考浏览器的重绘与重排。

这也是handler节点存在必要性的第三个证明：减轻计算量。

有了handler节点的辅助，缩放操作进行中（请注意是进行中，不包括起始和结束时刻）唯一的计算便是handler的transform，无需将其转换为SVG的transform。当然，换算仍然是必须的，但是我们将其推迟到缩放操作结束之后进行，这样便可以在一次完整的操作流程中只进行一次换算工作，大大减少了总体的计算量。具体的换算公式下文详述。

Container - 地铁图居中

上文并没有过多的描述container节点，因为它的作用非常简单。container作为svg的容器，同时在初始化时以浏览器窗口为参考将地铁图居中。如下图12所示：

1 Offset.x = (container.width - window.innerWidth)/2;
2 Offset.y = (container.height - window.innerHeight)/2;

1 container.style.cssText = [
2   ‘postion: absolute;‘,
3   `left: -${Offset.x};`,
4   `top: -${Offset.y};`
5 ].join(‘‘);