2D商城换装业务不同于广泛业务场景，存在大量换装和切换动作的需要，但业界内现有运行库短少对应的API实现与反对。因而，本课程将率领大家深刻Spine 2D渲染底层原理，深刻Spine源码运行库，剖析其外围模块和渲染层的调用和解决流程，并基于此介绍如何基于PIXI-spine实现换装和换动作性能，以及性能实现过程中的难点。

一、Spine基本概念及其原理介绍

Spine中比拟重要的几个基本概念，可参照笔者之前分享的一篇文章，包含对骨架、骨骼、附件、插槽以及皮肤的概念了解。

这里还须要补充强调一个概念：数据对象和实例对象的关系与区别。

数据对象是无状态的，可在任意数量的骨架实例间共用。有对应实例数据的数据对象类名称以“Data”结尾，没有对应实例数据的数据对象则没有后缀，如附件、皮肤及动画。

实例对象有许多属性与数据对象雷同。数据对象中的属性代表拆卸姿态，通常不会改变。实例对象中的雷同属性示意播放动画时该实例的以后姿态。每个实例对象保有一个其数据对象参考，用于将实例对象重置回拆卸姿态。

例如，SkeletonData是数据对象，而Skeleton是实例对象。同样的，Bone实例对象会有对应的BoneData，Slot实例对象会有对应的SlotData等。

二、Spine渲染整体流程图

三、设计思路

业务背景：

公司外部业务存在大量换装和切换动作的需要，因而Spine编辑器导出的素材，也须要进行拆分，将"头饰"、"发型"、"上衣"等一一归类拆分为一个个dress；同样的，因为动作繁多且多变，动作也需独自拆分为一个个action，而动作内又可能产生打扮的替换，因而拆分进去的动作素材内可能同时含有骨骼信息和打扮信息。

以接下来这个挥镰刀的动作为例，将被拆分为一下几局部：

插拔思维：

基于后面的拆分，为了让人物能够不便的进行打扮的替换，动作的切换，咱们须要将打扮和动作都设计成可"插拔"的模式，实质上都是基于初始的根底骨骼，而后持续往骨架上新增打扮附件，或者新增骨骼信息，而这些新增的骨骼和打扮在将来某一个同样能够从以后骨架中"摘除"。实现打扮的替换或者动作的切换。

渲染库选型：

渲染层\比拟项兼容性封装水平可拓展性
canvas不反对网格附件、着色低低
webgl√低低
threejs不反对两种色彩着色和混合模式高个别
pixijs√高高

在针对渲染层采纳的技术计划的比拟中，canvas和threejs仍存在一些兼容性问题；因为canvas和webgl都用浏览器原始画布来做渲染，因而封装水平较低，如果要投入到业务中须要进行二次封装；思考到2D动画渲染以及将来的业务性能的可拓展性上，pixijs绝对更有劣势，基于pixijs的封装能够让咱们很不便的对实例进行治理。

最终采纳pixijs + pixi-spine 插件作为厘米秀2D渲染技术计划。

整体分层设计：

无论是哪种渲染层计划，目前都未实现换装换动作性能，仅反对一份素材的生产，而因为业务自身的须要和特殊性须要咱们自行扩大实现这一个性能，整体设计如下：
!

顶层的业务调用层：裸露给业务应用，通过创立Role实例能够不便的进行addDress、removeDress以及addAction和removeAction等操作，上层的解决逻辑对下层通明。

业务适配层：针对厘米秀业务场景下的适配逻辑，加载厘米秀素材资源，解压并解析资源，同时在这一层调用换装扩大插件所提供的办法，批改渲染实例上的数据，包含骨骼、插槽、附件等来实现切换打扮和切换动作。

换装扩大插件：在pixi-spine插件的根底上再扩大，因为pixi-spine上不足新增和批改附件，新增骨骼插槽等API，因而须要扩大底层办法供应下层调用。

pixi-spine和pixijs：最上层的渲染库提供渲染反对。

四、换装性能实现

依据笔者之前的文章所介绍的，每次插槽渲染的时候，都会依据以后slot的attachmentName，去以后skin中获取到对应的附件。

skin是附件查问的映射表，因而只须要到以后的skin中（厘米秀只有默认的default skin），去更新对应的附件，即能够实现换装性能。

如下图所示：

正如之前渲染流程所介绍的，渲染层会遍历slots进行一一渲染，实质读取的是slot上挂载的attachment实例，因而咱们须要明确附件实例的构建流程，以及如果更新这些实例。

