Unity接入SDK全流程指南：从概念到真机调试

第一次在Unity项目里接SDK，我记得自己对着AndroidManifest.xml发了一下午呆。玩法已经跑通了，结果一说到接广告、接支付，整个进度直接卡住。后来把思路理顺了回头看，SDK接入在Unity游戏开发里其实就是一层窗户纸：它本质上就是把你选的第三方服务，比如广告、统计、登录、支付，通过官方给的代码包和文档“请”进你的Unity工程，再按约定调用接口、处理回调。

这篇文章就按我自己带新手接项目的完整流程来写。从SDK到底是什么开始讲，再到接入前要准备什么、完整的实操步骤、以及常见问题的排查方法，最后聊一些接多了才会有的体会。适合刚接触Unity、或者已经在写玩法但还没碰过SDK的开发者。已经是老手的话，也可以直接跳到你关心的章节看。

1. 内容整体设计与思路拆解

1.1 SDK到底是什么，说得直白一点

SDK的全称是Software Development Kit，翻译过来是“软件开发工具包”。但在游戏开发的实际场景里，你不用把这个概念想得太复杂——它就是别人提供给你的一套“打包好的服务”，让你不用自己从零去写某个功能。

举个生活化的例子：你想在店里装一台扫码收款设备，你不会自己研发一套支付系统，而是用别人做好的收款机，通电、连网、注册一下，就能用了。SDK就是这个“收款机”，Unity是你的“店铺”，接SDK的过程就是把这个第三方设备装好、接通、确保它能正常工作。

在游戏项目里，常见的SDK类型包括：

• 广告SDK：负责请求和展示广告，比如激励视频、插屏、横幅。
• 支付SDK：拉起支付页面，处理下单和回调。
• 统计SDK：上报用户行为、设备信息、留存数据。
• 登录/分享SDK：快速接入第三方账号系统，比如微信、QQ、苹果账号登录。
• 渠道SDK：国内渠道平台通常要求你必须接入它的账号、支付、防沉迷体系，才能上架。

对游戏客户端来说，这些SDK的接入方式虽然各有不同，但大流程是通的：拿AppID→导入SDK文件→改配置文件→调用接口→监听回调→跑到真机验证。

1.2 为什么Unity接SDK，总让人觉得乱

我在新手阶段最头疼的不是代码，而是“SDK的形态太多了”。同样是第三方服务，有的只给你一个UnityPackage，双击导入就行；有的给你一个aar文件，要自己拖进工程；还有的给你一个framework，是针对iOS的；更有一些要通过Gradle拉远程依赖。

这种混乱还来自平台差异。Android和iOS两端的SDK文件格式、初始化方式、回调机制完全不同。同一个SDK在Android上接好了，切到iOS又要重新对照文档搞一遍。

还有一个概念很多人一开始容易懵：渠道SDK和聚合SDK。我们常说的“渠道”在Android平台特指各个应用商店或分发平台，比如华为、小米、OPPO、vivo，以及一些第三方联运平台。它们各自有一套对接标准。如果你的游戏想上架多个渠道，一个个去接别提有多痛苦。聚合SDK做的事情，就是把多家的SDK再统一封装成一套接口，你只需要接一次，底层由聚合平台帮你分发到各个渠道。

对于个人开发者或者小团队，我的建议很直接：除非你只上一个平台、只接一个服务，否则优先选聚合SDK，别自己造轮子去维护多家直连。

1.3 接入前先想清楚三件事

动手之前，别急着下载SDK。先想清楚这三件事，能帮你少走一半弯路。

第一件：你要接什么能力。是广告、支付、统计，还是渠道登录？同一个服务在市面上往往有好几个供应商，不同供应商的文档质量、稳定性、审核周期差别很大。如果目标很明确，就只接自己真正需要的那几个，不要贪多。

