本文目录导读：
对第三方SDK进行防腐层封装是一种常见的架构设计实践，核心目的是解耦，它能防止业务代码直接依赖某个具体的第三方库，当SDK升级、替换或出现问题（如Bug、许可证变更、收费）时，只需修改封装层,而无需改动上层业务逻辑。
以下是进行防腐层封装的标准步骤和最佳实践：
第一步：定义抽象接口
这是最关键的一步，不要用第三方SDK的类名或方法名来定义接口，而应该从业务需求出发，设计通用的、业务语义化的接口。
- 不要这样：
interface PushService { void init(JPushInterface jpush); } - 应该这样：
interface PushService { void initialize(); void register(String userId); void setTags(List<String> tags); void handleNotification(Map<String, String> data); }
原则：
- 业务语义化： 接口方法名描述“做什么”（如
sendMessage），而不是“怎么做”（如sendBySocket）。 - 参数简化： 使用业务对象（如
UserInfo）代替SDK的复杂配置对象（如HuaweiConfig）。 - 返回值抽象： 返回业务通用的结果类型（如
Result<T>或ListenableFuture<T>）,而非SDK特有的回调。
第二步：创建适配器实现
针对每一个不同的SDK（如极光、个推、厂商通道）,写一个适配器类实现上述接口。
- 适配器职责： 将第三方SDK的API调用,转换为接口定义的调用。
- 对象转换： 在适配器内部完成业务对象到SDK对象的转换（将
UserInfo转换为JPushRegistrationConfig）。 - 错误处理： 捕获SDK的特定异常,转换为业务通用的异常或错误码。
示例（伪代码）：
public class JPushAdapter implements PushService {
@Override
public void initialize() {
// 这里调用JPush的初始化API
JPushInterface.init(getApplicationContext());
}
@Override
public void register(String userId) {
JPushInterface.setAlias(getApplicationContext(), userId, null);
}
@Override
public Result<Boolean> sendMessage(String targetId, String content) {
try {
// 调用JPush的推送API
JPushNotification notification = new JPushNotification();
// ... 填充内容
return Result.success(true);
} catch (JPushException e) {
// 将JPush异常转为业务异常
return Result.failure(new PushException("Send failed", e));
}
}
}
第三步：使用工厂或依赖注入（DI）管理
业务代码不应直接 new 某个适配器,需要通过工厂或依赖注入来获取接口实例。
- 工厂模式：
public class PushServiceFactory { public static PushService create() { // 可以通过配置、BuildConfig、设备厂商等决定返回哪个实现 if (isHuaweiDevice()) return new HuaweiPushAdapter(); else return new JPushAdapter(); } } - 依赖注入（推荐）： 使用 Dagger / Hilt / Spring IoC 在模块中提供实现。
@Module public class PushModule { @Provides public PushService providePushService() { return new JPushAdapter(); } }
第四步：业务层调用
上层业务代码只依赖接口,绝不依赖任何SDK类或适配器类。
public class MainActivity {
@Inject // 或 PushServiceFactory.create()
PushService pushService;
public void onLoginSuccess(String userId) {
pushService.register(userId);
}
}
五大核心价值（为什么要做）
- 可替换性： 从极光换成个推，只需新增一个
GeTuiAdapter，修改工厂/DI配置,业务代码零改动。 - 隔离风险： 如果SDK有严重Bug，可以在适配器中加熔断、降级或抛出特定异常,不影响整体系统稳定性。
- 简化测试： 单元测试时可以轻松Mock接口,无需集成第三方SDK的测试环境。
- 统一管控： 所有SDK调用集中在适配层，方便做日志、统计、权限校验等横切关注点。
- 减少编译依赖： 业务模块只需依赖接口模块（一个普通Java/Kotlin库），不需要依赖具体SDK的aar包,可以更快构建。
最佳实践与注意事项
- 粒度控制： 不要一个SDK一个接口，建议按功能域拆分（如
PushService,MapService,PaymentService）。 - 回调处理： 第三方SDK常使用回调（Callback/Listener），建议在适配层内，将SDK的回调转换为业务回调，并使用
EventBus、LiveData或Flow等响应式机制传递,避免回调泄露。 - 生命周期管理： SDK通常需要
init()和destroy()，适配器应配合组件生命周期（如Activity/Fragment的生命周期）或应用生命周期进行管理。 - 版本兼容： 当SDK大版本升级（如 API v1 到 v2），适配层内部可以有两种策略：
- 类适配器模式： 旧适配器实现新接口,内部调用旧SDK。
- 版本判断： 在适配器中判断当前SDK版本,调用不同API。
- 避免过度封装： 如果该SDK非常稳定且短期内不会替换（如系统级API），或者使用范围极小（仅一个类使用），可以考虑不做防腐层，直接用带注释的方式标记依赖点,未来改起来也快。
- 文档与测试： 对适配器进行充分的单元测试和集成测试，尤其是对象转换和异常处理逻辑，文档标注清楚“如果需要更换SDK，请修改这里的适配器”。
防腐层的本质是“依赖于抽象，而非具体”，付出的代价是多一层抽象和少量的适配代码，换来的是架构的灵活性、可测试性和抗风险能力。
一句话口诀：接口定义业务逻辑，适配器桥接SDK细节，依赖注入动态切换，业务代码只认接口。
