阿里自主研发的互动游戏引擎Hilo开源啦！【内有详解】-阿里云开发者社区

Hilo，一套HTML5跨终端的互动游戏解决方案。Hilo支持了多届淘宝&天猫狂欢城等双十一大型和日常营销活动。内核极简，提供包括DOM，Canvas，Flash，WebGL等多种渲染方案，满足全终端和性能要求。支持多种模块范式的包装版本以及开放的扩展方式，方便接入和扩展。提供对2D物理，骨骼动画的内建和扩展支持。另外，Hilo提供丰富的周边工具及开发案例。下文来自一位云栖社区新的朋友，天猫事业部-产品技术部江成的分享。

目前，Hilo已经开源，并入到Hilo Team中。开源地址 https://github.com/hiloteam/Hilo （欢迎Star）

Hilo的特点：

极简内核： Hilo核心模块极精简，保留了2D游戏引擎最必要的模块，同时采用模块化管理。
完善接入&扩展： Hilo 支持多种模块范式的包装版本，包括AMD，CMD，Standalone多种方式接入。另外，你可以新增和扩展需要的模块和类型。
多种渲染方式：提供DOM，Canvas，Flash，WebGL等多种渲染方案，可以做到跨全端，高性能的要求。
完善的周边工具：提供动画编辑器，Yeoman脚手架及典型案例产出的辅助开发工具。
案例丰富：支持天猫，手淘多次大型和日常活动，如双十一，年中大促等。代表产品如狂欢城。

极简内核，完善的接入和扩展

Hilo采用极简的内核。核心模块包括基础类工具（Class），事件系统（EventMixin），渲染（Render）和可视对象（View），如下图所示。

首先，我们来看看如何接入Hilo。

Hilo是模块化的架构，且每个模块尽量保持无依赖或最小依赖。在Hilo的源码中，你看不到一般的模块定义的范式：

取而代之的是，Hilo的每个模块都会有这样的注释定义：

我们使用注释标签@module来标记模块名称，用@requires标记模块的依赖。

在编译阶段，我们会根据这些标记获取模块的相关信息，然后编译生成符合不同的模块范式定义的代码。比如：

我们除开提供一个独立无依赖的版本外，还提供AMD、CommonJS、CMD、CommonJS、Kissy等多种模块范式的版本。开发者可以根据自己的习惯，下载Hilo的不同范式版本使用。

接下来，我们来看看Hilo如何做扩展。

Class.create 是Hilo里创建类的主要方法，如下：

其中：

Extends - 指定一个父类。
Mixes - 指定混入对象。可以是一个Object或Array。
Statics - 指定静态属性。
constructor - 创建类的构造函数。

此外 Hilo 使用 Class.mix(target, [mixinObject])，可以为target混入属性和方法。

代码示例：

再以扩展Hilo的可视对象的基础类View为例。View在表现上就是一个个矩形，无论图片还是文字都可以使用一个最小的矩形包裹。在这些可视对象上做平移，旋转，缩放，透明处理等操作就可以实现普通动画的绝大部分。

如上图所示，View解决了可视对象展示的基本问题。

利用Hilo提供创建类和扩展类的方法，我们可以扩展出可视对象所属管理的Container类：

添加和删除可视对象
可视对象排序
位置对换，可视对象的所属包含判断
由坐标系的位置获取可视对象
根据位置、索引、Id来添加和删除可视对象

类似地，根据不同View的其他展示特性，Hilo扩展出舞台Stage，位图Bitmap，画图Graphic，精灵动画Sprite等类型。

多种渲染方式

我们知道一个游戏运行的核心流程——在一个Loop循环内，接受输入并完成对所有可视对象的游戏属性更新，然后渲染。下面是单个可视对象的一个循环过程：

作为一个可视对象，包含了位置，大小，缩放，旋转等自然信息，如下图所示：

Update是个计算过程，后面赛车案例会讲通过Update我们可以做一些特殊的效果出来。在这之前，我们先看看渲染，即如何根据可视对象的自然信息来把他们 “画”出来。那么如何实现View的render函数呢？如上图所示，在render函数中主要解决两个问题：

位置，尺寸，旋转等变换（transform）
渲染（背景样式，图片，颜色，透明度等）

Hilo首次提出了特别的渲染方案——即提供DOM 、Canvas、 Flash或者WebGL 四种渲染的方式来实现render，目前该方案已经申请专利。这四种渲染方式是和View独立分开的，View在做自身属性更新时完全不需要考虑怎么被“画”出来，同样，拿到View后我们可以使用不同的“画笔”把它描绘出来。如果你有更好的绘制方式，也可以扩展出更多的渲染方案。如下图所示：

View可以粗略分为普通类的View，文字类View（Text）和画图类View（Graphic）几种类型。不同类型的View“长相”不尽相同，在做Update和Render时也要针对处理。