第二件：你要在哪些平台跑。只做Android的话，准备工作会简单很多；要出iOS版，就需要有一台Mac，还要处理签名、隐私弹窗、App Store审核材料。这个决定会影响SDK选型和后面的联调安排。

第三件：直连还是聚合。直连就是直接接某一家官方SDK，优点是步骤少、问题好排查；缺点是平台一多，接入成本会线性增长。聚合SDK是接一个统一入口，内部再分发到多个底层SDK，前期配置复杂一点，但后面加渠道很方便。

2. 核心前置准备与环境搭建

2.1 Unity开发环境检查

很多小白接到SDK后第一反应是“直接导入工程”，结果构建Android包时报一堆环境错误。这是因为Unity本身只是一个引擎，它要打出Android包，还需要对应的构建模块和平台工具链。

在Unity Hub里安装编辑器时，一定要勾选Android Build Support。这一项下面通常还有子选项：SDK、NDK、JDK。如果你图省事，可以直接把它们全部一起装上，反正后面用的概率很高。

但有个细节要提醒你：Unity自带的SDK和JDK，跟你自己机器上安装的Android Studio版本可能会冲突。最典型的症状就是，构建时Unity一直提示找不到SDK或签名工具，路径明明存在，就是无法识别。这种情况，我建议你在Unity的Preferences->External Tools里手动把路径切到Android Studio自带的SDK目录，或者干脆在命令行里把路径配好。路径一定要全英文，不要带空格和中文，否则又会在后面给你挖坑。

iOS那边如果暂时没有Mac，你也可以先在Windows上把逻辑和Android流程走通，iOS相关的代码尽量用宏包起来，避免编辑器报错。

2.2 从SDK包里找到该看的内容

拿到一个SDK包，不要脑子一热就全部导入工程。哪怕是同一个厂商，不同版本的SDK包结构也可能不一样。我习惯先把下载好的压缩包解压到一个临时目录，然后重点看这些东西：

• README或快速开始文档：这一定是优先级最高的。它通常讲了接入条件、最低版本要求、初始化代码、需不需要额外权限。
• Demo工程：很多官方SDK会附一个Unity示例工程。值得先把它整个跑起来，确认它能工作，再考虑搬到自己的项目里。
• 目录结构：看清楚里面哪些是编辑器扩展文件，哪些是运行时库，哪些是给Android用的aar，哪些给iOS用的framework。

我见过不少同行，SDK下载完直接双击导入，导致Assets目录里塞了一堆用不到的文件，后面出了问题根本分不清是自己写的代码问题，还是SDK的默认配置有问题。

2.3 导入UnityPackage和手动集成的选择

现在市面上的SDK，提供给Unity开发者的包形态大致分两类。

一类是UnityPackage，它把代码、资源、配置文件都帮你打包好了，导入时会自动放到对应目录。这是新手最友好的形态，基本不需要你自己处理目录结构，只需要检查一下导入选项，该勾的全勾上。

另一类是原生SDK，只提供Android的aar、jar，或者iOS的framework、pod依赖。这类SDK是给原生应用用的，Unity要用它，必须手动把文件放到Plugins目录，并处理好Gradle和Manifest配置。很多新手听到“手动集成”就紧张，其实原理不复杂，后面我会专门写一节。

选哪个？如果官方同时提供UnityPackage，优先用它，因为官方已经替你想好了目录结构和兼容问题。如果只有原生SDK才支持某些核心能力，那也别嫌麻烦，手动集成的技术含量并没有想象的那么高。

2.4 日志工具准备：不会看日志，就找不到问题

接入SDK，说到底就是你和第三方系统“对话”，而对话的内容都记录在日志里。你想想看，如果对方回了一句话，你看不到，那不就只能瞎猜了？

Android真机调试时，最常用的工具是ADB，配合Android Studio的Logcat一起用。只装Unity也能看日志，打开Window->General->Console，然后通过adb logcat把系统日志灌进来，一样能看。常用的命令大概是这样的：

