前言 最近在做一个 2D 游戏，项目做的差不多了，整理一下自己在制作过程中用到的知识点，这篇写 Canvas 与 Camera 的使用。
Canvas 画布是所有 UI 元素都应该在其中的区域。Canvas 是一个带有画布组件的游戏对象，所有 UI 元素都必须是此类画布的子元素。下面是 Canvas 组件
Canvas 有以下三种渲染模式：
1.Screen Space Camera
此模式画布被放置在指定的摄像机前的距离。UI 元素由这个摄像头呈现，这意味着摄像头的设置会影响 UI 的外观。如果将相机设置为透视，UI 元素将以透视的方式呈现，视角的失真程度可以通过相机的视角来控制。如果屏幕被调整了大小，改变了分辨率，或者相机的截屏改变了，画布也会自动地改变大小以匹配。
tip：如果想在 UI 上显示特效，可以使用此渲染模式
2.Screen Space Overlay
此模式将 UI 元素放置在场景顶部呈现的屏幕上。如果屏幕被调整大小或改变分辨率，画布将自动改变大小以匹配它。
tip：如果想在 UI 上显示特效 ，此模式不适用。
3.World Space
在此模式中，画布将表现为场景中的任何其他对象。画布的大小可以通过它的 Rect 变换来手动设置，UI 元素会基于 3D 布局呈现在场景中的其他对象的前面或后面。这对于注定要成为世界一部分的 UI 是有用的。
UI 适配
Canvas Scaler
对于设置为“Screen Space - Overlay” or “Screen Space - Camera”的画布，可以将画布比例器 UI 比例模式设置为 Constant Pixel Size, Scale With Screen Size, or Constant Physical Size。
前言 最近在做一个 2D 游戏，用到了 Sprite 与 Image。UI 界面使用 Image ,游戏场景相关制作使用 Sprite。后来跟小伙伴交流的时候，提到了这一点，说到具体原理，我记得是渲染方式不同，Image 的渲染方式是 Canvas Renderer；Sprite 的渲染方式是 Sprite Renderer，至于具体为什么要使用，一知半解。
异同 1.都是使用一个 Sprite 源进行渲染，而 Image 需要位于 Canvas 下才能显示出来。
2.场景中的 Sprite 可以像普通的 3D 游戏物体一样处理，通过 Transform 组件进行移动，旋转等操作；而 Image 则使用 RectTransform 进行布局，以便通过 Canvas 统一管理，RectTransform 可以设置大小，对齐方式等。
3.同一 Canvas 下 不同的 Image 的渲染顺序是根据 Image 在 Hierarchy 的上下顺序渲染的，上面的先被渲染，下面的后被渲染；不同的 Sprite 是根据 Order in Layer 数值的大小渲染的，数值小的先被渲染，数值大的后被渲染。
4.Image 和 Sprite 都可以引用 Material; 都可以通过 Color 修改颜色；如果想对图片进行拉伸，而不影响图片的显示， Sprite 可以通过 DrawMode 修改渲染模式，Image 则是通过 Image Type 修改 Image 的显示方式。
Unity 特殊文件夹编辑顺序 前一段时间做图文混排导入了一个插件 Super Text Mesh，把文件夹直接导入到项目根目录下 Assets 文件夹里面，忘记放到 Plugins 文件夹下。之后再转移文件目录的时候，会报一个外部类不存在之类的错误，查了半个小时无果，同事提示我查 Unity 的编译顺序，看完 Unity 相关的官方文档之后恍然大悟，原来跟 Unity 的特殊文件夹的编译顺序有关。
在使用 Unity 创建项目的时候，我们可以根据需求创建相应的文件夹；不过有一些特殊文件夹名称会被 Unity 解释为一个指令，文件夹中的内容会被 Unity 特殊对待，这些文件夹的会影响脚本编译的编译顺序。
Assets
Plugins
SteamingAssets
StandardAseets
Editor
Resources
Editor
default resources
以上是 Unity特殊文件夹名称
有关于这些特殊文件夹名称的相关信息，官网文档Special folder names给出了详细的说明
脚本编译有四个不同的阶段，处于哪个阶段编译由其父目录确定。
编译阶段：
阶段1：编译Standard Assets、Pro Standard Assets、Plugin中的运行时脚本
阶段2：编译Standard Assets、Pro Standard Assets、Plugin中的Editor脚本
阶段3：编译其他不在Editor目录下的脚本
阶段4：编译Editor目录下的脚本
不同的编译顺序对脚本之前的引用很重要。基本规则是 被引用的类一定是在较早的阶段编译的。也就是说，在当前阶段之后编译的任何内容都不能被引用。在当前结算或早起阶段编译的任何内容都是完全可用。
我出现的情况是 我转移到Plugins的文件夹里面有脚本调用 Plugins以外的普通文件夹里的脚本。因为Plugins文件夹的编译顺序比Plugins之外的普通文件夹的编译顺序靠前，所以会报 “xx类未定义，找不到xx类的定义”之类的问题。
解决了我的问题之后，回头想想为什么要放到 Plugins 呢？除了规范文件夹的目录位置，还有什么作用呢？
在网上查了一些信息，大概是说会缩短项目的编译时间。
如果项目当中一些长时间不需要改动的脚本代码放到特殊文件夹里面，这些代码只需要编译一次，这样会缩短项目的编译时间。
———————– DLL 分割线 ——————————–
程序集 DLL 工作环境：
语言：C#
Unity 版本：2017.
FlappyBird 制作进度： 1.创建 GitHub 仓库；
2.安装 Unity2018.1.0b12,创建 Unity 工程，导入项目资源；
3.处理图集；
4.整理整体思路，创建相关文件夹以及目前会涉及到的脚本；
5.根据背景图大小设置 Camera 的相关参数；
6.制作 Bird ,Wall 等预制体以及相关动画；
7.制作 Start、GameOver、Score 等 UI 界面。
FlappyBird 制作进度 6月9号 1.创建游戏状态机，bird的状态机
2.Bird 默认飞行，按键向上飞行
3.Bird 与 Walls、Ground 的碰撞检测
剩余功能：
1.动态加载 Wall、ground、bird。
2.Audio 音效系统
3.完善状态机，将游戏流程串联起来。
4.评分机制
5.游戏模式：简单，复杂，困难
FlappyBird 制作进度 6月11号 1.简易 UIManager
2搭建（Start, Ready,Gameover）界面；
3.Bird 的碰撞检测;
4.Ground Pipe 循环移动;
5.创建 GameMansger 实现游戏循环；
未完成部分:
1.音效管理器；
2.根据选择的不同难度，Pipe 的动态加载；
3.加分机制（加分，本地数据存储）；
4.随机背景颜色；
5.Bird （随机颜色，上升掉落角度调整）;
简介 正则表达式是一些用来匹配和处理文本的字符串。正则表达式是用正则表达式语言创建的，没有能够直接安装并运行的程序，是内置与其他语言或软件产品里的迷你语言。几乎所有的语言或工具都支持正则表达式。语法是正则表达式最容易掌握的部分，真正的挑战市学会如何运用那些语法把实际问题分解为一系列正则表达式并最终解决，所以必需通过实践才能真正掌握他们。
例外，正则表达式里区分大小写的，大多数正则表达式里的实现也支持不区分字母大小写的匹配操作。
匹配单个字符 “.” 字符是元字符，可以匹配任意单个字符，确切得说：只能匹配出了换行符以外得任何单个字符。
匹配特殊字符：
“.” 在正则表达式里有特殊含义，如果想要匹配字符本身的话，要在前面加上 “\” 来对他进行转义。 “\” 是元字符，用来对字符进行转义，在正则表达式里，有特殊含义得字符序列总是以 “\” 字符开头
匹配一组字符 左括号 [ 是元字符，它标志着一个字符集合的开始；右括号 ] 是元字符，它标志着一个字符集合的结束。
使用 元字符 [ 和 ] 定义一个字符集合，必须匹配该集合里的字符之一。[ ] 里可以写你要匹配的字符，如：[a],[abcdefg]；也可以匹配字符区间 [0-9]，[A-Z]；也可以取非字符 [^0-9]
连字符：
“-” (连字符) 是一个特殊的元字符，作为元字符只能在 [ 和 ] 之间，在字符集合以外的地方，只是一个普通字符，只能与 “-” 本身相匹配。（因此，在正则表达式里，“-” 字符不需要被转义 “?” 需要做测试）
取非字符：
字符集合通常用来指定一组必需匹配其中之一的字符，但在某些场合，需要反过来做，给出一组不需要得到的字符。即：除了那个字符集和里的字符，其他字符都可以匹配。 使用 “^” 元字符表明想对一个字符集合进行取非匹配。
“^” 的效果将作用于给定字符集和里的所有字符或字符区间，而不是仅限于紧跟在 “^” 字符后面的那一个字符或者字符区间。
使用元字符 元字符大致分为两种：一种是用来匹配文本的，比如（.），另一种是正则表达式中的语法所要求的（比如 [ 和 ] ）
对特殊字符进行转义
元字符是一些在正则表达式里有着特殊含义的字符。因为有着特殊的含义，所以这些字符就无法用来表达它们本身，所以就需要一个转义字符 “\” ，例如 “.” 将匹配到这个字符本身，而不是它的特殊含义。
任何一个元字符都可以通过给它加上一个反斜杠字符（\）作为前缀的方法来转义。
note：配对的元字符 比如 [ 或 ] 不用作元字符时必须转义，否则正则表达式分析器很可能会抛出一个错误。
GitHub 网站建起来有一周了，GitHub 支持自定义域名，于是就想着买个自己域名作为网站门面
购买域名 通过同事的推荐下，在 namesilo 购买的域名。
在GitHub配置 我是第一次配置，所以想做个总结记录下。
官网手册里写的比较详细，链接 GitHub 官网配置文档。
在 GitHub 配置，需要以下几个步骤：
1.需要在你的 GitHubPages 的根目录下创建 CNAME 文件，里面只写上你的域名，如 xueyuyao.com
2.进入你的 GitHub Pages 里，选择 Settings。 下面有一个 GitHub Pages 的标签里面的 Custom domain 下面写下你的域名 ，如果你配置的是 www 的，域名前要加 www。
3.在 namesilo 里配置
登录 namesilo，在右上角点击 Manage My Domains。
点击右边蓝色的按钮
在框内填写你的对应的信息，最后点击 SUBMIT
提交之后 DNS 配置有延迟，可以通过 nslookup 命令 可以查到 DNS 记录的生存时间还可以指定使用哪个 DNS 服务器进行解释。
通过下面代码测试 DNS 记录配置是否成功。
dig docs.example.com +nostats +nocomments +nocmd
Debuging 调试在编程工作中很常见，几乎每天都会很它打交道。可以说对于编程人员来说是一件很困扰的事情，有时候查找一个 Bug 原因，需要花费大量的时间和精力。
本书一共总结了调试规则九则：
1.理解系统
2.制造失败
3.不要想，而要看
4.分而治之
5.一次只改一个地方
6.保持审计跟踪
7.检查插头
8.获得全新观点
9.如果你不修复 Bug，它将依然存在
单看这 9 个规则的标题，会有熟悉的感觉吧，会不会跟自己平时调试的时候，有一些方法差不多，觉得很简单。那回想一下，这些简单的规则，是否都能用对地方呢，是否在关键的时候，想的到呢？
其实在实际工作中，有时候越简单的规则往往越被人忽略。有些规则显而易见，会记得运用在特定的问题上，越往往不容易；有时候会被人忽视，有时候会走所谓的捷径，最终所花的时间越久。所以看的过程中，有时候会产生共鸣；有时候会暗自懊悔，自己为什么当时没有使用这种调试方法，所以要记住并运用好这些规则会很有帮助。
读这本书并写下读书笔记，最主要的是想提高自己的调试能力，提高工作效率；当然也能节省下来时间去做其他的事情。 书中每个规则里面都有详细细分了规则使用的不同情况，还有举例说明。我把自己在看书过程中的想法记录一下，加深下对于规则的理解，以便更好的运用到工作生活中去。
理解系统 项目已经到了中后期，基本每天会被分配到不同的 Bug，有时候会接到自己不熟悉的功能 Bug，接到这样的 Bug，首先要做的工作就是理解系统。
理解系统就是你必须掌握系统的工作原理以及它是如何设计的，在某些情况下，还要知道为什么这么设计，如果你没有理解系统的某个部分，那么通常就是出问题的地方。
『昨天我在查找一个 Bug 的原因：我查找到在跟 AI 一起比赛时，对方使用的 Buff 跟显示出来的一致；跟真实的玩家比赛时，对方使用的 Buff 跟显示出来的不一致。我咨询了主程 AI 跟真实玩家的数据上的区别：AI 的 Buff 使用是纯客户端处理，而真实的玩家需要发送给服务端，服务端会再进行计算，再分发给其他玩家的。我断定问题出在服务器那边。最后结果肯定不是服务端的问题，问题出在客户端读取服务端的一个类型 type 上，type 并不是 BuffType 而是需要做一个类型转换，之前直接当做 BuffType 接收的，所以会出现对方使用跟显示不一致的问题。』
上面的事例中我忽略了一个错误，就是没有理解系统，我没有去查看这个功能的数据接口相关的文档说明，导致了判断错误。
在开发的过程中，在接触到新的功能时、修改 Bug，容易犯经验主义错误，没有仔细的看相关文档，导致最后漏掉功能细节，或者修改 Bug 不彻底，甚至找不到出现 Bug 原因。
理解系统可以通过以下几方面来做：
1.阅读手册，手册里会告诉你正确的使用方法；
2.逐字逐句的阅读整个手册，解决问题的方法可能就隐藏在不起眼的角落；
3.知道什么是正常的，即必须掌握你所工作技术领悟内的基础知识，才能知道什么是正常的；
4.知道工作流程：当你尝试查找错误时，必须知道要查找的路线；
5.调试工具是用来观察系统的眼和耳，你必须选择正确的工具，正确地使用工具，并正确地解释得到的结果；你越是精通工具，就越容易查明系统中发生了什么事情；
6.了解你的工具：调试工具是用来观察系统的眼和耳，你必须选择正确的调试工具，正确的使用工具，并正确的解释得到的结果。还要必须了解工具的局限性，可以显示什么错误，不能显示什么错误。还必须了解开发工具，所使用的编程语言；
7.在项目中，对一个组件或者语法的运用有分歧，不要盲目的相信自己的记忆力，不要猜测，去查阅手册，要养成良好的查阅习惯。
制造失败 有时候理解了系统，还是锁定不了 Bug 的来源，这时候就需要执行下一个方案了。
1.制造失败：顾名思义就是把失败再重复一遍，或者几遍。
为什么要制作失败呢？
图文混排总结 最近在做图文混排相关的功能，先后使用了几种方式实现；有的本身有问题，有的不适用与我们的项目， 总结一下以后略过这些坑。
TextWithImage Text 中加载个 Image 是没有问题，加载1个以上，就会报错(错误位置是 TextWithImage 里 99 行)，将多余的 Image 的 enable 设置为 false，不能进行设置，删除等操作，还会出现加载一个 Image 创建出 2 个， 加载 2 个，创建出 3 个…翻倍的创建 Image，消耗性能。
TextInlineSprite 实现原理：（text中插入图片） 1：总体显示方面都还可以 (可以设置 Image 显示大小，支持动态图）
2：显示 Bug（表情会出现丢失的情况，关掉界面再打开就会显示）
3: 需要手动清理画布上的表情 list 显示(如果是分页显示的话，切换表情时，需要把前一个 Image 内同清理掉)
4:最严重的问题时分辨率适配问题(不同比例的分辨率，表情位置会出现偏差，目前没有找到合适的办法解决)， 在网上看的是， 写插件的作者之前设计的时候，没有把适配考虑进去，
5:性能未测试
参考链接：TextInlineSprite
EmojiText 实现原理：（文字和图片独立渲染） 这个方案目前想到有两个弊端：
1：Outline、Shadow 使用时，图片也被处理的问题
2：图片是根据文字大小来渲染的，跟文字大小一样，显示看起来表情没有很突出
参考链接：EmojiText (文字和图片独立渲染)
上面的这些情况是我在项目中遇到的实际问题，以下链接中有详细的
UGUI 图文混排解决方案和优化
Super Text Mesh SuperTextMesh 是个功能很强大的插件，可以实现渲染动态文字，富文本支持图文混排。具体的功能类型有：文字效果、TextColor、Automatic、Master、Inline；（图文混排就是 Inline 的一种实现方式：Quads）还有一个比较好的是，SuperTextMesh 是开源的，根据项目的需求可以修改源代码。
unityAssetStore 下载链接 Super Text Mesh
学习之路 讲述了作者自己编程经历，以及写这本书的过程。写一个成功的模式需要历经许多从业者的使用、反馈、不断的修改验证，才能越来越完善。我们目前使用的编程语言、编程模式、以及读到的技术书籍，都是作者反复推敲验证过之后的成果，我们确实是站在许多人的肩膀上。在本书的一开始，作者讲述了在编程道路上，总结了大概学徒期、熟练工、师傅这三种阶段，这三个阶段不能按传统行业那么单纯的定义。处在师傅阶段的时候，在学习新的语言时，也需要经历学徒期、熟练工等等。
在编程道路上，处在不同阶段，或者不同状态下，需要采用不同的学习模式来应对。
第一部分：在学习过程中要持有空杯心态 在学习一门新的语言过程中，需要理解支撑其规则的底层因素及原理。只有了解了原理，才能适应实际使用过程中的各种情况，以不变应万变。 在实际工作中，发现问题时不要回避，寻求解决问题的方法、敢于失败、去尝试不同的解决方法，以找到最合适的解决方案。
持有空杯心态来吸收接触新的知识，领域。与身边的人沟通、交流；在这个过程中不要隐藏自己的无知，相反要正式自己的无知，多向专业的人请教问题。在工作中不要不懂装懂，不要去承诺一项自己根本无法完成的工作，来显示自己的技术能力。要让同事们看到自己的学习能力而不是已经掌握的知识。多去看一些技术厉害的人、收集她们的履历、学习的书籍、找出对自己有用的，总结出一份计划，并付出行动；以解决实际问题来学习新的知识，学习一项技能之后，做一个实际的小项目来验证自己的学习成果；养成定期把自己的履历审查一遍的习惯，整理自己的技能列表。
发现了一项技能，身边的人都了解而自己不了解。这时采取行动去掌握（看相关文献、API，然后做实际的一个小项目）来填补自己的这项技能空白，在此期间不要因为自己的学习影响了公司的工作，也不要发现了技能空白之后，不采取行动去填补它，这样只会让自己更无知。能意识到自己缺少的东西并补充它，就会向前迈进了一步，准确的自我评价，确定了自己走了多远，并记下知识中的空白，要对自己已有的能力，和即将胜任的技能以及长期感兴趣的知识都了然于胸。
如果觉得在目前的职位上如鱼得水了，没有什么挑战性的时候，尝试申请一些具有挑战性的工作，当然也不要冒失的去申请自己根本无法完成的工作，要结合自身的实际情况，这样技能得到提升，又不耽误公司的项目进度。
第二部分：编程之路是漫漫长路 要理解不是所有的人都会在编程之路上一直走下去。有的可能因为各种原因不得已选择其他的职业；有的可能对编程失去兴趣了；有的职位得到的提升，工作过程使用代码很少很少了；所以在学习过程中要明确自己的目的，明确自己要走的路。 如果确定自己要在编程之路上走下去，肯定会遇到许多状况会导致自己的意志不坚定。
1.想要在编程道路上走下去，首先先得保住饭碗，在公司工作要以工作内容为主，技能是简历在牢固的关系之上，是要解决实际问题的，不能太理想化，影响了公司的项目。
2.写下15项能力为你提供的动力的事情，再列出5项最重要的为你提供动力的事情。
3.当现实生活工作扼杀你对软件工艺的激情时，要采取措施来保护并培养自己对软件技艺的激情，做点自己喜欢的事情，从工作中找出一些感兴趣的东西。
4.为自己的职业生涯确定一个合理但又须付出努力的下一步，到达自己的下一步，然后继续制定整个过程计划，直到抵达理想的目标。（过程步骤具体化）
第三部分：准确的自我评估 在学习编程的道路上，要对自己做出准确的评估，其实的不太容易的。你可能知道你学习的起点在哪里，但你不知道学习编程的终点在哪里，尤其是处于学徒期阶段。所以要寻找办法，来帮助自己对自己做出准确的评估。 这时候就寻找优秀的人，跟优秀的团队一起工作，在团队中只求最差，即宁为狮尾、不做狐头。在团队中只求最差，这时候就会重视自己的学习技能的机会，从最后面开始一路追上去，不断找到改善的方法，不断模仿更强的开发者，知道跟同一团队处于同一水平上。跟优秀的程序员一起工作是一种更好的学习方法，能够帮助自己维持更加准确的自我评估。在学习过程中，寻求同道中人，一起学习，或者定期进行沟通交流，并记录自己学习的过程、经历。无论是正面的还是负面的。谦虚是成功学徒过程的基础之一，与自己的志向结合，谦虚能让你集中精力，并保持沿正确的方向前进，没有谦虚你很容易过早地宣告自己学徒期结束，并遗漏一些重要的课程。编程道路是一条漫漫长路，要花点时间好好利用自己的学徒期，要明白不管工作多久自己，还是一个初学者。
第四部分 恒久学习 1.在学习的前期，提高自己学习的能力是关键的一步，尽管有时候知识多的很，必须采取一些方法和技巧来高效的获取，理解、维持并应用新知识，通过多个维度来寻求新的知识和经验。比如:看技术博客、看软件大师都在做什么、看别人问的问题，并尝试回答。
2.在开始写程序时，避免不了会出错，而实际工作中是不允许出错，或者不允许频繁性的出错。为了避免这种错误，在私底下，我们需要对新学的知识进行不断的实践、敢于失败、总结经验。
3.要尝试使用源码，找别人的代码来读一读，看看人家是怎么构建项目的，为什么要这么写，试着重构代码，来理解人家这么写的原因。看代码的过程中遇到了跟自己意见不一样的情况，思考一下，作者是否考虑过你想法，也有可能是作者遗漏的部分。
最好的学习方法是阅读源代码 在软件开发领域做一名会思考的从业者。包括经常反思自己的工作状态。考虑下自己的实践是否过时。对团队中都想当然的事情，多给自己画几个句号。对工作中的出现的问题，多一些观察、思考，从而做出改变。在日志，个人wiki或者博客中为自己的行程做个记录，将自己学到的经验按时间顺序记录，这会给你所指导的那些人提供一点启发。对于我自己而言，是记录自己所学，所做。然后经常是翻看下自己写过的东西，可能会有不同的理解或者需要添加新的修改。在开始学习的时候，就要养成定期分享所学的经验的习惯。形式可以是撰写博客，或者跟你的同道中人一起开展会议，做演讲，或者为正在学习的各类技术技巧编写教程，可能一开始会很难。有时候自我评估会很片面，因为自我评估只能相对于过去拥有的能力，永远缺乏客观性，其他人会很容易歪曲自己对自身能力的判断。这时候就需要建立一些机制，定期收集关于自身绩效的相对客观的外部数据，通过今早，经常而且高效的寻求反馈，至少你可以提高知道自己不行的概率。在工作过程中，失败是不可避免的，迟早会发生在每个人身上，所以要学会失败，设法确定你常常会在哪些情况下失败并试着解决哪些需要改正的方面，这并不是要你沉溺与对过往食物的自悯，也不是一次追求完美的联系。真正的目标是让你对导致失败的模式，条件，习惯和行为有所自知。有了这种自知，你可以做有意识的选择，而且基于对自身能力边界和局限性的了解，采用自定路线模式时能使之趋于理想状态。
读完前四部分，觉得很有必要做一个自我整理，整理自己所学、想学知识，做一个自我评估。系上白色腰带，从学徒期开始，持续动力，重走慢慢长路。
第五部分 安排你的课程 学习了一段时间以后，要学会自己看书，通过别人指导、推荐、整理出一份读书列表。
用他来跟踪你准备要读的书，并记下已经读过的书。每天拿出固定的一个时间段读书，比如通勤路上，晚上回来到睡觉前的一段时间。在此期间，如果跟“找人指导”，跟“同道中人”交流，会事半功倍。在工作中，听到同事们说一些没听过的概念，要暴露自己的无知，向他人请教那些不知道的概念，以及他们的出处，并把他们加入读书清单。在读书过程中，要结合自己的实际情况去整理读书清单，读适合自己的书籍。
对工具的使用 学会深入挖掘一些工具、技术和技艺，对知识的学习达到“知其所以然”的程度，理解其原理，可以解释其原理，也能增强自己的自信心。不要靠巧合编程，需要难以解决的 Bug，愿意从一个系统从上到下层层追踪问题，愿意花时间弄清楚弄够解释这一问题的知识。时间是公平的，你花多少时间，就会收获多少。在这个过程中有一个方法那就是从第一手资料获取信息，比如看源代码、原版API。对于知识的运用，要做到不仅仅会使用，要深入理解表面知识背后隐藏的计算机原理和基础概念，这样在采用的实现中会有权衡和取舍。
未完待续…
学习计划 自己之前看过一些关于学会一门语言，或者学会一个具体开发软件的流程图，其实多数时候效率都不是很高。看完那本《软件开发这路线图》，里面总结了许多不同学习状态下的学习模式。看的过程中，回想了之前那些年工作学习的时候，有点误入歧途的感觉，也不是说不努力，是方法没有用对，再加上懒惰，所以从现在开始回归正途。
第一步 自我整理 总结一下自己接触过的所有的语言、引擎软件、用过的工具插件、看过的书籍、收藏的书籍。 分别整理下对这些内容的掌握程度。 整理出来哪些内容是现在工作需要使用到的。 整理出来哪些是你感兴趣的，还没开始学习的部分。 以上部分将以脑图形式呈现
第二步 具体技能 之前没有养成良好的记录习惯，导致好多东西都在反复的学习；或者是第一遍没有学精通，导致第二次再用到的时候还需要重新看一遍。为了提高学习质量，计划一边学一遍记录总结。学习目前工作需要的技能：目前使用的开发引擎是 Unity，编程语言是 C#；目前这两个的掌握程度会用的阶段，首要任务是把这两大块精通，理解其原理。
1.学习 Unity Manual Unity 引擎版本更新比较快，打算把 UnityManual 看一遍，一边看，一边实际操作。 学习顺序： 2D->Graphics->Physics->Scripting->Networking->Audio->Animation->Timeline->UI->Navigation->Unity Services->Virtual Reality->Platform Specific
注：其中看到 UI 部分的时候，结合着相对应的 UGUI 源码看一遍，然后做总结；看源码的过程中，可以结合着 C# 本质论里面的知识点一块看，然后做相应的总结。
2.渲染与Shader->AssetBundle->编辑器扩展 这三个大块知识，打算分别拿出单独的时间段来学习，然后做练习，具体多久看前一部分的学习情况。
Shader 结合着《Unity Shader 入门精要》；
AssetBundle 看原 API 和网上的文章；
编辑器扩展看 API。
这三个都要建立自己的“质脆玩具”。
3.游戏设计模式->网络通讯->性能优化 设计模式：目前用的最多的是观察者模式、单例模式、命令模式、状态模式、工厂模式等。现在流行的 23 种模式，其根本还是要遵守设计模式的六大原则。后期学习的时候，通过学习设计模式，来理解其映射出来的设计原则，结合着《游戏编程模式》一块看。
网络通讯：Http、Socket网络通讯。
性能优化：内存（资源内存占用、引擎模块自身内存占用 、托管堆内存占用）；CPU （引擎模块<渲染模块、UI、 模块、 加载模块>，自身代码）；GPU。
第三步 扩展 前两步写的都是跟目前工作联系比较密切的知识内容，这一部分打算再此做一些扩展。
比如学习 Lua 语言，之前专门练习过 Lua 的语言，不过现在有些生疏了；
Java 语言也是接 SDK 的时候，有所接触；