Flutter与Android原生代码间如何复用同一DTO模型类

问题1：Flutter侧复用Kotlin编写的DTO、实现类似.d.ts类型适配的可行性 #

结论：完全可行，且改造成本极低，完全匹配你当前的跨应用调用链路

• 你当前的跨应用调用本来就是通过Intent传递JSON序列化后的字符串，本身不存在跨运行时传自定义类的需求，Method Channel不支持传自定义类的限制对你这个场景完全没有影响——你只需要在Android原生层把Intent拿到的JSON字符串通过Method Channel传给Flutter侧就行，传参全程用基础字符串类型，没有任何兼容性问题。
• 要实现类似TS与JS混用时.d.ts的类型对齐效果，核心是保证Kotlin侧DTO和Flutter侧Dart模型的字段、类型、可空性、序列化规则完全一致，不需要尝试在Dart侧直接加载Kotlin编译后的字节码，用代码生成就能做到100%对齐：
  • 最优实现方式是写一个轻量的构建插件，基于Kotlin Poet和Dart Poet对接你现有Kotlin DTO库的构建流程：每次Kotlin侧DTO更新发布到内部Nexus时，自动扫描DTO类的字段、类型、序列化注解（不管你用的是Gson、Moshi还是Kotlinx Serialization），生成对应版本的Dart模型类（包含JSON序列化/反序列化逻辑），发布到内部私有Pub仓库。Flutter侧直接依赖对应版本的Dart包即可，类型完全同步，不会出现手动写模型带来的字段错漏、类型不匹配问题，体验和.d.ts的类型提示、校验效果完全一致。
  • 如果暂时不想写自定义构建插件，也可以先从现有Kotlin DTO导出JSON Schema，通过json_serializable基于Schema自动生成Dart模型，一样能保证类型对齐，只是后续同步更新的流程稍麻烦一点。

问题2：将Dart包编译为Jar供原生侧直接调用的可行性 #

结论：技术上可实现，但完全不适合你当前的场景，性价比极低

• Dart官方确实提供了编译为对应平台二进制产物的能力：可以通过dart compile aot-snapshot把Dart代码编译为Android平台支持的二进制，再通过JNI封装成Jar包供Kotlin侧调用，也可以通过Flutter add-to-app模式把Dart模块打包成AAR依赖供原生工程集成。
• 但这个方案在你的DTO共享场景下有几个无法规避的硬伤：
  • 包体积浪费严重：哪怕只是简单的DTO定义类，只要打包Dart运行时环境，最少会给宿主应用增加3~5M的包体积，为了数据模型引入这么大的体积增量完全没有必要。
  • 调用链路冗余：原生侧拿到JSON字符串后，需要跨JNI调用Dart运行时完成解析，再把解析结果回传给Kotlin层，性能比直接在Kotlin侧反序列化差一个量级。
  • 维护成本高：每次Dart侧DTO更新都要重新全量编译Jar包，还要处理不同CPU架构的ABI兼容、Dart版本和宿主环境的兼容问题，维护成本远高于直接维护原生Kotlin DTO。

针对你当前场景的方案建议 #

你现有链路是跨应用传JSON序列化数据，最适配的方案是收敛DTO的定义源，基于同一套定义自动生成Kotlin和Dart双侧的模型代码：如果不想改动现有Kotlin DTO的发布流程，就从Kotlin DTO侧自动生成Dart模型；长期维护可以把DTO定义收敛到中立的Schema（比如JSON Schema、Protobuf），同时生成双侧代码，从根源上避免类型不一致问题，没有额外运行时开销，改造成本远低于单向编译某一侧代码为另一侧依赖的方案。

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