Kotlin Multiplatform 实战记 | QCon

作者 | 曹立成

10 月 21 日我在上海举办的 QCon 全球软件开发大会上分享了 Kotlin Multiplatform 相关的内容，这里记录成文章，分享给你。

1 为什么选择 Kotlin 跨平台？

我先介绍一下我们团队的情况，交代清楚我们技术选型的背景。

我们是阿里巴巴 1688 无线团队，主要负责阿里巴巴客户端、1688 工业品、商家版和采源宝四个 App，是 Android & iOS 混合团队，双端的同学都有。主要负责基础业务、搜索、首页、用增相关等内容，会经常遇到多个 App 部分业务需要复用的情况。在日常开发中，会遇到以下几个问题：

• 基础模块逻辑相对复杂，多端研发成本高

• 双端逻辑代码膨胀，无法保证完全一致，问题排查难

• 逻辑代码穿插在各个模块中，现有跨端复用方案迁移成本高

这些问题可能很多存量 App 都会遇到，随着不断迭代，很多逻辑写着写着双端就出现不一样的细节了，出了问题不好查，迭代维护成本又高，如果再出现人员变动，那一部分代码就会变成「祖传代码」。

为了解决这些问题，我们希望寻找一种方法，可以将逻辑收拢，提升研发效能，降低维护成本。从技术栈的角度出发，我们对比了 Flutter、Kotlin Multiplatform、React Native 三种方案：

我们的诉求是，能够收拢逻辑层面的东西，UI 并不重要，因为我们已经有统一协议渲染框架。而且我们需要更好的性能，对原生能力的融合（不要桥），以及较低的上手学习成本和更轻量化的方案。所以我们选择了 Kotlin Multiplatform。在下文中，我会多次提到 KMM 这个简称，这里先简单讲一下 KMM 是什么：

• 基于 KMP（Kotlin Multiplatform）派生，全称 Kotlin Multiplatform Mobile。它不是一个框架，是一种研发范式，通过代码管理与插件，降低 Kotlin 跨 Mobile 端上手门槛

• 更贴合 Android & iOS 平台。Android 平台产物 aar，iOS 平台使用 Kotlin Native 编译，产物 framework

• 与平台无关的 common 逻辑可以跨更多的平台，如 Mac、Linux、Windows、Web 等

2 Kotlin 是如何实现跨平台的？（技术解析）

代码工程结构

对于 Kotlin Multiplatform 来说，代码工程结构会和其他的工程不太一样。官方给出的基础结构是一个 commonMain 的代码包，其他平台的代码包依赖它（jvmMain、jsMain 等）。对于 KMM 工程来说，通过 Android Studio KMM 插件生成的结构是这样的：

如何扩展原生能力

先举一个最简单的例子，实现一个双端的 Log 工具。在 commonMain 里定义好 expect fun，然后分别在 iosMain 和 androidMain 中实现 actual fun。

1 + 1 = 2 的例子举完了，在真正的应用开发中，调用 Android 能力是非常简单的，和普通 Android 开发没有区别，只要通过 gradle 引入需要的库，就可以调用里面的代码了。iOS 则是通过 cinterop 这个能力生成 Kotlin 识别的三方库头文件实现能力调用的。

cinterop 是 Kotlin Native 支持的能力，KMM 工程的编译使用了 gradle 工具链，其中对 iOS 来说，我们使用了 Kotlin CocoaPods 插件。引入一个三方库，首先通过 pod 脚本写好库和版本，接着执行 gradle sync，其中会执行两个关键的 task，第一个是 podGen，它会把我们需要依赖的库通过 pod 拉到本地，生成一个壳工程，然后会执行对应库的 cinterop task，执行成功以后会生成上图里的 klib 文件，里面包含了导出的头文件函数（knm 文件），最后代码里 import 进来就可以直接使用了。

内存管理机制

• Android：现代垃圾回收算法

• iOS（Kotlin Native）：基于引用计数的垃圾回收算法，额外增加了对环的处理

多线程实践

• 不可变状态才允许多线程访问（Kotlin Native 中不可变不只是 val ，必须是 frozen 状态）

• 使用协程库

• 使用 @ThreadLocal 或 @SharedImmutable

• 封装平台特性的线程方法（线程池、Handler、GCD）

• 使用原子类（Atomic）

3 Kotlin Multiplatform 在阿里巴巴的实践

1688

日志

