殊途同归：游戏引擎和dom在底层握手

消失的重绘逻辑

最近初学egret游戏引擎，我按照之前学canvas开发的经验，去找requestAnimationFrame里不断重绘的逻辑，发现没找到。想了很久没想通，canvas绘制的时候改变了数据需要再次绘制才能看到最新的渲染结果，而这里根本没有重新绘制啊。思考许久，当看到性能面板的帧率时我突然明白了。

游戏引擎和dom渲染的FPS

使用canvas的时候，每一帧的绘制都是我们自己控制的，改变了数据或者绘制的内容，然后重新调用绘制的api来再次绘制，定时通过setInterval或者requestAnimationFrame手动控制。而游戏引擎把定时重绘的逻辑都给封装了，我们只需要去改变渲染的显示对象，下一帧会自动的绘制。两者的区别是一个主动的去绘制，一个在开发的时候只需要改变需要绘制的内容就可以了，绘制一直在进行。

其实这和dom的机制类似，dom也是当我们改变了一个元素的样式的时候，不需要去手动的调用重绘的api，绘制是一直在进行的，打开性能面板，我们可以看到浏览器绘制的帧率，

当我们什么也不做的时候，依然有一定的FPS，当我们进行一些交互的时候，FPS会相应的上升，但是CPU和GPU的计算速度是有上限的，表现出来就是帧率会有上限，浏览器的单线程导致当有大计算量的任务在占用着CPU的时候，帧率就上不去，动画就会卡顿，所以或者把大计算量的任务拆开，比如react的fiber架构，或者开启硬件加速，使用GPU来计算、渲染。

游戏引擎和dom体系的异同

游戏引擎提供了显示对象的一系列api，比如Stage、Sprite、DisplayObjectContainer等，通过他们我们可以组成一颗显示对象树，每一个显示对象都有自己的样式，修改样式，会自动触发重新计算和渲染，就像dom的重排和重绘一样。而且也实现了一套事件的机制，支持冒泡。当然他也有特殊的地方，比如优化了对图片和音视频的处理，提供了一些生成动画的算法等。

殊途同归

最终，dom或是canvas都是操作的一块二进制的数组，dom的方式是浏览器提供的封装好的机制，canvas暴露了底层的绘制能力，游戏引擎是在canvas之上实现了一套类似dom，但又有自己特点的渲染和事件体系。两者思想相同，但一个更重数据展示和收集，一个更重视复杂的显示和交互效果。就像游戏和应用的区别一样。但是，从显存往上看，两者殊途同归。