📚 课程目录第4章基础接入验证

4. 基础接入验证：SDK初始化流程、权限申请检查、基础功能连通性测试

好，终于走到动手验证这一步了。很多同学觉得接入SDK就是拷个包、配个AppKey、运行一下，完事。嗯，天真了。

基础接入验证，说白了就是检查两件事：你的App有没有正确地「请」SDK进来，以及SDK进来之后能不能正常「干活」。我见过太多项目，花了两周调通业务逻辑，最后发现是初始化配置少了一个参数，所有功能都在报空指针。所以这一章，我会把验证拆成三个台阶，每个台阶都有坑。

4.1 SDK初始化流程验证

先上结论：初始化验证的核心不是看日志，是看时序和上下文。

我个人的习惯是，拿到一个新SDK，第一件事不是跑Demo，而是先看它的初始化API签名：

// 常见初始化接口
SDKConfig config = new SDKConfig.Builder()
    .setAppKey("your_key")
    .setDebugMode(true)
    .setUserId("test_user")
    .build();

MySDK.init(getApplicationContext(), config);

这里有三个检查点：

上下文是不是Application级别。如果你传的是Activity的Context，很有可能引发内存泄漏或生命周期错乱。
初始化方法在主线程还是子线程？文档没写？抓一下Looper。我在项目中发现过某个支付SDK，初始化里做了大量I/O操作，直接怼在主线程上——冷启动活生生慢了3秒。
是否串行化。有些SDK内部依赖多模块初始化顺序，比如必须先初始化核心模块，再初始化业务模块。你如果并行调用，大概率会抛异常。

曾经的坑： 我曾经在一个海外项目中同时接入了推送SDK和统计SDK。它们的初始化方法互相依赖对方的日志组件，结果循环等待，App直接ANR。后来我加了一个「初始化信号量锁」，才把问题压下去。所以，多SDK共存时，一定要验证初始化时序。

4.2 权限申请检查

权限这块，我不啰嗦安卓6.0动态申请那套基础。我只讲SDK接入时你最常遇到的三种权限问题：

4.2.1 权限清单核对

把SDK的AndroidManifest.xml合并到你项目的Manifest里，逐条对照。我一般会列一个对比表：

权限名称	SDK声明	项目是否继承	是否可选
INTERNET	android.permission.INTERNET	是	必选
ACCESS_NETWORK_STATE	android.permission.ACCESS_NETWORK_STATE	是	必选
READ_PHONE_STATE	android.permission.READ_PHONE_STATE	是	可选（用于设备标识）
ACCESS_FINE_LOCATION	android.permission.ACCESS_FINE_LOCATION	否（需手动添加）	可选

注意，「可选」权限是最容易出事的。很多SDK在获取不到权限时会静默降级，但也有非常流氓的——拿不到READ_PHONE_STATE直接罢工。你需要在测试用例里覆盖「拒绝授权」的场景。

4.2.2 运行时权限的测试策略

正常流：用户同意所有权限，验证SDK功能正常。
拒绝流：用户拒绝关键权限（比如互联网权限），验证SDK是否有友好的提示或降级表现。
撤销流：在App运行中，去系统设置里关闭某个已授权的权限，验证SDK能否及时感知并处理。

你想想看，运营同学可能永远不点「拒绝」，但用户会。如果在撤销权限后，你的App直接闪退……嗯，等着应用商店差评吧。

4.3 基础功能连通性测试

初始化通过、权限也勾上了，接下来就要验证SDK能不能和它的后端说上话。这个阶段我称之为「心跳测试」。

4.3.1 核心连通性检查项

请求能发出吗？抓一下网络日志（Charles、Fiddler或者直接用Android Studio的Network Inspector）。确认URL、Header、Body符合文档预期。
响应能回来吗？Mock网络超时、服务器500、返回空JSON，每一种都要试。
回调链完整吗？SDK可能在子线程回调，也可能切到主线程。你自己写个回调测试桩，确认onSuccess/onFailure被正确调用。

   核心经验： 我建议你在连通性测试阶段，不要用真实的生产环境服务器。搭一个本地Mock Server（用OkHttp MockWebServer或者WireMock都行），可控、可复现、不污染线上数据。

4.3.2 一个标准的连通性测试框架

基于我自己的经验，我会写一个类似的测试桩：

public class ConnectivityTest {

    @Test
    public void testInitAndPing() {
        // 1. 初始化SDK
        SDKInitializer.init(mockContext, testConfig);
        // 2. 请求基本的连通性接口（比如ping或health check）
        SDKConnectivity.ping(new Callback() {
            @Override
            public void onSuccess(PingResponse response) {
                // 验证响应状态码和关键字段
                Assert.assertEquals(200, response.code);
                Assert.assertNotNull(response.sessionId);
            }

            @Override
            public void onFailure(Throwable t) {
                // 预期内的失败要验证异常类型
                Assert.assertTrue(t instanceof TimeoutException);
            }
        });
    }
}

技巧： 如果你的SDK提供了「沙箱环境」的配置开关，一定要在测试时打开。沙箱环境通常有更完整的Mock后端，能帮你更早发现问题。有一个团队接入地图SDK时没切沙箱，结果在测试环境里疯狂请求线上配额，三个小时把当月百万次调用限额用光了——这个月剩下的时间他们只能用离线缓存看地图了。

4.3.3 别忘了异常场景

无网络环境下的初始化——会不会一直卡在主线程等超时？
弱网环境（模拟丢包30%、延迟2000ms）——SDK的重试机制是否生效？
校验AppKey/过期——SDK是否主动刷新，还是直接报错？

我自己的记法：基础验证阶段走完这三个台阶，你应该能回答三个问题了——App准备好没有？权限谈妥没有？通讯通没有？任何一个回答「没有」，就不要往下一阶段走。千万别在初始化都没跑通的情况下，就开始调支付、调地图、调推送，你会被无数个「不可能发生的bug」拖垮。

下面这张图可以帮你快速回顾整个验证链路：

这三个台阶走完，你的基础接入验证就算闭环了。接下来你可以放心地推进到更复杂的业务功能测试——因为你已经确认过地基是稳的。要牢记：初始化不出错，权限不缺失，通讯不掉线，这是所有后续测试的前提。