我们在日志建设上使用了 Kotlin 收拢双端逻辑。对于偏中间件的开发来说很好理解，Kotlin 调用双端基础能力，提供对上的 API 即可。代码示例如下：

上层入口提供了 log 的 API，调用的就是 Kotlin 代码中 LogKit 里的 log 方法。对于 log 相关的配置和策略，通过 LogConfig.kt 封装实现。最终上报也是使用了原生的上报通道，对接了原生已有的能力，比如 TLog ，这是我们的个案日志上报系统，expect 定义好 fun，双端各自实现。整个日志模块中 Kotlin 部分，起到一个承上启下的作用。

搜索筛选

搜索筛选是个业务场景，1688 APP 首页就可以直接跳转到搜索，是一个非常大的流量入口。搜索逻辑比较复杂，有不同场景的搜索、不同品类的搜索、下拉的筛选项、侧边栏的筛选项等。在开发维护搜索逻辑的时候，我们遇到过好几次由于双端逻辑不一致，出现问题很难排查的情况。为了追求双端逻辑强一致，我们把搜索筛选业务的请求策略、场景管理、筛选模型、埋点策略封装在了 Kotlin 中。

FilterManager 是最核心的入口，用户点击筛选项就会走到这里。通过筛选模型和场景模型联合处理，最终拿到请求参数给 UI 层，再通过我们已有的统一协议渲染框架进行渲染。从收益上看，我们的人力投入减少了大概 30%，稳定性持平，逻辑强一致，维护成本降低，排查问题成本也降低。

饿了么商家端

饿了么商家端也深度使用了 Kotlin 收拢双端逻辑，还使用了 Redux 管理数据流。这里就不展开细讲了，详细内容可以查看 PPT，会在文末给出链接。

4 应用场景

总结一下，Kotlin Multiplatform 比较适合以下场景：

• 没有 UI 的复杂逻辑场景

• 基于 MVP 设计的复杂业务中 M 和 P 层

不太适合以下场景：

• 涉及 UI 的场景

• 动态化较多的场景

5 研发模式

根据我们的实践经验，我给大家推荐三种研发模式：

对于基础库开发来说，其实比较简单，Kotlin 把双端逻辑收拢，提供对上 API 调用双端能力即可。对于常规业务开发来说，我更推荐 MVP 设计法则，把 M 和 P 层收拢在 Kotlin 中。如果有多端业务开发的场景（常见于 B 端业务），逻辑层可以用 Kotlin 跨更多的平台，饿了么商家端和美团商家端就有在这个场景下使用。

6 最后

目前在用 Kotlin Multiplatform 进行开发的国内互联网公司有：阿里巴巴、美团、携程、快手，腾讯也在跟进中。

追求双端逻辑一致性，是目前很多存量 App 的诉求。使用 Kotlin Multiplatform 实现逻辑跨端，既可以低成本地满足逻辑一致性诉求，又可以提升研发效能。

对于客户端技术团队，我推荐大家试一试，还挺香的。如果遇到什么问题，也可以联系我一起交流，我的联系方式也在 PPT 里。

附上 PPT 下载链接：https://ppt.infoq.cn/slide/show?cid=92&pid=3441

嘉宾介绍：

曹立成（蒜蓉）阿里巴巴 CBU 技术部 无线开发专家

早期在饿了么蜂鸟负责过 React Native 技术体系的探索落地；2016 年 - 2018 年，在美团点评研究过客户端自动化测试，作为核心成员参与 Logan 大前端个案分析系统的研发工作并推动开源；在内部刊物和《美团技术团队》博客上发表多篇文章。2020 年初加入阿里巴巴，负责 1688 Android 端侧体验与质量。ArchSummit 上海站 2021 届优秀讲师。研究领域包括但不限于动态化容器、端基础架构与中间件、性能优化等。

活动推荐

跨端技术核心在于研发效率和性能体验之间的平衡与突破，移动互联网诞生至今，跨端技术层出不穷，百花齐放，仍没有出现终极解决方案。那终极解决方案会是什么样子呢？面向众多跨端技术，作为业务方该如何选型？

如果读完本文你还没有答案，那么欢迎关注 12 月 5-6 日举办的 GMTC 深圳站，其中「跨端技术」专题将重点解读各种跨端技术所更为适用的业务场景，从工程实践、容器框架、自渲染、平台体系等角度，和大家一同探讨不同跨端技术的特点与未来趋势。点击阅读原文了解详情。

会期临近，余票有限，购票欢迎咨询票务小姐姐：18514549229（微信同电话）