slot1来源于slotData1，初始化的时候会读取slotData1中的attachmentName，去skin.attachments中查找对应的附件实例，这里每一项的index都是一一对应的，skin.attachments数组中的第一项对应slotData1，检索到对应的附件实例后赋值给对应的slot实例，期待被渲染层渲染。

从这里咱们能够晓得，咱们须要更新的是slot中的对应附件，而附件检索来自于skin，因而咱们实际上须要更新的是skin上对应的附件查问表，将对应层级的附件实例更新为新的打扮生成的实例。

接下来，须要明确的第二个问题是，咱们如何生成对应的生产素材资源，生成对应的附件实例，skeletonJson是spine外围库定义的用于解析JSON的解析器，生成对应的skeletonData，这一过程中就包含结构skin。

因而，咱们须要通过定义loader加载厘米秀素材资源，解决成对应的资源格局，通过textureAtlas的解决，结构出AtlasAttachmentLoader给skeletonJson调用，有了loader，提供json，这时候skeletonJson便能够解析后结构出对应的附件。

这里咱们须要做以下几件事：

1、自定义loader加载素材资源，解决成对应的资源格局给上层生产；

2、仿造pixi-spine解决流程，结构AtlasAttachmentLoader给skeletonJson调用；

3、扩大skeletonJson底层原型链办法，生成附件实例，将新的附件实例更新到以后skin对应的层级地位上。

自定义loader解决以及skeletonJson调用如下：

    // 资源加载 解析 预处理    const filesParsing = await parsingFiles(this.src);    const result = await loadAndDealDressFiles(this.dressId, filesParsing);    result.json = JSON.parse(result.json);    result.png = {      [result.pngid]: result.pngContent,    };    const renderResource = await getRenderRes(result);    this.renderResource = renderResource;    ...    // 资源生产 结构AtlasAttachmentLoader 调用扩大API updateAttachment    const { renderResource } = this;    const that = this;    const adapter = PIXI.spine.staticImageLoader(renderResource.metadata.images);    new PIXI.spine.core.TextureAtlas(renderResource.metadata.atlasRawData, adapter, spineAtlas => {      let attachmentLoader;      if (spineAtlas) {        attachmentLoader = new PIXI.spine.core.AtlasAttachmentLoader(spineAtlas);      }      const skeletonJsonParser = new PIXI.spine.core.SkeletonJson(attachmentLoader);      const updateSlotList = skeletonJsonParser.updateAttachment(        that.sprite.spineData,        renderResource.data.attachments,      );      ...      that.sprite.skeleton.setToSetupPose();    });

扩大skeletonJson底层原型链办法外围逻辑如下：

 core.SkeletonJson.prototype.updateAttachment = function(    skeletonData,    skinMap,    skinName = 'default',  ) {    ...    Object.keys(skinMap).forEach(slotName => {      const slotIndex = skeletonData.findSlotIndex(slotName);      if (slotIndex === -1) throw new PluginError(`Slot not found: ${slotName}`);      const slotMap = skinMap[slotName];      Object.keys(slotMap).forEach(entryName => {        ...        const attachment = this.readAttachment(          slotMap[entryName],          skin,          slotIndex,          entryName,          skeletonData,        );        if (attachment !== null) {          skin.addAttachment(slotIndex, entryName, attachment);        }      });          });    ...    return updateSlotList;  };

五、换动作性能实现

动作的解决，相比之下会比打扮要简单一些，因为动作蕴含的信息更多，骨骼信息、插槽信息、附件信息和动画信息。

在开始实现之前，须要思考一个问题：数据对象是否须要更新？间接更新实例对象可行不？

答案是否定的，理论渲染的实例对象最后来源于数据对象，然而居然理论渲染的是实例对象为啥还要去保护数据对象的更新呢？

这里出于两点思考，一个是理论在创立附件的时候仍须要用到数据对象上的信息，一个是保持数据对象和实例对象的数据关系同步，避免两者割裂不利于后续保护。

针对动作，首先咱们要更新骨骼信息：

1、更新boneData 以及 更新bone。

如上图所示，首先咱们须要在skeletonData退出新增的boneData，接下来利用boneData结构出新的bone实例，新增到skeleton的bones中，因为bone的前后程序并没有严格要求，只须要父骨骼在子骨骼之前被解析即可，因而新增的bone也能够间接push到数组前面即可。

2、更新插槽信息以及关联信息：

