1. 从一次项目崩盘说起Unity资源管理到底难在哪如果你做过超过半年的Unity项目大概率经历过这样的场景项目初期一切顺畅资源随手拖、随手放美术给什么就塞什么反正能跑起来就行。等到项目进入中期场景越堆越多包体从几十兆膨胀到几个G打开编辑器要等五分钟切个场景卡到怀疑人生美术改一张图整个工程重新导入半小时——这时候你才意识到资源管理这件事从来不是“以后再说”的小问题而是能直接拖垮项目进度的隐形杀手。我见过太多团队在资源管理上栽跟头。有个做休闲游戏的朋友项目做到80%的时候发现包体超标硬生生花了两周时间做资源精简和重构原本计划的上线时间直接推迟。还有个做数字孪生项目的团队场景里塞了几百个高精度模型运行时内存直接爆掉最后不得不把已经做好的效果砍掉一半。这些问题的根源都不是技术能力不够而是从一开始就没有建立起对Unity资源管理体系的正确认知。这篇内容就是想把Unity资源管理这件事从头捋一遍。我会先讲清楚Unity的资源体系到底是怎么运作的然后逐个拆解那些最常见的痛点——包体膨胀、加载卡顿、内存泄漏、引用混乱、平台适配——每个痛点都会说清楚它的成因、表现和排查思路。不管你是刚接触Unity的新手还是做了几年但一直没系统梳理过资源管理的开发者都能从中找到对自己有用的东西。关键词就三个Unity、资源管理、痛点分析我们一个一个来。2. Unity资源体系的全貌先搞清楚你在管什么2.1 Assets、Library、Packages、ProjectSettings四个目录的分工很多人做Unity开发好几年其实从来没认真看过工程目录里那几个文件夹到底是干什么的。你打开一个Unity工程根目录下通常有这几个东西Assets、Library、Packages、ProjectSettings可能还有Logs、Temp、obj这些临时目录。它们各自承担什么职责直接决定了你该怎么管理资源。Assets目录是你唯一需要手动管理的目录。所有美术资源、脚本、场景、预制体、配置文件全部放在这里。Unity只会把这个目录下的内容纳入版本控制其他目录都是自动生成的。所以你在做版本管理的时候只需要管好Assets和ProjectSettings就够了。Library目录是Unity的本地缓存里面存的是资源的导入结果。你往Assets里放一张PNGUnity会把它转换成引擎内部使用的格式转换结果就放在Library里。这个目录可以随时删掉重建但重建的过程就是重新导入所有资源大项目可能要等几十分钟甚至几个小时。这也是为什么换电脑或者拉新分支之后第一次打开工程特别慢的原因。Packages目录管理的是项目依赖的包包括Unity官方包和你自己引入的第三方包。manifest.json文件记录了当前项目依赖了哪些包packages-lock.json则锁定了具体版本。这个目录的存在意味着你不需要把第三方库的源码直接拖进Assets里而是通过包管理的方式来引用升级和移除都更干净。ProjectSettings目录保存的是项目的各种设置包括图形质量、物理参数、输入映射、标签层、时间设置等等。这个目录里的文件都是文本格式适合纳入版本控制团队协作时能保证所有人的项目设置一致。理解这四个目录的分工之后你就能明白一个基本原则Assets目录的组织结构直接决定了你的资源管理效率。Library和Packages你基本不用操心但Assets怎么规划是每个团队必须认真对待的事情。2.2 资源的导入管线从原始文件到引擎可用资产Unity的资源导入管线是一个容易被忽视但极其重要的环节。你往Assets里丢一个FBX模型Unity不会直接拿这个FBX去渲染而是会经过一系列处理解析模型数据、生成网格、提取材质、烘焙贴图引用、生成预制体——最终产出一个引擎内部使用的Asset。这个过程中导入设置Import Settings是关键。每个资源都有自己的导入设置面板比如贴图有压缩格式、分辨率上限、Mipmap开关模型有缩放因子、网格压缩、材质导入方式、动画导入选项。这些设置决定了资源最终在包体和内存里占多大、长什么样。问题在于很多开发者从来不主动调整导入设置全部用默认值。默认值在项目初期可能没问题但随着资源数量增加不合理的导入设置会成倍放大资源开销。比如一张4096x4096的贴图如果实际只需要显示在UI上的小图标默认设置会把它完整加载进内存浪费大量空间。再比如一个模型如果不需要读写网格数据却开启了Read/Write Enabled内存里就会多存一份网格副本。导入管线的另一个关键点是依赖关系。一个材质引用了贴图一个预制体引用了材质和网格一个场景引用了预制体——这些引用关系构成了资源之间的依赖图。Unity在打包和加载时会沿着依赖图把所有需要的资源都带上。如果依赖关系混乱就会出现“我只想加载一个UI图标结果把整个角色模型都拉进来了”这种荒唐事。2.3 运行时资源的生命周期加载、使用、卸载资源在运行时的生命周期是很多内存问题的根源。Unity的资源加载方式主要有几种Resources.Load、AssetBundle加载、Addressables加载、直接引用场景或预制体上挂着的资源。每种方式的加载时机、内存占用和卸载策略都不一样。直接引用是最简单的方式资源跟着场景或预制体一起加载。优点是使用方便缺点是没法精细控制加载时机而且容易造成不必要的内存占用。比如一个场景里引用了大量只在特定条件下才用到的资源它们会在一开始就全部加载进内存。Resources.Load是从Resources文件夹里加载资源。这个方式在早期项目里很常见但它有几个致命问题Resources文件夹里的所有资源都会被打进包体不管你有没有用到加载是同步的会阻塞主线程卸载需要手动调用Resources.UnloadUnusedAssets而且时机不好把握。Unity官方现在已经不推荐使用Resources系统了。AssetBundle是传统的资源打包方案可以把资源分成多个包按需加载和卸载。但AssetBundle的使用比较复杂需要自己管理依赖关系、加载顺序、引用计数稍不注意就会出现重复加载或者提前卸载的问题。Addressables是Unity推出的新一代资源管理方案建立在AssetBundle之上但提供了更高级的抽象。它用地址来标识资源自动处理依赖关系支持异步加载、引用计数、远程加载等功能。对于新项目来说Addressables基本是首选方案。理解这些加载方式的区别是解决资源管理痛点的前提。你选择哪种方式直接决定了你的项目在包体、内存、加载速度这几个维度上的表现。3. 包体膨胀为什么你的游戏越做越大3.1 包体膨胀的五个主要来源包体膨胀是Unity项目最普遍的痛点之一。一个原本计划几百兆的游戏做到后面发现安装包超过两个G这种事太常见了。要解决这个问题首先得知道包体里的空间到底被什么占了。第一个来源是贴图。贴图通常是包体里占比最大的资源类型。一张未压缩的4096x4096 RGBA贴图在内存里占64MB即使经过压缩在包体里也可能占几MB到十几MB。如果项目里有几百张这样的贴图包体轻松就上G了。更糟糕的是很多贴图的实际使用尺寸远小于原始尺寸或者根本就是重复的。第二个来源是模型和动画。高精度模型的面数和顶点数据、骨骼动画的关键帧数据都会占用大量空间。特别是那些从外部资源站下载的模型往往带着极高的精度和大量无用的动画数据直接拖进项目就会把包体撑大。第三个来源是音频。未压缩的WAV音频文件体积巨大一首几分钟的背景音乐可能就占几十MB。虽然Unity支持压缩音频但默认设置不一定是最优的而且不同平台对音频格式的支持也不一样。第四个来源是视频。如果项目里包含视频文件特别是高分辨率、高码率的视频包体会迅速膨胀。视频文件通常很难通过常规的资源压缩手段来减小需要在导入前就做好转码和压缩。第五个来源是冗余资源。这是最隐蔽也最容易被忽视的问题。同一个贴图被多个材质引用但每个材质都复制了一份同一个模型在不同场景里各存了一份第三方插件里带着大量用不到的示例资源。这些冗余资源在项目里悄悄堆积包体就这样一点点被撑大了。3.2 用Editor日志和构建报告定位包体大头知道了包体膨胀的来源接下来要做的就是定位具体是哪些资源在占空间。Unity提供了几种工具可以帮助你分析包体构成。构建报告Build Report是最直接的工具。在Build Settings里勾选“Create Report”构建完成后Unity会生成一个详细的报告列出每个资源在包体里占用的空间大小。你可以按大小排序快速找到那些占用空间最大的资源。这个报告还会显示资源之间的依赖关系帮你发现哪些资源是被间接引入的。Editor.log日志里也包含了构建过程的详细信息。构建时Unity会把每个资源的处理结果输出到日志里包括压缩后的尺寸、使用的压缩格式等。通过分析日志你可以发现哪些资源的压缩效果不理想需要调整导入设置。除了Unity自带的工具还有一些第三方工具可以帮助分析包体。比如Asset Hunter可以扫描项目里未被引用的资源UABEUnity Asset Bundle Extractor可以查看AssetBundle里的具体内容。这些工具在排查冗余资源时特别有用。定位到包体大头之后处理思路就很清晰了对于贴图检查分辨率和压缩格式是否合理对于模型检查面数和动画数据是否可以精简对于音频检查压缩设置是否最优对于冗余资源直接删除或者合并。3.3 贴图、模型、音频的压缩策略与取舍资源压缩的核心原则是在保证视觉效果的前提下尽可能减小资源体积。但“保证视觉效果”这个前提在不同项目里的标准是不一样的需要根据实际情况来取舍。贴图压缩方面Unity支持多种压缩格式包括ETC、ASTC、PVRTC、DXT等。不同平台支持的格式不同压缩效果和视觉质量也有差异。一般来说ASTC是移动端比较推荐的格式它在压缩率和质量之间取得了较好的平衡。对于不需要透明通道的贴图使用RGB格式而不是RGBA可以节省25%的空间。对于UI贴图可以考虑使用图集Sprite Atlas把多张小图合并成一张大图减少Draw Call的同时也方便统一管理。模型压缩方面Unity的模型导入设置里有Mesh Compression选项可以降低网格数据的精度来减小体积。但压缩率过高会导致模型变形需要根据模型的重要程度来调整。对于远处的背景模型可以使用较高的压缩率对于主角和近景模型压缩率要低一些。另外如果模型不需要在运行时修改网格数据一定要关闭Read/Write Enabled这样Unity可以在内存里只保留一份压缩后的网格数据。音频压缩方面Unity支持PCM、ADPCM、Vorbis、MP3等格式。PCM是无压缩的音质最好但体积最大一般只用于极短的音效。Vorbis是有损压缩适合背景音乐和较长的音效。ADPCM适合短音效压缩率不错且解码开销低。对于移动端还需要注意不同平台对音频格式的支持情况比如iOS对MP3的支持就不如Vorbis好。压缩策略的取舍本质上是在包体大小、内存占用、CPU开销和视觉质量之间找平衡点。没有一套通用的最优配置需要根据项目的目标平台、性能要求和美术风格来具体调整。4. 加载卡顿与内存泄漏运行时资源管理的深水区4.1 同步加载阻塞主线程的典型场景加载卡顿是玩家最能直接感受到的性能问题。你点一个按钮界面卡住不动过了两三秒才跳转——这种体验足以让玩家直接卸载游戏。造成卡顿的原因绝大多数情况下是同步加载阻塞了主线程。Unity的很多加载API都是同步的比如Resources.Load、AssetBundle.LoadFromFile、SceneManager.LoadScene非异步版本。这些API在执行时会阻塞主线程直到资源加载完成。如果加载的资源比较大或者依赖比较多阻塞时间可能达到几百毫秒甚至几秒玩家就会感觉到明显的卡顿。一个典型的场景是场景切换。如果直接用SceneManager.LoadScene加载一个新场景Unity会销毁当前场景的所有对象然后加载新场景的所有资源整个过程都在主线程上完成。新场景越大、资源越多卡顿越明显。正确的做法是使用SceneManager.LoadSceneAsync它会在后台线程加载场景资源只在激活场景时才占用主线程卡顿感会大大降低。另一个典型场景是UI界面的打开。很多项目在打开一个复杂界面时会同步加载界面需要的所有资源包括预制体、贴图、字体、动画等。如果这些资源没有提前加载好打开界面的瞬间就会卡住。解决方案是提前异步加载资源或者在界面打开时先显示一个加载动画等资源加载完成后再显示实际内容。4.2 资源引用计数与卸载时机的判断内存泄漏是比加载卡顿更隐蔽的问题。它不会立刻表现出来但随着游戏运行时间增长内存占用会越来越高最终导致崩溃。Unity里的内存泄漏绝大多数情况下是资源没有被正确卸载。Unity的资源卸载机制是基于引用计数的。当一个资源被加载后它的引用计数为1每次被引用计数加1每次引用被释放计数减1。当计数归零时资源就可以被卸载了。但问题在于Unity的引用计数并不总是符合直觉。比如你用Resources.Load加载了一个贴图把它赋给了一个材质的mainTexture。这时候贴图的引用计数是2一次是Resources.Load一次是材质的引用。如果你只调用了Resources.UnloadUnusedAssets贴图不会被卸载因为材质还在引用它。只有当你把材质也销毁了贴图的引用计数才会归零才能被卸载。AssetBundle的卸载更复杂。AssetBundle本身和它加载出来的资源是分开管理的。你可以用AssetBundle.Unload(false)卸载AssetBundle文件本身但保留已加载的资源也可以用AssetBundle.Unload(true)同时卸载AssetBundle和它加载的所有资源。但如果你用了Unload(true)而某个资源还在被使用就会出现“资源被销毁但还在被引用”的情况导致显示异常甚至崩溃。Addressables在这方面做了很多改进它自动管理引用计数你只需要在不需要资源时调用Release系统会自动判断是否可以卸载。但即便如此如果使用不当比如忘记Release或者循环引用仍然会导致内存泄漏。4.3 用Profiler和Memory Profiler定位泄漏点定位内存泄漏工具是关键。Unity自带的Profiler是最常用的工具它可以实时显示内存占用、资源数量、GC情况等。在Profiler的Memory区域你可以看到总内存、纹理内存、网格内存、音频内存等分类数据。如果某一类内存持续增长而不下降基本可以确定那一类资源存在泄漏。Memory Profiler是更专业的工具它可以对内存进行快照然后对比两个快照之间的差异精确找出哪些资源被泄漏了。使用方法是在游戏运行到某个状态时拍一个快照然后执行一些操作再拍一个快照对比两个快照看看哪些资源在第二个快照里还存在但本应该被释放。Memory Profiler会显示每个资源的引用链帮你找到是谁在持有这个引用。除了工具一些编码习惯也能帮助避免内存泄漏。比如使用对象池来复用频繁创建销毁的对象避免频繁的Instantiate和Destroy在场景切换时手动清理不再需要的资源使用弱引用WeakReference来持有那些可以被回收的资源定期调用Resources.UnloadUnusedAssets来清理无引用资源。5. 引用混乱与协作冲突团队开发中的资源管理难题5.1 预制体嵌套与引用丢失的常见原因预制体Prefab是Unity里最常用的资源组织方式但也是引用问题的高发区。预制体嵌套Prefab嵌套在Unity 2018.3之后得到了正式支持但嵌套带来的引用关系复杂化让很多开发者头疼。一个常见的问题是引用丢失。你做了一个预制体A里面引用了一个材质M。然后你把预制体A放到另一个预制体B里再把预制体B放到场景里。某天你修改了材质M的路径或者删除了它预制体A里的引用就断了场景里的对象会显示成粉色Missing Material。如果项目里有大量嵌套预制体这种引用丢失会非常难排查。另一个问题是覆盖Override管理。当你修改嵌套预制体里的某个属性时Unity会记录这个修改作为覆盖。如果覆盖太多或者覆盖关系混乱预制体的行为会变得难以预测。比如你在场景里修改了预制体B里嵌套的预制体A的某个属性这个修改是保存在场景里的不会影响预制体A本身。但如果后来有人修改了预制体A场景里的覆盖可能会和新的预制体A产生冲突。避免这些问题的关键是保持预制体结构的扁平化尽量减少嵌套层级统一管理共享资源比如材质、贴图放在固定的目录下不要随意移动使用Prefab Variant来管理预制体的变体而不是直接复制预制体。5.2 多人协作时的资源冲突与合并策略团队协作中资源冲突是另一个大问题。Unity的场景和预制体文件都是YAML格式的文本文件理论上可以合并但实际上合并起来非常困难。两个人同时修改同一个场景合并时几乎必然出现冲突而且冲突解决起来极其痛苦。场景文件的冲突是最常见的。解决方案是场景拆分把一个大场景拆成多个小场景每个人负责不同的子场景通过Additive加载的方式组合起来。这样每个人修改的是不同的场景文件冲突概率大大降低。预制体文件的冲突也很常见。解决方案是预制体拆分把复杂的预制体拆成多个简单的预制体每个人负责不同的部分。另外使用Prefab Variant可以让变体继承基础预制体的修改减少直接修改基础预制体的需求。资源文件的冲突主要发生在美术资源上。比如两个人同时修改同一张贴图或者一个人修改了贴图另一个人修改了引用这个贴图的材质。解决方案是建立清晰的资源命名和目录规范让每个人知道自己该把资源放在哪里使用版本控制系统的文件锁在修改关键资源时先锁定文件定期同步避免长时间不同步导致的巨大差异。5.3 用Assembly Definition和命名空间隔离资源模块随着项目规模增长代码和资源的耦合会越来越严重。一个模块的修改可能影响到另一个模块编译时间越来越长维护成本越来越高。Assembly Definition程序集定义是解决这个问题的有效手段。Assembly Definition允许你把代码划分成多个程序集每个程序集有独立的编译单元。修改一个程序集里的代码只会重新编译这个程序集不会触发整个项目的重新编译。对于大型项目来说这能显著减少编译时间。更重要的是Assembly Definition强制你明确模块之间的依赖关系。一个程序集只能引用它明确依赖的其他程序集不能随意跨模块访问。这促使你设计更清晰的模块边界减少代码的耦合。配合命名空间的使用可以进一步隔离资源模块。比如把所有UI相关的代码放在UI命名空间下把所有战斗相关的代码放在Battle命名空间下。这样在引用资源时也能通过命名空间快速定位资源所属的模块避免资源引用混乱。6. 平台适配与特殊场景那些容易翻车的细节6.1 移动端与PC端资源格式的差异处理不同平台对资源格式的支持差异很大这是跨平台项目必须面对的问题。移动端和PC端在贴图压缩格式、音频格式、着色器精度等方面都有不同的要求。贴图压缩格式方面PC端主要使用DXT也叫S3TC移动端主要使用ETC、ASTC或PVRTC。如果项目要同时发布PC和移动端需要为不同平台设置不同的压缩格式。Unity的贴图导入设置里可以针对每个平台单独配置你可以为Android设置ASTC为iOS设置ASTC或PVRTC为PC设置DXT。音频格式方面移动端对音频解码的开销更敏感需要选择解码效率高的格式。Vorbis在移动端表现不错但iOS上MP3的支持更好。对于短音效ADPCM是移动端的好选择。PC端则可以使用更高质量的格式因为PC的解码能力更强。着色器精度方面移动端GPU对浮点精度的支持有限使用高精度浮点运算会导致性能下降甚至渲染错误。移动端着色器应该尽量使用half或fixed精度避免使用double。Unity的Shader语法支持精度修饰符可以在不同平台上自动适配。6.2 微信小游戏等小游戏平台的资源限制微信小游戏、抖音小游戏等平台对包体有严格的限制。微信小游戏的首包限制是4MB总包限制是20MB通过分包可以扩展到更大。这意味着你不可能把所有资源都打进首包必须做精细的资源分包和按需加载。小游戏平台的资源管理策略和原生App有很大不同。首包只放最核心的资源比如启动画面、主界面UI、必要的配置数据。其他资源通过CDN远程加载按需下载。使用AssetBundle或Addressables做资源分包把不同功能模块的资源分开打包玩家用到哪个模块就下载哪个模块。小游戏平台的另一个限制是内存。小游戏运行在浏览器的JavaScript环境中内存上限比原生App低很多。资源加载后要及时释放避免内存堆积。贴图分辨率要严格控制音频要使用低码率格式模型面数要精简。6.3 数字孪生与工业仿真场景的大规模资源调度数字孪生和工业仿真项目对资源管理有特殊的要求。这类项目通常需要加载大规模的场景数据包括建筑模型、设备模型、地形数据、点云数据等资源量远超普通游戏。大规模场景的加载策略是关键。不能一次性加载所有资源必须做分块加载Chunk Loading和LODLevel of Detail管理。根据摄像机的位置和视野只加载可见范围内的资源远处的资源用低精度模型代替。当摄像机移动时动态加载新进入视野的资源卸载离开视野的资源。资源调度方面数字孪生项目通常需要从服务器动态获取资源。可以使用Addressables的远程加载功能把资源放在CDN上运行时按需下载。对于特别大的模型可以考虑使用流式加载Streaming边下载边显示而不是等整个模型下载完再显示。数据压缩方面工业模型通常包含大量细节直接使用会导致资源量爆炸。需要在导入前做模型简化Mesh Simplification减少面数和顶点数。贴图可以使用更激进的压缩格式因为工业场景对贴图精度的要求通常低于游戏场景。7. 从认知到行动建立资源管理的长效机制7.1 项目初期的资源规范制定资源管理最重要的一步是在项目初期就建立规范。很多团队等到问题爆发才想起来治理这时候已经积重难返了。项目初期的规范应该包括以下几个方面。目录结构规范明确Assets目录下的一级目录划分比如Art、Scripts、Scenes、Prefabs、Materials、Textures、Audio、Resources等。每个目录下再按功能模块或资源类型细分。目录结构一旦确定就要严格执行不允许随意创建新目录。命名规范资源命名要统一包括前缀、后缀、大小写、分隔符等。比如贴图统一用T_前缀材质用M_前缀预制体用P_前缀。命名要能反映资源的用途和归属模块方便搜索和定位。导入设置规范为不同类型的资源制定默认的导入设置模板。比如UI贴图统一使用Sprite格式、关闭Mipmap、使用ASTC压缩场景模型统一使用Mesh Compression、关闭Read/Write Enabled。可以使用Preset功能来保存和应用这些设置。版本控制规范明确哪些文件纳入版本控制哪些不纳入。Assets和ProjectSettings必须纳入Library和Temp不纳入。使用.gitignore或.svnignore来排除不需要的文件。对于美术资源考虑使用Git LFS或SVN来管理大文件。7.2 持续集成中的资源检查与自动化规范制定之后还需要有机制来保证规范被执行。人工检查不可靠必须靠自动化。持续集成CI是实施自动化检查的最佳场所。资源大小检查在CI流程中加入资源大小检查如果某个资源超过预设阈值就报错或者警告。比如单张贴图不超过2048x2048单个模型不超过5万面单个音频不超过5MB。引用检查检查资源之间的引用关系是否合理是否存在循环引用、悬空引用、重复引用等问题。可以使用Unity的AssetDatabase API来编写检查脚本。导入设置检查检查资源的导入设置是否符合规范。比如贴图是否使用了正确的压缩格式模型是否关闭了Read/Write Enabled音频是否使用了正确的压缩格式。包体大小检查每次构建后检查包体大小如果超过预设阈值就报警。可以结合构建报告分析包体构成的变化趋势及时发现异常增长。7.3 资源热更新与版本管理的配合热更新是很多项目的刚需但热更新和资源管理的配合是一个复杂的话题。热更新的核心是在不重新安装App的情况下更新部分资源或代码。这要求资源管理方案支持远程加载和版本管理。AssetBundle和Addressables都支持热更新。基本流程是把资源打包成AssetBundle上传到CDN客户端启动时检查版本如果有新版本就下载。下载完成后用新的AssetBundle替换旧的。版本管理是热更新的关键。每个AssetBundle都有一个版本号客户端需要记录当前使用的版本并在启动时和服务器上的版本对比。如果版本不一致就触发更新。版本号的管理要谨慎避免出现版本回退或者版本冲突。热更新的资源粒度需要仔细设计。粒度太粗每次更新都要下载大量资源粒度太细AssetBundle数量太多管理复杂且加载效率低。一般来说按功能模块划分AssetBundle是比较合理的做法每个模块的资源打成一个包更新时只更新有变化的模块。热更新的兼容性也是需要注意的问题。新版本的资源可能依赖新版本的代码如果代码没有同步更新就会出现兼容性问题。解决方案是把代码热更新和资源热更新结合起来确保两者版本匹配。资源管理这件事说到底是一个从认知到实践的过程。你首先得理解Unity的资源体系是怎么运作的然后才能识别出项目里的痛点最后才能有针对性地制定解决方案。这篇内容覆盖了包体膨胀、加载卡顿、内存泄漏、引用混乱、平台适配这几个最常见的痛点每个痛点都给出了成因分析和解决思路。但每个项目的情况都不一样具体怎么落地还需要你结合自己项目的实际情况来调整。我在实际项目里踩过的坑告诉我资源管理没有一劳永逸的方案只有持续的关注和优化。