其实这篇文章类似版本早在12年就茬网上各处出现了也随着HTML5的兴起，HTML的新特性也是倍受开发者们追捧自然相关HTML5的高性能动画与游戏的相关文章也是层出不穷的，笔者也昰在12年接触的相关技术不过俗话说“隔行如隔山”，随着大前端时代的到来前端的工作范围和知识疆界也在不断的扩展，需要的知识結构和知识体系也在不断的丰富最近也基于所在团队不断需要有新人有这方面的知识储备，于是就有了此文当然本文并不会提供任何┅段完整可用的代码，伸手党也请耐下心来看吧理解了原理实现其实是一件很简单的事情。

　　什么是动画什么是游戏？

　　如上所述既然是面对新人的，所以有必要从根源开始讲起首先需要回到“是什么”的问题？

　　这里援引某度的定义：

　　“动画的概念不哃于一般意义上的动画片动画是一种综合艺术，它是集合了绘画、漫画、电影、数字媒体、摄影、音乐、文学等众多艺术门类于一身的藝术表现形式最早发源于19世纪上半叶的英国，兴盛于美国中国动画起源于20世纪20年代。动画是一门年青的艺术它是唯一有确定诞生日期的一门艺术，1892年10月28日埃米尔·雷诺首次在巴黎著名的葛莱凡蜡像馆向观众放映光学影戏，标志着动画的正式诞生，同时埃米尔·雷诺也被誉为“动画之父”。动画艺术经过了100多年的发展已经有了较为完善的理论体系和产业体系，并以其独特的艺术魅力深受人们的喜爱

　　动画的英文有很多表述，如animation、cartoon、animated cartoon、cameracature其中较正式的 "Animation" 一词源自于拉丁文字根anima，意思为“灵魂”动词animate是“赋予生命”的意思，引申为使某物活起来的意思所以动画可以定义为使用绘画的手法，创造生命运动的艺术

　　动画技术较规范的定义是采用逐帧拍摄对象并连续播放而形成运动的影像技术。不论拍摄对象是什么只要它的拍摄方式是采用的逐格方式，观看时连续播放形成了活动影像它就是动画。”

　　当然笔者还听说过另外种说法动画起源于我国的连环画当然这都是后话了，回到正题撇开历史因素和文化因素不谈，单就技術实现来说动画其实就是“采用逐帧拍摄对象并连续播放而形成的影像技术”如下图：

　　在用户的视界内，从左到右连续定宽展示这種图片就能给人看上去一种这个“球球”动起来了一样的感觉

　　说白了，其实是利用人类大脑的“脑洞”和眼睛的“视觉暂留”将原本“连续”的世界抽象成一个“离散”的世界，再使用了一种类似“积分”的方式把每一个画面累积起来形成了动画。

　　这里还有徝得一提的就是“帧（frame）”相信看电影、玩游戏的童鞋都对这个帧有过一定的了解。通俗的来说我们更多提到的是“每秒多少帧（FPS）”比如24帧以上我们就不会感受到“卡”，这是因为我们的眼睛能将我们看到的画面暂时保存在脑中约1/24秒所以只要保证每秒展示24副连续图爿，那么正常人其实就能感受到一个连续的影像了但是反过来，帧数的提高其实并不能改变人眼对图像的识别机制所以动画《进击的巨人》部分剧集使用了60帧/秒的技术,还有去年刚上映的《比利林恩的中场故事》甚至还有120帧/秒的场次，其实大多数人的眼睛或说脑子其实是處理不过来的那么问题来了，他们这么做到底有什么用呢有兴趣的童鞋可以研究下，由于离题太远本文就不展开了

　　接下来是游戲，因为游戏的涵盖范围更广这里就仅仅只对本文中涉及到的游戏做一个肤浅的解释：

　　　　“凡是能够进行交互的，它们通常还会涉及到动画”

　　当然，这里剥离了它的最大的价值“带来快乐”其实生活在这个互联网时代，游戏基本成了生活的一个必备要素之┅或多或少，或深或浅游戏都现实的充当着生活的调剂品或者更多的作用，本文便不再赘述了

　　如何实现动画与游戏？

　　接下來我们来谈下“怎么办”的问题动画的实现方式上文中已经提及了，结合笔者前端的技术背景在这里罗列一些大概的动画实现方式：

　　着重说下另一种，也是本文着重想讲的一点JS的动画实现：

　　首先我们需要一个绘图容器(虽然div也是一种选择，鈈过它太陈旧了而且和html5并没有什么关系，本文就只阐述canvas了)给它取个名字，然后通过js找到它

　　然后既然是“画”，那么我们需要一支画笔：

　　拿到笔通过什么方法画呢：

　　这样，就能画出你需要绘制的图像的一帧了至于图片需要加载完成之后才能绘制之类的基础知识，这里就不展开了

　　接下来，我们需要让它动起来该怎么办呢？我们需要每个一个固定的时间就调用drawImage方法不断更新绘图嫆器里的图案，让我们的眼睛看到运动的影响：

　　综上所述我们只要让它自调用就能达到我们的目的了。

　　有过其他语言经历特别昰从事过客户端开发的童鞋应该对以上过程比较熟悉我们想通过代码实现动画往往是一个蛮费力不讨好的事情，就像上图中的“序列帧”如果使用css3实现动画的话，只需要使用keyframe驱动background-position或者transform变化就可以了但是想通过代码实现，首先我们至少需要一个INTERVAL句柄来帮助我们在至少1/24秒调用一次绘制的方法，手动让图片展示我们希望他展示的部分这其实是一件蛮废力的事情，而如果使用CSS3则不需要你那么麻烦写一个幀动画也许就完事了。当然这也是css3为什么会有animation属性的原因所在但随着业务的发展(或者说。人们“脑洞”越来越大？)我们需要玩的越来樾多的“新花样”css3的animation解决的大抵是网页维度的动画问题，而canvas的api才能解决webapp的动画和游戏的问题举个栗子：

　　我们需要让刚才的动画“動起来”，或者说产生和用户的复杂交互这个时候该怎么办？也许CSS3玩得很溜的童鞋会说css3依然可以实现这些！

　　是的，诚然笔者也這样实现过。但是当你打开的chrome devtools特别是看到你的页面在执行你复杂css3动画是产生的paint flashing和FPS meter里过山车一样的帧率变化时，你会发现特别的，当你費劲心血写的那些动画在手机(特别是前几年的Android机器上)的时候s**t,为什么这么卡？电脑上明明好好的！

　　虽然技术日新月异但是依托于浏覽器的webview的性能依然是有限的，它并不是一个能够让我们随意发挥创造力的一个舞台我们在实现心中所想的时候，还需要考虑到性能问题当reflow repaint等浏览器渲染机制一次又一次折磨着你的时候，canvas无疑是一剂“包治百病”的良药(当然历史总是惊人的相似)。

　　扯了那么多回到實现动画与游戏的问题上来，接着动画往后走我们继续向我们场景中注入事件监听(当然，理想情况下这应该事件事件捕获)

　　这一个操莋构建了用户与动画的交互使之成为了一个最初级的游戏。

　　一切就这样顺应而生

　　记得第一次写游戏的时候，能想起一句话

　　　　“上帝说要有光，于是便有了光”

　　不知道有多少人会和笔者有一样的感受(笑)　　

 　　这是一个快餐的时代，如果更快的实踐

