适配器模式+策略模式：多SDK集成解耦的完整落地指南

之前维护的那个项目里，接入的第三方SDK一多，代码就慢慢变得特别拧巴。光推送就接了三家，支付还有两套渠道，再算上地图、分享、统计，业务侧每次提需求，真正写业务逻辑可能只要一两个小时，但把各个SDK的调用理顺，往往要花上一整天。最绝望的是某一个SDK升级了，它把某个方法签名改了，或者回调从主线程挪到子线程，你就得把所有落点翻个底朝天。后来我花了两个迭代，把整套外部能力接入改成“适配器模式 + 策略模式”的组合架构，才终于把这块烂摊子收拾干净。这篇文章就是我当时重构思路的完整记录，适合那些项目里已经接了两个以上SDK、又想在后续迭代里控制复杂度的团队参考。

1. 多SDK项目的失控路径：业务代码是怎么一步步被拖垮的

1.1 接入初期：每一个SDK看起来都很简单

最开始项目里只有一个推送SDK，接入过程确实不复杂。在Application里初始化一下，用户登录后调一个绑定接口，然后处理前台展示回调就行。那会儿如果让我画调用关系，就是两三条直线，业务方和SDK直接面对面，谁都能看懂。

问题出在第二个、第三个SDK进来的时候。项目不会只加推送，还要加统计、支付、分享、地图，每加一个SDK，调用链就多出一撮分支。刚开始你还会坚持在工具类里封装一下，但随着需求排期越来越紧，封装逐渐变成“哪里用到就在哪里调用”。我印象很深的一次，是某个新同事接支付渠道，他在订单确认页直接调了微信支付的SDK方法，又在支付回调页写死了渠道判断，结果后面要加第二个支付渠道时，那一环扣一环的改动差点把线上版本拖崩。

反正在真实项目里，多SDK带来的问题从来不是“第一次接入有多难”，而是第二次、第三次接入时，你发现自己已经没办法只改“新增部分”了。旧代码里到处散落着对旧SDK的依赖，改一个地方根本不够，你得顺着调用链把所有被SDK污染过的地方全部找出来。

1.2 失控后的典型症状

我后来总结了几个特别典型的失控信号，如果你项目里已经出现了，说明SDK集成层该重构了：

• 业务代码里到处是渠道分支判断，if (channel == JPUSH)、if (channel == WECHAT)、else if (channel == ALIPAY) 这类逻辑散落在各个页面。
• 更换或升级某一家SDK时，改动点超过十个文件，而且每次都要小心翼翼判断“这个方法到底被谁用了”。
• 新增一家同类SDK（比如再加一个推送渠道），排期不是一到两天，而是一周以上，因为不只是新增实现，还要动所有调用点。
• 某个SDK初始化失败或者运行时抛异常，没有降级机制，轻则功能不可用，重则可能导致崩溃。
• 团队里新来的同学代码规范再好，也不敢轻易动SDK相关代码，因为不知道里面藏着多少隐式依赖。

一旦出现这些迹象，就别再靠“代码审查严格一点”来续命了。问题的根子在于结构：业务层和具体SDK的耦合度太高，你永远堵不住新的分支往里加。

1.3 重构目标：业务代码不再直接认识任何一家SDK

我当时定的重构目标非常明确：业务层不再直接依赖任何一家第三方SDK，它只依赖一个由我们自己定义的统一接口。SDK升级、更换、增加，都只发生在封装层内部。

这个目标说起来简单，做起来难的一点在于：你不能为了解耦而设计出一套大到离谱的抽象层。如果统一接口把各家SDK的所有能力全塞进去，那封装层本身会变成一个大杂烩，维护成本不降反升。

所以第一件事是收敛。要抽象的不是“第三方SDK能做什么”，而是“业务目前需要第三方SDK做什么”。这两者区别很大。拿推送举例，业务方其实只关心四件事：初始化、绑定用户、解绑用户、接收消息回调。至于极光推送还支持自定义消息、地理围栏、富媒体通知，这些能力如果你当前业务没用上，就不应该出现在统一接口里。

2. 适配器+策略：两个模式为什么是绝配

2.1 适配器模式解决的是“接口不一样”

适配器模式的核心价值，是把两个原本接口不匹配的对象通过一个中间层对接起来。放在SDK集成场景里，每个第三方SDK的API设计思路都不一样，但你希望业务方调用时看到的语义是一致的。

