我的js游戏小引擎—— 谈谈 基于dom VS 基于canvas

    迎来html5以后，用js开发游戏迅速火爆起来。但不知是什么原因，大多数游戏开发者会偏好基于canvas来开发游戏，关于这个问题我一直不太理解。

    我想基于canvas开发游戏，绕过dom，最大的好处有三个：

1）可以节省一些dom节点的开销（比如dom自带的一些用不上的属性和方法），应该能省一点内存;

2）不需要浏览器通过dom引擎对dom进行渲染，直接进行像素级渲染，理论上速度应该会快一点;

3）可以减少一些兼容浏览器差异的风险，web前端本来是基于浏览器开发的，基于canvas的话就可以进一步只基于浏览器的一个子集进行开发。

    我一时想不到还有别的什么好处，如果各位有见解，真心求教。如果只有这三点好处的话，这三点好处在绝大多数时候其实看不出太大的差别和优势，但劣势却十分明显——没有了dom和css引擎的帮助。

    我做前端开发很多年了，在这轮大潮来袭之前，我就一直在做web前端的工作，前端的GUI没说的，一定是dom + css，而html5迎来了一个强大的元素canvas，可以无视dom，直接进行像素级操作。这固然是强大的，浏览器已经提供了如此底层的像素级api，只要你够聪明，运用各种算法几乎没有做不出来的效果。但，在给予绝对自由度的同时，也少了很多的帮助，canvas只是一个画布，画布里可以画很多元件，但这些元件其实都只是像素点，没有了dom，css无法使用了，dom的事件监听、冒泡没法使用了，dom的appendChild等等容器的方法全部没法使用了。

    浏览器本来提供了非常好的css和dom引擎，特别是有了css3以后，css对GUI的帮助非常非常大，很简单的一点代码就能实现非常强大的功能。但如果使用canvas的话，相当于主动放弃了这些强大的帮手，什么底层的工作都要自己来实现。

    当然，如果坚持基于canvas开发的话，也可以自己去封装一套东西来模拟dom，比如我去年就写过一个类库CANVASNODE http://hi.baidu.com/cly84920/item/501892dc457a84db251f4095，目的就在于在canvas中模拟一套dom的接口出来。CANVASNODE做了部分工作，效果还行，但其实也只是dom中几个最常用的接口。但，对于css还是完全没有办法——我想不会有谁那么BT，自己用js去实现一套css语法的DSL去渲染canvas里的自定义元件吧。。。

     css可以帮助做什么？画个圆角、投个阴影、实现个旋转（子孙一起旋转）、不影响游戏主循环的动画、换个z-index、overflow:hidden、overflow:auto。。。

     dom可以帮助做什么？append个child、监听个事件、事件冒个泡、阻止个默认事件。。。

     想想，这些事如果让canvas来做，自己去模拟一套类似的东西该有多难，有多辛苦。也许你会说，可以让canvas和dom配合使用嘛，用dom合适的地方就用dom，不合适的地方就用canvas——配合使用肯定是对的，问题是：究竟基于dom还是基于canvas，以哪个为主？

    虽然基于canvas开发游戏现在很流行，但我始终觉得主动放弃dom和css引擎的帮助，是件非常不划算的事情。

     这周时间里，我开发了一个游戏用的底层引擎，是基于dom的，http://www.adanghome.com/js_demo/12/实现了“动画组件”、“主时间轴”、“多边形碰撞”、“容器”等功能。

     舞台有两个儿子：黑色方块和金币mc，黑色方块有一个儿子：绿色方块，绿色方块有一个儿子：爆炸mc。按上下左键控制黑色广场移动,按wasd控制绿色方块移动，按回车键控制黑色方块旋转，按空格键控制爆炸mc旋转。移动时子孙节点会跟着一起移动。红色的方块为多边形的边界顶点，蓝色方块表示旋转基点，可在css中更改方块的样式。

     未来的时间里，我想基于这个基础引擎开发一些游戏，证明html5开发游戏基于dom会更明智。

转载于:https://www.cnblogs.com/cly84920/archive/2012/07/01/4426509.html