从一个 APK，
到可配置加载的插件。
把原本需要反复手工改代码、整理资源和打包的步骤，交给自动化构建。Template 基于 Shadow，将已有应用接入插件工程，再由宿主承载业务。
反编译、资源接入、字节码处理与重编译。
自定义 Gradle 插件组织任务，集成 Shadow 产物。
减少人工改码和打包投入，便于重复执行与维护。
01系统如何协同
构建端负责把 APK 变成宿主可加载的插件；运行端负责准备插件、加载运行环境，并启动其中的业务页面。
图表可左右滑动；也可聚焦图表后用方向键查看，或打开原图放大。
绿色为构建链，青色为运行链，黄色虚线为作者说明的加载策略。
打开架构图原图 ↗
我负责的部分：Template 的自动化处理、字节码编辑、构建编排和宿主集成。基础插件化能力来自 Shadow。
技术路线：Shadow 采用零 Hook 插件化路线，减少对系统内部实现的依赖。零 Hook 描述插件化机制，工程中仍可使用反射完成组件连接。
02放入 APK，交给构建流程
拆解 APK 后，工程会整理 Manifest、资源和字节码，接入插件模块。自定义 Gradle 插件把基于 ASM 的字节码编辑纳入构建过程，结合 Shadow 的插件化转换完成打包，最后集成到宿主产物中。
图表可左右滑动查看完整内容。
省下的是重复处理时间：应用处理、组件适配和打包步骤集中在构建流程中，减少逐个项目手动操作。
字节码编辑：通过 ASM 读取类文件、访问并修改字节码，再写回构建产物。它与反编译、资源接入共同组成自动化处理流程；Shadow 提供插件化转换和运行时支持。
处理的对象：反编译后处理 Smali、DEX、JAR 和资源文件，再接入插件模块；这一过程不等于还原完整的原始 Java/Kotlin 工程。
03宿主承载，插件按需加载
按项目的加载策略，应用先展示宿主，再由配置决定是否加载目标插件。下图用虚线说明这项产品策略，用实线展开源码中的插件安装、运行环境加载和业务页面启动。
配置策略依据作者说明，远端配置及条件分支需结合具体版本验证；实线加载链依据源码与生成模板整理。
图表可左右滑动查看完整内容。
技术说明与适用范围
本案例依据 Template 源码、生成模板与作者说明整理。Template 负责自动化处理、构建编排和宿主集成，Shadow 提供基础插件化能力。图解展示工程结构与处理流程，具体 APK 的适配、Android 兼容范围及配置服务需按项目验证。
可以从现有应用、重复工作和希望改进的流程聊起。