Kotlin 跨平台 ｜我觉得可以试试_kolin 跨端方案

今年我投入了非常多的时间到kotlin相关的事情中了，上半年改造完成了全工程的kotlin android extensions的移除，主要是为了方便后续升级kotlin版本。然后5月份开始就为整个阿逼工程的kmp(kotlin multiplatform)工程准备到九月份。另外最后从阿逼走之前在做的就是kotlin相关的组件版本升级到1920。

降本增效之后呢我月初已经入职了xhs，转眼已经在xhs打工了三个礼拜了，我打算在xhs开始继续实践我的kmp跨端，当然也有可能我试试就逝世了。

选型原因

跨端一直在业内都是一个讨论度非常高的话题，无论是flutter，rn或者rust，各自都有自己的优劣势。上面这张图我是用AI赋能生成的，大部分描述我觉得还是比较准确的，我们也能很好的分析出各个跨端框架的优劣，对于技术选型工作还是有一定的参考价值的。

kmp对比于其他的跨端框架来说，我觉得他的优势是上手相对比较简单(主要我是安卓啊 门槛比较低)，另外就是由于jetbrains的优势吧，kotlin是一门编译性质的语言，最终的构建产物对于安卓和iOS性能上基本没啥损耗。另外这几年jetbrains也非常努力，基本上生态方面已经非常ok了。但是其中最大的劣势就是没法使用UI相关的代码。当然UI都是在基于Compose的基础上继续迭代了，但是国内什么情况懂得都懂吧。

另外其实有一部分iOS的同学对于构建产物会有疑虑，可以放心大胆的使用，因为编译出来的OC，也就能非常好的做到和swift代码进行交互了。

我也和一些业内的大佬都聊过，他们一致都喜欢问我一句话，为什么考虑用kmp而不考虑rust。我连cli工具都用kt写，肯定的原因就是因为懒啊。年纪大了不想学习了。

AI 赋能下，kmp和rust之间的差异。

KMP 和 Rust各有优势和劣势，具体选择哪种语言取决于具体的需求。如果需要开发跨平台的应用程序，并且希望提高开发效率和降低代码维护成本，那么 KMP 是一个不错的选择。如果需要开发性能要求高的应用程序，或者需要保证应用程序的安全性，那么 Rust 是一个更好的选择。

Rust 的优势

• 性能高：Rust 是一门系统级语言，具有优异的性能表现。
• 安全性高：Rust 采用了内存安全的设计，可以有效避免内存泄漏和安全漏洞。
• 生态系统完善：Rust 的生态系统已经相当完善，提供了丰富的库和工具。

Rust 的劣势

• 学习成本高：Rust 是一门比较复杂的语言，学习成本较高。
• 开发效率低：Rust 的开发效率不如 KMP，尤其是在开发 UI 等平台特性相关的代码时。

所以两者的核心差距还是在于学习成本，还有就是上手的曲线。另外就是如果想挖写rust的人也相对来说比较困难。

开发环境

在阿逼的时候，由于我需要一个kmp工程接入到主项目中，所以我其实挺少的参与到业务代码编写中去的，这次kmp启动算是踩了点坑。主要都是集中在iOS的工程运行起来方面上。

kdoctor非常重要，因为我们不仅要让安卓的部分跑起来，同时也要对于iOS的部分进行负责。

还有就是一个非常重要的idea插件，但是不知道为啥用只能在as中下载到。有了这个插件，我们基本就可以快速在as上开发和调试一个iOS的app了。

最后我们就可以直接在as上通过configuration配置出一个iOS运行app了。

切入点

我个人觉得如果技术选型选择kmp最大的目的其实应该是多端一致性的这件事。相信大家在做业务需求的时候碰到最多的问题就是隔壁iOS的同学实现不一致导致的双端不对齐。

而且非常多的技术优化会从双端变成单端的技术方案，导致大家的技术路线越走越远，差异化也越来越大，最终可能会让一个技术方案都变得不可维护。

尤其是一个相对来说比较计算比较复杂的sdk中，当测试验收的时候发现一端的表现和另外一端是不同的情况。那么这种时候我觉得就可以通过kmp来去解决这种问题。

1. 使用 Kotlin 编译器将 Kotlin 代码编译为 IR（Intermediate Representation）文件。
2. 使用 IR 转换器将 IR 文件转换为目标平台的二进制文件。

kmp的一个特性就是通过kotlin的编译器来把kt的翻译成别的语言比如OC或者jvm的字节码。那么我们就可以把这部分差异化代码进行抹平，从而解决多端业务逻辑的一致性问题。

人效这件事情我就觉得很难评估了啊，所谓仁者见仁智者见智，说句不太中听的话，跨端这么多年了，没有那个库真的能说真的一个人完全解决所有端问题，最后都是缝合怪。

还有就是跨端和热发布真的不是一码事，业内通常把热发布叫做容器化，另外两者确实经常出现在一起。

小尝试

我现在会考虑对一些重逻辑的sdk进行kmp化，比如说埋点的数据部分，Config的解析器，ABTest Sdk等等。我觉得这些都是一个非常好的切入点，因为他们都是那种相对来说比较重逻辑，而且行为上需要双端高度一致的库，最后这些库都不太涉及复杂的ui处理逻辑。

如果要考虑在业务层上接入kmp，就不得不避免的要去思考如何把网络库，埋点等等依赖必须项引入到kmp的工程中。我们就需要先定义好一些基础的interface，通过依赖反转的形式把这些依赖库注入到kmp工程中，然后才能让业务进行后续的迭代开发。这样就不可避免的也需要双端大量的桥接工作，也没办法做到很好的功能复用了。

另外换一个角度思考，就是单纯的接入一个新东西，你也比较难去描述这个东西带来的价值和收益。如果一件事情要考虑整体梭哈，不如小步慢跑，先从一件小事做起，如果方案ok说得过去，那么后续想要推广的成本也会大大下降。

另外就是能去解决实际在工程中出现的一系列的问题，不要有什么炫技的成分，避免做一些过度的设计。

我现在呢是在工程内找到一个比较小的切入点已经马上就要开始准备接入双端了。还是挺期待能不能达到预期的效果的。