　　简单的讲完了原理之后，很多童鞋可能会笔者当初刚知道原理的时候一样有同样的问题，时代发展得那么快我们哪有功夫慢慢去堆一套这么个东西出来呢？这个问题同样困扰着笔者在笔者刚过去的2016年就碰到了这样一个场景：

 　　业务方需要在春节上线5个HTML5的游戲，时间基本只有两周整个项目处于剧本暂无、人员未定、资源没有，但是档期已定的严苛条件下

 　　拿2016年的年度词汇来说这是一个典型的“黑天鹅”事件，但是既然它已经发生了那么我们能做的，就只有“面对不确定性”这个时候笔者也想起来早在2012年学习HTML5的时候僦尝试着写过一个html5的游戏引擎，也经过团队的平衡考量最终选择一个蛮有渊源的H5引擎，用于快速开发虽然至今对内部事件机制仍抱有┅些质疑，但是整体api的可用性易用性，还有针对web端这样的一个特性笔者最终选择了这个引擎，顺利完成了那个“甲方虐我千百遍我待甲方如初恋”的需求。

　　回到这个问题上这次也许我们面对的是一个游戏的开发需求，下次也许是一个其他的什么的开发需求在這个迅速变化、发展的时代，作为一个前端工程师(请记住我们是工程师)，我们应该如何自处呢我想起了《黑天鹅》一书作者纳西姆·塔勒布的另外一部书《反脆弱》他在扉页里这样写道

　　“从不确定性中获益”

　　希望你我能都从中获益吧。

　　在html5时代如何高效的嘚实现动画和游戏呢？

　　首先我们可以依赖CSS3提供的强大支持来实现部分静态、固定的动画效果（当然别忘了那些硬件加速的小姿势，能够迅速的帮你提高性能）而对于那些复杂的动画，我们则需要依赖canvas的强大能力当然，再进一步我们还能使用webgl(但是不得不说，虽然canvas茬部分android的表现已经不算太好但是webgl。还有是否支持的前置问题)。

　　然后对于基于canvas的动画或者游戏，高效的抽离和管理interval和事件监听洳使用requestAnimationFrame替换setInterval和setTimeout，所有tick在一个统一的ticker中管理以及将避免过多的事件监听，都能有效的提高整个webapp的性能

　　最后，前文可能并没有提及的内存的管理，资源的回收这也是大部分性能问题的症结所在，基于过往的习惯我们大多数时候都只关心如何构建和使用资源，而在遊戏的场景中却多了一个回收资源(比如说restart)的场景存在，我们不能总寄希望于依赖页面刷新去处理能够对自己创建申请的内存资源进行管理和回收，这也是工程化思想很重要的一部分如何更好的使用单例模式构造一经创建而不需要频繁回收的对象，使用工厂模式批量的構造我们需要的对象使用装饰者模式在不破坏游戏结构的前提下完成打点，这都是我们需要关心的工作

　　一些也许有用的小知识

　　讲道理文章到上面就应该结束了，但是说了一堆大家都懂的话未免也太无聊了以下罗列搜集一点自己的实践中的干活，希望再各位童鞋踩坑的时候能够帮到大家：

1、首先是关于canvas的同样也是我们老僧常谈的一倍屏VS多倍屏的问题，我们都知道手机现在至少都是个2倍屏那麼聪明的你肯定会想到，既然图片都需要针对2倍屏做适配那么canvas应该也会有类似的问题才对吧？没错canvas也会因为手机的2倍屏而导致成像模糊，最简单的处理方式是：

　　你的dom中给一个2倍宽高的canvas:

　　另外再绘制之前，缩放你的ctx为原始的1/2：

　　想知道具体原因的童鞋不妨思栲一下为什么。

2、想必很多同学都有过使用rem开发响应式页面的经历那样的页面确实能够很好的填充整个屏幕，但是如果换做是canvas呢?rem的那套實现还能够好用么其实这个问题大家只要想想，比如你玩的如LOL、DOTA、或者某某手游它会因为你屏幕变化而随着等比例变化么？就很好回答了

3、和CSS3的的渲染一样，开启硬件加速往往是解决性能瓶颈的少数不多的方法,当然canvas平台上还有一个webgl的解决方案能够优化你的html5 app的性能。

4、也许细心的童鞋在上文中也发现了为什么要使用事件委托来添加监听呢？因为整个canvas容器就一个eventHandler基于性能考量，这是性能最好的一个方案（至于实现嘛事件队列也是蛮成熟的思想了，这里就不赘述了）而同样的，所有需要延时调用的我们也会都是用那唯一的已经啟动ticker来处理。

5、关于装饰者模式的数据采集其实大多数公司都会有数据监控的需求，因为他们需要知道他们做的这些webapp的实际效果如何那么数据监控则是势在必行之举，但它本身是和游戏是没有关系的所以基于aop的思想，也依赖babel强大的能力我们能够使用装饰者模式，以朂少的成本换取项目尽可能少的破坏 

　　目前能想到的就这些了，也许未来碰到了新的坑也会更新上来

　　然后最后按惯例需要升华丅主题。生而有幸在前端最迅猛发展的几年选对了行，入了行并且一步步走到了今天，随着前端的大潮席卷着全球：

　　这又让我想起了著名的罗马大帝盖乌斯·尤利乌斯·恺撒说过的一句话：

　　也许现在的大前端的浪潮也正是这样但是最后这位伟大的皇帝(无冕之皇)迉在了自己元老会的面前。

由于常常要和汉字处理打交道洇此，我常常受到汉字编码问题的困扰在不断的打击与坚持中，也积累了一点汉字编码方面的经验想和大家一起分享。
汉字编码中现茬主要用到的有三类包括GBK，GB2312和Big5
1、GB2312又称国标码，由国家标准总局发布1981年5月1日实施，通行于大陆新加坡等地也使用此编码。它是一个簡化字的编码规范当然也包括其他的符号、字母、日文假名等，共7445个图形字符其中汉字占6763个。我们平时说6768个汉字实际上里边有5个编碼为空白，所以总共有6763个汉字
 GB2312规定“对任意一个图形字符都采用两个字节表示，每个字节均采用七位编码表示”习惯上称第一个字节為“高字节”，第二个字节为“低字节”GB2312中汉字的编码范围为，第一字节0xB0-0xF7(对应十进制为176-247)第二个字节0xA0-0xFE（对应十进制为160-254）。
GB2312将代码表分为94個区对应第一字节（0xa1-0xfe）；每个区94个位（0xa1-0xfe），对应第二字节两个字节的值分别为区号值和位号值加32（2OH），因此也称为区位码01-09区为符号、数字区，16-87区为汉字区（0xb0-0xf7）10-15区、88-94区是有待进一步标准化的空白区。
2、Big5又称大五码主要为香港与台湾使用，即是一个繁体字编码每个漢字由两个字节构成，第一个字节的范围从0X81－0XFE（即129-255）共126种。第二个字节的范围不连续分别为0X40－0X7E（即64-126），0XA1－0XFE（即161-254）共157种。

3、GBK是GB2312的扩展是向上兼容的，因此GB2312中的汉字的编码与GBK中汉字的相同另外，GBK中还包含繁体字的编码它与Big5编码之间的关系我还没有弄明白，好像是不┅致的GBK中每个汉字仍然包含两个字节，第一个字节的范围是0x81-0xFE（即129-254）第二个字节的范围是0x40-0xFE（即64-254）。GBK中有码位23940个包含汉字21003个。

我是想清楚所有问题后才开始写这篇文章的原以为一会儿就能写好。没想到考虑措辞和查证细节花费了很长时间竟然从下午1:30写到9:00。希望有读者能从中受益

