Android应用运行时动态选择对应版本library的实现方案咨询

完全可以通过封装层实现不同版本API的适配，以下是两种可落地的实现方案：

方案1：运行时动态加载对应版本依赖库 #

该方案直接匹配你提到的runtime时引用对应版本依赖的需求，实现逻辑如下：

• 提前准备1.0.0、1.1.0、1.1.2三个版本的独立jar包，可放在应用assets目录内置，也可存放在云端按需拉取降低包体积
• Android平台通过DexClassLoader实现动态加载：用户选择对应服务商后，加载对应版本的jar文件生成Dex实例，通过反射调用对应版本的模型类属性和通信方法
• 注意事项：动态加载的类不能直接和主程序的同包名类强转，需要提前抽象统一的调用接口，或者全程通过反射操作，避免类加载冲突；同时需要适配Android 9及以上版本对非公开反射API的限制，避免触发系统拦截。

方案2：静态统一封装适配层（优先推荐） #

由于你的场景中三个版本API是向上兼容的，仅高版本新增属性，该方案稳定性更高、适配成本更低：

• 以当前内置的1.1.2版本模型类为基准，给所有低版本不存在的新增属性添加@Nullable注解，标注为可选字段
• 统一封装序列化/反序列化逻辑：如果使用Gson可自定义TypeAdapter，使用Fastjson可配置值过滤器，当用户选择低版本API时，序列化请求自动过滤高版本新增字段，反序列化返回结果时自动将缺失的高版本字段赋值为null，避免序列化异常导致崩溃
• 对外提供统一的业务调用接口，内部根据用户选择的API版本做分支处理：调用低版本接口时自动过滤不必要的新增参数，返回上层统一结构的实体，上层业务无需感知底层API版本差异。

选型建议 #

• 若后续API版本迭代频繁，不同版本除新增属性外还有结构、逻辑的修改，可选择方案1，后续迭代只需更新对应版本的jar包，无需修改主程序逻辑
• 若当前三个版本仅存在属性新增差异，优先选择方案2，没有动态加载的机型兼容性问题，性能更高，调试成本更低。

内容的提问来源于stack exchange，提问作者Pandarian Ld