对于移动端开发来说，跨平台是一个不可避免的话题。在跨平台移动开发的技术选择中，最流行的两个是React Native和Flutter。这两种方式各有优缺点，对于跨平台移动开发，究竟是选择React Native还是Flutter，对许多人来说是个难题。
当然，这篇文章不是来对比这两个技术的，而是来介绍另一个新的移动跨平台技术选择——KMM。
KMM
KMM的全称是Kotlin Multiplatform Mobile，它是JetBrains公司的产品，是一个业务跨平台的移动端开发框架。在KMM的官网上，它对自己最简明的介绍是：共享iOS和Android应用的逻辑，同时保持原生用户体验。用中文理解就是：不同平台共享业务逻辑的同时又保持各自原生的UI实现。这就是它最大的与众不同之处。
跨平台移动开发的思路
对于跨平台移动开发技术，以现在流行的来说，总体上有以下几种思路：
基于JS来实现跨平台开发：许多年以前，有一个预言：任何可以用JavaScript来写的应用，最终都将用JavaScript来写。审视今天的技术现状，它已经不是一种预言，某种程度上已经是一种事实。今天用JS来开发，在任何方向都是值得考虑的选项，跨平台移动开发也有React Native。只要你懂JavaScript，就能使用React Native来开发移动应用。React Native的思路是将JS实现转换成原生实现，相当于中间有一层翻译层的存在。
底层重新构建式的跨平台开发：使用React Native仍然有许多困难需要克服，最显著的就是性能以及与原生实现的一些难以兼容的地方，这也是React Native开发中经常需要自己实现原生实现的原因所在。想要在缺少原生开发能力的前提下，纯粹依赖于使用React Native，是一件比较有挑战的事。所以，就出现了Flutter这样的解决方案，它的思路与RN完全不同，它抛弃了原生开发技术，基于Skia引擎完全重新构建了一套自己的控件与实现。这意味着它与原生是一个实现模式，性能上更佳。而且使用Flutter你可以真正抛弃原生开发，因为它完全不依赖原生的技术与控件。选择Flutter，最大的问题在于你选择了另一个生态，无论是从语言还是从各种支持框架，与主流流行的技术几乎没有任何重叠之处。这个选择对于不缺钱不怕招不到人的大公司可能是可以克服的问题，但对于其他大多数公司来说，这是个阻碍。
保持原生开发，而使业务重用：无论是React Native还是Flutter，它们的缺点都是非常明显的，这使得在移动开发中，它们始终无法取代原生开发，甚至直到今天，原生开发或混合开发仍然才是主流。原生开发的优势不言而喻，无论是在人员、技术生态还是性能上都远优于跨平台开发。但原生开发这种一个APP，两端分别开发，始终在成本上是企业非常想避免的事。于是KMM则完全从另一种思路来解决这个问题。在移动端开发中，一个显著的特征是：不同端的业务逻辑是几乎完全一致的，只是它们的实现技术与载体不同而已。所以，KMM基于上述这个思路，创新式地引入了另一种模式：在保持原生开发的基础上，使业务模块重用。
与众不同的实现
KMM的实现思路是重用业务逻辑。在Android中开发业务实现，KMM会将你的业务生成iOS类库。你在iOS开发的时候，相当于依赖了一个类库，这个类库提供了本身你业务的很多方法。在业务重用过程中，数据库SQLite与网络都是支持的，也就是你的业务实现可以使用数据存储查询以及网络等。而数据存储与网络其实是移动开发中极为重要的两个关键依赖。关于KMM的技术点，建议访问官网以查阅，这篇文章只是一个介绍。
示例项目发布
我一直在关注与调研移动开发的技术，对iOS的SwiftUI、Android的Jetpack Compose都非常感兴趣，做了前端开发之后，就会发现声明式UI是更好的方式。而无论是SwiftUI或是Jetpack Compose都转向了声明式UI。KMM也是我关注的一个移动开发技术方向，因为它一方面重用了业务，另一方面又维持了原生开发，似乎是个挺不错的实现思路。最近基于KMM做了一个可运行的示例项目。这个项目主要是最小化的示例及说明如何基于KMM进行开发，示例是一个最小骨架的尝试，包括APP的UI、从服务器获取数据、将数据存储到数据库都包含在内，实现了Android与iOS两端的开发。
未来
对于KMM这个技术，我也仍然在学习与尝试中，如果未来证明它的可行性，会考虑把它纳入相关框架中，作为移动端实现的技术选择。如果你对它感兴趣，可以持续关注相关技术发展。