举个实际例子：极光推送绑定别名的方法是 JPushInterface.setAlias(context, alias, callback)，友盟的方法叫 UMengPushManager.setAlias(alias, callback)，个推的方法又是另一个签名 PushManager.getInstance().bindAlias(alias)。方法名不同、参数顺序不同、回调机制不同，但它们表达的业务语义都一样：把当前用户和一串别名绑定起来。

适配器就是用来消化这些差异的。你定义统一接口 bindAlias(String alias, Callback callback)，然后给每家SDK写一个适配器实现，适配器内部去调用真正SDK的API，并把结果翻译成统一回调。业务方看到的是同一个接口，底层是谁在干活，它完全不关心。

2.2 策略模式解决的是“用哪一家”

适配器解决完“接口长得不一样”的问题之后，还有一个问题没解决：多套实现并存时，运行时到底该选哪一套？

这就是策略模式出场的地方。策略模式的核心思路是定义一族可替换的算法或实现，把它们封装起来，在运行时根据条件动态选择。在SDK这个场景里，“用哪家推送”“用哪个支付渠道”“走哪个地图厂商”本身就是一类策略选择问题。

策略模式落地时通常有个选择器，由一个注册表加一个当前指针组成。各家适配器先注册进来，选择器根据渠道标识切换当前实现，后续所有调用都走当前策略。

2.3 组合起来的化学反应

两个模式单独用，都差点意思。只做适配器，虽然接口统一了，但业务层如果要切换渠道，还是会到处写 new JpushAdapter() 或者 new GetuiAdapter()，选择逻辑依然散落；只做策略，虽然切换机制有了，但各家的接口差异还是得靠一堆 if-else 去适配，策略内部就乱成一锅粥。

适配器负责把“不同”变成“相同”，策略负责在多个“相同形状但不同实现”之间做选择。前者是结构上的翻译，后者是行为上的分流，组合在一起，才能形成一条完整的“统一接入-动态切换”链路。我理解为：适配器是让你把所有插头都插进同一个插座，策略模式是你随时拨动开关决定哪一路通电。

3. 落地实操：接口定义、适配器封装与策略注册

3.1 抽统一接口是第一步，也是最关键的一步

我建议不要直接从写适配器开始，而是先站在业务调用方的角度，把统一接口定义出来。这个接口只表达“业务需要什么”，不表达“SDK能做什么”。

以推送为例，我最终收敛出的接口大致是这样：

java复制public interface PushProvider {

    // 渠道标识，比如 "jpush"、"getui"、"umeng"
    String channelName();

    // 初始化，传入应用上下文和该渠道需要的配置
    void initialize(Context context, PushConfig config);

    // 绑定别名（用户ID）
    boolean bindAlias(String alias, ResultCallback callback);

    // 解绑别名
    boolean unbindAlias(String alias, ResultCallback callback);

    // 设置消息接收回调
    void setMessageCallback(MessageCallback callback);

    // 当前渠道是否可用
    boolean isAvailable();

    // 释放资源
    void release();
}

接口里我特意保留了 isAvailable()。这个方法的用处后面再说，但它是降级策略的基石。至于 release()，是为了统一生命周期的收口。有些SDK提供了释放方法，有些SDK本身是全局单例不需要释放，适配器内部处理掉差异就行，上层永远不用关心。

3.2 为每家SDK写适配器，公共逻辑提到抽象类里

接口定义完，接下来是每个渠道一个适配器。我给推送写了三个Adapter：极光、个推、友盟。它们的结构几乎一样，所以我把公共逻辑抽了一个抽象模板类出来。

java复制public abstract class AbstractPushProvider implements PushProvider {

    protected Context context;
    protected PushConfig config;
    protected MessageCallback messageCallback;
    protected volatile boolean initialized = false;
    protected volatile boolean available = false;

    @Override
    public void initialize(Context context, PushConfig config) {
        this.context = context.getApplicationContext();
        this.config = config;
        this.initialized = true;
        this.available = doInitialize();
    }

    // 由子类实现真正调用SDK初始化逻辑
    protected abstract boolean doInitialize();

    @Override
    public boolean isAvailable() {
        return initialized && available;
    }

    protected void dispatchMessage(PushMessage message) {
        if (messageCallback != null) {
            messageCallback.onMessage(message);
        }
    }
}

然后具体适配器就只关注“怎么把SDK的API翻译成统一接口语义”。以极光为例，核心逻辑大概是：

