• 一切的起源在于这篇文章，在文中对AssetBundle的加载进行了详细的描述，但是疑问也由此而生。以下是我在UWA讨论群的提问：

  在讲WWW的时候有这样一段话【解压后的内容，通常为原Bundle文件的4~5倍大小，纹理资源比例可能更大】，在我理解就是www这样的方式获取到的资源（压缩形式的）会被解压缩，并放置到webstream中。而在【AssetBundle加载进阶】部分的【前者劣势】部分，又有【每次加载都涉及到解压操作】，请问这个【加载】指的是什么？是www.assetBundle还是AssetBundle.Load？还有【解压缩】是指的什么？不是在WWW的时候已经解压缩了吗？

第三篇：序列模型

• 双缓冲模式算是书中第三篇：序列模型中的一个，它与游戏循环和更新方法组成了第三篇。后两者可以说是在我做Unity中最常用到的，而且也是游戏引擎本身已经实现了的。谨以下文来说明下序列模型部分的重要性。

电子游戏之所有有趣，很大程度上归功于它们会将我们带到别的地方。 几分钟后（或者，诚实点，可能会更长），我们活在一个虚拟的世界。 创造那样的世界是游戏程序员至上的欢愉。

大多数游戏世界都有的特性是时间——虚构世界以其特定的节奏运行。 作为世界的架构师，我们必须发明时间，制造推动游戏时间运作的齿轮。

这本篇的模式是建构这些的工具。 游戏循环是时钟的中心轴。 对象通过更新方法来聆听时钟的滴答声。 我们可以用双缓冲模式存储快照来隐藏计算机的顺序执行，这样看起来世界可以进行同步更新。

观察者模式

定义

• 定义：在此种模式中，一个目标对象管理所有相依于它的观察者对象，并且在它本身的状态改变时主动发出通知。这通常透过呼叫各观察者所提供的方法来实现。此种模式通常被用来实时事件处理系统。
• 看图
  

说明

• 这篇文章是对《Unity預計算即時GI》这个系列文章的笔记。

Clusters

叢集，透過修改叢集(Clusters)也是一個降低Unity預計算流程所需要執行的工作數量的好方法。降低叢集數量也能提高執行時的效能。

當採用PRGI來計算場景光照時，Unity會簡化產生一個立體像素化結構的計算，這些立體像素(Voxel)叫做叢集。叢集實際上是反映到場景靜態幾何表面用於照明的表面，叢集用一種層級關聯的結構來儲存，用來預計算Unity的全域光照漫反射所需要的複雜運算。雖然叢集和光照圖很像，但兩者用途是各自獨立的。

• 通过设置CPU Usage即可。

说明

• 这篇文章是对《Unity預計算即時GI》这个系列文章的笔记。

光照图

什么是光照图

• 光照图在第三章中有如下的定义，读起来很是费解。

一個光照圖(Chart)是表示一個光照貼圖的區域，用來映射場景物件的光照貼圖UV。你可以想像是能影響物件的一張小磁磚圖，一張光照圖由兩部分組成:輻照度(照明)和方向性(主要光線方向編碼)。

• 到了第六章又有如下讲解，读完之后我更加费解了，所以暂时搁置吧。

產生光照圖(Charts)的目的主要是用來包住靜態網格著色器(Static Mesh Renderer)的UV貼圖座標。

说明

• 这篇文章是对《Unity預計算即時GI》这个系列文章的笔记。

基本概念

在Unity裡，可以用兩種不同的技術來計算全域光照GI或光源反射，就是烘焙全域光照(Baked GI)和預計算即時全域光照(Precomputed Realtime GI)。

當啟用PRGI時，一個光照預計算就是用來計算靜態幾何物件周圍光的反射，並存成資料給Runtime執行使用的一個過程。這個過程減少了原本必須在Runtime執行時的光照計算數量，讓專案得以在保持FPS的穩定之下還能計算光的反射。

模式定义

• 定义：将一个请求封装成一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或者记录请求日志，以及支持可撤销的操作。

• 看图（图片资源来自于百度，侵删）
  

架构、性能、游戏

• 在开始读第一章的时候会觉得有点混乱，作者提出了什么是架构这个问题，但是并没有像其它书里那样给出一个明确的定义，而是提到了：

  这本书是关于上面这一切要使用的代码的组织方式。这里少谈代码，多谈代码组织。

