2. RePlugin整体架构分层
核心观点：RePlugin 采用严格的三层纵向切分架构，将「宿主运行环境」「插件管理内核」「业务插件」彻底解耦。三层之间通过预定义的接口契约通信，任何两层不可直接穿透内部状态。理解这一分层模型是后续对比 Atlas 以及进行选型决策的基础。
2.1 分层模型与架构边界
RePlugin 的三层架构从上至下依次为：Host层（宿主应用层）、Manager层（管理核心层）、Plugin层（插件业务层）。每一层都有清晰的职责边界，且依赖方向严格单向：Host 依赖 Manager，Manager 依赖 Plugin；反向通信通过回调接口或事件总线完成。
| 层次 | 定位 | 边界特征 | 对外暴露接口 |
|---|---|---|---|
| Host 层 | 运行容器与环境提供者 | 不直接持有任何插件类引用；仅通过 Manager 操作插件 | PluginContext、IClientService |
| Manager 层 | 插件生命周期与通信中枢 | 不包含业务逻辑；只管理元数据、加载、安全与通信 | PluginManager、ILoader、IBridge |
| Plugin 层 | 业务功能载体 | 不感知宿主内部实现；通过 Manager 获取受限能力 | IPlugin、IComponent |
架构边界原则：Host 层永远不直接 import 任何 Plugin 层的类；Plugin 层也不允许持有 Host 层 Context 的强引用。所有跨层对象传递必须经过 Manager 层的序列化/反序列化或代理包装。
2.2 各层职责详述
2.2.1 Host 层
- 插件容器：为每个插件分配独立的 ClassLoader 与资源映射表，提供沙箱运行环境。
- 生命周期管理：对接 Manager 层的安装、启动、暂停、恢复、卸载请求，并回调插件状态变更事件。
- 基础能力引擎：封装网络请求、文件存储、日志输出、线程池等通用能力，以 Service 形式注册到 Manager 层。
- 安全门面：在加载插件前校验签名与权限白名单，拒绝未授权的插件包。
2.2.2 Manager 层
- 插件解析器：解析
plugins.json或AndroidManifest.xml中的插件元数据，提取 name、version、依赖、权限声明。 - 加载调度器：维护插件状态机（未安装→已安装→已加载→已激活），处理并发加载请求与依赖排序。
- 安全校验器：校验插件包签名摘要、完整性哈希、权限声明是否匹配宿主策略。
- 通信桥接器：管理 Host 与 Plugin 之间的双向消息通道，支持同步 RPC 与异步事件两种模式。
2.2.3 Plugin 层
- 业务组件：实现具体的 Activity、Fragment、Service、BroadcastReceiver 等组件，遵循插件化组件规范。
- 资源隔离模块：插件自己的资源文件（layout、drawable、string）通过独立的 Resource 对象加载，与宿主资源池隔离。
- 独立运行环境：每个插件拥有独立的 ClassLoader 实例，类加载顺序为「插件优先→宿主桥接→系统类库」。
关键约束：Plugin 层不允许直接使用
android.app.Application 或 Context.getApplicationContext() 获取宿主 Application；必须通过 Manager 层提供的 PluginContext 访问受限能力。
2.3 边界关系与通信机制
三层之间的通信遵循「控制流向下，数据流向上」的主模式，同时允许 Manager 层作为双向代理转发异步事件。
2.4 数据流 / 控制流 / 信任链路
| 流向类型 | 方向 | 典型操作 | 信任等级 |
|---|---|---|---|
| 控制流 | Host → Manager → Plugin | 安装、激活、去激活、卸载 | 高（Manager 校验后转发） |
| 数据流 | Plugin → Manager → Host | 组件结果、事件通知、请求宿主能力 | 中（Manager 过滤 + 审计） |
| 信任链路 | Manager 作为信任代理 | 签名校验、权限映射、类加载隔离 | 强（宿主策略在 Manager 层落地） |
信任风险点：Manager 层本身如果被植入恶意代码将导致所有插件失陷。因此 Manager 层的代码需要经过严格的安全审计，并且建议在编译期通过 R8/ProGuard 做高度混淆和完整性校验。
2.5 选型权衡
| 维度 | 优势 | 成本 / 约束 |
|---|---|---|
| 解耦程度 | Host 与 Plugin 零直接依赖，可独立迭代 | 需要维护额外的接口定义层（.aidl 或抽象接口） |
| 可扩展性 | 新增插件类型只需扩展 Manager 层的解析器 | Manager 层可能成为单点瓶颈，需做线程隔离 |
| 安全性 | 统一的校验入口，策略集中管控 | Manager 层自身升级需要与 Host 版本对齐，否则兼容性断裂 |
| 性能开销 | 按需加载，插件不占用宿主进程常驻内存 | 每次跨层通信需经过序列化 + 桥接转发，单次延迟约 0.2~0.8 ms |
2.6 风险点
- Manager 层单点故障：Manager 层内部出现死锁或内存泄漏会导致所有插件不可用。
- 分层接口膨胀：随着插件类型增多，Manager 层接口数量线性增长，维护成本上升。
- 回调链路过长：Plugin → Manager → Host 的回调路径上如果出现未捕获异常，容易导致插件进程或宿主进程崩溃。
- 版本兼容困境：Host 与 Manager 之间的接口版本必须严格匹配，否则旧宿主无法加载新 Manager 插件。
常见陷阱：团队在初期容易让 Plugin 层直接持有 Host 层的
Application 引用以图方便，这会破坏分层边界，导致后续无法升级宿主或独立测试插件。务必在 Code Review 阶段拦截此类跨层侵入。
2.7 落地步骤
- 定义接口契约：在独立的
plugin-api模块中声明 Host 与 Manager、Manager 与 Plugin 之间的全部接口，使用.aidl或纯 Java 接口 + 注解。 - 实现 Manager 内核：先实现插件解析器与加载调度器，确保单插件安装/启动链路走通，不急于加入安全校验。
- 构建沙箱容器：在 Host 层实现 ClassLoader 隔离与资源表映射，验证插件能否正常加载资源与类。
- 接入通信桥接器：实现双向消息通道，先用同步 RPC 覆盖 80% 场景，再补充异步事件总线。
- 注入安全校验：添加签名校验与权限白名单，编写测试用例覆盖非法插件、篡改插件、权限越界场景。
- 全链路压测：模拟 30+ 插件并发安装、频繁启动/停止、跨层大数据量传输，验证 Manager 层无内存泄漏。
2.8 验收标准
| 验收项 | 通过标准 | 验证方式 |
|---|---|---|
| 分层边界隔离 | Host 层无任何 Plugin 层类的直接引用；Plugin 层无 Host 层 Application 强引用 | 静态代码扫描（ArchUnit / Checkstyle） |
| 控制流正确性 | 安装→加载→激活→去激活→卸载 状态机完全正确，无状态残留 | 自动化测试 + 状态日志断言 |
| 数据流延迟 | 跨层同步调用 P99 < 2 ms，异步事件投递延迟 < 5 ms | 性能基准测试（JMH / Macrobenchmark） |
| 安全校验覆盖 | 签名不匹配、权限缺失、包被篡改三种场景均被拦截并上报错误码 | 安全测试用例 + 模拟攻击测试 |
| Manager 层稳定性 | 72 小时压力测试无崩溃、无 OOM、无句柄泄漏 | Monkey 测试 + Memory Profiler |
验收建议：在落地初期先以 1~2 个非核心业务插件作为试点，跑通完整的分层链路后再逐步推广到全业务。不要试图在第一个版本就覆盖所有插件类型，避免 Manager 层接口过度设计。