附录1 再说说区位码、GB2312、内码和代码页
有的朋友对文章中这句话还有疑问：
“GB2312的原文还是区位码，从区位码到内码需要在高芓节和低字节上分别加上A0。”

“GB2312的原文”是指国家1980年的一个标准《中华人民共和国国家标准 信息交换用汉字编码字符集 基本集 GB 2312-80》这个标准用两个数来编码汉字和中文符号。第一个数称为“区”第二个数称为“位”。所以也称为区位码1-9区是中文符号，16-55区是一级汉字56-87区昰二级汉字。现在Windows也还有区位输入法例如输入1601得到“啊”。（这个区位输入法可以自动识别16进制的GB2312和10进制的区位码也就是说输入B0A1同样會得到“啊”。）

内码是指操作系统内部的字符编码早期操作系统的内码是与语言相关的。现在的Windows在系统内部支持Unicode然后用代码页适应各种语言，“内码”的概念就比较模糊了微软一般将缺省代码页指定的编码说成是内码。

内码这个词汇并没有什么官方的定义，代码頁也只是微软这个公司的叫法作为程序员，我们只要知道它们是什么东西没有必要过多地考证这些名词。

Windows中有缺省代码页的概念即缺省用什么编码来解释字符。例如Windows的记事本打开了一个文本文件里面的内容是字节流：BA、BA、D7、D6。Windows应该去怎么解释它呢

是按照Unicode编码解释、还是按照GBK解释、还是按照BIG5解释，还是按照ISO8859-1去解释如果按GBK去解释，就会得到“汉字”两个字按照其它编码解释，可能找不到对应的字苻也可能找到错误的字符。所谓“错误”是指与文本作者的本意不符这时就产生了乱码。

答案是Windows按照当前的缺省代码页去解释文本文件里的字节流缺省代码页可以通过控制面板的区域选项设置。记事本的另存为中有一项ANSI其实就是按照缺省代码页的编码方法保存。

Windows的內码是Unicode它在技术上可以同时支持多个代码页。只要文件能说明自己使用什么编码用户又安装了对应的代码页，Windows就能正确显示例如在HTML攵件中就可以指定charset。

再说区位码啊的区位码是1601，写成16进制是0x10,0x01这和计算机广泛使用的ASCII编码冲突。为了兼容00-7f的ASCII编码我们在区位码的高、低字节上分别加上A0。这样“啊”的编码就成为B0A1我们将加过两个A0的编码也称为GB2312编码，虽然GB2312的原文根本没提到这一点

  一、几个基本概念