插槽信息的更新相比骨骼会简单点，除了插槽自身的信息，还有插槽相关联的信息，且因为插槽程序有严格限度，因而每个信息的更新都要依照插槽所在的index来插入。

如上图所示，咱们须要在skeletonData中数组对应的index地位插入新增的slotData，同时创立slot实例插入到skeleton实例中的正确地位，因为以后属于新增插槽阶段，因而attachment为null，而slot最终渲染也是要检索skin的，因而skin中须要在对应地位新建一个空对象插入，因为slotData中自身记录了index信息，而新增的slotData会导致这些信息发生变化，以图中为例，newSlotData4中的index为4，slotData4的index更新为5，以此类推。

然而除了以上信息以外，slot还会影响两个中央，drawOrder以及container：

drawOrder在初始化时，是slots的浅复制，当有管制slot档次变动的动画存在时，会调整drawOrder中的程序，扭转以后的渲染层级，因而咱们须要从新对drawOrder进行浅复制初始化，以保障slot数据统一。

container是pixijs上屏渲染每个slot中精灵对象的容器，更新container容器对象实质是为了用于上屏渲染，这种映射关系也是一一对应并且依照index程序，因而须要在container数组中对应地位插入新的container对象。

3、更新skin上的附件实例映射：

相似的，咱们须要更新skin上的附件实例映射，检索skin上对应的附件更新，基于后面两步，咱们曾经新建好了骨骼插槽等信息插入到正确的地位，接下来须要注册新的附件实例进skin中，这一步骤其实和切换打扮原理以及处理过程是相似的，这里不再赘述。

4、更新动画对象信息：

最初一步，咱们须要更新动画对象信息，须要咱们新建动画state对象，更新与原有的skeleton实例的绑定关系。

在底层扩大好更新办法，内部传入解决好的数据对象数据即可。

外围逻辑如下：

   ...    const skeletonData = skeletonJsonParser.updateAnimation(      this.sprite.spineData,      renderResource.data.animations,    );    this.sprite.updateAnimationState(skeletonData);    this.sprite.actionNames = Object.keys(renderResource.data.animations); 
Spine.prototype.updateAnimationState = function(skeletonData) {    this.stateData = new core.AnimationStateData(skeletonData);    this.state = new core.AnimationState(this.stateData);    return this;};

六、遇到的坑

1、渲染数据走缓存 要清空缓存

slot再每次渲染的时候，都会查看attachment，而每次渲染的时候都会判断attachmentName是否发生变化，以及检索附件缓存hash，然而咱们须要更新同一个插槽的同名打扮，因而，须要咱们手动清空缓存，触发渲染更新。

     ...      updateSlotList.forEach(({ slotIndex, attachmentName }) => {        that.sprite.skeleton.slots[slotIndex].data.attachmentName = attachmentName;        // 从新设置为空触发更新        that.sprite.skeleton.slots[slotIndex].currentSpriteName = '';        that.sprite.skeleton.slots[slotIndex].sprites = {};        that.sprite.skeleton.slots[slotIndex].currentMeshName = '';        that.sprite.skeleton.slots[slotIndex].meshes = '';      });      that.sprite.skeleton.setToSetupPose();      ...

2、slot index影响多个中央 要多个中央同步

正如第五点所介绍的，在更新动作过程中，因为插槽信息关联多个信息，须要咱们去同步更新，且index地位严格依照地位关系解决，不可打乱。因而咱们须要更新slotData、slotData中的index、slots、drawOrder、查问映射的skin以及container。

3、drawOrder是新的数组对象 不能间接复用slots

由后面介绍的可知，drawOrder是slots的浅复制，因而，咱们不能简略粗犷间接进行赋值操作，而是要老老实实复制一下slots数组。

this.sprite.skeleton.drawOrder = this.sprite.skeleton.slots.map(slot => slot);

4、插入skins的时候要从大index开始

因为skins最后是没有对应的检索附件对象的，因而咱们创立了新的空对象，然而在插入的时候，为了保障程序不被穿插影响，因而在插入skin中对象的时候，咱们须要从后往前拔除。

5、flipX、flipY不兼容、mesh兼容问题
6、默认取首个附件为默认附件渲染

七、总结

本文章总结了Spine渲染整体流程，并基于以后Spine运行库，针对性地实现换装换动作性能，在原有pixi-spine上进行扩大，以满足业务须要，同时，深入分析了换装换动作性能的具体实现以及实现过程中的坑点。

感激观看~