# 查看Unity相关日志 adb logcat -s Unity # 查看所有日志，并过滤关键词 adb logcat | grep -E "Unity|AndroidRuntime|FATAL" # 保存日志到文件，方便慢慢排查 adb logcat > app_log.txt

我的习惯是，真机运行前先把logcat清空，复现完问题后立刻停止，再把日志导出来看。不要一上来就整包翻日志，效率太低。

iOS那边，Xcode的控制台日志也很重要。Unity的Debug.Log在iOS真机上同样会输出，用Xcode跑一遍，比在Unity编辑器里假装跑通有意义得多。

2.5 提前在平台后台把信息填好

SDK接入不只是代码活，更多是配置活。这里说的“平台后台”，是你选择的第三方服务的官网后台。你需要在后台创建应用，拿到分配给这个应用的AppID、AppKey、AppSecret等一串参数。

创建应用时，大部分平台会让你填写应用包名，也就是Bundle ID。这个包名必须和你Unity工程里Player Settings填写的包名保持一致，否则SDK后台校验会失败，最常见的表现就是初始化后回调报错，或者广告拉不出来。

我建议你在正式打包前，就定好正式包名和测试包名，并记录在项目文档中。不要图方便用一个包名打天下，更不要在联调过程中频繁改包名，否则后面渠道审核的时候想哭都没地方哭。

3. 实操过程与核心环节实现

3.1 用UnityPackage走通第一个SDK

这里我用一个虚构的广告SDK来演示完整流程，思路是通用的。实操之前，先在平台上创建一个测试应用，拿到测试AppID和测试广告位ID。

第一步，导入UnityPackage。打开Assets->Import Package->Custom Package，选择下载好的unitypackage，弹出导入列表后，建议全部勾选。

第二步，找到官方Demo场景。一般SDK包会自带一个场景，名字往往叫Demo、Sample或Main，双击打开。先别急着改任何东西，把平台上拿到的AppID填到对应的脚本组件里，点Play运行。

第三步，在编辑器里观察日志。如果SDK设计得好，你会发现控制台里依次输出“初始化开始”“初始化成功”“广告请求成功”之类的日志。走到这一步，说明SDK环境本身没问题，你的工程环境也没问题。

第四步，把日志里确认可用的初始化代码和广告调用代码，复制到你自己项目的管理代码里，然后删掉Demo场景。这样就完成了一次最小闭环。

很多人的习惯是“先复制自己的项目里再说”，结果各种报错之后，根本分不清是SDK的问题还是自己集成的问题。先跑通Demo，就相当于先确认路通不通，然后再开车。

3.2 手动集成原生aar时的目录与Gradle配置

如果SDK只有Android的aar文件，没有UnityPackage，那操作路径大概是这样的：新建一个Plugins/Android文件夹，把aar文件放进去，有需要的话把对应的AndroidManifest.xml也放进去，然后再修改Gradle模板。

Unity的Gradle模板在Player Settings里开启“Custom Main Gradle Template”后，会自动生成到Assets/Plugins/Android/mainTemplate.gradle。你需要在里面加上仓库地址和依赖声明，常见形式如下：

allprojects { repositories { mavenCentral() maven { url 'https://your-sdk-repo.example.com/android' } } } dependencies { implementation 'com.example.sdk:ad-sdk:1.2.3' }

这里最麻烦的一个坑是，第三方SDK依赖的库可能会和你接入的其他SDK冲突。比如两个SDK都依赖了不同版本的AndroidX库，构建时就会报Duplicate Class或者Version Conflict。遇到这类提示，先不要慌，去查一下冲突的是哪个包，然后在Gradle里用exclude把重复的模块排除掉。

我接广告SDK时遇到过Gradle版本不一致导致整个项目构建失败的情况，最后发现只是Unity生成的模板版本太高，而SDK还是用旧版本Gradle写的。解法也很直接：把Unity的Gradle版本临时降一档，构建通过后再升回去。

