1. 从一次线上崩溃说起Unity内存管理到底管什么做Unity项目这些年最怕的不是功能做不出来而是测试机跑得好好的一到用户手机上就闪退。我印象特别深早些年做一个中低端机型适配的休闲项目包体不大美术资源也不算夸张编辑器里Profiler看着曲线挺平稳结果真机跑二十分钟左右必崩日志里清一色OutOfMemory。当时团队里有人说是贴图太大有人说是GC太频繁还有人怀疑是第三方插件泄漏排查了整整一周最后定位到的问题其实很朴素AssetBundle加载出来的Texture2D没有及时释放加上场景切换时Resources目录下的对象被反复实例化托管堆和非托管堆同时膨胀触发了系统级的内存回收失败。这件事之后我才真正意识到Unity的内存管理不是“知道有GC就行了”这么简单。它横跨了托管内存Managed Memory、非托管内存Native Memory、引擎内部对象Engine Objects三条线每条线的分配、回收、释放时机都不一样而且互相之间还有引用关系。你光盯着Mono堆看没用光盯着Profiler的Total Reserved看也容易误判。真正要搞清楚的是谁在分配、分配到了哪块区域、什么时候会被回收、回收不掉的时候卡在哪。这篇内容适合两类人看。一类是刚接触Unity性能优化、被内存问题折腾过但还没形成系统认知的开发者另一类是有一定经验、但排查内存问题时总是靠“猜”和“试”的中级同学。我会把Unity内存管理的核心机制拆开讲结合我实际踩过的坑把托管堆、GC、AssetBundle、Resources、对象池、Profiler工具链这些串起来给出可以直接照着做的排查流程和优化手段。不堆术语尽量说人话但该有的原理和参数一个都不会少。2. Unity内存的三层结构先搞清楚内存到底花在哪2.1 托管堆、非托管堆与引擎对象的分工Unity的内存大致可以分成三块理解这三块的分工是排查一切内存问题的前提。托管堆Managed Heap是C#脚本层的内存区域由Mono或IL2CPP的运行时管理。你new出来的类实例、字符串、数组、List、Dictionary这些基本都落在这里。托管堆的特点是分配快、回收靠GC但GC的触发时机不完全受你控制而且GC过程中会产生卡顿。托管堆的大小不是固定的它会随着分配增长但增长之后通常不会主动还给操作系统这是很多人看到Reserved内存居高不下的原因之一。非托管堆Native Heap是引擎和底层系统分配的内存比如Texture2D的像素数据、Mesh的顶点缓冲、AudioClip的采样数据、AssetBundle的压缩数据等。这部分内存不受C# GC管理必须通过Destroy、UnloadUnusedAssets或Dispose等显式操作释放。很多“内存泄漏”其实是这部分没释放干净而不是C#对象没回收。引擎对象Engine Objects是Unity内部用C实现的对象比如GameObject、Component、Material、Texture等。你在C#里拿到的其实是一个引用句柄真正的数据在引擎侧。当你Destroy一个GameObject时引擎侧的对象会被标记销毁但托管侧的包装对象要等GC才能回收。这就造成了一个经典现象你明明Destroy了对象Profiler里托管堆还是没降。提示排查内存问题时先分清是托管堆涨了还是非托管堆涨了两者的排查手段完全不同。托管堆看GC Alloc和堆大小非托管堆看Profiler的Detailed视图和Memory Profiler包。2.2 为什么Reserved和Allocated总是对不上在Profiler的Memory区域你会看到几个关键指标Total Allocated、Total Reserved、Mono Heap、Mono Used。很多人第一次看会懵为什么Reserved比Allocated大那么多简单说Allocated是实际用掉的内存Reserved是向系统申请下来、留给Unity用的内存池。Unity为了减少频繁向系统申请内存的开销会一次性申请一块较大的区域然后自己管理分配。所以Reserved通常大于等于Allocated而且Reserved一旦涨上去即使Allocated降下来Reserved也可能不降。这在移动端特别明显因为系统对每个进程的内存有硬上限Reserved过高会导致后续申请失败。我实测过一个项目场景切换后Allocated从180MB降到90MB但Reserved还是维持在220MB左右结果在低内存设备上继续加载新场景时直接崩了。后来通过手动调用Resources.UnloadUnusedAssets配合GC.Collect并调整了AssetBundle的卸载策略才把Reserved压下来。这里的关键是不要只看AllocatedReserved才是决定你能不能继续申请内存的天花板。2.3 托管内存的分配与GC触发机制托管堆的分配逻辑其实不复杂。C#里每次new一个引用类型对象运行时会在托管堆上找一块足够大的连续空间放进去。如果空间不够就触发GC。GC的过程是标记-清除-压缩Mono的Boehm GC是标记-清除IL2CPP用的也是类似的机制先找出所有还被引用的对象把没引用的清掉然后可能做内存压缩。GC触发的主要时机包括托管堆分配达到阈值、显式调用GC.Collect、系统内存压力大时。问题在于GC的阈值不是固定的而且GC过程中会暂停主线程。对于帧率敏感的游戏来说一次Full GC可能导致几十毫秒甚至上百毫秒的卡顿。所以优化的核心思路不是“少用GC”而是减少不必要的堆分配尤其是每帧都在发生的分配。一个典型的反面案例在Update里写string.Format或者拼接字符串每帧都会产生新的字符串对象托管堆迅速膨胀GC频繁触发。我见过一个项目仅仅把Update里的字符串拼接改成缓存好的StringBuilderGC Alloc就从每帧2KB降到了0.1KB帧率稳定性提升非常明显。3. 托管堆优化实战从GC Alloc源头掐断卡顿3.1 用Profiler定位每帧的GC Alloc优化托管堆的第一步不是改代码而是找到谁在分配。Unity Profiler的CPU Usage区域有一个GC Alloc列可以按帧查看每个函数的托管分配量。操作路径是打开Profiler切换到CPU Usage点击某一帧然后在下方列表里按GC Alloc排序。我通常的做法是先跑一个典型场景比如战斗最激烈的时候抓10到20帧看哪些函数的GC Alloc持续偏高。重点关注Update、LateUpdate、FixedUpdate以及协程里的逻辑。如果某个函数每帧都有几百字节到几KB的分配那基本就是优化目标。注意Profiler本身在Editor下会有额外开销GC Alloc的数值可能比真机偏高。建议用Development Build在真机上连Profiler看数据更准。另外Deep Profile模式会大幅增加开销只适合定位具体函数不适合长时间跑。3.2 常见的GC Alloc来源与消除方法根据我的经验托管堆分配主要集中在以下几个地方按出现频率排序字符串操作。string.Format、拼接、ToString()、String.Split都会产生新字符串。优化方法是缓存、用StringBuilder、避免在热路径里做字符串处理。比如UI上的分数显示不要每帧scoreText.text Score: score而是只在分数变化时更新并且用缓存好的字符串数组或StringBuilder。装箱与拆箱。把值类型当object用比如ArrayList、Hashtable、或者方法参数是object但传了int都会触发装箱。优化方法是使用泛型集合ListT、DictionaryTKey,TValue避免用非泛型容器。闭包与委托。Lambda表达式捕获外部变量时会生成闭包类每次执行都可能分配。比如list.ForEach(x { ... })如果捕获了外部变量就会分配。优化方法是把lambda提取成静态方法或者用for循环代替ForEach。数组与集合的临时创建。在Update里new ListVector3()、new RaycastHit[]这类操作每次都会分配。优化方法是把集合声明为成员变量复用而不是重建。Unity自身的一些API也会分配比如GetComponentsT()会返回新数组可以用GetComponentsT(ListT)的重载来避免。协程与yield。yield return new WaitForSeconds(1f)每次都会分配一个新的WaitForSeconds对象。优化方法是缓存WaitForSeconds实例或者用自定义的计时器逻辑。下面这张表是我整理的高频分配点与对应优化手段可以直接对照排查分配来源典型写法优化方案预期收益字符串拼接HP: hp缓存字符串或StringBuilder每帧减少数百字节装箱dict.Add(1, a)用非泛型改用泛型集合消除装箱分配闭包list.ForEach(x ...)改for循环或静态方法消除闭包类分配临时集合new ListT()in Update成员变量复用消除每帧分配协程等待new WaitForSeconds缓存实例减少GC压力GetComponentsGetComponentsT()用List重载消除数组分配3.3 对象池不是万能药但该用就得用对象池是减少频繁创建销毁的经典手段尤其适合子弹、特效、敌人这类高频生成销毁的对象。Unity官方也有ObjectPoolT但很多人用不好反而引入新问题。我的经验是对象池适合生命周期短、创建成本高、数量可控的对象。比如射击游戏的子弹一秒可能生成几十个每个子弹有GameObject、Collider、Rigidbody频繁Instantiate和Destroy开销很大。用对象池预生成一批循环复用能显著降低GC和引擎侧的开销。但对象池不是越多越好。如果池子太大预生成阶段就会占用大量内存如果池子太小频繁扩容又失去意义。我一般会根据峰值数量来定池子大小比如子弹峰值同屏50个池子就设60个留一点余量。另外从池子里取出的对象一定要重置状态位置、旋转、速度、粒子系统、动画状态都要复位否则会出现“复用的子弹带着上次的拖尾”这种诡异问题。提示对象池里的对象在归还时建议先SetActive(false)再放回池子。这样能避免它们继续参与物理计算和渲染减少不必要的开销。取出来时再SetActive(true)。4. 非托管内存与资源释放Destroy了为什么内存没降4.1 AssetBundle的加载与卸载陷阱AssetBundle是Unity资源管理的核心也是内存问题的高发区。很多人以为AssetBundle.Unload(true)就万事大吉了实际上这里面的坑非常多。AssetBundle.Unload(true)会卸载AssetBundle本身以及从它加载出来的所有资源。听起来很彻底但问题是如果这些资源还被场景里的对象引用着卸载后会出现丢失引用、材质变粉、模型消失等问题。而AssetBundle.Unload(false)只卸载AssetBundle的压缩数据保留已加载的资源但这些资源会一直占着内存直到你手动Resources.UnloadUnusedAssets。我踩过的一个典型坑项目里用AssetBundle加载UI图集切换界面时调用Unload(false)以为资源会被自动回收结果反复切换几十次后内存暴涨。原因是图集Texture还被UI组件引用着UnloadUnusedAssets不会回收还在引用的资源。后来改成切换界面时先销毁UI组件再调用Unload(true)同时确保没有其他对象引用这些资源内存才稳定下来。正确的AssetBundle管理策略应该是明确每个Bundle的生命周期引用计数为0时才卸载卸载时确保没有活跃引用。如果项目复杂建议自己封装一层AssetBundle管理器记录每个Bundle的引用计数和依赖关系。4.2 Resources目录的代价与替代方案Resources.Load用起来很方便但它的代价很多人没意识到。Resources目录下的所有资源都会被打进包体并且在游戏启动时加载一部分索引数据。更麻烦的是Resources.Load加载出来的资源如果没有被显式卸载会一直留在内存里Resources.UnloadUnusedAssets只能回收没有被引用的部分。我见过一个项目大量使用Resources.Load加载配置表和图标结果启动内存就比同类项目高出一大截。后来把配置表改成AssetBundle加载图标改成图集按需加载启动内存降了将近40MB。我的建议是Resources目录只放最核心、启动必须的资源比如初始场景的UI、字体、少量配置。其他资源一律走AssetBundle或Addressables。Addressables是Unity官方推荐的资源管理方案它底层也是AssetBundle但提供了更完善的引用计数和异步加载接口适合中大型项目。4.3 Texture、Mesh、Audio的内存占用计算非托管内存的大头通常是Texture、Mesh和AudioClip。了解它们的占用计算方式有助于你在设计阶段就控制内存。Texture的内存占用 宽 × 高 × 每像素字节数 × Mipmap系数。每像素字节数取决于压缩格式RGBA32是4字节RGB24是3字节RGBA4444是2字节ETC2/RGBA是1字节压缩后ASTC根据块大小不同。Mipmap会额外增加约33%的内存。举个例子一张2048×2048的RGBA32贴图不带Mipmap是2048×2048×4 16MB带Mipmap约21MB。如果换成ASTC 6x6压缩大约只有5.5MB。差距非常大。Mesh的内存占用 顶点数 × 每顶点字节数 索引数 × 索引大小。顶点数据包括位置、法线、UV、切线、颜色等每个属性占的字节数不同。一个1万顶点的Mesh如果包含位置(12字节)、法线(12字节)、UV(8字节)、切线(16字节)大约360KB。索引如果是32位每三角形3个索引也要占不少。AudioClip的内存占用 采样率 × 声道数 × 位深 × 时长。未压缩的CD音质44.1kHz、16位、立体声每秒约176KB一分钟约10MB。所以音频一定要压缩移动端常用Vorbis或MP3背景音乐可以流式加载音效可以压缩后常驻。注意Texture的Read/Write Enabled选项会让贴图在内存中保留一份CPU可读的副本内存直接翻倍。除非确实需要在运行时读取像素否则一律关闭。5. 工具链与排查流程用数据说话别靠猜5.1 Unity Profiler的正确打开方式Profiler是排查内存问题的第一工具但很多人只用它看个大概。我的使用习惯是第一步看Memory区域的总体趋势。关注Total Reserved和Total Allocated的变化曲线看是持续增长还是周期性波动。持续增长通常意味着泄漏周期性波动可能是GC或资源加载卸载。第二步用Detailed视图看细分。在Memory区域切换到Detailed可以看到Texture、Mesh、Material、AnimationClip、AudioClip等各类资源的数量和内存占用。如果某一类异常高就重点排查。第三步用Memory Profiler包做快照对比。Unity的Memory Profiler包可以抓取内存快照对比两个时间点的差异精确找到哪些对象在增长。这个工具在排查泄漏时非常有用我一般会在场景切换前后各抓一次快照对比差异。第四步真机连Profiler。Editor下的数据只能参考真机才是最终战场。用Development Build打包连上Profiler跑典型场景看真机上的内存表现。5.2 Memory Profiler包抓快照的实操步骤Memory Profiler包需要通过Package Manager安装。安装后在Window菜单下打开Memory Profiler。操作流程是运行游戏到达想要分析的状态。在Memory Profiler窗口点击Capture抓取快照。快照抓取后可以看到所有托管对象、引擎对象、资源对象的列表。点击某个对象可以查看它的引用链找到谁在引用它。对比两个快照看哪些对象数量增加了。我通常会在以下几个时间点抓快照游戏启动后、进入主场景后、战斗结束后、返回主菜单后。对比这几个快照就能看出哪些资源没有释放。提示抓快照会暂停游戏而且快照文件可能很大建议在真机上抓取时关闭其他无关应用避免干扰。5.3 常见内存问题的排查速查表下面这张表是我在实际项目中总结的常见内存问题与排查方向遇到问题时可以按表索骥现象可能原因排查工具解决方向托管堆持续增长每帧分配未回收、事件未注销Profiler GC Alloc消除热路径分配、注销事件Reserved居高不下资源未卸载、内存池未收缩Memory Profiler卸载AssetBundle、UnloadUnusedAssets切换场景后内存不降静态引用、单例持有、协程未停Memory Profiler引用链清理静态引用、停止协程真机闪退系统内存上限、大图未压缩真机日志、Profiler压缩贴图、分帧加载GC卡顿明显Full GC频繁、堆碎片多Profiler CPU减少分配、分帧GC资源重复加载AssetBundle重复加载、缓存未命中AssetBundle浏览器引用计数、缓存管理6. 几个我踩过的坑和对应的解决思路6.1 静态引用导致的内存泄漏静态字段是内存泄漏的常见元凶。因为静态字段的生命周期和应用程序域一样长只要它引用了一个对象这个对象就永远不会被GC回收。我遇到过一个案例一个静态的ListEnemy缓存了所有敌人敌人被Destroy后没有从列表里移除导致所有敌人的托管对象和引擎对象都无法释放。战斗打了几十波之后内存直接爆掉。解决方法是静态集合一定要在对象销毁时同步移除。可以在OnDestroy里做清理或者用弱引用WeakReference来持有对象。另外事件监听也要注意event如果没注销发布者会一直持有订阅者的引用导致订阅者无法回收。6.2 协程未停止引发的连锁反应协程是另一个容易出问题的地方。如果一个协程在对象销毁后还在运行它可能继续访问已经销毁的对象导致异常也可能持有引用导致内存无法释放。我见过一个项目场景切换时没有停止所有协程结果旧场景的协程还在跑引用了旧场景的对象导致旧场景的资源一直无法卸载。解决方法是在对象销毁或场景切换时显式停止所有协程。可以在OnDestroy里调用StopAllCoroutines或者自己维护一个协程列表统一管理。另外协程里的yield return如果等待的是自定义的YieldInstruction也要确保这些指令在对象销毁后不会继续执行。6.3 大图集与Mipmap的取舍图集是UI优化的常用手段但大图集也会带来内存问题。一张4096×4096的图集RGBA32格式带Mipmap内存占用约85MB这在移动端是灾难性的。我见过一个项目UI图集做了三张4096×4096结果光UI就占了250MB内存。优化思路是按功能拆分图集控制单张图集大小不超过2048×2048。对于不需要缩放的UI元素可以关闭Mipmap。对于确实需要大图的场景考虑用压缩格式比如ASTC。另外UI图集里的透明区域也会占内存尽量把图集排布得紧凑一些。6.4 真机与Editor的内存差异Editor下的内存表现和真机差异很大原因有几个Editor本身占内存、Editor下的资源加载路径不同、Editor下没有真正的平台压缩。所以永远不要用Editor的内存数据来判断真机表现。我的习惯是在Editor下做初步排查定位大致方向然后打包到真机上验证。真机测试时用Profiler连真机或者用adb logcat看系统日志里的内存信息。对于iOS可以用Xcode的Instruments工具看内存分配。对于Android可以用dumpsys meminfo看进程内存。提示真机测试时尽量用低端机做压力测试。高端机上跑得稳不代表低端机没问题而低端机的内存上限往往更低更容易暴露问题。7. 内存优化的优先级与长期维护7.1 先解决大头再抠细节内存优化最忌讳一上来就抠细节。正确的做法是先用Profiler找到占用最大的几块集中火力解决然后再处理小问题。比如一个项目总内存300MBTexture占了150MB那优化Texture的收益远大于优化脚本里的几个小分配。我一般的优先级是Texture Mesh AudioClip AssetBundle冗余 托管堆分配 其他。Texture通常是最大的头压缩格式、尺寸、Mipmap、Read/Write都是可以下手的地方。Mesh次之合并网格、减少顶点属性、用LOD都能降内存。AudioClip用压缩格式和流式加载。AssetBundle要避免重复打包和冗余依赖。7.2 建立内存预算与监控机制对于中大型项目建议建立内存预算。比如设定主场景内存不超过200MB战斗场景不超过250MBUI不超过50MB。每次版本迭代后用自动化工具跑一遍内存测试看是否超标。超标就排查找出新增的内存占用。监控机制可以用Unity的Profiler API在运行时定期采样内存数据上传到服务器做统计。这样能及时发现线上版本的内存异常。我见过一些团队会在内部测试包里加一个内存面板实时显示当前内存占用和峰值方便测试同学反馈问题。7.3 资源规范与团队协作内存问题很多时候不是技术问题而是规范问题。美术同学导出贴图时用了4096×4096程序同学加载后忘了卸载策划同学配置了大量重复资源这些都会导致内存问题。所以建立资源规范很重要。规范包括贴图尺寸上限、压缩格式要求、Mipmap使用规则、音频格式和时长限制、AssetBundle打包规则、资源引用计数规范等。这些规范要写成文档在团队内同步并且在导入资源时做自动检查。比如写一个AssetPostprocessor在贴图导入时自动设置压缩格式和尺寸上限超过就报警。7.4 版本迭代中的内存回归测试每次版本迭代都可能引入新的内存问题所以内存回归测试是必要的。我一般会在CI流程里加一个内存测试环节用自动化脚本跑一遍核心场景采集内存数据和上一个版本对比。如果内存增长超过阈值就阻断合并要求开发者排查。这个机制一开始可能会觉得麻烦但长期来看能避免很多线上问题。我经历过一次版本更新后内存暴涨导致大量用户闪退的事故事后复盘发现是新增的一个特效资源没有压缩单这一个资源就多了80MB。如果当时有回归测试这个问题在合并前就能发现。8. 一些零散但实用的经验关于GC.Collect的调用时机。很多人建议不要手动调用GC因为会卡顿。但在某些场景下比如场景切换的Loading界面手动调用一次GC是合理的因为这时候玩家对卡顿不敏感而且能及时释放内存避免后续加载时内存不足。我的做法是在Loading结束时调用GC.Collect和Resources.UnloadUnusedAssets然后等一帧再进入新场景。关于Resources.UnloadUnusedAssets的耗时。这个API会遍历所有资源检查引用关系耗时可能达到几百毫秒甚至更长。所以不要在游戏过程中频繁调用最好在Loading界面或者暂停时调用。另外它只能回收没有被引用的资源如果有静态引用或者事件持有它也无能为力。关于Texture的Streaming Mipmap。这个功能可以让贴图按需加载Mipmap级别减少初始内存占用。对于大世界场景或者开放世界游戏很有用。但它的代价是增加IO和CPU开销而且需要配合Mipmap Streaming系统使用。如果项目不大可以不开。关于IL2CPP与Mono的内存差异。IL2CPP生成的代码是C运行时内存管理机制和Mono不同。IL2CPP的托管堆通常比Mono更紧凑但生成代码的体积更大。另外IL2CPP下的一些反射操作可能产生更多分配。如果项目从Mono切换到IL2CPP建议重新做一遍内存测试。关于AssetBundle的压缩格式。LZ4比LZMA加载快但包体大LZMA包体小但加载慢且内存占用高。移动端通常用LZ4因为加载速度更重要。如果包体是瓶颈可以考虑LZMA但要做好加载时的内存预留。关于图集的Padding。图集打包时Sprite之间需要留Padding避免采样时出现边缘渗色。但Padding太大会浪费空间太小又可能出问题。一般建议2到4像素具体看Sprite的过滤模式和缩放情况。关于RenderTexture的释放。RenderTexture是容易被忽略的内存大户尤其是后处理效果用的RenderTexture。如果每帧创建新的RenderTexture内存会迅速膨胀。正确的做法是复用RenderTexture或者用RenderTexturePool来管理。另外Camera.targetTexture用完后要记得释放。关于Shader的内存占用。Shader本身占的内存不多但Shader Variant会显著增加包体和内存。如果项目里Shader Variant数量失控不仅包体大运行时加载和编译也会占内存。建议用Shader Variant Collection来管理剔除不必要的变体。关于字体资源。中文字体文件通常很大一个完整的中文字体可能十几MB。如果项目里用了多个字体内存占用会很可观。优化方法是按需打包字体只包含用到的字符或者用动态字体字体图集的方式。TextMeshPro在这方面做得比较好支持字体图集和动态加载。关于音频的加载方式。Unity的AudioClip有Decompress On Load、Compressed In Memory、Streaming三种加载方式。Decompress On Load适合短音效加载后解码到内存播放快但占内存。Compressed In Memory适合中等长度音频保持压缩状态在内存播放时解码。Streaming适合长音频比如背景音乐边读边播内存占用最小但IO开销大。根据音频长度和播放频率选择合适的加载方式能省不少内存。关于场景加载的内存峰值。场景加载时新旧场景的资源可能同时存在导致内存峰值。如果峰值超过系统上限就会闪退。优化方法是先卸载旧场景不需要的资源再加载新场景或者用Additive加载分帧加载资源避免一次性加载太多。另外Loading界面本身也要控制内存不要用太大的图。关于内存泄漏的排查思路。如果怀疑内存泄漏可以按以下步骤排查先用Memory Profiler抓两个时间点的快照对比对象数量找到增长最多的对象类型查看这些对象的引用链找到谁在持有它们如果是静态引用检查静态字段如果是事件检查事件注销如果是协程检查协程停止如果是AssetBundle检查引用计数和卸载逻辑。这个过程可能需要反复几次但只要有耐心基本都能定位到。关于内存优化的收益评估。优化之前先估算收益优先做收益大的。比如压缩一张4096的贴图到2048可能省几十MB收益很大优化一个每帧分配100字节的字符串可能只省几KB收益很小。把精力放在大头上面小问题可以后续慢慢处理。关于团队内的内存意识培养。内存优化不是一个人的事需要整个团队都有意识。我一般会在团队内做分享讲清楚内存问题的危害和常见原因让美术、策划、程序都知道自己的操作对内存的影响。另外在代码审查时关注内存分配在资源导入时做自动检查形成习惯之后内存问题会少很多。关于内存测试的自动化。如果团队有CI可以加一个内存测试环节。用自动化脚本跑核心场景采集内存数据和基线对比。这样每次提交都能及时发现内存回归。实现方式可以用Unity的Profiler API或者用ProfilerRecorder采集特定指标。数据可以存到数据库做趋势分析。关于低内存设备的适配。低端机的内存上限可能只有1GB甚至更低系统本身占一部分留给应用的可能只有几百MB。所以低端机适配要特别小心。我的做法是在低端机上降低贴图质量、关闭后处理、减少同屏对象数量、缩短音频长度、用更激进的资源卸载策略。另外可以在游戏内加一个画质选项让玩家自己选择低端机默认低画质。关于内存与性能的平衡。内存优化有时候会牺牲性能比如压缩贴图会增加解压开销流式加载会增加IO。所以要在内存和性能之间找平衡。我的原则是先保证不闪退再保证帧率稳定最后才追求极致的内存占用。如果内存充足可以适当放宽压缩提升画质和性能。关于未来趋势。Unity的内存管理机制在持续演进比如DOTS、ECS、Burst这些技术对内存的使用方式和传统GameObject完全不同。如果项目在用这些技术内存管理的思路也要调整。另外Addressables在逐渐取代Resources和手动AssetBundle管理建议新项目直接上Addressables。这些经验都是我在实际项目中一点点积累的有些是踩坑之后才明白的有些是同行交流时学到的。内存管理没有银弹关键是理解原理、用好工具、建立规范、持续监控。希望这些内容能帮你少走一些弯路。