东北砍王的栖息地

如果打开一个界面非常卡，是不是因为加载太慢了呢？是不是因为资源太大了呢？这个问题，一定仔细分析，因为打开界面，不是单纯的加载行为。我们目前的AssetManager管理资源，加载支持异步与同步。异步是完全异步，加载AssetBundle文件、从AssetBundle加载文件都是异步操作（因为Unity版本，异步加载AssetBundle主线程还是会有消耗，最新的Unity版本解决了这个问题，同时从AssetBundle异步加载文件结束，返回主线程时的消耗也进行了优化）。而同步加载，加载AssetBundl

如果相对项目做优化，那就要先按照如下顺序考虑（按照影响力）：1.资源影响最大的一个选项，应该优先考虑可能很简单的一个设置，就可以减少30%的内存消耗等等2.引擎3.代码尽量避免一些很过分的写法4.着色器一般很少会改，因为优化一点就达不到美术要的效果了1.资源（最优先）动态物体 1。主角、NPC、怪物 面片数量：300-2000面片，消耗GPU SkinnedMeshRenderer数量：1个，GPU蒙皮技术也要求一个 材质数量：1-3种 骨骼数量

根据雨松大大的文章，代码如下：具体结果输出为：1.池总容量：Power.capacity（毫安）2.电压：Power.voltage（伏）3.实时电流：curE（毫安）4.实时平均功率：avgE * Power.voltage5.满电量能玩：(Power.capacity / avgE).ToString(“f2”)（小时）public class Power{ static public float electricity { get {#

基础：RGB：三原色。（颜色都是RGB按照一定比例搭配而成）Alpha：透明度。RGBA32：就是每个通道占8位。（越高越好，低的有明显的色块）NPOT：Not Power of Two不是二的整数次幂大小计算：1.1024 * 1024，RGBA32：每个像素32位，也就是4字节：1024 * 1024 * 4 = 4M2.1024 * 1024，ASTC 4 * 4 block一个block是16个字节：1024 * 1024 * (16 / 4 * 4) = 1M压缩格式：JPG

1.CanvasCanvas下所有的UI元素都是合在一个Mesh中的。过大的Mesh在更新时会开销很大，复杂的UI界面应该自成一个Canvas。但是过多的Canvas会导致Draw Call的上升。动态元素会导致Canvas的Rebuild（mesh更新），要做到动静分离。Set Dirty，UGUI会在这一帧收集所有的修改，统一进行处理。2.Scroll Rect滚动的时候会触发 Canvas.SendWillRenderCanvases。应该是开启了 Pixel Perfect的选项，

很多地方需要滑动列表，比如：排行榜。滑动列表组件：其中ScrollView，就是控制滑动的组件Viewport就是视野区域，通过Mask控制可显示的范围Content就是真实滑动的区域，长度可能为很长很长滑动通过控制，达到不同的区域透过视野区域显示的效果问题：假如有1000个人，就需要实例化1000条对应的记录很浪费性能其实真正现实的永远那么几个，可以优化做成循环滑动列表1.向上滑动，下面的通过移动补到上面2.向下滑动，上面的通过移动补到下面若能显示n个记录真正只需要n+1个记

不多bb了，看图原因：tile格式，会导致每个tile生成一个面MeshType :Full Rect 和 Tight的区别：Full Rect：Tight：

参考文章：Unity 游戏的 string interning 优化C#的字符串优化-String.Intern、IsInternedhttp://172.17.144.30:8082/browse/DHR-3071.优化字符串数量字符串是不可变的，每次修改字符串都会生成一个新的字符串即使创建了两个相同的字符串，也会生成2个对象问题是啥：1.string创建与销毁的时机2.是否存在重复的字符串3.存在没有意义的字符串对象4.capacity远大于length5.string泄露那对

参考文章：图形渲染及优化—Unity合批技术实践图形渲染及优化—Batch批是啥？对某对象进行批量处理叫批处理Batch是啥？引擎每帧提交的Batch数量就是衡量渲染压力的指标Batch就是调用一次API的绘制接口向GPU提交相同渲染状态的一定数量的三角形的行为接口：OpenGL的glDrawArrays/glDrawElementsBatch等于一堆打包后的Draw call什么叫合批：以中性能优化的方式将多次绘制请求，在允许的条件下进行合并处理，减少CPU对GPU绘制请求的次数

参考文章：扒一扒Profiler中这几个“占坑鬼”1.WaitForTargets一般CPU开销过低，切设定了目标帧率情况下当上一帧低于目标帧率时，将会在本帧产生一个WaitForTargetFPS的空闲等待耗时，以维持目标帧率这个是在Unity主循环中 根据上一帧的CPU耗时，在当前帧最早的时候 通过增补 WaitForTagertFPS 的方式运行 FPS 维持到目标值eg：目标帧率 30，每一帧 1/30 = 0.033s上一帧消耗 15ms当前帧WaitForTagetFPS将会是3

这是我在《Unity游戏优化 (第2版)》看的，记录一下~Unity Profiler 是啥？是内置的一种方便的方法，通过在运行时为大量的Unity3D子系统生成使用情况和报告统计，来缩小性能瓶颈的搜索范围可以给不同的子系统收集如下数据：1.CPU消耗量（每个主要子系统）2.基本和详细的渲染和GPU信息3.运行时内存分配和总消耗量4.音频源/数据的使用情况5.物理引擎（2D和3D）的使用情况6.网络消息传递和活动情况7.视频回放的使用情况8.基本和详细的用户界面性能9.全局光照统计数

这是我在《Unity游戏优化 (第2版)》看的，记录一下~如何更快速的找到问题的根源呢？- 验证目标脚本是否出现在场景中不要理所当然，可以搜索一下脚本是否存在于场景中在Hierachy窗口中搜索 t:XXX，并且判断它是否激活- 验证脚本在场景中出现的次数是否正确可能自身调用了重复的方法，产生了性能瓶颈- 验证事件的正确顺序最不可预测的可能是 WaitForSeconds yield 类型- 最小化正在进行的代码更改少加入log啥的，可能会影响性能- 尽量减少内部干扰垂直同步（VSy

Profiler只是可用的工具之一有时也不确定它是否能给出正确答案，因为它的开销太大了也可能当我们不用unity的，不提供这个工具了，也需要一种方法来测试分析那咋整呢？可以实现一个计时系统.Net 库提供了 一个类 System.Diagnostics.Stopwatich可以随时停止和启动，很容易度量耗费了多长时间（精确到毫秒）public class CustomTimer : IDisposable{ string _timerName; int _numTests;

这是我在《Unity游戏优化 (第2版)》看的，记录一下~写Mono脚本的时候需要注意哪些问题呢？大概从以下几个方面介绍：1.访问组件获取组件有三种方式GetComponent(string)GetComponent<T>()GetComponent(typeof(T))其中：泛型的最快，应该优先用这个字符串的最慢，如非必要情况，绝对不要使用这个另外：需要经常访问的组件尽可能地来缓存每次都会节省一些CPU开销，代价是少量内存消耗2.函数回调Unity最常用的回调

这是我在《Unity游戏优化 (第2版)》看的，记录一下~批处理是啥？一般出现在3D图形和游戏中大概意思就是：将大量任意数据快组合在一起并将它们作为单个大数据块进行处理的过程对CPU或GPU友好，可以使用多个内核同时处理多个任务批处理和分别处理有啥区别呢？在内存中的不同位置来回切换内核是需要时间的，因此切换内核所花的时间越少越好批处理的对象通常指：网格、顶点、边、UV坐标或者其他用于描述3D对象的不同数据类型的大集合也可以简单代表批处理音频、Sprite、纹理以及其他大数据集的行为Un

这是我在《Unity游戏优化 (第2版)》看的，记录一下~批处理的目的：就是减少在当前视图中渲染所有对象所需的DrawCall数量DrawCall是啥？基本概念：就是一个从CPU发送到GPU中用于绘制对象的请求也就是为初始化当前渲染过程之前的配置选项（Unity中也叫做 SetPassCall）请求DrawCall之前需要准备什么呢？1.网格和纹理数据必须从CPU内存（RAM）推送到GPU内存（VRAM）中（通常发生在场景初始化期间，或者是实例化场景物体完成时）CPU必须配置处理对象（

这是我在《Unity游戏优化 (第2版)》看的，记录一下~在Unity中，渲染状态本质是通过材质呈现给开发者的那么材质是啥呢？材质是着色器的容器着色器又是啥呢？着色器是一种用于定义GPU应该如何渲染输入顶点和纹理数据的简短程序本身没有必要的状态信息来完成任何有价值的工作需要诸如漫反射纹理、法线映射和光照信息之类的输入，并有效地规定了为了呈现传入的数据需要设置哪些渲染状态变量PS：着色器最初仅实现为处理对象的光照和着色现在已经有额外的功能了，但是还用这个名字其关系：每个着色器都需要一个

FrameDebugger是啥？是一个帮助批处理是如何影响场景的工具，如何打开？Windows/Analysis/FrameDebugger（如上图所示）左边是GPU指令列表，右边是选中的DrawCall的详情介绍：左边列出了场景中的所有DrawCall每一项表示一个唯一的DrawCall和它的渲染对象单击任意一项，就能立刻在Game窗口中看到场景中渲染到所单击的那一项所需的DrawCall好处：可以快速、直接的区分两个连续的DrawCall也很容易准确地指出DrawCall渲染了

这是我在《Unity游戏优化 (第2版)》看的，记录一下~动态批处理可以降低DrawCall，他有啥优势呢？1.批处理在运行时生成（批处理是动态产生的）2.批处理中包含对象在不同的帧之间可能有所不同，这取决于哪些网格在主摄像机视图中当前是可见的3.甚至能在场景中运动的对象也可以批处理举个例子：首先需要需要关闭影子显示关闭静态动态批处理关闭天空盒子如图所示，为啥有9个DrawCall呢？1.有1个批处理渲染场景的背景2.剩余8个批处理渲染8个对象那么要是开启动态批处理呢？

这是我在《Unity游戏优化 (第2版)》看的，记录一下~Unity也提供了第二种批处理机制：静态批处理其最大的区别就是：只能处理标记为Static的对象，因此叫静态批处理静态批处理的要求：1.网格必须标记为Static（里面的Batching Static）通过Inspecter面板设置缺点就是不能修改对象的变换（移动、旋转、缩放）2.每个被静态批处理的网格都需要额外的内存取决于批处理网格中复制的次数静态批处理工作时，会把所有标记为static的可见网格数据复制到一个更大的网格数据缓冲

这是我在《Unity游戏优化 (第2版)》看的，记录一下~了解了音频加载方式和音频格式后，如何来优化一下性能呢？1.最小化活动音源数量每个播放中的音频源消耗特定数量的CPU，因此禁用场景中冗余的音频源可以节省CPU周期限制同时播放音频文件的实例数（同时有10个脚印声和同时有20个脚印声听起来没啥区别）2.为3D声音启用强制为单声道启用 Force to Mono （强制为单声道）设置后来自两个音频通道的数据混合到一个通道中，文件的磁盘和内存空间使用量有效地降低了50%一般不给2d的用，就给

这是我在《Unity游戏优化 (第2版)》看的，记录一下~Unity支持3种音频文件的编码格式可以通过 Compression Format设置：a.Compressed（会随着平台不同而不同）独立应用程序和其他非移动平台将会转换为 Ogg Vorbis 格式移动平台则转换为MP3格式此处展示了压缩所节省的磁盘空间预估值（仅针对当前buildTarget）Original Size是原始文件大小Imported Size是磁盘上的开销大小b.PCMPCM是一种无损的、未压缩的音频格式，

这是我在《Unity游戏优化 (第2版)》看的，记录一下~艺术是一个非常主观的领域，由个人的意见和偏好所支配支持游戏艺术性的艺术资产背后的技术也是非常主观的Unity中有多种不同的资源类型首先探索一下音频文件啥玩意是音频文件？少数音效或者单一背景音乐，或者数百万行对话、音乐和环境音效等等有啥问题呢？运行时的音频处理会造成CPU和内存的消耗为啥有这问题呢？过度压缩、或者过多的音频操作、过多的活动音频组件、低效的内存存储方法和访问速度等等将音频文件导入Unity中1.加载音频文件怎

音频资源导入后如下图：1.内存开销Imported Size 是内存开销。2.CPU开销LoadType 是 加载方式。a.Decompress On Load：加载时就解压。（占用内存大，但是对CPU开销小）b.Compressed In Memory：加载时是压缩格式，播放时解压。（内存小，CPU开销大）c.Steaming：加载时不加到内存里，播放前会被读取到内存中。（内存最小，CPU开销最大）Compression Format 是 压缩格式。a.PCM：不压缩。（内存大，CPU

这是我在《Unity游戏优化 (第2版)》看的，记录一下~内存效率是性能优化的一个重要元素有啥问题呢？不必要的内存分配由于过高的垃圾回收（消耗CPU时间）将导致糟糕的用户体验内存泄漏将导致崩溃1.Mono平台Mono是个开源项目，基于API、 规范和微软的.Net Framework的工具构建了自己的类库平台本质上，是.Net类库的开源重置，在几乎不访问原始源码的情况下完成，和微软的原始类库完全兼容Mono项目的目标是通过框架提供跨平台开发，也就是说用一种编程语言编写的代码运行在很多不同的

这是我在《Unity游戏优化 (第2版)》看的，记录一下~垃圾回收是啥？重要工作就是 确保不使用比所需要的更多的托管堆内存，而不再需要的内存会自动回收比如创建一个GameObject，接着销毁他，那么GC将标记该GameObject使用的内存空间，以便以后回收GC不会立即回收，只在有需要的时候回收当请求使用新的内存空间，托管的堆内存中有足够的空间空间以满足该请求时，GC只简单的分配新的空间并交给调用者如果没有足够空间，那GC就开始扫描所有已存在并且不再使用的内存分配并清除他们（GC一般作为扩展