3.3 AndroidManifest潜规则：权限、Activity、查询包名

AndroidManifest.xml是Android工程的“户口本”，SDK需要在里面登记权限、Activity和服务的说明。不少SDK接入后打不开、闪退、拉不起支付页面，都是这里出了问题。

常见的必填权限包括网络权限、网络状态权限、安装未知来源权限等。部分广告SDK要求读取设备状态权限，您可以根据业务需要决定是否主动声明。此外，支付类SDK往往要在Manifest里注册对应的Activity，注意Activity的exported属性和launchMode都要按文档写对，否则拉起支付页面时会直接崩溃。

<manifest xmlns:android="http://schemas.android.com/apk/res/android"> <uses-permission android:name="android.permission.INTERNET" /> <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" /> <application> <activity android:name="com.example.sdk.SdkPaymentActivity" android:exported="true" android:launchMode="singleTask" /> </application> </manifest>

新版Android系统对包可见性也有限制。如果你需要判断用户是否安装了微信、支付宝这类App，必须在Manifest里加queries标签，否则调用SDK查询接口时会一直返回“未安装”。

在Unity工程里改Manifest，我建议不要直接去改Unity安装目录下面的默认Manifest，而应该在Plugins/Android/AndroidManifest.xml里维护自定义版本，这样打包时Unity会自动合并，出错也方便回滚。

3.4 写一个SDK管理器：C#怎么和原生通信

手动接入SDK时，你需要在C#侧通过一个统一的SDK管理器，把原生代码包一层。下面这段代码是一个典型的单例管理器骨架，里面用到了AndroidJavaClass和AndroidJavaObject，这是Unity调用Android原生代码的核心方式。