• 仔细品读这句话，你会发现这里面其实已经提到了什么是架构：所谓架构就是代码的组织方式。但是从我个人的认识来看这并不够全面，在这里在引用几段《架构漫谈》中的文字来阐述什么是架构：

  在每个人都必须自己完成所有生活必须品的生产的时候，是没有架构
  的(当然在个人来讲，同一时刻只能做有限的事情，在时间上还是可能会
  产生架构的)。一旦产生的分工，就把所有的事情，切分成由不同角色的什么是架构
  人来完成，最后再通过交易，使得每个个体都拥有生活必须品，而不需要
  每个个体做所有的事情，只需要每个个体做好自己擅长的事情，并具备一
  定的交易能力即可。

  这实际上就形成了社会的架构。那么怎么定义架构呢?以上面这个例
  子为例，把一个整体(完成人类生存的所有工作)切分成不同的部分(分 工)，由不同角色来完成这些分工，并通过建立不同部分相互沟通的机制， 使得这些部分能够有机的结合为一个整体，并完成这个整体所需要的所有 活动，这就是架构。

  软件架构实际上包括了:代码架构， 以及承载代码运行的硬件部署架构。实际上，硬件部署架构最终还是由代 码的架构来决定。因为代码架构不合理，是无法把一个运行单元分拆出多 个来的，那么硬件架构能分拆的就非常的有限，整个系统最终很难长的更大。

• 关于架构和性能的冲突，我认为这个点写的很好，可以说我之前没有这样的认识。长久以来我都希望写出非常面向对象的代码，在我长久的认知中，代码的灵活性、高扩展性和可维护性是最重要的，因此设计模式是我在编写代码时所追求的。

• 但是作者提出良好的架构是需要很大的代价的，因为这需要遵守一些列的准则，Coder必须谨慎的组织代码，而且在引入了抽象，引入了可扩展性，引入的某个设计模式时，我们在增加了代码的灵活性的同时也增加了不可读性，增加了代码复杂度，这就增加了理解的难度。过度的架构设计往往会导致代码库失控，也许你会看到接口和抽象无处不在，我们可能需要花费大量时间才能找到真正功能的代码。关于这一点我也是深有体会，最近在看UniRx库，发现各种接口齐飞，大量的重载，梳理起来确实很费劲。

• 同时，从代码本身执行角度来说，灵活的代码往往意味着执行速度比较慢。从UNITY的角度来说，因为有类似CLR的东西，当使用面向接口编程时，往往意味这具体类型的判断需要在运行期，JIT做的越多，性能也越差。而且还很可能导致无法实现代码缓存，每次运行都需要实时的做判定。

需求

• Editor模式下，在运行或者非运行状态下，能够按照指定的变化率来自动改变material中属性数值。

需求分析

• 如何在Editor模式下获得一个游戏对象及其组件，尤其是在非运行状态下？我们知道在Unity IDE运行起来后是很容易获得一个对象和组件的，在GameObject上挂一个脚本即可。但是在非运行状态下呢，transform.GetComponent这样的方法怎么执行？好在unity已经为我们考虑到了这个问题，提供了[ExecuteInEditMode]Attribute，通过指定这个attribute使得组件类中的方法可以在edit模式下执行，并且是在非运行状态下的。

• 如何在非运行状态下匀速改变数值呢？update方法中配合Time.deltaTime是一个完美的方案，但是即使设置了[ExecuteInEditMode]，update的表现在非运行和运行时也是完全不同的，查资料看到 is only called when something in the scene changed. 这句话时也有种吐槽的冲动。好在unity又为大家考虑到了这个问题（话说unity editor确实功能强大，AssetAtore里面那些插件真是厉害）,Edit模式下提供了EditorApplication.update，这是一个事件，我们注册一个自己的方法就可以在非运行状态下实现update的功能。我个人比较推荐使用EditorCoroutine，一个基于EditorApplication.update的协程实现。

0.出发点

• 现在的项目需要设置多套动画组合，全部是由策划在XML文件中设置完成，如果完全的手动在AnimatorController中去做不但工作量大而且如果将来有配置修改了还要一个个去找到对应的自状态机并且修改。因此就萌生了用代码去生成状态机的想法，而且在网上也有了很多的教程可以参考，只是每个项目都不同，且对于一些参数和属性的设置也不尽相同，因此还是把自己的代码进行一些修改后分享出来，基本上应该是包含了状态机常用的功能。

• 需要注意我的具体代码中是在一个已有的AnimatorController基础上创建的。如果完全是从0开始可以参考别的资料，其实道理是一样的都是代码创建对象。

1.数据来源

一个典型的XML文件

1
2
3
4
5
6
7
8

<?xml version="1.0" encoding="ISO-8859-1"?>
<config>
	<datas>
		<data INDEX="1" Clip1="jump" Clip1Count="1" Clip2="BackLeap" Clip2Count="2" Clip3="die" Clip3Count="1"></data>
		<data INDEX="2" Clip1="BackLeap" Clip1Count="3" Clip2="jump" Clip2Count="0" Clip3="jump" Clip3Count="0"></data>
		<data INDEX="3" Clip1="BackLeap" Clip1Count="1" Clip2="ForwardLeap" Clip2Count="1" Clip3="jump" Clip3Count="1"></data>
	</datas>
</config>