java复制public class JPushProvider extends AbstractPushProvider {

    @Override
    public String channelName() {
        return "jpush";
    }

    @Override
    protected boolean doInitialize() {
        JPushInterface.setDebugMode(config.isDebug());
        JPushInterface.init(context);
        return true;
    }

    @Override
    public boolean bindAlias(String alias, ResultCallback callback) {
        JPushInterface.setAlias(context, alias, new JPushInterface.AliasCallback() {
            @Override
            public void onResult(int code, String alias, Set<String> tags) {
                if (code == 0) {
                    callback.onSuccess();
                } else {
                    callback.onFailure(code, "极光绑定失败，错误码：" + code);
                }
            }
        });
        return true;
    }
}

实际业务里返回值和异步回调都要仔细设计，但这已经不是重点。重点是，从这开始，业务层和极光的SDK类不再有任何直接联系。

3.3 策略注册与运行时选择

适配器写完之后，需要一个策略选择器把各渠道管起来。我用的是一个非常朴素的注册表加当前指针的结构：

java复制public class PushStrategyContext {

    private final Map<String, PushProvider> providerMap = new ConcurrentHashMap<>();
    private volatile PushProvider currentProvider;

    // 注册渠道
    public void registerProvider(PushProvider provider) {
        providerMap.put(provider.channelName(), provider);
    }

    // 根据渠道标识切换当前策略
    public boolean switchTo(String channelName) {
        PushProvider provider = providerMap.get(channelName);
        if (provider == null) {
            return false;
        }
        currentProvider = provider;
        return true;
    }

    // 获取当前渠道
    public PushProvider current() {
        if (currentProvider == null) {
            throw new IllegalStateException("未初始化推送策略");
        }
        return currentProvider;
    }
}

为什么用字符串做key而不是枚举？因为渠道配置往往来自服务端下发的配置，字符串的兼容性更强。以后新增一个渠道，只需要注册一个适配器，不需要改枚举、改switch、改动所有调用点。

3.4 调用侧的效果对比

重构前，业务代码大概是这种风格：

java复制// 重构前：散落的分支和SDK调用
public void bindUser(String userId) {
    if (pushChannel == 1) {
        JPushInterface.setAlias(context, userId, null);
    } else if (pushChannel == 2) {
        PushManager.getInstance().bindAlias(userId);
    } else {
        UMengPushManager.setAlias(userId, null);
    }
}

重构之后，业务代码只需要写：

java复制// 重构后：统一走策略入口
pushStrategyContext.current().bindAlias(userId, callback);

你想换哪个渠道，在策略注册阶段决定一次就够了。新增渠道时，流程从“改所有调用点”变成了“写一个Adapter，注册一行代码，完事”。

4. 运行时管理：初始化、动态切换与降级兜底

4.1 初始化时机：别在构造函数里干重活

第三方SDK的初始化通常都需要Context、AppKey、渠道信息，有些SDK初始化还会弹通知申请权限。这些工作绝对不能放在适配器的构造方法里，否则策略注册的时候就可能搞出各种副作用。

我这边统一在Application的onCreate里，根据本地配置或服务端配置做初始化：

java复制public class App extends Application {

    @Override
    public void onCreate() {
        super.onCreate();

        String pushChannel = fetchPushChannel();

        PushStrategyContext pushStrategy = new PushStrategyContext();
        pushStrategy.registerProvider(new JPushProvider());
        pushStrategy.registerProvider(new GetuiProvider());
        pushStrategy.registerProvider(new UmengProvider());

        if (pushStrategy.switchTo(pushChannel)) {
            PushProvider current = pushStrategy.current();
            current.initialize(this, buildPushConfig());
        }
    }
}

注意，这里我没有保证所有渠道都初始化。我只初始化了当前策略对应的那个渠道。这个做法的好处很直接：不用的SDK不做多余启动，省电省内存，也避免一些SDK在后台互相打架。

但也有一种场景需要把多个渠道都初始化进去，比如多个推送厂商通道同时在线做厂商级推送保活，那是另一个话题了，策略选择器的结构本身不受影响，只是初始化逻辑要微调。

4.2 动态切换：用户主动选还是服务端下发

策略模式的真正威力在于运行时切换。我遇到过的切换场景主要有两类。

一类是用户主动选择。典型的是支付收银台，用户选了微信还是支付宝，就切换对应的支付策略发起订单。这类切换逻辑不需要持久化，每次发起支付时根据用户选择切换一下就行。

另一类是服务端下发。比如推送渠道，服务端可以下发一个JSON配置，指定当前运营阶段用哪家推送，客户端在冷启动或者热更新时读到配置，调用 switchTo(channel) 切换。这个能力在生产环境特别有用，比如某家SDK厂商出现故障，运营只用改配置，不用发版，就能把流量切到另一家。

