仁希的博客

动”指的是元素移动，或放大/缩小频率比较高的 UI。“静”就是静止不动的 UI，准确的说是界面上不会移动、旋转、缩放、更换贴图和颜色的 UI。

首先它需要依赖 Unity3D 的 Animator 组件 [RequireComponent (typeof(Animator))]其次它要有播放（Play）接口用来播放指定动画，这里 Play 的参数包括动画名、播放完毕后的回调函数委托等。再次在 public 变量中需要 AutoPlay 这个参数，这样美术人员就可以在 Unity3D 界面上设置自动播放而无需程序调用了。最后需要在自动播放时选择指定的动画名和是否循环播放，以及循环播放间隔。

我们常用的组件 Image、RawImage、Mask、RectMask2D、Text、InputField 中，Image、RawImage、Text 都是继承自 MaskableGraphic ，而 MaskableGraphic 又继承自 Graphic 类，因此 Graphic 相对比较重要，它是基础类，也存放了核心算法。所有核心部分都围绕着如何构建网格、谁将重构，以及如何裁切来进行的。，它内部采用 List 容器对象池，将所有使用过的废弃的数据都存储在里对象池的容器中，当需要时再拿旧的继续使用。

本篇中使用的源码是 Unity 2017 版本。

UGUI 是，它的每个可显示的元素都是通过的形式来构建起来的。当 UI 系统被实例化时，UGUI 系统首先要做的就是。Unity3D 在制作一个图元，或者一个按钮，或者一个背景时，都会。可以理解为制造了一个 3D 模型，用一个网格绑定一个材质球，材质球里存放要显示的图片。如果每个元素都生成一个模型并且绑定一个材质球存入一张图片的话，那么界面上成千上万个元素就会拥有成千上万个材质球，以及成千上万张图。

从图集工具来看，NGUI有更多的自主选择权，而UGUI更多的自动化的便利，从组件支持度来看NGUI更适合快速原型，而UGUI更多的是需要自己编写适合自己的组件。从UI底层可定制度上看，两者都是可定制的，但NGUI更加方便。从输入事件处理上看，NGUI混合了物理系统，而UGUI有一套自己独立的事件系统。从层级显示上看，NGUI概念有点混淆，而UGUI层级概念清晰干净。从字体制作上看，NGUI麻烦了点，而UGUI更加方便。从社区完善上看，NGUI更加商业化，而UGUI有官方支持后台强大。

一般文字都会以 Key-Value 形式存放在 Excel 表里，就比如 Key 为 “RoleName”，Value 为 “角色名字”，或者 Key 为 “1101”，Value 为 “好友分享” 等。这种 Key-Value 形式一般会以 Int-String（整数对字符串）或 string-string（字符串对字符串）的形式存在。

最简单的就是直接将 Excel 里的数据复制粘贴到文本文件中作为游戏数据。手动导出为 CSV。使用 Shell 或 Bat（ Window 批处理）设计自动化流程操作。通过特定语言编写自动化程序。使用 Jenkins 来强化自动化流水线。使用 Unity3D 的菜单栏编辑功能。

数据表相当于是一个外部的数据库，数据库中存储着与游戏人物相关的数据，只不过这个数据库里的数据是不能更改的。数据表是连接美术，设计策划，和程序的桥梁。

不只是算法能大幅度提高业务逻辑的效率，普普通通的业务代码也同样可以有质的飞越。优秀程序员常关注代码对性能的影响，普通人只关注是否能完成功能，这样日积月累代码质量就会形成差距。

广度优先搜索和深度优先搜索是最常见的搜索算法，但如果不进行些枝剪的话效率是比较差的，直接使用不加修饰的广度和深度算法，会消耗比较多的 CPU 以至于整体效率比较差。好的搜索算法，需要有数据结构的支撑，在数据结构里记录了信息的特征，每次搜索的痕迹和当前的内容环境都可以用于枝剪和优化。

基础能力决定你到底能走多远。我们不是写一两年程序就完事了，从毕业算起，我们可能要写20-30年的程序，这段漫长的长跑路程中，最终比的不是谁熟悉API比较多，也不是谁用插件用的有多熟练，更不是比谁更熟悉某软件，而是。

在 C# 中指针被封装在内部函数当中。不过回调函数却依然存在，于是 C# 多了一个委托（delegate）的概念，所有函数指针都以委托的方式来完成的。委托可以被视为一个更高级的函数指针，它不仅仅能把地址指向另一个函数，而且还能传递参数、获得返回值等多个信息。系统还为委托对象自动生成了同步、异步的调用方式，开发人员使用 BeginInvoke()、EndInvoke() 方法就可以避开 Thread 类，从而直接使用多线程调用。

浮点数计算在我们大多数项目中并没有使用到特别的科学计算部分，所以float基本都够用。double也同样有精度问题，无论怎么样都是无法避免精度导致的在逻辑中的不一致的问题。名称。

Dictionaray是由数组构成，并且由哈希函数完成地址构建，由拉链法冲突解决方式来解决冲突。从效率上看，同 List 一样最好在实例化对象时，即 new 时尽量确定大致数量会更加高效，另外用数值方式做 Key比用类实例方式作为 Key 值更加高效率。从内存操作上看，大小以 3->7->17->37->….的速度，每次增加 2 倍多的顺序进行，删除时，并不缩减内存。如果想在多线程中，共享 Dictionary 则需要我们自己进行 lock 操作。

List 并不是高效的组件，真实情况是，它比数组的效率还要差的多，他只是个兼容性比较强得组件而已，好用，但效率差。

C#、VB、J#这些遵守CLI规范的高级语言，会被各自的编译器编译成中间语言 IL，当需要运行他们时就会被实时的加载到运行库中，由虚拟机动态地编译成汇编代码（JIT）并执行。IL2CPP 有自己的虚拟机，该虚拟机不执行 JIT 或翻译代码，主要用于内存管理，其内存管理才有类似 Mono 的方式，程序员无需关心两者的内存差异。首先由 Mono 将 C# 翻译成 IL，再将 IL 重新变回 C++ 代码，再有各个平台的 C++ 编译器直接编译成能运行的机器码。，虚拟机不能跟踪这类代码，需要手动管理。

如何做好前端架构了解如何构建Unity3D项目。

软件研发、系统架构中最重要的能力——抽象能力。架构师先要在大脑中，然后是，以及子模块之间的，然后是子模块，最后将子模块起来，形成最后系统。我们常说编程和架构设计就是搭积木，优秀的架构师受职业习惯影响，眼睛里看到的世界都是模块化组合方式。

实际上架构无处不在，它实质上是解决生活和工作中的问题的一种方案。在软件系统架构中，架构承担了解决项目从研发到上线运营的方案。项目中的每个子系统的都有自己的决策方向，而子系统的决策方向，把它们合起来加入一定的关联性就构成了一个完整架构整体，即每个系统、模块、组件都是软件系统架构中的一部分。优秀的架构师，需要对每个子系统决策的方向要进行深思熟虑，不仅只针对单个系统的决策方向，还要结合其他系统以及整体系统需求的方向进行决策。在架构中这五项能力缺一不可，某项能力特别突出也不能决定整个架构的好坏，综合因素才是。