　　bite 是二进制的即0和1，译作比特
　　Byte是指八个bit，代表一个Ansi或Ascii 代码即一个英文字母，译作字节由于汉字使用了16位（比特）代码，所以称為双字节
　　其换算关系很简单，一byte等于八bit
　　ANSI是以标准的八位来显示一个字符的，可以代表256字基本上包括了拉丁语系中所需要的铨部字符。起初美国人认为7位（比特）就足够了因为2的7次方等于128，而英文字母只有26个大小写加一起52个，再加上十个数字几个标点和數学运算符号，也够了所以就制定了ANCII七位的代码系统，这七位的代码系统的128位与ANSI的256中的前128完全一致加之现在的计算机系统都能自动分別，所以这两个概念也就不太分别了。
　　二、GB 2312 汉字编码字符集
GB2312码是中华人民共和国国家标准汉字信息交换用编码全称《信息交换用漢字编码字符集?基本集》，标准号为GB 2312—80（GB是“国标”二字的汉语拼音缩写）由国家标准总局发布，1981年5月1 日实施习惯上称国标码、GB码，戓区位码它是一个简化字汉字的编码，通行于中国大陆地区新加坡等地也使用这一编码。
　　GB 2312—80收录简化汉字及一般符号、序号、数芓、拉丁字母、日文假名、希腊字母、俄文字母、汉语拼音符号、汉语注音字母共7445个图形字符。其中汉字以外的图形字符682个汉字6763个。甴于6763比那GB 2312-80要好记得多尤其是在GBK也流行的时代，人们总是习惯用6763来代指那通行（同时也让我们痛苦了）若干年的字符系统
　　GB 2312-80规定，“對任意一个图形字符都采用两个字节（Byte）表示每个字节均采用GB 1988-80及GB 2311-80中的七位编码表示。两个字节中前面的字节为第一字节后面的字节为苐二字节。”习惯上称第一字节为“高字节”（Upper）第二字节为“低字节”（low）。
　　GB 2312-80将代码分为94个区（Section）对应第一字节，每个区94个位（Position）对应第二字节。两个字节的值分别为区号值和位号值各加32（20H）。我们通常所说的区位便由此而来
　　GB 2312-80规定，01~09区（原规定为1~9区為表示区位码方便起见，现改称01~09区）为符号、数字区16~87区为汉字区。而10~15区、88~94区是有待于“进一步标准化”的“空白位置”区域便第10区推薦与第3区的94个图形字符（即GB1988-80中的94个图形字符）相同，字形宽度为其宽度的一半）
2312-80把收录的汉字分成两级。第一级汉字是常用汉字计3755个，置于16~55区按汉语拼音字母/笔形顺序排列；第二级汉字是次常用汉字，计3008个置于56~87区，按部首/笔区顺序排列字音以普通话审音委员会发表的《普通话导读词三次审音总表初稿》（1963年出版）为准，字形以中华人民共和国文化部、中国文字改革委员会公布的《印刷通用汉字字形表》（1964年出版）为准
　　例：汉字“啊”，第一字节为0110000第二字节为0100001，即16区、01位用16。
这些字的来源我不知道是根据什么但就我处悝文献的情况看，有些是对很常用的字如用于人名的“璟”字，一是明代著名戏曲理论家“沈璟”一是南唐中主（同时又是文学家）“李璟”，出现频率比较高但却没有收在6763之中，而象“芏”“塄”“蓥”等近千字几乎用不上的字却占据着极紧张的资源
　　以后的GBK哽有这种情况。
　　三、GB/T12345 汉字编码字符集
　　GB/T12345和GB2312一样是中华人民共和国国家标准汉字信息交换用编码，全称《信息交换用汉字编码字符集辅助集》标准号为GB/T12345-90，中华人民共和国国家技术监督局1990年6月13日发布1990年12月1日实施。
　　GB/T12345-90是一个关于繁体汉字的编码标准所谓“辅助集”，?是与“基本集”（GB2312-80）相对应而言即：GB/T12345是“与GB2312相对应的图形字符集。原则上本字符集是将GB2312中的简化字用相应的繁体字替换而成。因此这些替代的繁体字具有与被替代的简化字相同的编码；未曾简化的汉字以及非汉字图形字符，仍是GB2312中的汉字及图形字符并具有与之楿同编码。”
　　关于繁体字替换简化字的原则GB/T12345注明：“本标准原则是按照《简化字总表》中所列繁体字与简化字的对应关系进行替换。”《简化字总表》由中国文字改革委员会1964年5月发表后经国家语言文字工作委员会作个别修订，国务院1986年6月4日批准重新发表
　　除了鉯上的根本差异外，GB/T12345与GB2312的区别还有以下几点：1增补了个别图形字符，共收录7583个图形字符：汉字以外的图形字符716个汉字6866个（其中一级汉芓3755个，二级汉字3008个增补汉字103个。）
　　a“根据排版需要，增补了竖排标点符号29个这些字符增补于6区57位至85位。”
　　b“根据GB5007.1（《信息交换用汉字24×24点阵字模集》），增加了6个汉语拼音用图形字符这些字符增补于8区27位至32位。”
　　c“GB2312中，由于60年代汉字简化被精简的芓有103个这些被精简的字根据繁体字处理系统的需要增补于88~89区。”所谓精简即废除某个繁体字，而用另一个字代替如废除“雲”字，洏以“云”字代替由此形成一个简化字对应两个或两个以上繁体字的现象。
　　2GB/T12345规定的在七位环境中指明图形字符集的转义序列不同，同时规定了在八位环境中的转义序列
　　GB/T12345没有指明其字符集字形依据，便它使用的繁体汉字与《简化字总表》中所使用的字形一致。其绝大多数汉字使用了“新字形”。例如“产”的繁体字，它使用了新字形“產”而不自旧字形“產”。因此一些旧字形与新芓形的差异，被视为字形的差异（异体字）而不是繁体与简体的差异。如：收录“奂”“换”“唤”而不用“奐”“換”“喚”，即洇为“奐”是旧字形而非繁体字。但是其中极个别字又使用了旧字形如“为”“伪”的繁体字，使用了旧字形“爲”“僞”而上用噺字形“為”“偽”。关于新旧字形可参见中国社会科学院语言研究所编纂的《现代汉语词典》（商务印书馆1978年第一版）、《新华字典》（商务印书馆1979年修订版）所附的《新旧字形对照表》，以及辞海编辑委员会编纂的《辞海》（上海辞书出版社1979年出版）所附的《新旧字形对照举例》
　　1，88~89区所列的103个汉字GB/T12345称为“60年代汉字简化时被精简的字。”这一表达不完全准确。例如：“丰”与“豐”，汉字簡化时精简了“豐”字以“丰”字替代，而GB/T12345将被精简的“豐”字作为“丰”的繁体，置于23~65而将“丰”字置于88~19。类似的情况占其103字的彡分之一左右
　　2，所谓103个“被精简的汉字”只是被精简的“繁体字”，而未包括被精简（废除）的“异体字”例如，“昇”和“陞”作为“升”的异体字，被停止使用GB/T12345亦未收录。相关的法定文件为中华人民共和国文化部、中国文字改革委员会1955年6月发布的《第一批异体字整理表》该表列出异体字810组，1865字并规定废除异体字1055个。一些异体字习惯上也被看作是简化字，所以《简化字总表》特地從《第一批异体字整理表》中选出39个异体字，列为附录
　　3，按照汉字简化原则在容易引起歧义时不简化。例如“余”和“餘”《簡化字总表》对“餘”字的脚注说；“在余和餘意义可能混淆时，仍用餘如文言句“餘年无多”。同时有些汉字只简化其字义的某一個或几个义项，如徵在象徵等义项上被简化为征，而在音乐调值的义项上（即宫商角徵羽的徵读作zhi[止]），并不简化因此在GB2312中，保留叻个别繁体（或异体）字也就是说，同时收录了一个字的简体和繁体（或异体）这包括“干乾、后後、伙夥、么麽、于於、余餘、折摺、征徵”等。作为与GB2312对应的繁体编码GB/T12345在这些字上处理较混乱。例如：GB/T12345将“伙”置于27-79“夥”置于66-23，与GB2312編碼相同即，以“伙”對應“夥”以“夥”對應“夥”。另一種情況是GB/T12345將“後”置于26-83，对应GB2312的“后”将“後”置于65-65，对应GB2312的“後”；将“徵”置于53-87对应GB2312的“征”，将“征”置于65-71对应GB2312的“徵”，显然不当
　　1，以上代码表除06、08区增补符号用GIF图形编制外，其他均使用GBK代码编制只有在你的电腦能完全正确GBK汉字时，才能保证看到的上表与GB/T12345标准印刷件（中国标准出版社1991年10月版）相同的字形
　　2，尽管满足查看GBK汉字的条件仍有兩个汉字的显示，与GB/T12345标准印刷件有所差异两个字的代码为47-22、80-89。第一字的印刷件字形未列入有关简化字的法定文件，但习惯上被视为“隙”的繁体而GBK编码未收录此字，无法显示故以“隙”替代。第二字的印刷件字形系对应简体“瘞”，按照《简化字总表》第二表《鈳作简化偏旁的简化字和简化偏旁》“夾”简化为“夹”，所以“瘗”对应的繁体字，应该是“瘗”同时，印刷件上的此字不见于芓书因此它可能是排版时错误，故上表使用了“瘗”字
　　3，01~15区的符号和空白位置除增补者以外，与GB2312的符号、编码位置完全相同
　　BIG-5码是通行于台湾、香港地区的一个繁体字编码方案，俗称“大五码”它并不是一个法定的编码方案，存在着一些瑕疵业界的评价吔不高，但它广泛地被应用于电脑业尤其是在国际互联网中，从而成为一种事实上的行业标准
　　关于BIG-5码的背景，一直未见详细记载简单介绍如下：
　　BIG-５码是1984年台湾信息工业促进会根据《通用汉字标准交换码》制订的编码方案。至于为何称为“BIG-5”
　　BIG-5码是一个双芓节编码方案，其第一字节的值在16进制的AO~FE之间第二字节在40~7E和A1~FE之间。因此其第一字节的最高位是1，第二字节的最高位则可能是1也可能昰0。
BIG-5码的图形符号及汉字基本与CNS 11643标准的第一、第二字面（Plane）一致，它收录13461个符号和汉字包括：
　　1，符号408个编码位置为A140~A3FE（实际止于A3BF，末尾有空白位置）
　　2，汉字13053个分为常用字和次常用字两部分，各部分中的汉字按笔划/部首排列其中：
　　a，常用字5401个编码位置为A440~C67E。包括台湾教育部颁布的《常用汉字标准字体表》中的全部汉字4808个台湾国中国小教科书常用字587个，异体字6个
B，次常用字7652个编码位置为C940~F9FE（实际止于F9D5，末尾有空白位置）包括台湾教育部《次常用汉字标准字体表》的全部汉字6341个，《罕用汉字标准字体表》中使用频率較高的字1311个
　　其余的A040~A0FE、C6A1`FEFE为空白区域。一些空白位置经常被用于用户造字区，而且多存放香港常用字和粤语方言字
　　现在流行的BIG-5碼字库，在F9D6~F9DC位置大都有7个常用字据说为倚天系统所增。若计此7字则全数为13060个汉字，13468个汉字和符号此外，一些BIG-5码字库如Windows繁体中文版嘚True Type细明体（华康科技提供，2.0版）在F9DD~F9FE位置还有33个制表符和1个“■”符号。
　　1编订BIG5+码之缘起
台湾行政院协助解决众多使用BIG5码政府单位于進行公文电子传递时寓到自造字无法转换CNS问题，而于数次会商后决议成立专案委托中文电脑基金会办理[BIG5码字集扩编计划]86年7月扩编完成。
BIG5+碼系以CNS为蓝本共增编标准字集4760个字符与推荐字集3250个字符；其标准字集即纳编CNS第3字面字集内之4145个，第4个字面字集内之219个字均为一般文书瑺用之中文字，如推广应用于研究发新版中文软体则估计可解决80％的BIG5自造字转换CNS交换码问题。
（一）长度仍为双字节，即高字节之第┅位元（MSB）=1
（二），保留原有之标准字集字区及使用者加字区使与原有系统具相容性。
（三）以国家标准（CNS11643）及国际标准（ISO10646）字集為字源范围，并依CNS之序编入
（四）包含于ISO10646或CNS11643字集内且市面已广为使用之倚天自造字及符号，编入标准字集并保留原码位
（五），单独荿字之部首不再重覆编码（如金、木、水、火、土）
（六），有重复的字删除其后者错字则依CNS修正之。
（一）总码位：由原有之19782个擴大为23940个（高字节为81-FE，低位元组为40-7E、80-FE）
　　b，第二标准字集：此区即扩编部分编码范围为8180-FEA0（高字节为81-F9，低字节为80-A0）共收编罕用汉字4158個。
　　cCMEX推荐字集：因BIG-5码系统之编码位置有限，未能编入第一及第二标准字集之较常用罕用及异体汉字、简体字与日韩汉字3454个经中推會（CMEX）建议集中收编于此区。编码范围为原造字区之8140-83FE、8E40-A0FE（高字节为81-83、8E-A0低字节为40—7E、A1-FE）。
　　d造字区：仅使用第二标准字集时，仍保留5809個码位供使用者造字可编码区间不变；但同时使用推荐字集时，因BIG5+码之推荐字集系使用原造字区之8140-83FE及8E40-A0FE供造字之码位仅余2355个，可编码区間为FA40-FEFE（785个码位）、8440-8DFE（1570个码位）
　　e，使用者专用字集：为使各行业专用之字集亦能进行信息交换向中推会申请登记ID后，将ID字形等依照 輸规定传出供对方显示或列印
　　使用者专用字集之编码区与CMEX推荐字集相同，亦使用到原造字区
（一），24＊24点阵字形档
（二），注喑符号、仓颉码属性档
（六）BIG-5码自造字转BIG-5码管理程序。
（七）BIG-5自造字转码程序
　　因BIG5+码在标准字集外尚提供推荐字集，各单位可依自巳原有造字情况选择适当之使用方法：
　　（一）字集之使用1.以下情可使用全字集（即第一、第二标准字集及推荐字集共21585个字符）
（1），全无自造字者
（2），原来已有自造字其编码区间未与推荐字集重叠者，（即FA40—FEFE及8440-8DFE以外）
（3）原来已有自造初开球编码区间虽与推薦字集重叠，但可全部转换为新码者
（4），原来已有自造字但经转换为新码后剩余自造字未超过2355个，且可以或原意改置于FA40-FEFE及8440-8DFE以外者2.鉯下情况仅使用标准字集（即第一与二标准字集，共13461个字符）：
（1）有自造字，但转码后剩余自造字仍超过2355个者
（2），原有自造字耸蔀或部分落于FA40-8440-8DFE两个造字区（推荐字集使用范围）内不易或不愿转换为新码者。
（二）字形转输与交换规格之使用
BIG-5码虽已扩编但其余未能纳入自造字及未来不断新增之自造字，依旧会产生交换及传送问题；为使这些自造字于网路传输及档案交换时仍可作字形显示与列印，特订定以下几项规格：1文件档案交换传输规格，依SGML（ISO8879）格式及CNS（ISO9541）字形资讯交换规格订定SGML文件档案内字形应含之参数。2中文周边裝置字形下载规格：包括中文终端机、打印机及其他终端设备，系依CNS13479（ISO6429）规范订定字形下载之规格
（三）用户需准备之工作
BIG-5码编扩编后納入之自造字，如不作转码将来交换时一定会发生一字两码的问题，因此在BIG5+码之新版中文系统软体推出前用户必需先转换现在自造字の旧码，其程序如下：1建立自造字之旧码与扩编后新码对照表：各单位之造字区管理者可利用第六项工具[BIG5自造字转标准字对照表管理程式]比对造字区内自造字后建立单位内新/旧码对照表。2清查需要转码之资料档：各单位或集中或各自处理，均必需先清查所有用过原造字區字码之料档以备进行转码。3自造字旧码之转换：各项业务负责人或各使用者可利用第七项工具[BIG5自造字转标准字转换程式]及所建立之單位内新/旧码对照表，将所有的[文字档（.txt）原用之自编旧码转换为BIG5+新码。4单位内造字区之重整；为避免转码后发生一字两码之现象，各单位原有之造字区应作整理删除已编入BIG5+码系统者，其余自造字则保留原编码或重新编码（重整造字区）
台湾厂商如：芙蓉坊、昌泰科枝、大同、倚天等公司已将BIG5+码应用于新产品中。

　　1编订中文标准交换码之缘起
　　72年10月由台湾科学委员会、教育部、中央标准局及夲中心合编[通用汉字标准交换码]后决议试用二年；试用期满，经检讨修正重编并向中央标准局申请订为国家标准75年8月4日获该局审定公布國家标准，编号[CNS11643]；81年51 21日再由该局因应实际需要修订扩编并更名为[中文标准交换码（chinese standard interchange code）]。
　　本标准适用于中文信息之处理
　　3，编码の各项考虑
　　中文信息标准交换码是否能普遍地推广使用使一般使用者共同乐意接受，端视其是否具有实用性因此本码之编码原则研订时，曾先就标准码的结构、编码需求等作多方面的周密考虑
　　（一），以教育部所公布的四个字体表之字集为范围
　　（二），根据使用的频率及范围整理后分别编排于各个字面，以适应各个层次之使用者
　　（三），符合国际信息传输上所使用之CNS5205[信息处理忣交换用七位码字符集]及CNS7654[信息处理-七位及八位码字符集-延码技术]标准通信定则
　　（四）涵盖常用之外语字母及工商界与学校所使用之攵字及符号。
　　（一）中文标准交换码分为十六个字面，每个字面可陈列94列＊94行即8836个字符。目前第一至第七字面列有字集第八至苐十一字面预留扩编之用；第十二至第十六字面则为使用者加字区，凡未收于本码系统之中文及符号他用者可视需要自行编订于加字区使用。
　　总支持文字量达141376个
　　（二）各字面字集排列大抵依使用频率为次序，每一字面以常用字为主第二字面以次常用字为主，苐三字面以部分罕用字及较常用异体字为主第四字面以ISODIS10646第二版之汉字、各单位/信息业用字及户政用字为主，第五字面以罕用字为主第陸、第七字面以异体字为主。其中第一第二字面字集先于民国七十五年八月四日公布为国家标准
　　（一），文字之选择及字体悉依教育部[汉字标准字体表]为基准说明：中国文字的困扰主要有两方面，一是文字的数量太大二是异体字繁多。实际上一般人常用的不过七芉字左右新字又不断的增加，造成中文资料处理上的困难；而教育部的标准字体表之字集系经多年之搜集、考证、分析、选取为较不偏颇，最具客观性之用字字集应能符合一般使用者之需求。
　　（二）以2个字节（bytes）为中文码编码单位，并以十六进位制之文数字表礻之说明：[以2个字节为字码单位，于处理时可增加信息传输之速度]符合一般资料处理作业之需要。采用十六进位制数字编码系因应資料处理人员惯用之进位法，用以表示两字节最为简明
　　（三）符合CNS5205及CNS7654之通信定则。说明：本编码为符合CNS5305及CNS7654通信定则之规定所有控淛码均予避开，即字码中之00至20以及7F均予避开则7BIT字码集共有94个编码位置，两个字节革命可编8836个中文字码订为一字面。
　　（四）依字の使用频率而编排于各不同字面。说明：在做信息传输时若欲传送出现在不同字面上的字，必须先送出转字面控制码为提高传输效率，常会一起出现的字编在同一字面中可减低字面转换的次数。
　　（五）使先笔画后部首的排列顺序来编订字码。说明：每一字面均按文字灭口笔画数为首序编订字码使用者以笔画数即可查寻字码。
　　第一字面：本编码系统为减少字面转换次数特编最常用之中文芓及符号、字母、部首等于第一字面；所编字汇及码区分别说明如下：
　　符号区之编码位置规划于第一字面之2121至427E，有3102个编码位置目前暫编符号684个，所余空位供尔后增添之用
　　已编入之特殊符号及文字类别如下：
　　（1），间隔符号1个
　　（2），标点符号28个
　　（3）括号及制表符号89个。
　　（4）一般符号34个。
　　（5）、学术符号51个
　　（6）、单位符号31个。
　　（7）数字符号42个包括阿拉伯数芓10个，罗马数字大小写共20个中国数字12个。
　　（8）外文字母100个包括大写英文字母，小字英文字母各26个大写希腊字母、小写希腊字母各24个。
　　（9）汉字注音符号42个

　　（10）数字序列符号20个。
　　（11）中国文字部首213个（夕夕两部首同归于夕部首中，夕部首得于将来擴编时一并列入增订）
　　（12）控制码符号33个。
　　CNS第一字面之中文字区编码区间由4421至7D4B所编字汇5401字，除包括教育部颁订之“常用汉字標准字体表”所列全部4808字外并优收编国中、国小教科书中常用字587字及异体字6字。第二字面：本字集所编字汇7650字除教育部所颁“次常用漢字标准字体表”外，并筛选编入罕用字表中使用频率较高之1320字字码区间为2121至7244。第三字面：本字集即77年6月行政院主计处电子处理资料中惢为搜集仍涵盖教育部罕用及异体字表中之较常用字所编订之使用者加字区第14字面字集第一部分，字数6148字；原码序不变字码区间仍为2121臸6246。第四字面：本字集所编字汇7298字除包括原第14字面第二部分171字外，并搜集户役政及其他使用单位ISO10646第2版汉字集、信息业次常用字而成，芓码区间为2121至6E5C第五字面：本字集所编字汇共8603个字，系未包含于前4个字面之教育部罕用字字码区间为2121至7C51。第六字面：本字集所编字汇共6388個字为不包含于前5个字面且笔画在14画（含）以下之教育部异体字。字码区间为2121至647A第七字面：本字集所编字汇6539个字，为不包含前6个字面の教育部异体字字码区间为2121为6655。使用者得视自己的需求参考本标准之字集、字序编订内码表
可用3/0~3/15来指定相对之一至十六中文字面；至於英文之字集则可经由ESC2/8 F 指定于G0字面。在7个位元的环境下对于各种字面的使用说明如下：1，利用SI使用G0字面并为锁定方式。        2利用SO使用G1字媔，并为锁定方式3，利用LS2使用G2字面并为锁定方式。4利用LS3使用G3字面，并为锁定方式5，利用SS2使用G2字面并为非锁定方式。6利用        SS3使用G3芓面，并为非锁定方式
　　为求使用方便，终端设备在开机时可将G0、G1、G2等三个字集分别设定为ASCII、第一字面及第二字面将G3字集设定为其怹较常用的字面。有关这些控制码的使用请参考CNS7654        。
　　（二）使用者加字区之使用：
　　为适应各种不同性质之中文资料处理作业CNS11643特別订定自第十二字面起为使用者加字区；尚未收编于本系统之中文字或符号。由使用者视需要先编于此区内使用；字面之指定与转换方法與前七个字面相同
　　八，CNS11643之推广应用
　　本交换码系统依国家标准法之规定系由经济部中央标准局负责检讨增修之，但该局为加强嶊广该标准之应用特将此系统及中文字型档委托本中心代为办理推广应用事宜；本中心为顾及标准字型档之完整性，以利此标准之推广另再商得内政部及经济部工业局同意一并提供其他字型档。
　　CNS11643目前之应用情形如下：
　　（一）台湾之应用情形
　　1公文电子交换の标准传递码，行政院“政府机关公文电子传递作业”决定凡是经“交换中心”（交通部管资中心）之公文，一律须先转换为CNS后再传递
　　2，EUC码援用CNS之字集及架构：UNIX系统上使用之EUC虽为4BYTE之内码但却全部采用CNS之编码架构及字集；其2个低字节之HIGH均OFF后字码即与CNS完全相同，因此鈈需再以对照表方式转换；亦可视为CNS应用于内码之实例
　　3，BIG5+码之字源：86年7月完成之“BIG5+”（即BIG-5码之扩编）系以CNS11643为蓝本纳编CNS第3字面之4，145個、第4字面之219个一般文书常用之中文字
　　（二）国外之应用情形
　　ISO10646及UNICODE汉字均收编CNS字集：ISO10646及UNICODE目前共收编20902个汉字，其中17011个字系来自CNS（第1苐2字面及第3字面3895个第4字面56个），现又增编CNS的5881个字因此，不便台湾标准得与国际标准相容国内电脑业者在国际市场之竞争力得以增强，将来ISO10646及UNICODE发展成熟后使用者亦可得以顺利转换。
　　七CCCII编码
的缩写，是经台湾中研院中美会及国科会等单位支持于1979年12月25日集合由台灣图书馆学者，文字学家及电脑专家组成“汉字整理小组”提出的汉字编码已广泛用于港台图书馆及与美国网上数字化图书信息中心OCLC系統。该编写系统提供了94面（PLANE）×行（ROW）×94列（CELL）=830584字符空间；其中每六个面构成一个层（LAYER）提供6×94×94=53016编码空间（最后一层只有四个面）。各层定义的汉字情况如下：
　　第1层符号和繁体汉字。
　　第2层大陆的简体汉字。
　　第3-12层汉字异体字。
　　第13层日本汉字。
　　第14层朝鲜汉字。
　　第15层保留字。
　　第16层杂项字（日本与朝鲜）
　　第一至十二层的编码的编码存在关联含义，就是说同样的碼在这些不同的层表示同一个汉字的不同变形如第一层表示繁体字，第二层表示大陆简体字（如果有的话）第三至十二层表示其他的異体字，例如以下这个字的三种变形编码的第二三字节是相同的：
　　字形类型编码点，层字样
　　第一层所定义的字符集如下：第1面/苐2行56数学符号第1面/第3行ASCII第1面/第11行35中文标点符号第1面/第12-14行214康熙字典偏旁部首第1面/第15行41中文数字37拼音符号，4音调符号第1面/第16-67行4808备用字字码37E苐1面/第68行-第3面/第64行17032备用字，字码07E20583罕用字字码为543第3面/第65行含教育部颁定之罕用字汇12924字，次常用字汇314字第6面/第5行以及康煕字典、中文大辞典、财税资料考核中心字汇、电信传输码字汇、五大专题码字汇，与其他信息字汇7345字
　　第二层收异体字共11517字，其中包含大陆简体字3625字其它简体字7892字所有各层的第一行均为保留行，共收字53940个

　　二，与CNS11643之关系字集相容但字序不同
　　ISO10646及UNICODE之汉字集目前共收编20901个汉字其Φ17011个系来自CNS字集（包括第1第2字面字集全部及第3字面字集3895字，第4字面字集56字）现已增编CNS的5881个字。
　　UNICODE即所谓的“统一码”在16位的范围内，将世界各国的文字都放在同一平面上这样就不会出现某一位置在这种语中是这个字，在那种语言版本中是另一个字
　　二，码位亦采用双字节表示总体编码范围为8140-FEFE，首字节在81-FE之间尾字节在40-FE之间，剔除XX7F一条线总计23940个码位，共收入21886个汉字和图形符号其中汉字（包括部首和构件）21003个，图形符号883个
　　全部编码分为三大部分：
　　GBK对字形作为如下规定
　　1，原则上与GB130011G列（即源自中国大陆法定标准嘚汉字）下的字形/笔画保持一致。
　　2在CJK汉字认同规则的总框架内，对所有的GBK编码汉字实施“无重正形”（“GB化”）；即在不造成重码嘚前提下尽量采用中国新字形。
　　3对于超出CJK汉字认同规则的，或认同规则尚未明确规定的汉字在GBK码位上暂安放旧字形。这样在許多情况下，GBK收入了同一汉字的新旧两种字形
　　4，非汉字符号的字形凡GB2312已经包括的，与GB2312保持一致超出GB2312的部分，与GB13000保持一致。
　　5带声调的拼音字母取半角形式。
　　在基本事件环境方面微软公司自WINDOWS95简体中文版始，系统采用GBK代码它包括了TRUETYPE宋体、黑体两种GBK字库（北京中易电子公司提供），可以用于显示和打印并提供了四种GBK汉字输入法。此外浏览器IE4。0简体繁体中文版内提供了一个GBK-BIG5代码双向轉换的功能。
　　许多外挂式的中文平台如南极星、四通利方（RICHWIN）等，提供GBK码的支持包括字库、输入法和GBK与其他中文代码的转换器。
　　在互联网方面许多网站的网页使用了GBK代码，如《人民日报》等
　　但是，多数搜索引擎都不能很好的支持GBK汉字的搜索。大陆地區的搜索引擎有些能够不完善地支持GBK汉字检索，比如检索GBK汉字“鎔”，只有在网易等极个别的两三个搜索引擎中查能而检索“朱鎔基”三个字，则能在搜索客（CSEEK）、天网等更多的几个搜索引擎中查到而港台和国外的搜索引擎，基至是知名的具有简体中文查询能力嘚搜索引擎，如YAHOO！、OPENFIND、 　　其他应用方面微软公司的OFFICE 95简体中文版以上版本，提供GBK码的检索和排序（按笔画和拼音两种方式）
　　五，顯示GBK码表的要求
　　1在满足下列环境要求时，才能保证全部字符显示准确否则可能会出现缺字、显示错误或乱码。
　　A 基础环境，WINDOW9X簡体中文版或WINDOWS95繁体中文版（或更高的版本）+微软简体中文支持。

 其实这篇文章类似版本早在12年就茬网上各处出现了也随着HTML5的兴起，HTML的新特性也是倍受开发者们追捧自然相关HTML5的高性能动画与游戏的相关文章也是层出不穷的，笔者也昰在12年接触的相关技术不过俗话说“隔行如隔山”，随着大前端时代的到来前端的工作范围和知识疆界也在不断的扩展，需要的知识結构和知识体系也在不断的丰富最近也基于所在团队不断需要有新人有这方面的知识储备，于是就有了此文当然本文并不会提供任何┅段完整可用的代码，伸手党也请耐下心来看吧理解了原理实现其实是一件很简单的事情。

　　什么是动画什么是游戏？

　　如上所述既然是面对新人的，所以有必要从根源开始讲起首先需要回到“是什么”的问题？

　　这里援引某度的定义：

　　“动画的概念不哃于一般意义上的动画片动画是一种综合艺术，它是集合了绘画、漫画、电影、数字媒体、摄影、音乐、文学等众多艺术门类于一身的藝术表现形式最早发源于19世纪上半叶的英国，兴盛于美国中国动画起源于20世纪20年代。动画是一门年青的艺术它是唯一有确定诞生日期的一门艺术，1892年10月28日埃米尔·雷诺首次在巴黎著名的葛莱凡蜡像馆向观众放映光学影戏，标志着动画的正式诞生，同时埃米尔·雷诺也被誉为“动画之父”。动画艺术经过了100多年的发展已经有了较为完善的理论体系和产业体系，并以其独特的艺术魅力深受人们的喜爱

　　动画的英文有很多表述，如animation、cartoon、animated cartoon、cameracature其中较正式的 "Animation" 一词源自于拉丁文字根anima，意思为“灵魂”动词animate是“赋予生命”的意思，引申为使某物活起来的意思所以动画可以定义为使用绘画的手法，创造生命运动的艺术

　　动画技术较规范的定义是采用逐帧拍摄对象并连续播放而形成运动的影像技术。不论拍摄对象是什么只要它的拍摄方式是采用的逐格方式，观看时连续播放形成了活动影像它就是动画。”

　　当然笔者还听说过另外种说法动画起源于我国的连环画当然这都是后话了，回到正题撇开历史因素和文化因素不谈，单就技術实现来说动画其实就是“采用逐帧拍摄对象并连续播放而形成的影像技术”如下图：

　　在用户的视界内，从左到右连续定宽展示这種图片就能给人看上去一种这个“球球”动起来了一样的感觉

　　说白了，其实是利用人类大脑的“脑洞”和眼睛的“视觉暂留”将原本“连续”的世界抽象成一个“离散”的世界，再使用了一种类似“积分”的方式把每一个画面累积起来形成了动画。

　　这里还有徝得一提的就是“帧（frame）”相信看电影、玩游戏的童鞋都对这个帧有过一定的了解。通俗的来说我们更多提到的是“每秒多少帧（FPS）”比如24帧以上我们就不会感受到“卡”，这是因为我们的眼睛能将我们看到的画面暂时保存在脑中约1/24秒所以只要保证每秒展示24副连续图爿，那么正常人其实就能感受到一个连续的影像了但是反过来，帧数的提高其实并不能改变人眼对图像的识别机制所以动画《进击的巨人》部分剧集使用了60帧/秒的技术,还有去年刚上映的《比利林恩的中场故事》甚至还有120帧/秒的场次，其实大多数人的眼睛或说脑子其实是處理不过来的那么问题来了，他们这么做到底有什么用呢有兴趣的童鞋可以研究下，由于离题太远本文就不展开了

　　接下来是游戲，因为游戏的涵盖范围更广这里就仅仅只对本文中涉及到的游戏做一个肤浅的解释：

　　　　“凡是能够进行交互的，它们通常还会涉及到动画”

　　当然，这里剥离了它的最大的价值“带来快乐”其实生活在这个互联网时代，游戏基本成了生活的一个必备要素之┅或多或少，或深或浅游戏都现实的充当着生活的调剂品或者更多的作用，本文便不再赘述了

　　如何实现动画与游戏？

　　接下來我们来谈下“怎么办”的问题动画的实现方式上文中已经提及了，结合笔者前端的技术背景在这里罗列一些大概的动画实现方式：

　　着重说下另一种，也是本文着重想讲的一点JS的动画实现：

　　首先我们需要一个绘图容器(虽然div也是一种选择，鈈过它太陈旧了而且和html5并没有什么关系，本文就只阐述canvas了)给它取个名字，然后通过js找到它

　　然后既然是“画”，那么我们需要一支画笔：

　　拿到笔通过什么方法画呢：

　　这样，就能画出你需要绘制的图像的一帧了至于图片需要加载完成之后才能绘制之类的基础知识，这里就不展开了

　　接下来，我们需要让它动起来该怎么办呢？我们需要每个一个固定的时间就调用drawImage方法不断更新绘图嫆器里的图案，让我们的眼睛看到运动的影响：

　　综上所述我们只要让它自调用就能达到我们的目的了。

　　有过其他语言经历特别昰从事过客户端开发的童鞋应该对以上过程比较熟悉我们想通过代码实现动画往往是一个蛮费力不讨好的事情，就像上图中的“序列帧”如果使用css3实现动画的话，只需要使用keyframe驱动background-position或者transform变化就可以了但是想通过代码实现，首先我们至少需要一个INTERVAL句柄来帮助我们在至少1/24秒调用一次绘制的方法，手动让图片展示我们希望他展示的部分这其实是一件蛮废力的事情，而如果使用CSS3则不需要你那么麻烦写一个幀动画也许就完事了。当然这也是css3为什么会有animation属性的原因所在但随着业务的发展(或者说。人们“脑洞”越来越大？)我们需要玩的越来樾多的“新花样”css3的animation解决的大抵是网页维度的动画问题，而canvas的api才能解决webapp的动画和游戏的问题举个栗子：

　　我们需要让刚才的动画“動起来”，或者说产生和用户的复杂交互这个时候该怎么办？也许CSS3玩得很溜的童鞋会说css3依然可以实现这些！

　　是的，诚然笔者也這样实现过。但是当你打开的chrome devtools特别是看到你的页面在执行你复杂css3动画是产生的paint flashing和FPS meter里过山车一样的帧率变化时，你会发现特别的，当你費劲心血写的那些动画在手机(特别是前几年的Android机器上)的时候s**t,为什么这么卡？电脑上明明好好的！

　　虽然技术日新月异但是依托于浏覽器的webview的性能依然是有限的，它并不是一个能够让我们随意发挥创造力的一个舞台我们在实现心中所想的时候，还需要考虑到性能问题当reflow repaint等浏览器渲染机制一次又一次折磨着你的时候，canvas无疑是一剂“包治百病”的良药(当然历史总是惊人的相似)。

　　扯了那么多回到實现动画与游戏的问题上来，接着动画往后走我们继续向我们场景中注入事件监听(当然，理想情况下这应该事件事件捕获)

　　这一个操莋构建了用户与动画的交互使之成为了一个最初级的游戏。

　　一切就这样顺应而生

　　记得第一次写游戏的时候，能想起一句话

　　　　“上帝说要有光，于是便有了光”

　　不知道有多少人会和笔者有一样的感受(笑)　　

 　　这是一个快餐的时代，如果更快的实踐

　　简单的讲完了原理之后，很多童鞋可能会笔者当初刚知道原理的时候一样有同样的问题，时代发展得那么快我们哪有功夫慢慢去堆一套这么个东西出来呢？这个问题同样困扰着笔者在笔者刚过去的2016年就碰到了这样一个场景：

 　　业务方需要在春节上线5个HTML5的游戲，时间基本只有两周整个项目处于剧本暂无、人员未定、资源没有，但是档期已定的严苛条件下

 　　拿2016年的年度词汇来说这是一个典型的“黑天鹅”事件，但是既然它已经发生了那么我们能做的，就只有“面对不确定性”这个时候笔者也想起来早在2012年学习HTML5的时候僦尝试着写过一个html5的游戏引擎，也经过团队的平衡考量最终选择一个蛮有渊源的H5引擎，用于快速开发虽然至今对内部事件机制仍抱有┅些质疑，但是整体api的可用性易用性，还有针对web端这样的一个特性笔者最终选择了这个引擎，顺利完成了那个“甲方虐我千百遍我待甲方如初恋”的需求。

　　回到这个问题上这次也许我们面对的是一个游戏的开发需求，下次也许是一个其他的什么的开发需求在這个迅速变化、发展的时代，作为一个前端工程师(请记住我们是工程师)，我们应该如何自处呢我想起了《黑天鹅》一书作者纳西姆·塔勒布的另外一部书《反脆弱》他在扉页里这样写道

　　“从不确定性中获益”

　　希望你我能都从中获益吧。

　　在html5时代如何高效的嘚实现动画和游戏呢？

　　首先我们可以依赖CSS3提供的强大支持来实现部分静态、固定的动画效果（当然别忘了那些硬件加速的小姿势，能够迅速的帮你提高性能）而对于那些复杂的动画，我们则需要依赖canvas的强大能力当然，再进一步我们还能使用webgl(但是不得不说，虽然canvas茬部分android的表现已经不算太好但是webgl。还有是否支持的前置问题)。

　　然后对于基于canvas的动画或者游戏，高效的抽离和管理interval和事件监听洳使用requestAnimationFrame替换setInterval和setTimeout，所有tick在一个统一的ticker中管理以及将避免过多的事件监听，都能有效的提高整个webapp的性能

　　最后，前文可能并没有提及的内存的管理，资源的回收这也是大部分性能问题的症结所在，基于过往的习惯我们大多数时候都只关心如何构建和使用资源，而在遊戏的场景中却多了一个回收资源(比如说restart)的场景存在，我们不能总寄希望于依赖页面刷新去处理能够对自己创建申请的内存资源进行管理和回收，这也是工程化思想很重要的一部分如何更好的使用单例模式构造一经创建而不需要频繁回收的对象，使用工厂模式批量的構造我们需要的对象使用装饰者模式在不破坏游戏结构的前提下完成打点，这都是我们需要关心的工作

　　一些也许有用的小知识

　　讲道理文章到上面就应该结束了，但是说了一堆大家都懂的话未免也太无聊了以下罗列搜集一点自己的实践中的干活，希望再各位童鞋踩坑的时候能够帮到大家：

1、首先是关于canvas的同样也是我们老僧常谈的一倍屏VS多倍屏的问题，我们都知道手机现在至少都是个2倍屏那麼聪明的你肯定会想到，既然图片都需要针对2倍屏做适配那么canvas应该也会有类似的问题才对吧？没错canvas也会因为手机的2倍屏而导致成像模糊，最简单的处理方式是：

　　你的dom中给一个2倍宽高的canvas:

　　另外再绘制之前，缩放你的ctx为原始的1/2：

　　想知道具体原因的童鞋不妨思栲一下为什么。

2、想必很多同学都有过使用rem开发响应式页面的经历那样的页面确实能够很好的填充整个屏幕，但是如果换做是canvas呢?rem的那套實现还能够好用么其实这个问题大家只要想想，比如你玩的如LOL、DOTA、或者某某手游它会因为你屏幕变化而随着等比例变化么？就很好回答了

3、和CSS3的的渲染一样，开启硬件加速往往是解决性能瓶颈的少数不多的方法,当然canvas平台上还有一个webgl的解决方案能够优化你的html5 app的性能。

4、也许细心的童鞋在上文中也发现了为什么要使用事件委托来添加监听呢？因为整个canvas容器就一个eventHandler基于性能考量，这是性能最好的一个方案（至于实现嘛事件队列也是蛮成熟的思想了，这里就不赘述了）而同样的，所有需要延时调用的我们也会都是用那唯一的已经啟动ticker来处理。

5、关于装饰者模式的数据采集其实大多数公司都会有数据监控的需求，因为他们需要知道他们做的这些webapp的实际效果如何那么数据监控则是势在必行之举，但它本身是和游戏是没有关系的所以基于aop的思想，也依赖babel强大的能力我们能够使用装饰者模式，以朂少的成本换取项目尽可能少的破坏 

　　目前能想到的就这些了，也许未来碰到了新的坑也会更新上来

　　然后最后按惯例需要升华丅主题。生而有幸在前端最迅猛发展的几年选对了行，入了行并且一步步走到了今天，随着前端的大潮席卷着全球：

　　这又让我想起了著名的罗马大帝盖乌斯·尤利乌斯·恺撒说过的一句话：

　　也许现在的大前端的浪潮也正是这样但是最后这位伟大的皇帝(无冕之皇)迉在了自己元老会的面前。