maybe I need grow more

最新推荐文章于 2025-05-06 00:45:14 发布

原创最新推荐文章于 2025-05-06 00:45:14 发布 · 789 阅读

1 ·

CC 4.0 BY-SA版权

Unity Engine 同时被 2 个专栏收录

15 篇文章

订阅专栏

优化相关

8 篇文章

订阅专栏

本文探讨了Unity5.x中的内存优化和AssetBundle（AB）机制，包括图形学和渲染优化、AB资源加载与卸载、C#闭包和匿名函数的区别。重点介绍了AB的LZ4压缩、WWW加载方式以及内存管理策略，同时涉及lua与C#的交互。文章还提到了内存优化技巧，如减少字符串拼接、缓存组件和避免闭包的过度使用，以及流畅度优化策略，如减少MeshCollider使用和优化光照方案。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

成长，也许从来都不是一件容易的事儿。

内存优化
图形学、渲染优化
AssetBundle资源加载和卸载
C#高级特性（闭包和匿名函数的区别）

闭包和匿名函数的区别：

解释1: 闭包是指有权访问另一个函数作用域中的变量的函数。

解释2:闭包是一个函数和该函数被定义时的词法环境的组合，一个函数的返回值是一个函数引用，外部调用这个函数的引用时，需要堆栈中保留函数执行的变量环境，这种关系就叫做闭包。

匿名函数，一般用到匿名函数的时候都是立即执行的。通常叫做自执行匿名函数或者自调用匿名函数。常用来构建沙箱模式，作用是开辟封闭的变量作用域环境，

闭包跟函数是否匿名没有直接关系，匿名函数和具名函数都可以创建闭包。

Unity5.X的AB机制

http://www.cnblogs.com/murongxiaopifu/p/5629415.html#autoid-3-3-0

ChunkBasedCompression 新增LZ4进行压缩，加载时不需要加载整个AB，只加载对应数据块儿。

新增Manifest清单文件记录AB依赖关系，不必要再需要人为的处理PopAssetDependencies/PushAssetDependencis

AB压缩格式：

Lzma 默认的ab压缩格式，压缩比很高，但是加载时需要整个加载ab文件，会影响运行时加载速度，形成较大的内存开销。

不压缩，不压缩的AB加载速度快，但是体积大。

Lz4时5.3版本之后新增的压缩选项，压缩比没有lzma高，但优点在于加载时不需要整个加载AB，因此在加载速度和内存上有较大优势。

随包的AB建议lz4压缩，兼顾文件大小和加载速度，网络更新的ab建议lzma压缩，高压缩比可以减少数据流量。

www（url）的加载方式，加载完成后会在内存中创建较大的webStream，通常为原AB大小的3-5倍，便于后续加载直接从内存加载。

www.loadFromCacheOrDownload（）改方法的优势在于能将解压缩之后的ab文件存入磁盘作为缓存，只会在内存中创建较小的serilizedFile。而后的AssetBundle.loadAsset直接通过IO从磁盘缓存中获取。

AssetBundle.loadFromFile 与老版本CreatFromFile机制上的区别在于，之前版本只支持从解压后的AB文件创建资源，新版本对于无压缩或者LZ4方式的AB文件可以直接创建AssetBundle对象。

UWA关于AssetBundle的建议：

1/ 对于需要常驻内存的Bundle文件来说，优先考虑减小内存占用，因此对于存放非Prefab资源（特别是纹理）的Bundle文件，可以考虑使用WWW.LoadFromCacheOrDownload或AssetBundle.CreateFromFile加载，从而避免WebStream常驻内存；

2/ 而对于存放较多Prefab资源的Bundle，则考虑使用new WWW加载，因为这类Bundle用WWW.LoadFromCacheOrDownload加载时产生的SerializedFile可能会比new WWW产生的WebStream更大。

3/ 对于加载完后即卸载的Bundle文件，则分两种情况：优先考虑速度（加载场景时）和优先考虑流畅度（游戏进行时）。

1）加载场景的情况下，需要注意的是避免WWW对象的逐个加载导致的CPU空闲，可以考虑使用加载速度较快的WWW.LoadFromCacheOrDownload或AssetBundle.CreateFromFile，但需要避免后续大量地进行Load资源的操作，引起IO开销（可以尝试直接LoadAll）。

2）游戏进行的情况下，则需要避免使用同步操作引起卡顿，因此可以考虑使用new WWW配合AssetBundle.LoadAsync来进行平滑的资源加载，但需要注意的是，对于Shader、较大的Texture等资源，其初始化操作通常很耗时，容易引起卡顿，因此建议将这类资源在加载场景时进行预加载。

只在Bundle需要加密的情况下，考虑使用CreateFromMemory，因为该接口加载速度较慢。

尽量避免在游戏进行中调用Resources.UnloadUnusedAssets()，因为该接口开销较大，容易引起卡顿，可尝试使用Resources.Unload(obj)来逐个进行卸载，以保证游戏的流畅度。

AB加载卸载的操作流：

各种加载方式的内存、性能对比图：

内存优化&流畅度（fps）优化

代码GC和卡顿：

字符串拼接、

循环内部New对象、

反射减损、FieldInfo/MethodInfo缓存

循环for/foreach/iterator、foreach效率最差

装箱拆箱，

缓存所需的动态MonoBehaviour组件，或者在频繁instantiate/destroy应考虑pooling

异步waitfor进行缓存

不再运行时大量使用闭包（闭包效率？）

尽可能重用容器，以及容器操作的合理性（dic/list扩容，移除顺序）

不要大量使用delegate的-=/+=，

当你的对象订阅了外部的事件，而又没有取消订阅，那么该对象是不会被GC回收的！这会造成很恐怖的问题，产生了几千万个对象没法被回收。而且匿名函数无法取消订阅，就算是两个代码格式完全一样的匿名函数，编译器生成的也是两个不同的方法签名。链接：http://www.cnblogs.com/buptzym/archive/2013/03/15/2962300.html

减少不必要的 shader varients

关于代码GC的原理和优化思路：

https://www.cnblogs.com/zblade/p/6445578.html