原创 驭剑 淘系技术 4月22日
本文根据4月21日淘系技术前端团队出品的「阿里淘系用户体验优化前端实战系列直播」——《淘金币用户体验升级》整理而成。
大纲
▐ 总览
本文将围绕如下三点展开分享：
1、介绍淘金币业务和业务的发展历程，以及升级到最新版的背景。
2、介绍在这次升级过程中我们碰到的一些技术挑战
3、针对这些挑战的相关技术上的实现分享。
业务介绍
▐ 什么是淘金币
我想很多小伙伴一定听说过淘金币吧，但是不一定知道我们的淘金币业务，如果还不了解我们的业务，那你可以在手机淘宝首页上方的众多icon中找到“领淘金币”这个icon，点击进入后就能看到我们的淘金币产品了。
▐ 淘金币历程
淘金币宝箱版当时的是在抓住用户薅羊毛的心态以及金币抵钱心智的背景下产生的，页面功能上就只有一个签到按钮，用户每天过来签到下，签到后就走了，逗留时间相对比较短，这种签到就走的行为对频道带来的金币价值相对也有限。所以我们开始为考虑怎么打造一种新的互动体验，在不改变用户金币抵钱的心智上，可以让用户能更长时间的在我们的频道内逗留，并提升活跃度。
庄园1.0是淘金币走出游戏化探索的第一步，当时的背景就是在存量用户博弈下，如何增加用户黏性和使用时长成为了一个严峻的问题，而游戏是天然具有高用户黏性、高使用时长的特性，我们将游戏化和电商结合后产生了庄园，那当时上线后我们发现用户接受度和数据表现都很好。
有了庄园1.0的成功后，那我们对游戏化就更加有信心了，庄园2.0的时候我们加大了游戏区域来增加游戏场景感，并且增加了水滴任务来拓展用户获取金币的渠道。
升级成小镇的背景是在庄园的种植玩法在经历了两年多后，用户从熟悉期慢慢转化到疲劳期，我们需要给到用户更多的新鲜感；产品方面：在历次改版中积累了很多的经验和方法论可以得以实践验证。技术方面：我们自研互动游戏引擎日趋成熟，同时基础运营平台能力也越来越完善，我们有强大的任务系统和弹窗系统来满足用户运营的能力。
▐ 升级了哪些
淘金币业务运营过程中，产品积累了一些游戏化产品的经验，在产品业务形态和界面中得以应用，为了给用户更好的体验和新鲜感，产品增加了故事线和等级、称号、排名这些游戏化元素，并且增加助力、合力这些互动行为来增加用户体感，同时运营同学也提出了要增强运营能力以及更灵活的用户触达功能。
那这次升级在界面和功能上和庄园发生了巨大的变化，这些升级也在技术上对前端提出了一些挑战？
技术实现
▐ 技术上的难点
- 产品希望增强运营能力，多渠道的承接和分发，运营活动透出等更快用户触达的手段
- 素材资源数量众多，20倍于庄园，同时也给设计师和开发协同效率提出了更高的要求
- 相比庄园一颗植物场景复杂度高了很多，建筑上也承载更多的互动行为
- 业务用户覆盖度广，用户机器性能也良莠不齐，对稳定性和兼容性提出了很高的要求
相比庄园就一颗植物来说，小镇场景复杂了好多。场景中的建筑和装饰物都是可以升级的，这样导致素材资源数量是庄园的近20倍，给设计师和开发系统效率提出了更高的要求，淘金币用户的覆盖度很广，好多用户的机型性能不是非常好，这时候对我们业务的稳定性和兼容提出了很高的要求。最后就是运营同学还希望能实现多渠道的承接和分发，并且能更灵活的将一些信息快速触达给用户。
那针对以上的这几个难点我们采用哪些方式来解决这些问题呢？接下来我会简单介绍下：
▐ 合理的分层框架
-
混合开发模式（DOM+CSS和Canvas）
为了满足运营和视觉上的效果，我们设计了如下的分层框架，在保证层次分明的同时，我们也需要考虑到未来业务的灵活可扩展，在开发过程中我们采用的混合开发模式，就是DOM和Canvas混合开发，利用传统DOM和CSS的排版优势，更能跟上业务的迭代节奏。
分层上从下而上依次分为：
• 背景层：背景层是随着游戏章节不同也变化，各章节有着不一样的背景氛围，同时也能满足在各种节日可以透出当前节日氛围的效果• 游戏层：那游戏层就是渲染游戏建筑和装饰物的canvas层• 业务层：承载了游戏签到主玩法以及用户的合力和助力等互动行为• 消息层：刚刚我们提到的运营同学想要的运营能力和消息触达能力将在这一层实现，我们设计了一个高度定制化的弹窗模型，配合上后端能力，能实现弹窗界面编辑和DSL配置下发，这样我们在不需要发布版本的情况下就可以帮助运营同学将重要活信息透出给用户。
采取了上面的分层后，游戏层和业务层、消息层之间我们采用了最普遍的事件通信机制来相互通信。
▐ 游戏层实现
刚才我们说了前端的分层，上面的分层中除了游戏层其他的我们都可以采用DOM+CSS来开发，那传统的DOM+CSS的实现我就不多说了，接下来我会通过游戏场景搭建流程、动画实现、稳定性和性能优化、无障碍支持这个方面重点介绍下游戏层的实现细节。
游戏场景搭建流程
▐ 约定视觉交付规范
为了提升视觉和开发协同的效率，我们一开始就和设计同学约定了视觉交付规范，这样就能保证视觉交付的素材可以顺利渲染到场景中。
不知道小伙伴有没有发现我们的游戏场景中的建筑使用的是2.5D的方式来绘制的。举个2.5D风格例子，如果玩过纪念碑谷的小伙伴应该会非常有体感，这种风格的游戏就是我们经常说的2.5D游戏。2.5D风格的设计一般使用右侧的类似的是右侧下方展示的网格画布作为参考线，感兴趣的小伙伴可以自行了解下一个2.5D风格素材产出的过程。
▐ 视觉产出流程
上面我们聊了我们约定了视觉生产的素材要符合2.5D风格，这里我简单介绍下我们的视觉产生流程，相比传统的产生流程，我们的流程还是有些许不同的，这些流程上的差异也帮助我们实现更加细腻真实的场景。
上半部分是传统的2.5D风格生产的过程，设计师在PS中基于设定的网格画布来绘制一个个部件，然后将部件拼成模型。
而我们的流程如下方，我们是通过设定了建筑线稿和原画效果后采用了C4D建模的方式的方式，最终建模的模型渲染后交付。
▐ 三渲二
看到这里有没有小伙伴觉得疑惑，不是说好了2.5D是2D的方式吗，为什么引入了3D建模的方式？
其实我们这种流程一般被称为三渲二，三渲二是先建立三维场景等资源，然后以某个角度来渲染当前场景形成二维图片，那三渲二的优点有更真实的立体感，后期建筑会有动画，有了3D模型后制作就更简单，这在我之后的动画实现会讲到。同时三渲二更容易标准化和量产，因为传统的二维动画的每一帧都需要画师一笔一笔勾勒出来，很难标准化的大规模量产。
右侧我展示了两个使用三渲二的精彩案例，他们制作出来的动画画面精美，下方我放了个刺客伍六七剧组放出的花絮地址，它其中就使用到了部分三渲二技术，这个视频例子仅做参考，让大家对三渲二有个体感，具体伍六七中使用到了多少三渲二就不得而知了。
▐ 建筑排列
建筑的模型我们可以规范设计和流程化渲染交付了，那拿到这些建筑素材后我们应该如何渲染到场景下，同时又能符合设计师整个场景的效果呢？
大家一定注意到了，我们反复提到了格子画布，格子画布是我们素材设计时的容器和参考，我们在模型制作第一步，场景线稿时就是在格子画布上设计场景的，那一个个的格子其实就是我们建筑模型的定位点。那我们使用的就是TileMap（瓦片地图）。
在2.5D中这个格子画布就成为TileMap（瓦片地图），我们的建筑可以通过一个个格子的坐标来换算成屏幕上的坐标的，换算成屏幕上坐标后我们要做的就是把对应的建筑放到那个坐标上。然后一个个建筑按照坐标放入后即可，其实这里面还隐藏着一个各个建筑深度的换算，感兴趣的小伙伴可以去了解下TIleMap。
▐ 编辑器提效
为了帮助我们快速还原场景，我们开发了一个简单的编辑器来帮助我们提效，编辑器不仅仅帮我们将建筑放置好，他还有一个非常重要的功能就是帮助我们打通素材从产生、上传、引用这个链路。
视觉制作完素材后，上传到我们的资源平台，资源平台会对素材进行校验优化最终生成符合标注的素材，那编辑通过打通资源平台，可以直接使用资源平台的素材来编辑场景，编辑完后的场景可以通过导出DSL后使用我们开发的插件就可以渲染完成场景还原了。
动画实现
▐ 引子
上面我们简单介绍了我们场景的还原过程，我们也提到了使用插件来渲染场景，上面这些基础前提都来自于我们具有完善的互动游戏开发的链路，包括于我接下来要讲的我们团队开发的游戏引擎Evajs。
▐ 游戏引擎
在讲动画实现前我们先聊下游戏引擎，我们做游戏前还是绕不开需要和游戏引擎打交道，而我们这次渲染的动画能力都是有我们Evajs来支持的，Evajs的底层架构还是基于ECS， 关于ECS我简单的用右侧的这张图片来介绍下，比如我给一个 游戏对象 添加了ImgComponent组件属性，那它就能通过渲染成一个图片对象，同理我给它增加了一个TranslationComponent组件，那它就有了过渡动画的能力。每一个对应的系统管理对应的多个组件，组件的增删改就会通过系统作用到对应的游戏对象上。
回归到我们的游戏引擎，它所拥有的支持渲染和动画能力的特性能帮助我们实现场景中众多素材类型渲染的问题，我们要做的就是通过判断不同的动画类型来设置不同的动画组件即可，那接下来我将介绍下我们使用的动画类型：
▐ 不同的动画类型
- 骨骼动画
小镇场景中建筑很多是带有动效的，有些是可以通过简单的形变、位移、旋转就能搞定的动效，这类动画我们采用的骨骼动画，骨骼动画通过操作骨骼的朝向和位置来达到模型动画的效果，我们的骨骼动画是龙骨动画，龙骨动画由一张图片和两个描述文件组成，整体资源大小合适。
-
帧动画
那有些复杂的动效效果，比如一些带3D效果的旋转透视和阴影不能通过2D平台的动效实现，那我们这时候会采用帧动画的方式来实现，采用帧动画能保证用户看到最佳的视觉效果，当然我使用了压图、抽帧、优化拼接算法来达到效果和图片大小、占用内存之间的平衡。
▐ 稳定性和性能优化
淘金币产品的用户覆盖广，伴随着这次场景提升带来了资源近20倍的增长，这时候考虑到内存和可能存在的crash风险，我们采用了如上的一整套降级方案，底层的降级平台提供设备评分管理、降级策略配置、降级开关等功能，降级平台同时也支持降级某款指定机型，这样就能应对大促期间比如某些机型crash量增大时做降级。
页面级别我们有降级SDK获取当前设备的评分后根据降级平台的策略我来确定机型的评级，拿到了设备的端评级后，我们就可以执行我们的降级策略，针对高中端机型我们采用龙骨、帧动画这种效果优异的动画，在低端机我们就会降级成静态图片，同样的低端机在css动画、js动画上会被降级来稳定cpu帧率。
无障碍支持
▐ 背景
- 手淘APP的用户群体，就视障人士一直以来是有一定的量
- 近一两年大促互动活动中我们看到更多的视障人士也积极参与进来
- 从产品本身体验方面来说视障人士也是我们不应该忽略的用户
其实一直有视障人士在通过手机淘宝购物，手淘从2011年开始就在做无障碍方面的优化，随着近几年手机的普及率越来越高，越来越多的视障人士也享受到了网络购物所带来的便利。我们也惊奇的发现每年大促期间，是不是就会有报道说越来越多的视障人士参与到活动中。从淘金币本身出发，我们的用户群体覆盖也是非常广的，这部分的用户我们也是不应该忽略的，所以我们在开发过程中就尽量考虑到了无障碍的支持。
当我们提到手机端的无障碍时，由于障碍的划分非常多，比如聋哑、色盲、听力受损、阅读障碍和理解障碍等等，有些障碍类型在现阶段的情况下我们还没有好的办法来解决可访问性，我们今天讨论的主要围绕视障人士。那接下来让我们看下视障人士是如何来访问页面的：
▐ 视障人士如何使用手机
我们看到视障人士在开启了读屏功能后，通过手指在屏幕上滑动来切换页面中的元素焦点，然后听到相对应的焦点元素的信息来获取页面信息的。所以为了让视障人士能理解我们的产品和业务功能，我们需要在可获得焦点的元素上添加我们的信息。
▐ WAI-ARIA规范
WAI-ARIA是W3c的Web无障碍推荐推进组织发布的可访问互联网应用的实现指南，它主要包含两个部分，role和aria属性，role属性标识了这个Dom元素是做什么的，aria属性描述了与之有关的特征以其什么样的状态。
左下角我们给了一个示例，由于button默认样式等原因，在富应用下我们往往会用div来实现，在缺少语义的div上我们增加了role和aria属性就可以实现对无障碍人士友好的焦点元素，这时候开启了读屏软件后将我们的“签到获取金币”的信息读给用户。
WAI-ARIA规定的可远远不止这些，它是一份非常详尽的能指引我们构建对障碍人士友好页面的技术规范，它给出了各种富应用组件的最佳实践，如slider、checkbox、progressbar等。感兴趣的小伙伴可以去研究下。
▐ 具体实践中如何做
规范本身很复杂，也面面俱到，看到这些估计大部分会望而却步，其实我们至少能做到如上图这些点，我个人认为那你的页面在无障碍化方面绝对可以战胜网络80%-90%左右的页面了。
那我们刚刚讲的都是在Dom层你可以通过ARIA标准来实现无障碍化的方法，然而互动游戏产品很多都是Canvas区域，那我们怎么做无障碍呢？
▐ 游戏中如何实现
游戏中的Canvas层没有像Dom那样的可以被读屏软件读取到的元素，那我们应该怎么做呢？我们可以通过将游戏中可交互的对象，比如我们淘金币场景中的建筑物，我们计算建筑物的坐标、宽高等信息映射到Dom层，通过生成对应的Dom层，并且设置对应的ARIA信息我们就可以实现读屏软件读取了
▐ 最终效果
那我们做了无障碍要如何来验证呢？最简单的方式是我们在手机上打开读屏软件，然后尝试闭着眼睛去使用，当你认为你开发的页面在你没有看的情况下能顺利使用下来就可以认为合格了。
当然国内也有权威的机构来对你的产品来进行评定，深圳信息无障碍研究会就是其中之一，你可以通过提交你的测试产品给到它们，相比我们开发者他们这些用户是真实的视障用户，同时他们在不了解产品功能设定的前提下使用，他们能提出很多建议和优化点非常有价值的。右侧展示了我们产品无障碍化做的效果，大家可以感受下。
当然我们能做的无障碍化的功能可能也很有限，要做好无障碍需要很大的耐心和更多的对于视障人士的同理心，这里只是个简单的演示，感兴趣的小伙伴可以尝试在闭眼的情况下感受下自己开发的产品。
总结