移动端 webgl 对比 canvas 性能

       最近 h5 游戏火的不行，但是移动端 h5 性能从几年前开始就一直困扰着想要进入这个行业的开发人员，相信性能问题在最近两年依然是 h5 的核心问题。

        h5 的引擎很早以前就有了，以 dom 、canvas、webgl 为核心的渲染技术，但是究竟哪个才能胜任移动平台呢？特别是性能较好的 canvas 和 webgl，哪个更胜一筹？带着这个问题，研究了几款手机 chrome 浏览器上的 canvas 和 webgl 渲染性能。无图无真相，先上一张性能测试图，选了几款中低端 android 手机和 一款 iphone：

各个平台下保持 60FPS 渲染的最大图片个数

           从图中可知在没有任何优化的情况下，android 中 webgl 性能略胜 canvas，iphone 中只有 canvas 的一半。但是如果使用了批处理之后 webgl 各个平台都是完胜 canvas 的，综合来说性能达到 5 - 10 倍。

       有经验的人可能会觉得 webgl 的这个优化技术在实际应用中很难使用，怎么可能把所有的图片都放到一张纹理上，其实不然，再来看另外一个更深入的测试：

        假设可以切换纹理，但是切换纹理的次数不超过 webgl 模式下能渲染的最大图片个数，这句话可能有点绕，打个比方，拿上面的  "小米 2s" 为例子，测试 64 x 64 像素的图片渲染能力，假定可以切换纹理 200 次，小于 webgl 模式下保持 60 FPS 能渲染的最大图片个数 250，那么这样的情况下能渲染多少张图片：

                                           各个平台下保持 60FPS 渲染的最大图片个数

          也就是说我们不用保持一张纹理不变，只要纹理变化的次数不要太多，依然可以渲染非常多的图片。但是这里又存在一个问题，实际情况中很可能会出现纹理连续交替的情况，这样纹理切换次数很快就用完了，其实这样依然是可以优化的，只要图片不是纹理交替且区域重叠的，即纹理交替但图片不重叠，依然可以很好的优化纹理交换次数。

       

       说了这么多，都在说 webgl ，没有提 canvas，canvas 在 chrome 浏览器里面也是 3d 加速渲染的，但是由于不能优化纹理切换次数，所以性能还有提升空间，其实这个依然不是重点，我觉得重点在于目前的 canvas 性能指标是很难支撑一个大型甚至中型的游戏，做过类似游戏的应该都知道这样的一个游戏很可能出现 300 - 500 个 draw。就目前的手机性能来看，canvas 还是有点吃力。过几年软、硬件性能都提升一个档次应该也就无所谓了。

           测试代码已上传 git@github.com:mengjieli/webgl-canvas-testcase.git