普通类的View，如Bitmap，Container，Button，Sprite，在渲染层面主要处理图片的展示问题。单从图片展示的技术实现上讲，DOM渲染可以通过设置元素的background样式实现，Canvas也有绘图方法drawImage，WebGL则可以通过shader做纹理绑定。

特别地，在Flash的渲染模式下，Hilo首先将View所有和绘图相关的方法通过JSBridge的方式交由适配器FlashAdapter，FlashAdapter来翻译成对应Flash工程实现绘制的方法，如下图所示：

由于Flash在PC浏览器上的广泛支持，特别是IE的支持，使用Flash渲染额外好处就是跨终端，这个终端包括所有主流PC浏览器（包括IE 6，7，8）在内。

另外，在一些低端的手机浏览器上，可以选择DOM渲染模式来代替其他的渲染方式。在Canvas支持不好的机器上或者互动游戏场景本身比较耗性能情况下，DOM渲染模式可以很好地胜任渲染的工作。2015年天猫年中大促的赛车互动，我们就在Android机器上使用DOM渲染的方案。

衍生能力

除了多种渲染模式，Hilo还提供给一些其他衍生能力。这些衍生能力或者来自每次项目的技术改进，或者来自对其他优秀引擎的能力的吸收。例如Hilo支持主流骨骼动画和自建骨骼动画系统（Tahiti），狂欢城多图片下高性能优化，主流物理引擎无缝支持和一些特殊物理效果实现。

骨骼动画

相比较精灵动画（Sprite Animation），骨骼动画（Skeletal animation）使用一套资源就可以完成千万种动作变化。

目前做骨骼动画比较成熟的产品有Spine和DragonBones 。两者在功能上已经接近，考虑DragonBones免费，可自由使用，Hilo实现了对DragonBones的支持。

Hilo也实现了自己的动画编辑器（目前仅内部使用）——Tahiti。Tahiti通过Flash插件的方式实现，目前可以支持CSS3 animation，DOM，Canvas，Hilo动画导出。

骨骼动画将可视对象进行分解，得到一个个可视组件。很显然，这些一个个可视组件本身就是一个个View，只要调整相应的时间片内调整这些View的transform属性，把他们组合起来就是一套完整的动作。

Tahiti将分离出的可视对象扁平化管理，各个部件处于同一层级。借助我们自己实现Flash 插件就可以导出如下的动画数据格式：

Tahiti实现了对导出数据的解析，再借助Hilo的渲染，就可以把设定的动画运行起来了。特别地，Tahiti不仅对接了Hilo的渲染，还可以对接了CSS3 animation，独立JS模式（Canvas）的渲染。

Hilo 骨骼动画 Demo 点这里

性能

一年一度的双十一狂欢城是检验性能的大考。以2015年双十一狂欢城为例，在性能方面主要面临的挑战：

多图：100多商家，每个商家都有品牌Logo
动画：大部分商家需要动态展示Logo，至少3帧精灵动画
单屏：所有的动画需要在一个页面里分屏展示（IPhone 6 plus 下为8屏）

狂欢城预估图片总数为200张（ 252*296），为了优化性能，我们首先对整体画面做了三个分层：

地图部分：此层的资源绝大数为静止画面，内容更新概率低。
Logo展示部分：商家品牌的动态展示区域，一般为3帧的精灵动画。
UI 层：导航，操作UI等。

下面主要看看地图部分的优化。

地图部分多为静止画面，为TiledMap的拼块。由于Canvas大小有限制，同时为了性能考虑，我们把8屏狂欢城界面按512*512分解成多个块，分解方式如下图：

把这些分块独立成一个个Canvas，他们只在首次加载时和内容更改时（比较低的频率）进行渲染，渲染结果保存在这些Cache List中。这个List同时被图示地图Container管理，每次更新时只需要对这些缓存在内存中的List做一次整体渲染即可，这样就避免了成百个view单独渲染的问题，大大的降低了draw的次数。

此外，这些分块在有内容更新时，如上图的脏矩形更新所示，View 2在某一帧有内容更新，那么先找出和View 2 所有相交的view，然后把这些View按照Z轴次序从远及近更新，且只更新其相交部分。这样，便可以最大限度的只渲染需要渲染的部分。

概括地说，我们首先从结构上保证性能，大的方面上做了分层，抽出那些“动”和“不太动”的。其次，我们把view做了分块，把多个的view 更新渲染变成了一个512*512 大小的view 渲染，组成Cache List，然后在交互范围内把Cache List里需要输出的对象渲染到手机真实物理屏。与此同时，在更新Cache List时，为了避免Cache List 内 view对象的全部更新，我们尝试了更新引起变化的最小矩形块。