企业官网建设流程全解析

Unity2021升级后Android打包报错终极解决方案：从OBSOLETE警告到完美兼容

最近不少开发者反馈，在将项目升级到Unity2021版本后，Android打包时突然遭遇了一个棘手的报错信息："OBSOLETE - Providing Android resources in Assets/Plugins/Android/res was removed"。这个突如其来的变化让许多不熟悉Android原生开发的Unity开发者措手不及，特别是那些依赖Android资源文件夹进行本地化、UI定制或特殊功能集成的项目。本文将深入解析这一变更背后的技术原因，并提供一套经过实战验证的解决方案，帮助你在5分钟内完成迁移，恢复正常的打包流程。

1. 理解Unity2021的资源管理变革

Unity2021对Android资源管理方式做出了重大调整，这并非偶然。随着Android生态系统的成熟和模块化开发的普及，传统的直接将资源文件放置在Assets/Plugins/Android/res目录下的做法已经显得过于简单和脆弱。这种变更反映了几个深层次的技术趋势：

• 模块化开发需求：现代应用开发越来越强调模块化和组件化，而传统的资源管理方式难以支持这种开发模式
• 依赖管理优化：直接使用res文件夹可能导致资源冲突和版本管理困难
• 构建系统兼容性：新版Gradle构建系统对资源打包有更严格的要求

提示：这一变更实际上从Unity2019.4就开始逐步推进，但在Unity2021中成为了强制要求

理解这些背景后，我们就能明白为什么Unity团队决定废弃旧有的资源管理方式，转而推荐使用AAR(Android Archive)或Android Library这种更规范、更强大的解决方案。

2. 传统方案为何失效：技术细节剖析

在旧版Unity中，开发者习惯将Android相关资源直接放在以下目录结构：

Assets/ └── Plugins/ └── Android/ ├── res/ │ ├── drawable/ │ ├── layout/ │ └── values/ └── AndroidManifest.xml

这种结构虽然简单直接，但存在几个关键问题：

1. 资源ID冲突风险：当项目包含多个插件时，不同插件可能定义相同的资源ID
2. 构建过程不透明：Unity内部需要处理复杂的资源合并逻辑
3. 版本控制困难：难以管理资源文件的版本和依赖关系

新版Unity要求将这些资源迁移到标准的Android Library结构中，这带来了以下优势：

• 明确的资源作用域：每个库有自己的资源命名空间
• 更好的构建支持：Gradle可以正确处理库之间的依赖关系
• 更灵活的发布方式：可以单独更新某个功能模块而不影响整个应用

3. 五分钟解决方案：创建CustomAndroidResource.androidlib

虽然官方推荐使用AAR方案，但对于大多数中小型项目来说，创建完整的AAR可能过于复杂。下面介绍一种更轻量级的解决方案，只需几个简单步骤即可解决问题。

3.1 创建基本目录结构

首先，我们需要在项目中创建符合Android Library标准的目录结构：

1. 在Unity项目窗口中，导航到Assets/Plugins/Android目录
2. 右键点击，选择"Create > Folder"，命名为CustomAndroidResource.androidlib
3. 将原有的res文件夹从Assets/Plugins/Android移动到新创建的CustomAndroidResource.androidlib目录中

完成后的结构应该如下：

Assets/ └── Plugins/ └── Android/ ├── CustomAndroidResource.androidlib/ │ └── res/ │ ├── drawable/ │ ├── layout/ │ └── values/ └── AndroidManifest.xml

3.2 配置必要的库文件

Android Library需要两个关键配置文件才能被正确识别和处理。我们需要在CustomAndroidResource.androidlib目录下创建它们。

3.2.1 AndroidManifest.xml

创建一个新文件AndroidManifest.xml，内容如下：

<?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="custom.android.res" android:versionCode="1" android:versionName="1.0"> </manifest>

这个文件定义了库的基本信息：

• package属性为库指定了一个唯一的包名
• versionCode和versionName用于版本管理

3.2.2 project.properties