java复制// 服务端下发渠道标识，客户端切策
String channelFromServer = fetchRemoteChannel();
if (pushStrategy.switchTo(channelFromServer)) {
    log("推送渠道已切换为: " + channelFromServer);
}

4.3 一个SDK挂了，如何优雅降级

这是我在写这套架构之前踩过最深的坑。某一次线上故障，主要推送SDK的服务器连接超时，导致消息完全推送不出去，而且是静默失败，连日志都没有。业务侧完全无感知，用户收不到推送，消息模块日活数据直接掉了两个点。

用了策略模式之后，我把“健康度”概念加进了策略选择逻辑。适配器内部维护一个可用性状态，比如初始化失败标记为不可用，连续几次发送失败也标记为不可用。选择器在获取当前策略时，如果当前策略不可用，自动降级到备选策略：

java复制public class PushStrategyContext {

    private final List<PushProvider> providers = new CopyOnWriteArrayList<>();

    public PushProvider selectAvailable() {
        for (PushProvider p : providers) {
            if (p.isAvailable()) {
                return p;
            }
        }
        // 全部不可用时，走null object，避免空指针
        return new NoOpPushProvider();
    }
}

这个降级逻辑虽然简单，但非常实用。配合服务端配置，一次切换成本几乎为零。注意我加了一个 NoOpPushProvider，它是空对象模式的一种应用，就是什么都不做的实现，目的是保证上层永远拿得到对象，不会因为空指针直接崩溃。降级的极致是不影响主流程，哪怕推送功能不可用，应用本身不能崩。

4.4 生命周期管理：回调线程与资源释放

第三方SDK最容易出问题的两个地方，一个是回调线程不统一，另一个是资源释放不及时。

回调线程问题我在接口定义时就已经规避了。我们在统一接口的注释里明确要求：实现方负责把回调调度到主线程。也就是说，适配器内部如果收到SDK的子线程回调，要通过Handler或者MainScope切到主线程后再调用统一回调。这样业务层拿到的所有回调都在主线程，省得每个业务方自己再切线程，也避免了大量“在子线程更新UI导致崩溃”的线上问题。

资源释放方面，适配器接口定义了 release()，但业务层通常不需要主动调用，而是由框架层统一管理。我在Application的onTerminate里做了兜底，虽然Android里onTerminate在正式机上不一定被调用，但至少提供了一个收口。

5. 一个真实场景复盘：支付收银台从if-else到策略+适配器

5.1 支付场景的渠道差异比推送更明显

推送渠道之间差异大，但支付渠道之间的差异更大。微信支付发起业务要先生成prepayId，再调WXPay；支付宝要拼接订单参数，生成orderInfo，再调AlipaySDK；银联则是生成TN号，再拉起银联控件。回调格式也完全不同，有通过第三方App回调的，有通过服务端Notify异步通知的，有客户端同步返回结果码的。

如果每个渠道都在业务层直接调SDK，那订单确认页、支付结果页、订单详情页会各有一份渠道分支。这还算能忍，最让人崩溃的是新增渠道时，你要像排雷一样把所有页面过一遍。

5.2 重构后的支付流程

参照推送的思路，我也给支付设计了一套相同的组合结构。

java复制public interface PayProvider {

    String channelName();

    void initialize(PayConfig config);

    void pay(PayRequest request, PayCallback callback);

    boolean isAvailable();
}

微信支付的适配器核心逻辑大概是这样：

java复制public class WechatPayProvider implements PayProvider {

    @Override
    public String channelName() {
        return "wechat";
    }

    @Override
    public void pay(PayRequest request, PayCallback callback) {
        // 内部完成：生成预付单 -> 调起微信
        wxPayApi.sendReq(buildReq(request));
    }
}

支付宝适配器也一样，内部处理支付宝SDK的签名和调起逻辑。业务层发起支付时，只写一行：

java复制payStrategyContext.current().pay(payRequest, callback);

收银台选择具体渠道的逻辑，完全收敛到策略选择器里。用户在UI上点的是哪个图标，就切换到对应适配器。

5.3 收益和数据

这次重构之后，最直观的变化是新增支付渠道的成本大幅降低。以前接一个新渠道，开发加联调基本要一周左右，因为要动的点太多——发起支付、回调处理、订单状态刷新，任何一处漏改都可能出线上bug。重构之后，新渠道只要写一个Adapter，注册进策略选择器，再约定好回调格式，主体工作两到三天能完成，剩下的是商户后台申请和联调排期。

还有一个隐性收益：团队协作更顺畅了。以前大家改SDK相关代码都小心翼翼的，生怕引入莫名其妙的回归问题。有了统一接口之后，新同学只要看懂 PayProvider 和 PushProvider 两个接口，就能很快上手；各家Adapter的边界也很清楚，谁负责哪个渠道，定位问题一目了然。

