前言：为什么要把 SDK 拆成「小部件」？

在传统的游戏 SDK 中，所有功Neng往往堆在一个巨大的 app 里代码耦合严重，改动一个模块往往会牵连到其他模块，编译时间也会被拉得老长。 Ru果把登录、支付、礼包、数据上报等业务抽离成独立的组件，不仅Ke以让不同的团队并行开发，还Neng在需要时只替换掉某个功Neng，而不必重新打包整个 SDK。 这正是「组件化」想要解决的痛点——解耦、复用、热插拔。

下面给出一种比较通用的布局，每个子目录dou是一个 Gradle 模块：

zujianmodule 
├── app                     # 游戏壳工程，负责统一入口
├── app-base                # 核心基座，提供 SdkCore、ModuleMediator 等公共类
├── app-login               # 登录业务
├── app-register            # 注册业务
├── app-center              # 个人中心
├── app-changepassword      # 修改密码
├── app-update              # 强制geng新
├── lib-util                # 常用工具类库
├── lib-data                # 数据层封装
├── lib-logging             # 日志系统
└── lib-imgloader           # 图片加载

每个业务模块dou是 com.android.library 类型，这样它们既Ke以单独运行调试，又Neng被主工程统一聚合。

为了让子模块Neng够在不依赖 R 文件的情况下直接使用资源，我们封装了一套反射工具：

// 动态获取 layout ID
public static int getLayoutId {
    return ctx.getResources.getIdentifier);
}
// 动态获取 string ID
public static int getStringId {
    return ctx.getResources.getIdentifier);
}
// 动态获取 drawable ID
public static int getDrawableId {
    return ctx.getResources.getIdentifier);
}
// 动态获取 view ID
public static int getViewId {
    return ctx.getResources.getIdentifier);
}

只要把资源名称写成字符串，就Neng跨模块安全地拿到对应的整数 ID，避免了编译期的冲突。

SdKCore 定义了所有对外暴露的Neng力；SdKCoreImpl 则采用双重检查锁定实现全局唯一。

public abstract class SdkCore {
    public abstract void init;
    public abstract void login;
    public abstract void pay;
    // …其它方法如 logout、exitGame 等
}
public class SdkCoreImpl extends SdkCore {
    private static volatile SdkCoreImpl INSTANCE;
    private Context appContext;
    private boolean inited = false;
    private SdkCoreImpl { /* 防止外部实例化 */ }
    public static SdkCoreImpl getInstance {
        if  {
            synchronized  {
                if  INSTANCE = new SdkCoreImpl;
            }
        }
        return INSTANCE;
    }
    @Override
    public void init {
        this.appContext = context.getApplicationContext;
        this.inited = true;
        // Ke以在这里顺便初始化日志、网络等公共库
    }
    // login / pay 等方法省略……
}

我们不想让每个 Activity dou写死在 AndroidManifest 中，于是借助反射把页面地址抽出来用字符串常量统一管理：

public class ModuleMediator {
    // 页面全路径常量
    public static final String ACT_LOGIN   = "com.github.jeffery.login.LoginActivity";
    public static final String ACT_CENTER  = "com.github.jeffery.center.CenterActivity";
    public static final String ACT_REGISTER= "com.github.jeffery.register.RegisterActivity";
    // …geng多
    private static volatile ModuleMediator sInst;
    private ModuleMediator {}
    public static ModuleMediator getInstance {
        if  {
            synchronized  {
                if  sInst = new ModuleMediator;
            }
        }
        return sInst;
    }
    /** 简单页面跳转 */
    public void startActivity {
        startActivity;
    }
    /** 带参数跳转 */
    public void startActivity(Activity from,
                              String targetClass,
                              Bundle extras) {
        try {
            Class clazz = Class.forName;
            Intent intent = new Intent;
            if  intent.putExtras;
            from.startActivity;
        } catch  {
            e.printStackTrace;
            Toast.makeText(from,
                    "页面未找到：" + e.getMessage,
                    Toast.LENGTH_SHORT).show;
        }
   }
}

所有业务回调dou继承自同一个基接口，这样Ke以在统一位置Zuo异常捕获或日志打印：

// 基础回调
public interface SdkCallback{
   void onSuccess;
   void onFailure;
}
// 登录专属回调
public interface LoginCallback extends SdkCallback{
   void onLoginSuccess;
   void onLoginCancel;
}
// 支付专属回调
public interface PayCallback extends SdkCallback{
   void onPaySuccess;
   void onPayCancel;
   void onPayPending;
}

SdkCoreImpl.getInstance
          .login {
      @Override public void onLoginSuccess(String uid,
                                            String name,
                                            String token){
          Log.d;
      }
      @Override public void onLoginCancel{
          Log.w;
      }
      @Override public void onSuccess{/* 可选 */ }
      @Override public void onFailure{
          Log.e;
      }
});

PayParams params = new PayParams;
params.setProductId;
params.setProductName;
params.setPrice;           // 单位：分
SdkCoreImpl.getInstance
          .pay{
      @Override public void onPaySuccess(String orderId,
                                          String productId){
          Log.i;
      }
      @Override public void onFailure{
          Log.e;
      }
});

Bundle bundle = new Bundle;
bundle.putString;
ModuleMediator.getInstance
              .startActivity(this,
                            ModuleMediator.ACT_REGISTER,
                            bundle);

前缀约定：每个业务库必须在资源名前加上自己的标识，例如 @string/login_title -> gift_login_title。

gradle 配置：

android{
   resourcePrefix 'gift_'
}

动态读取：利用上文提到的 TestResourceUtil#getLayoutId 按名称取布局，无需手动维护 R 文件。

Apollo 风格地把 Application/Activity 的生命周期全部抛给核心实现，让日志收集和数据埋点自动完成。

public class MainActivity extends AppCompatActivity{
   @Override protected void onCreate{
       super.onCreate;
       SdkCoreImpl.getInstance.onCreate;
   }
   @Override protected void onStart{
       super.onStart; SdkCoreImpl.getInstance.onStart; }
   @Override protected void onResume{
       super.onResume; SdkCoreImpl.getInstance.onResume;}
   @Override protected void onPause{
       super.onPause;  SdkCoreImpl.getInstance.onPause;}
   @Override protected void onStop{
       super.onStop;   SdkCoreImpl.getInstance.onStop;}
   @Override protected void onDestroy{
       super.onDestroy;SdkCoreImpl.getInstance.onDestroy;}
}

在 /env.gradle 中将标记设为 false，每个子模块dou会生成独立的 APK，便于单元测试和 UI 验证。

打开标记后各子模块仅作为 AAR 被打进主工程；同时通过 Gradle 脚本自动混淆和压缩，Zui终产出体积geng小、geng安全的 SDK 包。

Dex 编译速度提升 30%+ ——因为每次只增量编译改动所在的库。

A/B 测试geng简单： 只需要替换对应 AAR 即可，无需重新打包整个游戏。

团队协作geng流畅： 登录组负责 "app-login", 支付组负责 "app-pay", 两边几乎不会产生冲突。

热geng新友好： Ru果后期想支持插件式加载，只需把各子库改为 runtime‑loadable 的形式即可。

把 Android 手游 SDK 拆成若干可插拔的小部件，是当下提升研发效率、防止资源冲突以及降低维护成本的一条捷径。希望本文提供的代码框架和思路Neng帮助你快速落地自己的组件化方案。Ru果你Yi经尝试过类似Zuo法，也欢迎在评论区聊聊实际踩过的坑和收获！祝编码愉快 🚀.