第二章：深入 Unity 资源导入管线

转载自: 知乎 - 伽蓝之洞

第二章：深入 Unity 资源导入管线 (Asset Import Pipeline)

1. Unity 是如何导入资源的？

当你把一堆文件拖进 Unity 时，你看到的只是进度条，但在底层，Unity 正在运行一套复杂的资产数据库 (Asset Database) 系统。

1.1 输入与输出：Source vs Artifact

首先要确立一个绝对的核心概念：Unity 运行时不读取你的源文件。

  • 输入 (Source Asset)：你硬盘上的 .png, .fbx, .cs。它们存储在 Assets 文件夹。
  • 转化 (Importing)：将源文件转化为引擎可读的格式的过程。
  • 输出 (Artifact)：转化后的二进制结果（如纹理的显存数据块、模型的顶点缓冲）。它们存储在 Library 文件夹。

只要源文件（.png）和导入设置（.meta）不变，生成的产物（Artifact）就是唯一的。 如果你把 Library 删了，Unity 只是失去了 “缓存”，它会重新根据源文件再翻译一遍，结果是一样的。

1.2 新版本并行导入 (Parallel Import)

在旧版本 Unity 中，导入是单线程的，大项目导入可能需要一小时。

新版本 Unity (Asset Database V2) 采用了多进程架构：

  1. 主进程 (Main Editor Process)：扫描文件变化，分配任务。
  2. 工作进程 (Worker Processes)：Unity 会启动多个后台的 Unity Editor 辅助进程。
  • 主进程把 A.png 分给 1 号工人，把 B.fbx 分给 2 号工人。
  • 这些工人并行工作，利用多核 CPU 极速完成工作。

并行导入时：

  • 不要在导入过程中争抢文件锁。
  • 如果你写了自定义的资源处理代码，要确保它是线程安全的，或者不依赖于其他正在被导入的资源

2. 规则：特殊文件夹

Unity 的导入管线并不是对所有文件夹一视同仁的。某些文件夹名字具有特例，会改变导入顺序或构建行为。

我们需要理解以下三个最关键的目录：

2.1 Editor： 这里的代码不进游戏

  • 行为：放在这里的脚本被视为编辑器扩展工具。

  • 管线影响：

    • Unity 会将这里的代码默认编译进 Assembly-CSharp-Editor.dll。
    • 打包时剥离：当构建游戏（APK/EXE）时，这个文件夹里的内容会被直接丢弃。

  • 用途：存放哪怕写错也不会让游戏崩溃的辅助工具、资源检查脚本（后面要讲的 AssetPostprocessor 通常放在这里）。

2.2 StreamingAssets： 唯一的例外

  • 行为：保留用于在运行时以其原始格式进行流式传输的资产文件。

  • 管线影响：绕过导入管线 。

    • 放在这里的文件，Unity 不会去尝试导入它，也不会生成 Artifact。
    • 它会被原封不动地复制到最终的安装包里。

  • 用途：存放视频文件（MP4）、需要在运行时通过 IO 读取的原始配置文件（JSON/XML），或者 AssetBundle 包本身。

2.3 Resources： 新手的陷阱

  • 行为：Resources 是一个特殊的文件夹。Unity 允许你将任何资源放入其中，并在运行时通过 Resources.Load(“Path/To/Asset”) 这种字符串路径的方式加载它们。

  • 管线影响：

    • 当构建项目（Build）时，Unity 会将所有 Resources 文件夹（无论它们分布在工程的哪个角落）中的内容，以及它们关联的元数据（Metadata，例如文件路径），合并打包到一个巨大的序列化文件中。
    • 打包时：整个文件夹内的所有内容，都会被合并打包进一个巨大的序列化文件中（resources.assets）。

  • 代价：

  • 细粒度内存管理的噩梦：Resources 系统让内存管理变得极其困难。由于所有资源都被打包在一起，且依赖关系隐晦，很难像 AssetBundle 那样精准地 “卸载一组不再使用的资源”。这容易导致内存峰值不可控。

  • 启动时间与构建时长 ：当应用程序启动时，Unity 必须读取这个巨大的序列化文件头，并为其中包含的所有资源路径构建索引。

  • 建议：除非是用来做原型开发或极少量的配置加载，否则不要使用 Resources 文件夹。

更多目录参考：https://docs.unity3d.com/6000.2/Documentation/Manual/SpecialFolders.html

3. 扩展：教 Unity 认识新文件

Unity 原生支持 PNG、FBX、C# 等格式。但如果你的项目里有一种自定义策划数据格式，比如 .lua 或者自定义后缀 .mydata，直接拖进 Unity 会发生什么？

Unity 会把它当成无法识别的二进制，你无法在 Inspector 里预览它。

我们可以编写 C# 脚本来扩展导入管线，让 Unity 学会” 认识新格式。

