今天咱们聊聊浏览器里的Canvas，这玩意儿可不是简单的画画那么简单。Canvas这东西，在浏览器里就是个画布，但是它背后的故事可复杂了。
Canvas的基础功能
首先，Canvas这东西，它就是一个基础的绘图API。你在浏览器里看到的那些花花绿绿的图画，很多都是通过Canvas画出来的。它就像是画家手里的画笔，虽然简单，但是能画出千变万化。
Canvas的功能其实挺基础的，就是让你在网页上画画。但是，这个画画可不是随便乱画，它得跨平台，得在不同的设备上都能显示出一样的效果。这就有点难度了，因为每个设备的系统都不一样，Canvas得适配这些不同的系统。
跨平台兼容性的挑战
Canvas要保持跨平台兼容性，这就意味着它不能直接跟当前系统的绘制API打交道。它得通过一些通用的图形封装库来工作，这就多了一层封装。这层封装可不是白加的，它消耗了资源，让Canvas的效率降低了。
这还不算完，为了让这层封装能被JavaScript调用，又得再加一层封装。JavaScript这东西，运行效率大部分情况下赶不上原生的代码，这就导致了第三层消耗。所以，相对来说，Canvas的效率就慢了一些。
Cocos2d和Egret的优化
说到效率，就不能不提Cocos2d和Egret这些游戏引擎。它们可不是在浏览器上加runtime，而是直接使用对应系统的API进行封装和调用优化。这样一来，它们的效率肯定比Canvas要高。
Cocos2d-html5这种在浏览器环境内使用JS封装的库，它最终用的还是Canvas。所谓的效率高，只是你在使用Canvas时，没有做到比它们更优化。比如全局重绘还是局部重绘，绘制数据的cachediff等等。
浏览器的平台性质
浏览器这东西，它就像是一个平台，承载着各种软件运行。它只会提供基础的API，不会提供用户级的高级API。因为用户级API与实际应用场景相关性太强，Canvas就是这样的基础API。
像touch事件这些，也是基础的API。想要用好这些基础API，你得根据自己的业务情况再次封装。如果提供了游戏引擎这种细分领域封装，那就成了游戏机系统了。
设备碎片化的问题
Canvas性能低，其实主要不是因为Canvas本身，而是因为手机设备碎片化严重。早期的手机硬件配置低，内置的浏览器对HTML5的支持不好，导致一个应用开发出来在各个设备上表现不一致。
比如iPhone4只支持elementAudio，而iPhone6就可以用webAudio。有时候在原生浏览器能流畅运行，但是到微信中就卡，是因为微信本身占用了大量系统资源，分配给浏览器的资源不够用了。
Runtime的作用
Runtime其实就是给各机型内置了一套统一的运行环境，再对引擎有针对性的做一些优化来保障运行的。这样一来，应用在不同设备上的表现就能保持一致，不会因为设备的不同而出现卡顿。
总结
Canvas这东西，虽然基础，但是背后涉及到的技术和问题可不少。它得跨平台兼容，得适配各种系统，还得通过JavaScript来调用。这样一来，效率就不可避免地降低了。但是，通过一些优化和封装，我们还是可以让Canvas发挥出更好的性能。
所以，我想问大家一个问题：你觉得在未来的发展中，Canvas会有怎样的变化和进步？欢迎大家留言讨论，点赞和分享这篇文章，让我们一起探讨Canvas的未来！
评论0