在 Unity 里做原生 SDK 接入做了六七年我见过太多同一个场景下的两种人生有人接广告 SDK、统计 SDK、推送 SDK 就像喝水一样拖进去、点两下、编译一把过有人接同一个 SDK光是依赖报错就能折腾一整天最后发现卡在“少了一个工具”上。那个工具就是 EDM4U全称 External Dependency Manager for Unity。如果你是一个 Unity 开发者尤其是做安卓方向早晚会碰到这个名字。碰不到说明你还没接入过稍微复杂一点的第三方原生 SDK。这篇就用一个“典型故事”的方式把“没有 EDM4U”和“用了 EDM4U”这两条路从头到尾对比一遍讲清楚它解决了什么问题、底层做了什么事以及实际接入时怎么配置、怎么排坑。适合所有正在被安卓打包折磨的 Unity 开发者不管你刚入行还是已经写了几年项目这篇文章都值得看完。1. 没有 EDM4U 的日子手动接 SDK 的三大痛点1.1 依赖库手动下载点了一碗面锅碗瓢盆都要自己买先讲一个我印象很深的翻车故事。几年前接一个第三方的广告 SDK当时项目里没有 EDM4USDK 文档写得很“简单”把 aar 文件放到 Assets/Plugins/Android 目录下然后在 AndroidManifest.xml 里加上对应权限完事。听起来确实简单照做了。结果一编译Gradle 直接报错找不到 okhttp 这个类。于是我去网上搜下载了 okhttp 的 jar 包丢进目录。再编译又报缺 okio。再下载 okio又报缺……就这么无限套娃。最后我数了一下为了接一个广告 SDK我手动往工程里塞了十几个依赖相关的 jar/aar 文件。这就是最原始的 Unity 接原生 SDK 的方式所有第三方依赖都得手动下载、手动放进工程。问题在于现代安卓 SDK 几乎没有“单文件”存在的一个 SDK 背后往往依赖着十几个其他库这些库又各自有传递依赖。手动管理这些东西工作量不是加法是乘法。这就像你去面馆点了一碗牛肉面结果老板只给了你面条告诉你牛肉得自己去隔壁买汤底得自己熬还得自己准备锅。更离谱的是你买了牛肉之后老板又告诉你炖牛肉还得要香料、要高压锅、要煤气灶……每一步都是“再补一个就行”但永远补不完。后来我学乖了开始用 Gradle 的方式来接 SDK。但问题又来了Unity 的老版本工程里Gradle 模板需要你手动改 mainTemplate.gradle 文件你需要在 dependencies 里面手动写每个依赖的坐标。这依然避不开安卓依赖生态的复杂性而且只要版本号填错、仓库没配全Gradle 会在编译的时候给你吐出一大串让人头皮发麻的红色日志。1.2 AndroidManifest 手动合并漏一个声明就是一颗定时炸弹除了依赖另一个大坑是 AndroidManifest.xml 的合并。一个安卓 SDK 要做事情通常需要在自己的 Manifest 里声明权限、Activity、Service、Provider、meta-data 这些东西。比如广告 SDK 需要一个 Activity 来展示广告推送 SDK 需要一个 Service 来接收消息统计 SDK 需要一个 Provider 来初始化数据。那问题就来了第三方 SDK 的 Manifest 是它自己打包时的东西不会自动出现在 Unity 工程里。你得手动把 SDK 文档要求的那些节点一条一条复制到 Unity 项目的 AndroidManifest.xml 里面去。我见过一个真实案例一位开发者接了一个地图 SDK漏了一个 activity 声明没有复制过去结果编译完全正常打包也能出App 一打开跳到地图页面就闪退报错信息是 ActivityNotFoundException。查了整整两天最后发现只是 Manifest 里少了一行 activity 声明。这种问题极其隐蔽因为编译期完全体现不出来只能运行到那个模块的时候才爆而且报错信息离真正的病根隔了十万八千里。如果你的 SDK 还要做渠道变体、动态配置、合并策略那些骚操作手动维护 Manifest 简直是噩梦。什么 tools:nodereplace、tools:noderemove、merge 冲突标记这些规则不是没有人能看懂而是看懂需要付出的学习成本对大多数做应用开发的 Unity 工程师来说根本不划算。1.3 混淆规则手动粘贴少贴一行线上必出鬼故事还有一个我踩了不止一次的坑ProGuard / R8 混淆规则。安卓 SDK 里大量用了反射、注解、JNI 这些东西混淆一开类名和方法名被乱改反射就找不到目标了。所以每个 SDK 都会给你一份 keep 规则让你加到工程的 proguard 文件里比如-keep class com.example.sdk.** { *; } -keepclassmembers class com.example.sdk.** { *; }听起来简单复制粘贴就行。但实际项目里一个工程通常会接十几个 SDK每家的 keep 规则有长有短有的还会互相冲突。每次接新 SDK都要把一堆规则追加到混淆配置文件尾部时间一长那个文件又长又乱根本没法维护。更麻烦的是某些规则缺失不是在编译时报错的而是在发布之后、用户跑到某个功能时才突然崩溃。比如混淆后某个类被重命名代码通过反射拿不到那个类直接抛异常。这种问题没有任何报错能告诉你“你的 keep 规则少了一行”你只能一遍又一遍地看崩溃堆栈然后对照 SDK 的混淆配置文档逐行比对。之前我们有个线上事故就是接某个聊天 SDK 的时候少加了一条 -keepclassmembers 规则用户在特定的手机上收发图片就闪退。排查了整整一下午最后发现根因居然是一个多月前接 SDK 时少复制了一行混淆规则。2. EDM4U 到底是什么帮你把这些脏活累活全包了2.1 从 Play Services Resolver 说起EDM4U 的完整名字是 External Dependency Manager for Unity早期叫 Play Services Resolver后来功能不断扩展才改成了现在这个名字。它本质上是谷歌开源的一个 Unity 编辑器扩展工具负责处理 Unity 工程里接入安卓和 iOS 原生库时遇到的那些“脏活”依赖解析、Manifest 合并、兼容库处理、初始化配置注入等。在最开始的时候这个工具就是为了解决 Google Play Services 和 Firebase 那一大堆依赖库的自动解析问题而生的。因为 Google 的移动服务库里每个模块都有一堆依赖手动管理根本不可能。后来整个行业发现这套思路通用性极强慢慢就变成了 Unity 接各种原生 SDK 的标配工具。现在几乎所有主流的广告、统计、推送、支付类 SDK在集成文档里都会提一句“你需要安装 EDM4U”。而且很多 SDK 的 Unity 插件包里面本身就内嵌了 EDM4U 的依赖声明文件导入工程之后会自动用 Resolver 解析。2.2 核心能力一依赖自动解析器Dependency ResolverEDM4U 的第一个核心能力是自动解析安卓依赖。每个 SDK 的 Unity 插件包里可以放一个 Dependencies.xml 文件里面声明这个 SDK 需要哪些安卓库、每个库的版本号是多少、需要从哪个 Maven 仓库拉取。EDM4U 会扫描工程里所有这种文件把里面声明的依赖汇总起来自动把对应的依赖坐标和仓库配置写入 Unity 生成的 Gradle 工程里。这样做的好处是什么理论上接一个新 SDK你唯一要做的事情就是把 SDK 包导入 Unity然后点一次 Force Resolve剩下的所有依赖下载、版本对齐、传递依赖处理全部由 Gradle 通过 Maven 仓库帮你搞定。刚才那个“点了一碗面要自己买牛肉”的比喻这里就完全反过来了你点的是一份完整套餐面、牛肉、汤底、锅具全都由工具配送上门。2.3 核心能力二AndroidManifest 自动合并器第二个能力是自动合并 AndroidManifest。SDK 插件包里可以包含一个 AndroidManifest.xml 片段EDM4U 在解析的时候会把这些片段和你主工程的 Manifest 自动合到一起。它用了一套标准化的合并规则处理权限、Activity、Service、Provider、meta-data 等各种节点的合并。不需要你手动去复制粘贴也不用担心漏声明。有些人可能担心自动合并会不会把不该合的东西合进去放心它有完善的冲突检测机制。如果两段 Manifest 里有冲突会自动打断并提示你让你手动决定到底保留哪个、移除哪个。这比你自己手动拼要安全得多。2.4 核心能力三兼容库处理与 Jetifier第三个能力是处理新旧安卓库的兼容问题。很多老 SDK 是基于旧版 Support Library 写的而新项目已经全面转向 AndroidX。这时候直接混用编译期或者运行期很容易出现 duplicate class 这种奇葩报错。EDM4U 内置了 Jetifier 能力能在解析依赖的时候把旧的 Support Library 坐标自动转换成 AndroidX 对应的坐标让老库也能在新项目里正常跑起来。它还支持自动导入 appcompat 这类安卓兼容组件避免因为缺少支持库导致初始化失败。这里顺带解释一下 Jetifier 是个什么概念。安卓生态从 2018 年开始从 Support Library 迁移到 AndroidX包名从 android.support.* 改成了 androidx.*。老 SDK 编译的时候引用的还是旧包名而新工程里用的全是新包名。Jetifier 做的事情就像一个翻译器在编译前帮你把老库里的旧包名引用全部改成新包名。这个能力在 EDM4U 里是自动的不需要你额外装什么。我不止一次见过有人问为什么我接的 SDK 文档里没说要用 AndroidX可项目编译老报 AndroidX 相关的错答案往往是你的工程启用了 AndroidX但那个 SDK 还是老的 Support Library 依赖没有 Jetifier 帮忙转换两边直接打架了。3. 实际接入 EDM4U完整实操流程与关键配置3.1 环境准备先把基础确认到位在开始用 EDM4U 之前有几个东西需要提前确认你用的 Unity 版本。EDM4U 支持绝大部分主流版本但越新的 Unity 越推荐用越新的 EDM4U 版本两者之间有兼容性迭代。之前我就在 Unity 2021 上用过很老的 EDM4U结果解析出的 Gradle 工程有问题升级到最新版就好了。你的目标平台已经切换到 Android。EDM4U 的菜单在 Window External Dependency Manager 下如果你没有先切换到安卓平台某些选项会显示为灰色或者找不到。确认安卓 SDK 和 JDK 环境。Unity 自带的模块一般够用但如果你是单独装的 Android Studio需要保证 SDK 路径和 JDK 版本对得上。这些确认完之后再进下一步。3.2 获取并导入 EDM4U获取 EDM4U 的常见方式有两种一是从它在 GitHub 上的官方仓库下载最新发布的 unitypackage 文件二是很多 SDK 提供商的插件包里面会自动包含一个 EDM4U 的 dependency导入时提示你安装。我个人的习惯是从官方仓库直接下载最新版单独导入。因为这样版本可控避免某些 SDK 内嵌的 EDM4U 版本太老给你带来一些奇怪的问题。导入方法和普通资源包一样Assets Import Package Custom Package选中下载好的 unitypackage一路 Import 就行。导入完成之后菜单栏会出现 Window External Dependency Manager这就是 EDM4U 的入口。3.3 核心设置一次配好长期省心打开 Window External Dependency Manager Android Resolver Settings你会看到一整套配置。其中这几个选项一定不能搞错第一个是勾选使用 Gradle 模板。这个选项的意思是EDM4U 会把你工程里 Assets/Plugins/Android/mainTemplate.gradle 文件作为依赖生成的基准模板。如果你工程里还没有这个文件先点击 Resolver 菜单里的 “Gradle Template” 相关按钮让它自动生成。第二个是依赖声明方式的选择。EDM4U 支持两种方式通过各 SDK 包里的 Dependencies.xml 文件声明或者直接在 mainTemplate.gradle 文件里写 dependencies。推荐用前一种因为更干净、自动化程度更高你只需要在 Dependencies.xml 里加依赖坐标EDM4U 会自动把它们汇总进 gradle 文件。第三个是自动导出安卓工程。在 Resolver 设置里有自动导出相关选项建议开启这样你每次 Build 的时候EDM4U 会自动先做一次依赖解析省得你手动去点。第四个是 Patch Settings 相关选项。这个会让 EDM4U 自动修改你工程里的 Gradle 模板、Manifest 等文件。默认开启即可不要觉得“它会乱改我的文件”就把它关掉它改的是有逻辑的不会动你的业务代码。提示如果你用的是 Unity 2020.3 及以上版本并且不想让 EDM4U 每次打包自动把工程导成 Android Studio 项目结构可以把 “Export 时自动解析” 的选项按需调整。下面会专门讲这个细节。3.4 Dependencies.xml 长什么样一个能直接抄的示例在一个 SDK 的 Unity 插件包里依赖声明文件通常放在包根目录的 Editor 文件夹下命名类似 Dependencies.xml。如果你是自己接一个安卓原生 SDK也可以手动创建这个文件来告诉 EDM4U “我要什么依赖”。这是一个最简示例dependencies androidPackages androidPackage speccom.google.android.gms:play-services-ads:23.0.0 / androidPackage specandroidx.appcompat:appcompat:1.7.0 / androidPackage speccom.squareup.okhttp3:okhttp:4.12.0 / repositories repositoryhttps://maven.google.com//repository repositoryhttps://repo.maven.apache.org/maven2//repository /repositories /androidPackages /dependencies这段代码的意思是这个 SDK 需要用广告库、appcompat 兼容库和 okhttp 网络库这些库分别从两个 Maven 仓库拉取。当 EDM4U 解析到这份文件时它会把依赖写入最终生成的 Gradle 脚本里。需要注意一点如果某个依赖本身在 google() 仓库里能找到就不需要额外加仓库地址。比如 play-services-ads 这种 Google 官方库走默认仓库就行。但如果你是接某个小众 SDK它把依赖发布在自定义的 Maven 仓库那你不写仓库地址解析的时候就会报找不到包。3.5 执行 Force Resolve 并观察结果配置写好后进入 Window External Dependency Manager Android Resolver点击 Force Resolve。这是整个流程里最重要的一个动作。点击之后EDM4U 会做下面这些事情扫描工程里所有 Dependencies.xml 文件汇总依赖清单。从网络上查询依赖信息处理版本冲突。将最终依赖写入 Assets/Plugins/Android/mainTemplate.gradle 文件。合并所有 SDK 的 Manifest 片段到主 Manifest。如果需要执行 Jetifier 转换。生成各种中间文件到 temp 目录。整个过程的日志会在 Console 窗口里显示。正常情况下日志末尾会出现 Resolve completed 之类的提示。如果你点了之后日志里报错那就是依赖配置有问题要去排查仓库地址、版本号、网络这些环节。解析成功之后你可以打开 Assets/Plugins/Android/mainTemplate.gradle 文件看一眼在 dependencies 部分你会看到 EDM4U 帮你写好的那一大堆依赖坐标。这时候你再正常打包之前那些缺 okhttp、缺 appcompat、Manifest 漏声明的报错基本就全没了。我当时的体验是第一次用 EDM4U 接一个重依赖 SDK从导入包到打包出 APK全程只点了两次按钮一次是 Force Resolve一次是 Build。整个过程比我之前手动接 SDK 少了大概两个小时的烦躁操作。3.6 新增或移除 SDK 后的正确操作习惯当你后续要新增一个 SDK 时流程变得更简单导入 SDK 包然后点击 Force ResolveEDM4U 会自动识别新增的依赖并更新 Gradle 文件。移除 SDK 时同理直接删掉包再点一次 Force Resolve 清理过期依赖即可。这里有个小习惯值得养成每次 Force Resolve 之后用版本工具看一眼 mainTemplate.gradle 的改动确认 EDM4U 的自动改动都在预期内。这不是不信任工具而是防止某些 SDK 包里的 Dependencies.xml 写得比较奇葩给你塞进来一些不必要的依赖导致 APK 体积变大。4. 常见问题与排查技巧实录4.1 问题一多个 SDK 依赖冲突版本号打架这是所有用 EDM4U 的项目里最高频的报错。现象是两个 SDK 依赖了同一个库但要求不同的版本Gradle 直接报 dependency conflict。比如广告 SDK 要求 okhttp 4.10.0而另一个支付 SDK 要求 okhttp 3.12.0两者无法统一。解决方案是在 mainTemplate.gradle 文件里加上强制版本配置android { configurations.all { resolutionStrategy { force com.squareup.okhttp3:okhttp:4.12.0 } } }这里的意思是不管哪个 SDK 要求什么版本我统一强制用 4.12.0。需要注意的点是强制版本之前最好确认这个版本对所有参与者都兼容。如果强推的版本太高某个老 SDK 可能内部用了老版本独有的 API编译不报错运行起来反而出问题。4.2 问题二Force Resolve 报找不到某个依赖包现象是日志里出现 Could not find 或 Unable to resolve dependency 之类的错误。常见原因有三个一是仓库地址没写全SDK 依赖发布在某个自定义 Maven 仓库但你的 Dependencies.xml 里没加二是网络问题某些地区的网络访问 Maven 仓库不稳定三是依赖坐标本身写错了比如版本号不存在。排查方向依次是检查 Dependencies.xml 的仓库配置检查坐标拼写和版本号最后检查网络。如果项目处于内网环境还需要配置代理或者镜像仓库不然 EDM4U 永远拉不下依赖。4.3 问题三禁用 EDM4U 或删除它之后工程反而编译不过了这个场景很经典不少人觉得 EDM4U 只是个“辅助工具”删了就删了结果删完一编译各种报错全涌出来。原因在于 EDM4U 在运行期间会改动你的工程文件包括 mainTemplate.gradle、AndroidManifest.xml、生成的依赖目录等。如果直接删除 EDM4U 本身但那些生成物还在而且还在引用它解析出来的依赖就必然出错。如果你真想彻底移除 EDM4U得同时清理以下几处干净才能让工程脱离它独立运行Assets/Plugins/Android/mainTemplate.gradle 中由 EDM4U 自动添加的 dependencies 和 repositories。Assets/Plugins/Android 下由 Resolver 生成的各种目录和文件。各 SDK 包里的 Dependencies.xml 文件。Project Settings 里 Player 的 Manifest 相关自定义配置。不过我的建议是既然工程已经开始用 EDM4U 管理依赖了就没必要再把它删掉。它常驻在工程里没有任何运行时开销只在编辑器里工作留着反而省心。4.4 问题四Jetifier 相关的 AndroidX 冲突有时候你明明开了 AndroidX跑 EDM4U 解析也正常但编译还是报 duplicate class 之类的错误。这通常是因为某个老 SDK 依然内部引用了 Support Library 的类而 Jetifier 没有正确转换它。排查方式有几种确认 Resolver 设置里有没有开启 Jetifier 选项确认使用的 EDM4U 版本是否支持这个功能确认 Unity 版本是否满足 Jetifier 的要求。另外还有一种很硬核的排查方法直接用文本搜索整个工程里有没有 android.support 字样残留如果有就说明某个库的包没被转换干净。4.5 超实用技巧用命令行工具看最终依赖树当依赖冲突特别复杂、Gradle 日报错又看不懂时有一个非常高效的排查技巧用命令行直接打出整个工程的依赖树。先选中 Build Settings 窗口里的 Export Project 导出为 Android Studio 工程然后在导出目录下打开命令行执行./gradlew app:dependencies这个命令会把最终参与编译的所有依赖以树状结构打印出来。你能一眼看到某个依赖到底被哪些库依赖、最终用了哪个版本一目了然。这比在 Unity 的 Console 日志里大海捞针高效多了。我之前排查一个极其隐蔽的版本冲突就是靠这个命令找到真凶的。4.6 常见问题速查表报错现象最常见原因快速排查方向Could not find / Unable to resolve dependency仓库地址缺失检查 Dependencies.xml 的 repositoriesDependency conflict / version conflict多个库要求不同版本用 resolutionStrategy 指定统一版本Duplicate classSupport Library 与 AndroidX 混用检查 Jetifier 是否开启ActivityNotFoundException 闪退Manifest 漏声明 Activity检查 EDM4U 的 Manifest 合并结果编译报错找不到某类依赖缺失或版本不对跑 ./gradlew app:dependencies 查依赖树Force Resolve 长时间没反应网络问题检查网络、配置镜像仓库最后再说点实在的接完这么多年 SDK我现在的习惯很简单任何 Unity 项目只要确定要接安卓原生 SDK第一件事就是把 EDM4U 装上然后才去谈别的。它不能帮你解决所有问题比如你自己的业务代码写得有 bug它管不了但它能把“依赖缺失”“Manifest 漏声明”“混淆规则不全”这几类最折磨人的问题从“需要逐个人工排查”变成“工具自动处理”。这个转变非常巨大。还有两个小技巧算是经验之谈。一是每次接入新 SDK、执行完 Force Resolve 之后一定要去打开 mainTemplate.gradle 看一眼改动不是为了学习而是为了确认工具没被某些奇怪的依赖带偏。二是遇到共享依赖冲突时不要第一时间去强制指定一个版本先查一下两个 SDK 官方有没有推荐版本很多大厂 SDK 的文档里会明确写它跟哪个版本兼容按官方建议走最稳。