实战：编写一个自定义文本导入器

假设我们的策划使用 .level 后缀的文件来描述关卡数据。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
using UnityEngine;
using UnityEditor.AssetImporters; 
using System.IO;

[ScriptedImporter(1, "level")] 
public class LevelFileImporter : ScriptedImporter
{
    public override void OnImportAsset(AssetImportContext ctx)
    {
        // 读取源文件文本
        string text = File.ReadAllText(ctx.assetPath);
        // --- 这里可以写你的解析逻辑 (Parsing) ---
        // 比如把文本解析成一个 ScriptableObject
        TextAsset subAsset = new TextAsset(text);

        // 3. 将产物注册到上下文
        // 这就是生成的 Artifact！我们将一个普通的文本文件，变成了一个内存中的 TextAsset 对象
        ctx.AddObjectToAsset("MainText", subAsset);
        
        // 4. 设置为主资源 (Main Asset)，这样在 Project 窗口里看到的就是它
        ctx.SetMainObject(subAsset);
    }
}

我们不仅是资源的使用者，更是管线的定义者。通过 ScriptedImporter，我们将任意格式的文件纳入了 Unity 的 Asset Database 管理体系中，享受 Cache Server 和 Artifact 的红利。

4. 管控：自动化 (AssetPostprocessor)

现在我们理解了导入机制，也知道如何扩展格式。最后一步是：如何确保团队里的几十个人都能正确地导入资源？

依靠口头规范 “记得把 UI 图片的 Mipmap 关掉” 是不可靠的。我们需要代码层面的强制力。 这就是 AssetPostprocessor 的职责。它允许我们劫持导入过程，在资源生成 Artifact 之前或之后修改设置。

process 处理：

  1. Pre-process (前处理)：在 Unity 生成 Artifact 之前。此时修改设置（如压缩格式、Mipmap），不消耗额外时间。这是最佳修改时机。
  2. Post-process (后处理)：在 Unity 生成 Artifact 之后。此时资源已经变成了内存对象（Texture2D, Mesh）。如果在此时修改属性，往往需要重新上传显存或触发二次导入，性能较差。

实战：自动化导入规范脚本

将此脚本放在 Assets/Editor 文件夹下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
using UnityEngine;
using UnityEditor;

public class ProjectResourceRule : AssetPostprocessor
{
    // -----------------------------------------------------------
    // 场景：UI 文件夹下的图片，自动关闭 Mipmap，自动设置为 Sprite
    // -----------------------------------------------------------
    // 调用时机：Unity 读取了 .meta 配置，准备生成 Artifact 之前
    void OnPreprocessTexture()
    {
        // 1. 获取导入器实例 (Importer Instance)
        TextureImporter importer = (TextureImporter)assetImporter;
        
        // 2. 路径判断 (基于字符串匹配)
        if (assetPath.Contains("Assets/Art/UI/"))
        {
            // 3. 强制修改设置
            // 不管美术有没有勾选 Mipmap，这里都会强制关闭
            if (importer.mipmapEnabled)
            {
                importer.mipmapEnabled = false; 
            }

            // 强制设置为 Sprite 模式
            if (importer.textureType != TextureImporterType.Sprite)
            {
                importer.textureType = TextureImporterType.Sprite;
            }
        }
    }

    // -----------------------------------------------------------
    // 场景：模型导入后，自动检查是否有多余的材质球引用
    // -----------------------------------------------------------
    // 调用时机：Artifact 已经生成，GameObject 已经构建完毕
    void OnPostprocessModel(GameObject g)
    {
        // 检查是否有未赋值的材质
        Renderer[] renderers = g.GetComponentsInChildren<Renderer>();
        foreach (var r in renderers)
        {
            if (r.sharedMaterial == null)
            {
                Debug.LogWarning($"[资源警告] 模型 {assetPath} 存在丢失材质的 Renderer: {r.name}");
            }
        }
    }
}

5. 总结

本章分析了 Unity 资源导入管线（Asset Import Pipeline）的运作机制。

掌握这些，可以具备了对资源生命周期的完全控制权，从而能够解决以下问题：

  1. 消除不确定性：通过理解 Source 到 Artifact 的转化逻辑，快速定位资源引用丢失（Missing Reference）与 GUID 冲突等管线异常。
  2. 构建性能优化：通过规避 Resources 索引开销并合理利用 StreamingAssets，从物理文件层面优化 App 启动速度与安装包体积。
  3. 管线扩展能力：利用 ScriptedImporter 将项目特定的自定义数据格式（如关卡配置、DSL 脚本）无缝纳入 Unity Asset Database 的管理与缓存体系。
  4. 自动化标准化：通过 AssetPostprocessor 建立静态资源检查机制，以代码强制执行项目规范（如纹理压缩格式、Mipmap 设置），消除人为操作误差和编写其他自动化处理。