Kotlin 移动端跨平台是种怎样的体验

人类对效率的极致追求推动着社会进步—— 苏格拉面

 

前言

近些年，移动端无论是在技术还是在市场方面都已经逐步成熟，效率成为各家争夺存量 、开拓疆土的利器，因而跨平台技术的热度也如日中天。其中Flutter算得上是跨平台技术的网红，易上手、UI像素级同步、性能优异，引起一大波粉丝（各大厂）为它打call，各大厂商都为Flutter社区带来了很大贡献，迅速扩大了它的技术生态。实不相瞒，个人也是Flutter的小粉丝，既然Flutter这么好，那我还在这吹什么Kotlin的牛逼呢。

 

首先，两者不是竞争关系，可以相辅相成，Flutter是框架，从用户最关心的UI切入，Kotlin是编译器+SDK，从开发者最关心的语言切入，完全可以用Kotlin实现双端业务领域，用Flutter实现双端视觉领域。其次，纵观技术历史，语言比框架的寿命长，好比一个是原材料一个是零部件，而且框架是约束的集合，约束是取舍，取舍也意味着灵活性的丢失。再者，鸡蛋不要放在同一个篮子里，保持不同技术的关注也是很必要的。技术里面没有非什么不可的道理。

 

因为Kotlin移动端跨平台主要使用的Kotlin/Native这部分，接下来都会用KN来指代Kotlin移动端跨平台。

跨平台技术决策

在选择跨平台技术时，我们权衡的点是什么？一般都会从技术角度去思考的，性能要好、生态要大、技术栈迁移成本低，这其实有点本末倒置，因为用户才是企业根本，如果不能满足用户体验，画面丑、操作响应慢，跨平台技术能提高多少效率都是徒劳。我认为这也是Flutter迷倒万千少男的原因——漂亮、勤快的“小花瓶”，同样的，KN的切入点更为“底层”，在任何方面的体验都能跟原生一致，没有限制，所以使用KN来进行移动端跨平台研发也未尝不是个值得尝试的方向。

 

其实，我个人偏向于抱着商业的视角去看待技术，很少技术特性是仅此一家的，就像各家app的功能都在互抄，技术也有这样的现象，胜出的关键点在于启动时的技术定位（能不能吸引种子用户）、和社区运营（提高用户迁移的沉末成本），这有点扯远了。

Kotlin跨平台介绍 

>技术现状

Kotlin Multiplaform是一个相当庞大的内容，包含Android、IOS、macOS、Window等多系统，JS、Java、ObjC、Python等多个技术栈。目前整体上还处于试验阶段，但Android/IOS领域是Kotlin团队的首要落地场景，提供了很多的支持，已具备可用性。针对常用的工具库也有相关的跨平台支持：stdlib、io、serialization\序列化、coroutines\并发、ktor\网络、SQLDelight\数据库。

>技术优势

以往的跨平台技术通常是在原生之上构建中间层抹平平台差异，这个中间层或是虚拟机或是框架，不可避免会带来额外的成本：引入技术栈、非原生性能、框架场景受限、割裂的技术生态。Kotlin选择从编译产物的角度实现跨平台，它的编译产物与原生一致，打通了原平台技术生态，可以与存量库零成本互操作，以最小化可实现的方式在原工程中接入。这意味着统一的技术栈，原生的性能，融合的技术生态，源码级别的灵活性。从实践体验来说，这很香！

>银弹还是臭蛋 

一款技术没经过线上的洗礼，尽是纸上谈兵都是在耍流氓。庆幸的是，有一群开拓者愿意去尝试。目前使用Kotlin共享双端代码的团队有：Yandex：俄罗斯的百度月活跃4000W、Quizlet：月活跃5000W的在线教育应用、IceRock：企业服务公司、Careem：打车软件等等，在效率、研发流程、性能方面的收益都十分明显。

Kotlin跨平台原理

编译产物要跟原生平台一致，本质上靠的还是编译器。Kotlin跨平台目前实现了三个编译器ÿ