适配器与策略模式在SDK集成中的实战应用

1. 多SDK集成的痛点与设计模式的价值

在移动应用和系统开发中，集成多个第三方SDK已经成为标配操作。以典型的电商App为例，可能需要同时接入微信支付SDK、支付宝SDK、极光推送SDK、百度地图SDK等。这些SDK往往由不同团队开发，存在以下典型问题：

• 接口规范不统一：有的用回调函数，有的用事件监听
• 初始化方式各异：有的需要ApplicationContext，有的需要Activity实例
• 依赖库冲突：不同SDK可能引入相同库的不同版本
• 业务逻辑耦合：支付、登录等功能直接写在Activity中

我在最近一个金融类App项目中就遇到了这样的困境：接入了7个不同厂商的SDK后，主Activity代码膨胀到3000多行，任何一个小改动都可能引发连锁反应。这时候，适配器模式(Adapter)和策略模式(Strategy)的组合使用就派上了大用场。

2. 适配器模式：统一异构接口

2.1 基础概念与典型场景

适配器模式就像电源转接头，让不同规格的插头都能正常工作。在SDK集成中，我们主要解决三类适配问题：

1. 接口形式适配：将回调式接口改为观察者模式
2. 参数格式适配：统一不同SDK的金额单位（分/元）
3. 异常处理适配：将各SDK的错误码转为统一体系

以支付功能为例，我们可以创建基础支付接口：

java复制public interface IPaymentAdapter {
    void pay(PaymentRequest request); 
    void setCallback(PaymentCallback callback);
}

2.2 具体实现方案

为每个支付SDK创建具体适配器：

java复制public class WechatPaymentAdapter implements IPaymentAdapter {
    private WechatPaySDK mSDK;
    private PaymentCallback mCallback;
    
    @Override
    public void pay(PaymentRequest request) {
        WechatPayReq req = new WechatPayReq();
        req.amount = request.amount * 100; // 元转分
        mSDK.sendReq(req);
    }
    
    @Override
    public void setCallback(PaymentCallback callback) {
        this.mCallback = callback;
        mSDK.setRespListener(resp -> {
            if(resp.errCode == 0) {
                mCallback.onSuccess();
            } else {
                mCallback.onError(convertError(resp.errCode));
            }
        });
    }
}

关键技巧：在适配器内部处理线程切换，保证回调始终在主线程执行

3. 策略模式：动态切换业务逻辑

3.1 策略模式的核心价值

策略模式解决了业务逻辑硬编码的问题。比如支付方式选择场景：

java复制public interface PaymentStrategy {
    void execute(PaymentContext context);
}

public class CreditCardStrategy implements PaymentStrategy {
    @Override
    public void execute(PaymentContext context) {
        // 信用卡支付逻辑
    }
}

public class CouponStrategy implements PaymentStrategy {
    @Override
    public void execute(PaymentContext context) {
        // 优惠券支付逻辑
    }
}

3.2 策略工厂的实现

建议使用枚举+工厂方法管理策略：

java复制public enum PaymentType {
    WECHAT(WechatStrategy::new),
    ALIPAY(AlipayStrategy::new);
    
    private final Supplier<PaymentStrategy> factory;
    
    PaymentType(Supplier<PaymentStrategy> factory) {
        this.factory = factory;
    }
    
    public PaymentStrategy create() {
        return factory.get();
    }
}

4. 模式组合实战：支付模块改造

4.1 架构设计图

code复制[Client] --> [PaymentManager] 
            /       |       \
 [WechatAdapter] [AlipayAdapter] [BankAdapter]
           |          |          |
      [WechatSDK] [AlipaySDK] [BankSDK]

4.2 核心管理类实现

java复制public class PaymentManager {
    private Map<PaymentType, IPaymentAdapter> mAdapters = new HashMap<>();
    private PaymentStrategy mStrategy;
    
    public void registerAdapter(PaymentType type, IPaymentAdapter adapter) {
        mAdapters.put(type, adapter);
    }
    
    public void setStrategy(PaymentStrategy strategy) {
        this.mStrategy = strategy;
    }
    
    public void processPayment(PaymentContext context) {
        mStrategy.execute(context);
    }
}

4.3 使用示例

java复制// 初始化
PaymentManager manager = new PaymentManager();
manager.registerAdapter(PaymentType.WECHAT, new WechatPaymentAdapter());
manager.registerAdapter(PaymentType.ALIPAY, new AlipayPaymentAdapter());

// 使用
PaymentContext context = new PaymentContext(order);
manager.setStrategy(PaymentType.WECHAT.create());
manager.processPayment(context);

5. 性能优化与疑难排查

5.1 内存泄漏防护

SDK通常持有Activity引用，必须注意：

java复制@Override
protected void onDestroy() {
    super.onDestroy();
    // 释放所有SDK资源
    mPaymentManager.release();
}

5.2 依赖冲突解决方案

在build.gradle中统一版本：

groovy复制configurations.all {
    resolutionStrategy {
        force 'com.squareup.okhttp3:okhttp:4.9.3'
        force 'com.google.code.gson:gson:2.8.9'
    }
}

5.3 常见错误码对照表

6. 扩展应用场景

6.1 登录模块的统一

同样的模式可以用于微信、QQ、微博等多渠道登录：

java复制public interface ILoginAdapter {
    void login(LoginCallback callback);
    void logout();
}

6.2 地图服务的抽象

封装百度地图、高德地图的差异：

java复制public interface IMapService {
    void showMarker(Location location);
    void routePlan(Location from, Location to);
}

在实际项目中，这种架构使我们的代码量减少了40%，新接入SDK的时间从3天缩短到半天。最关键的收益是：业务代码不再需要关心具体SDK的实现细节，真正实现了"面向接口编程"的理想状态。