public class SdkManager : MonoBehaviour { public static SdkManager Instance { get; private set; } private AndroidJavaObject sdkHelper; void Awake() { if (Instance != null && Instance != this) { Destroy(gameObject); return; } Instance = this; DontDestroyOnLoad(gameObject); } void Start() { InitSdk(); } public void InitSdk() { #if UNITY_ANDROID && !UNITY_EDITOR using (var player = new AndroidJavaClass("com.unity3d.player.UnityPlayer")) { var activity = player.GetStatic<AndroidJavaObject>("currentActivity"); sdkHelper = new AndroidJavaObject("com.example.sdk.SdkHelper", activity); sdkHelper.Call("init", "你的AppID"); } #elif UNITY_IOS && !UNITY_EDITOR // iOS 侧一般通过 UnitySendMessage 或 C# 调原生方法完成 #endif } public void ShowAd(string adId) { #if UNITY_ANDROID && !UNITY_EDITOR sdkHelper?.Call("showAd", adId); #endif } }

这段代码有几个关键点。

第一，不要用静态类来管理SDK，因为SDK往往有回调机制，回调会随时触发。MonoBehaviour的单例可以挂在一个不销毁的GameObject上，这样回调就能以事件、委托或者UnitySendMessage的方式正常发送到游戏逻辑。

第二，初始化放在Start里而不是Awake里。初始化是一个网络请求行为，需要确保其他场景对象已经准备好了，避免时序冲突。

第三，真机调试时，#if UNITY_ANDROID && !UNITY_EDITOR这个宏很关键。它保证你在Unity编辑器里不会执行原生调用代码，否则编辑器会直接报找不到Java类。

3.5 生命周期管理：初始化到底放哪里才稳

这里的“生命周期”不单指Unity的Awake、Start、Update，还指应用从启动到前后台切换再到退出的整个过程。

我现在习惯把SDK初始化放在第一个启动场景中，由一个常驻的“SDK启动器”负责。初始化一定不要放在收费接口触发时才调用，那样用户会明显感觉到卡顿，而且第一次请求大概率会失败。

Android端，Pay SDK或广告SDK对生命周期很敏感。应用切到后台，再切回前台时，一些SDK需要重新刷新状态；如果要做“前后台切换后恢复广告”这种需求，可以在OnApplicationPause里转发事件给SDK。比如：

void OnApplicationPause(bool pauseStatus) { #if UNITY_ANDROID && !UNITY_EDITOR sdkHelper?.Call("onApplicationPause", pauseStatus); #endif }

很多新手容易犯一个错误，就是场景切换时把SDK管理器这个对象摧毁了。SDK管理器一旦重建，SDK内部的状态就断了，后果是二次初始化报错，或者回调全部丢失。所以DontDestroyOnLoad这个操作非常有必要。

3.6 一个完整的广告加载展示流程示例

以激励视频为例，绝大多数广告SDK的操作逻辑都是三步走：初始化、预加载、展示。

初始化完成后，你要向SDK请求一个广告，这一步叫“预加载”。广告加载成功之后，SDK会通过回调告诉你“已经准备好了”。这个时候你才能展示按钮，用户点击后，SDK拉起广告页面，用户看完或跳过，再回调你最终结果。

时序大概是这样的：

1. 打开游戏，初始化SDK。
2. 初始化回调成功后，调用“加载广告”接口。
3. 收到“广告加载成功”回调时，把界面上的按钮置为可点击。
4. 用户点击按钮，调用“展示广告”接口。
5. 广告页关闭后，SDK会回调“是否完整观看”，这时候再发奖励。

很多新手忘了“预加载”这一步，用户点击按钮时才临时请求广告，结果等待时间太长，或者直接请求失败，奖励发不出去。正确做法是，在游戏早期场景就主动把广告加载好，甚至可以在一个广告展示完并回调关闭后，马上预加载下一个广告，保证任何时候都有“货”能拿出来。

iOS端同理，只是方法名可能不一样，但思想完全一致。只记住一点：广告是稀缺资源，别现用现取。

3.7 构建打包前的最后检查

接完SDK，你一定想打个包到真机上看看效果。在点Build之前，有几个设置值得检查一遍。

• 包名：Player Settings里的包名必须和SDK后台填写的一致，简称包名不一致是新手第一高发问题。
• 签名：Android发布使用的签名文件和测试时期是否一致。如果换过签名，登录或者支付的校验会失败。
• 脚本后端：推荐IL2CPP，兼容性和性能都更稳，但打包时间会长一些。
• 目标API级别：很多平台SDK对最低和最高API级别有要求，目标SDK版本过高或过低都会有问题。

第一次构建建议先打一个不带SDK的空包到真机上安装好，确认基础流程正常；再加上SDK打包，这样如果出问题，就能确定问题出在SDK这一层。

4. 常见问题与排查技巧实录

4.1 错误码速查表

每个SDK都会有一套错误码，但它们的含义大致是相通的。下面是一个常见的错误码速查表，遇到问题时先对号入座，能省去大量搜索时间。

4.2 编译不过、崩溃、类冲突怎么办

最常见的编译问题，几乎都出在重复的依赖上。比如你接入了一个广告SDK，它内部已经带了一份网络请求库，你又用另一个SDK带了一份不同版本的同类库，构建时就会爆出冲突警告，甚至编译直接失败。

遇到Duplicate Class之类的编译错误，先打开Build Report或Gradle Console，看清楚冲突的是哪个包名，然后在Gradle的dependencies里使用exclude模块排除重复依赖。

implementation('com.example.ad:sdk:1.2.3') { exclude group: 'com.squareup.okhttp3', module: 'okhttp' }

还有一种崩溃是运行时找不到类，多半是使用了Proguard混淆。如果你开启了代码压缩或者混淆，一定要把SDK相关类加入白名单。很多时候，官方文档会直接给你一条混淆配置指令，比如：

-keep class com.example.sdk.** { *; }

这类规则建议直接加在mainTemplate.gradle里对应的proguard文件，不要只写在某个临时文件里，以免被打包时忽略。

4.3 回调不触发、回调丢失怎么查

我接SDK踩过最多坑的地方，就是回调。广告明明展示完了，游戏里却一直不弹奖励；登录明明成功了，自己的界面却没有反应。这种情况十有八九是回调链路断了。

如果SDK用的是UnitySendMessage这种方式，它本质上是从原生代码往Unity场景里发送一条消息，调用指定GameObject上的指定方法。那么有以下几点必须注意：

• 目标GameObject的名字必须完全一致，大小写不能错。
• 目标GameObject必须处于激活状态，不能隐藏。
• 回调方法不能是私有方法，必须是public。
• 如果场景里存在多个同名GameObject，回调可能会分发到奇怪的对象上。

另外一个容易被忽视的点是线程问题。Unity的API不允许在非主线程调用，很多SDK的回调来自原生后台线程，收到回调后应该先切到Unity主线程再处理逻辑。如果你把回调处理直接放在原生线程里，Unity可能会直接报“get_main_thread_id”之类的错误，或者表现不稳定。

4.4 为什么Unity编辑器里能用，真机却不行

这是新手最容易困惑的场景：在Unity编辑器里点Play，什么事情都没有，日志也正常；一装到真机上，要么黑屏，要么点按钮没反应，要么直接闪退。

原因很直接，SDK的很多能力在编辑器环境里本来就不支持。最常见的原因有两个：一是SDK依赖了真机才有的系统能力，比如设备标识符、系统弹窗、系统浏览器；二是SDK的初始化需要真实网络环境和正确的签名信息，编辑器里跑的是假环境，很多校验直接跳过。

我建议所有SDK联调一律以真机为准，模拟器只用来做初步验证。iOS上还要特别注意苹果的ATS，就是“App Transport Security”。如果SDK里的接口域名是HTTP而不是HTTPS，真机上的请求会被系统直接拦截，报错看起来像网络问题，实际上是无HTTPS许可导致的。

真机调试时，优先使用开发者模式，打开USB调试，通过adb logcat观察运行时日志。你会发现在编辑器里“一切正常”的代码，在真机上其实输出了大量报错信息，只是Unity Console看不到。

4.5 包体变大、启动变慢怎么优化

接SDK必然带来包体和内存的增加，这是代价，但有些增长是可以优化的。

先看包体：在Build Report里查看各类文件大小，如果某个SDK自带的资源占了很大比例，就可以排查这个SDK是否支持拆分资源包。有些广告SDK支持按广告形式拆模块，你只用一个激励视频，就不要把插屏、原生模板的模块也编译进来。

再看启动：SDK初始化是一个串行过程，接的SDK越多，启动越慢。解决方案是“延迟初始化”，不在第一个场景把所有SDK全部初始化完，而是进入真实需要的场景时再初始化。比如在游戏主菜单里，优先初始化统计和登录SDK，到对局开始前再初始化广告SDK，这样玩家进入游戏的速度会明显提升。

最后提一点：能共用一套反馈通道的地方尽量共用。有些第三方SDK会内置埋点上报，它们各自上报一次还好，如果每个SDK都在启动时加载一份公用的数据分析库，内存会白白增加很多。

5. 进阶建议与实操心得

5.1 无论多急，先跑通官方Demo

接SDK本身并不难，难的是“在没确认路通不通的情况下就着急赶路”。我认识不少做独立游戏的朋友，为了赶版本，第一次接SDK就跳过Demo直接在自己工程里改，结果改了半天，最后还是灰溜溜回去跑官方示例。

跑通官方Demo有一个额外的好处：你能看到这个SDK作者推荐的项目结构。他们一般会把初始化代码、UI交互、回调处理组织得很清晰。你把Demo跑完，再看看它的代码是怎么组织的，会让你写自己的接入层时思路开阔很多。

这里需要注意一点，Demo跑通不代表万事大吉。Demo工程里通常用的是官方测试AppID，而你自己的正式AppID需要重新在后台申请权限。测试阶段一定要先申请测试模式，很多平台提供了测试广告位、测试支付环境，一定要用起来，别拿正式环境做测试，否则可能会让你的后台数据一团乱，甚至被平台判定为异常操作。

5.2 给SDK配置建一份“档案”

项目里的SDK会越来越多，可能这个月接一个，下个月换一个，到半年后你根本记不清当前工程里哪个SDK是哪个版本、AppID是什么、配置改过哪些地方。所以我强烈建议，在项目根目录放一份SDK接入档案，内容很简单，包括：

• SDK名称、版本号、官网下载地址。
• 使用的AppID、AppKey，以及这套参数对应的正式/测试环境。
• 接入时间、最近一次升级时间。
• 接入过程中踩过的坑和对应的解决办法。
• 配置过的Manifest权限、Gradle依赖、混淆规则。

这份档案平时看起来不起眼，等三个月后SDK需要升级、或者同事接手项目的时候，它的价值就体现出来了。我甚至会把每次联调时遇到的报错和修复方式直接追加在档案末尾，时间长了，它就变成你自己的私有排错手册。

升级SDK时，务必先看官方Release Notes。很多人喜欢“有新版必更”，结果新版SDK改了方法名、改了回调参数，自己还在按旧文档写，白白浪费一整天。升级前先确认新版和Unity版本兼容，再决定要不要升级。

5.3 与第三方平台打交道的经验

接入SDK的过程中，你迟早会遇到官方文档解决不了的问题，这时候就轮到你跟第三方平台的技术支持打交道了。

我吃了很多次亏后总结的经验是：提问时不要只发一句“我的广告拉不出来了”，要把以下信息一次性带上，效率会翻好几倍。

• Unity版本号、SDK版本号、操作系统版本。
• 手机型号和系统版本。
• 完整的报错日志片段，不要截几行，要能覆盖从初始化到报错的完整过程。
• 复现步骤，比如“启动App后点按钮X，等待5秒后崩溃”。
• 自己在什么条件下能稳定复现，切换到什么条件下就正常。

技术支持看到这种提问，基本很快就能定位问题。相反，如果你只发一个截图，对方问一句你才答一句，一个简单的问题能拖好几天。

跟渠道平台合作时还要注意审核周期，比如渠道SDK的版本更新、包体上传审核、广告位开通，这些都可能需要提前申请，临时抱佛脚很容易导致发布时间延误。

5.4 接多了SDK之后的个人体会

接的SDK多了之后，我对“稳定”二字的理解越来越深。能用官方插件就用官方插件，不要什么功能都觉得可以自己封装。自己造轮子一时爽，SDK一升级，你的封装层可能就废了，而官方插件通常会跟着新版SDK一起更新。

不要盲目追求最新版本。如果项目运行稳定，SDK版本老一点不是问题。很多平台的新版本SDK会强制要求更高的系统版本或更新的AndroidX依赖，你为了一个无关紧要的升级，去改全项目的依赖链，典型的不划算。只有在现有版本遇到无法绕过的Bug时，才考虑升级。

当项目里的SDK数量超过三个，强烈建议统一封装一层事件中心。把每个SDK的回调先集中到一个点，再由事件中心向各业务模块分发。如果没有这一层，你的项目里会到处散落着广告回调、支付回调、登录回调，查起问题来非常痛苦。

最后的最后，再分享一个我自己一直坚持的笨办法：每次接入SDK之前，先把官方文档里的接入流程完整看一遍，再用笔记把关键步骤写下来，最后再动手。这个办法看着慢，实际上是最省时的。因为SDK文档虽然繁琐，但它是唯一不会骗你的信息来源。搜索引擎里那些截图教程，很可能已经过期了好几个版本，跟着它们走，只会把你带到更深的坑里去。