6. 实际重构中踩过的坑和设计建议

6.1 别为了用模式而用模式

虽然我这篇文章通篇在推广适配器+策略，但也要说句公道话：如果项目里只有一个SDK，而且短期没有更换、增加的计划，那真的没必要上这套架构。适配器加策略虽然不难，但它引入了额外的类、注册逻辑、上下文管理，对只有一个渠道的项目来说，这些全是成本。

我自己判断是否要上这套组合，就看两个问题：一是未来半年内会不会出现第二个同类SDK；二是业务是否需要在运行时切换渠道。两个答案都是否，那就用一个简单的工具类封装SDK就行。不要一开始就设想一个完美架构，架构是为需求的变化服务的。

6.2 统一接口的语义要收敛，别跟着SDK的能力走

这是我在设计时期反复纠结的地方。极光推送有很丰富的扩展能力——自定义消息、地理围栏、通知栏样式定制、送达统计，友盟和个推也各有各的特色。如果我把这些能力全部挂到统一接口上，适配器实现会变得极其臃肿，因为大部分渠道根本用不到某些能力。

我的原则是：统一接口只收敛“当前业务确实需要”的能力，其他高级能力如果必须用，要么通过适配器内部的条件判断暴露，要么在接口中提供能力检测方法。比如：

java复制// 判断当前适配器是否支持某个高级能力
boolean supports(String capability);

但这个设计要慎用，用多了就等价于回到散落分支的老路。最干净的方案还是：业务负责提需求，SDK能力不适合的，就用设计或者产品方案避掉，不要在技术层强行塞入一个“超级接口”。

6.3 回调线程和超时问题一定要在接口层约定好

多SDK的重构踩坑中，回调线程不统一是最磨人的一个。有的SDK在子线程回调，有的在主线程回调，有的甚至不保证线程。如果不做统一约束，上层每次拿到回调都要自己做线程判断，等于把复杂度又分摊回业务层了。

我在统一接口的注释里写得很明确：所有回调实现方必须调度到主线程由Callback回调。这样上层不管接哪家SDK，拿到的都是主线程回调，可以直接刷新界面。代价是适配器内部要写一点线程切换代码，但这是值得的。

超时问题也一样。有些SDK在断网或者服务端异常时会长时间不回调，业务方会一直停留在支付中或者等待推送状态。我建议在适配器内部，或者策略上层，做基础的超时兜底。不要依赖SDK自带的超时机制，因为你不可控。

6.4 测试策略：Mock适配器比真SDK香多了

测试这块是我重构后才补上的，有点后悔。如果你用这套架构，最好从第一天就定义一个Mock适配器，并注册在测试环境中。Mock适配器完全不依赖真实SDK，响应是可控的。

java复制public class MockPayProvider implements PayProvider {

    private PayResult mockResult;

    public void setMockResult(PayResult result) {
        this.mockResult = result;
    }

    @Override
    public void pay(PayRequest request, PayCallback callback) {
        if (mockResult.isSuccess()) {
            callback.onSuccess(mockResult);
        } else {
            callback.onFailure(mockResult.getCode(), mockResult.getMessage());
        }
    }
}

有了Mock适配器，测试环境不需要真实SDK的AppKey、签名，也不需要依赖外部服务，回归测试、UI测试、CI流程都能稳定跑了。真实SDK只在集成环境做专项联调，不用每个迭代都跑一遍完整流程。

6.5 配置管理：渠道切换别写死在代码里

最后一点建议，也是我认为这套架构能不能长期发挥作用的关键：渠道配置尽量走配置中心或者服务端下发，别写死在代码里。用推送举例，你永远不知道哪家SDK厂商的通道哪天会出问题，也不知道运营是不是想换个渠道试投放效果。如果渠道标识是写死的，你就要发版，而发版的速度大概率追不上故障扩散的速度。

我这边是把所有渠道配置挪到了配置中心，下发后由框架层的配置模块刷新，再触发策略选择器的切换。这样运维或者运营发起切换，到客户端生效可能只需要十几秒。这个能力在线上故障处理时的价值，真的没法量化。

这些经验都是从实际项目里一步步踩出来的。如果你也被多SDK集成搞得很头大，我建议不要一上来就重构所有能力，先选一类最痛的业务（比如推送或者支付），把统一接口、适配器、策略选择器这一整套东西跑通，再推广到其他SDK上。一次收敛一类能力，风险可控，也更容易让团队认可这套做法的价值。