创建第二个配置文件project.properties，内容非常简单：

target=android-9 android.library=true

这个文件告诉构建系统：

• 该模块是一个Android库(android.library=true)
• 目标API级别是Android 2.3(target=android-9)

注意：虽然我们指定了较低的API级别，但实际构建时会使用项目设置中的目标API级别

3.3 验证最终结构

完成上述步骤后，你的目录结构应该如下：

Assets/ └── Plugins/ └── Android/ ├── CustomAndroidResource.androidlib/ │ ├── res/ │ │ ├── drawable/ │ │ ├── layout/ │ │ └── values/ │ ├── AndroidManifest.xml │ └── project.properties └── AndroidManifest.xml

4. 高级配置与疑难解答

虽然上述基本方案能解决大多数情况下的问题，但在实际项目中可能会遇到一些特殊情况。下面介绍几个常见的高级配置场景和解决方案。

4.1 处理多个资源库

如果你的项目需要包含多个独立的资源集，可以创建多个.androidlib目录，每个都有自己独立的res文件夹和配置文件。例如：

Assets/ └── Plugins/ └── Android/ ├── UIResources.androidlib/ │ ├── res/ │ ├── AndroidManifest.xml │ └── project.properties ├── Localization.androidlib/ │ ├── res/ │ ├── AndroidManifest.xml │ └── project.properties └── AndroidManifest.xml

4.2 资源合并冲突解决

当多个库定义了相同的资源ID时，构建系统会按照以下优先级决定使用哪个资源：

1. 主应用的资源(Assets/Plugins/Android/res，如果存在)
2. 最后声明的库的资源
3. 先声明的库的资源

为了避免冲突，建议：

• 为资源添加前缀，如lib1_btn_submit
• 在库的AndroidManifest.xml中使用<manifest package="unique.package.name">确保唯一性

4.3 常见错误及解决方案

5. 迁移后的验证与优化

完成迁移后，建议进行以下验证步骤确保一切工作正常：

1. 清理构建缓存：

   • 删除项目中的Library、Temp和Build文件夹
   • 在Unity中选择"Assets > Reimport All"

2. 测试构建流程：

   • 执行一次完整的Android构建
   • 检查构建日志中是否有相关警告或错误

3. 运行时验证：

   • 在目标设备上安装并运行构建的APK
   • 验证所有迁移的资源都能正常加载和使用

4. 性能检查：

   • 对比迁移前后的APK大小
   • 检查资源加载时间是否有明显变化

# 可以使用以下adb命令检查资源加载情况 adb shell dumpsys activity top | grep -E "ActivityRecord|Resources"

对于大型项目，这种迁移可能会影响构建时间。如果发现构建速度明显变慢，可以考虑：

• 将多个小型资源库合并为较大的库
• 使用AAR替代.androidlib以获得更好的构建缓存
• 检查Gradle配置是否最优

6. 长期维护建议

虽然.androidlib方案解决了眼前的兼容性问题，但从长远来看，考虑以下几点可以让你的项目更加健壮：

1. 逐步过渡到AAR：对于核心功能，考虑创建正式的AAR包
2. 资源命名规范：建立统一的资源命名规则，避免未来冲突
3. 版本控制策略：为每个资源库维护独立的版本号
4. 文档记录：在项目文档中明确记录资源管理方式

// 示例：在Unity中动态加载Android资源的C#代码 AndroidJavaClass unityPlayer = new AndroidJavaClass("com.unity3d.player.UnityPlayer"); AndroidJavaObject activity = unityPlayer.GetStatic<AndroidJavaObject>("currentActivity"); AndroidJavaObject resources = activity.Call<AndroidJavaObject>("getResources"); int resourceId = resources.Call<int>("getIdentifier", "icon", "drawable", "custom.android.res");

在实际项目中，我们还需要考虑不同屏幕密度、语言区域等特殊资源的处理方式。Android Library结构天然支持这些高级特性，只需按照标准方式组织res子目录即可。