一直以来，因为有着 iOS、Android 等多个系统的存在，开发者在开发同一款应用时也需要根据不同的平台去进行相应的修改，在此情况之下，Flutter、React Native、Weex 等多款跨平台框架应运而生，有效提升了开发者代码的复用性，大大降低了开发成本。
而在 Google I/O 大会上，自 Google 宣布将 Kotlin 作为 Android 开发的官方语言之后，Kotlin 的首席语言设计师 Andrey Breslav 也在 KotlinConf 上宣布 Kotlin/Native 已支持用于开发 iOS 应用。不过同时，不少开发者也提出质疑，其认为 Kotlin Native 处于早期阶段，根本没有想象中那么美好。
在本文中，作者 Jeremy Rempel 将从跨平台的发展以及框架对比等多重角度，剖析 Kotlin Native 是否有存在的必要。
以下为译文：
基于历史原因，移动应用一直以来都要求在2个或更多不同的平台和工具包上进行开发。包括但不限于：
iOS：Object C，Swift，XcodeAndroid：Java，Kotlin，Android Studio
逻辑抽象和公共代码共享以便在不同的功能上重用并不是一个新概念，在现代计算的起步阶段就有了。相比之下，iOS和Android的出现才刚过10年，还处于起步阶段。
为什么我们需要跨平台解决方案?
iOS和Android平台都非常复杂，开发者要在某一个平台上成为专家需要数年的时间。掌握每个平台需要懂得两种官方支持的编程语言、硬件知识、平台SDK和各种各样的支持库。希望同时支持iOS和Android应用程序的组织和公司必须至少要维持两个开发团队，因为同时拥有两个平台的丰富经验的开发人员是非常罕见的。两个开发团队都试图保持应用程序在两个平台的功能对等，在修补缺陷的同时仍然能够利用每个平台的优势，这就导致开发团队的进一步的碎片化。而具备平衡各个平台的复杂性，降低平台的冲突，有选择性地跨平台共享公共逻辑的能力，就能够使团队集中精力，为真正重要的用户提供所需的功能和价值。
用户体验
从用户的角度来看，移动体验是他们在移动应用上能够看到和交互的一切。用户并不知道或并不关心应用程序使用的语言、框架或者使用了何种web服务。用户与应用程序的交互是通过屏幕、通知、平台以及与蓝牙、传感器和摄像头等硬件的交互来进行的。苹果和谷歌都在各自的平台上进行了大量投资，并使其各具特色。每一次年度更新都会带给我们新的功能、新的API以及诸如手表、可弯曲电话、电视等等目标设备。
用户体验主要指的是UI和它与原生系统SDK的集成、以及性能和其他能力（如离线支持）。任何有使用限制，和在原生平台上需要额外抽象的移动框架都会阻碍开发人员充分利用整个平台的优势，从而导致用户体验受损或额外的开发开销。能够使一个应用程序别具特色并为用户带来价值的是用户与之交互的方面，如UI、Notification（通知）以及和系统其它部分的集成。而UI后面的应用层（如业务逻辑、REST端点、缓存、JSON序列化和依赖注入）则与平台的相关性并不大。
理想平台
一个理想的平台应该具备如下特点：
应该能够集成到现有平台构建工具链和持续集成的基础架构中应该能够以最小的代价，充分利用底层平台API和语言，尤其是面向用户的组件，如UI和Notification（通知）应该能够无缝集成，而不引入额外runtime的开销在IDE支持、编译器和lint代码检查方面提供一流的工具支持有成熟社区和第三方库的支持
Flutter（注：谷歌的移动UI框架）
Flutter之于移动应用就像Silverlight之于Web应用一样。它整合了自己的库、语言和页面渲染。Flutter是由谷歌的一个独立于Android的团队开发的，它使用DART编程语言，目标是通过直接写入视图层，并提供自己的SDK，UI widget(小部件)，runtime和编程环境，来开发出一个通用的开发平台和SDK。Flutter的主要目的是取代而不是扩充Android和SDK框架。它的主要应用场景是希望以一致的UI界面运行在多个平台上的新的待开发的项目。虽然Flutter可以提供高性能体验，但是对于期望使用每个平台独特功能的复杂应用，跨平台提供一致的外观和体验是很有挑战性的。巧合的是，最受欢迎和讨论最多的Flutter应用程序之一，Hamilton并没有使用Material或Cupertino组件。
Dart：谷歌之外很少见到的小众编程语言。现有开发人员需要重新培训，招募新人不容乐观。
Flutter SDK：目标是替换而不是补充原生SDK。
React Native
React是一个由Facebook开发的Javascript UI框架，用于开发现代单页web应用（SPA）。React使用声明性的方式描述UI。由于更新DOM树的成本很高，框架将接收到所需的UI作为输入，而React框架将比较新旧DOM之间的差异，并且只执行所需的更新。
React Native使用React框架。但是它的目标不再是HTML，而是原生Android和iOS平台的SDK。React Native Javascript的runtime将通过bridge（桥接器）与原生框架异步通信。虽然它的目标是给两个提升平台提供最好的框架，但结果是喜忧参半的。React Native的最大贡献是它充分利用并增强了底层移动平台，而没有取代它们。
React Native的主要缺点
Javascript：不管你是爱它还是恨它，Javascript已经成为最流行的语言之一，但它会引入第三方语言生态系统。要想在iOS和Android上成功部署或调试一个复杂功能，开发人员必须了解第三方语言和runtime。这种级别的抽象还引入了另一个要调试和支持的层。
Bridge（桥接器）：原生模块和本机代码之间的任何通信都是通过桥接器完成的。这可能导致复杂的集成，并带来性能损失。
依赖项：React Native引入了许多依赖项，导致无法在Android上支持X64等问题。React Native是一个大型平台，它在原生平台上引入了许多限制，从而导致安全性和可维护性问题。
Kotlin Native
Kotlin Native是由Kotlin编程语言的创建者Jetbrains开发的一个编译器和一组库。Kotlin Native旨在通过将代码编译成原生二进制文件并尽可能与原生平台紧密集成来解决代码共享问题，减少冲突，它并不是引入另一个runtime、语言或工具链。谷歌已经宣布将Kotlin作为Android开发的官方语言，因此大多数Android团队都公开接受它。不过，Kotlin对iOS开发来说显然是一门外语，但它与Swift、JavaScript和DART语言的相似性增加了它的内聚力。
与其他竞争框架相比，Kotlin Native的主要优势在于GUI、传感器、Notification以及每种设备独特的内容都能以原生语言开发和无限制的运行平台。与Flutter和React Native的解决方案相比，Kotlin Native解决方案减少了障碍并避免了损害。
在Android上，公共模块使用原生构建工具组装到最终的APK中。在iOS上，公共模块被编译到单个原生库中，并使用原生构建工具链和原生IDE组装到应用程序中。与React Native类似，Kotlin Native将尝试利用底层平台，并使开发人员能够基于特性或组件定义Seam，以及决定哪些特性应在特定平台或者在Kotlin Native上开发。Kotlin Native提供一个选项但并不强迫跨平台共享代码。
总结
移动计算的历史是一个代码分享和站在巨人肩膀上的历史。随着手机在我们的日常生活中变得越来越强大和无处不在，我们构建的移动应用将会越来越多，越来越复杂。能够跨平台共享代码在未来将变得更加重要。Kotlin Native仍然是早期的测试版，并非没有问题和挑战，但无论如何，它都将成为未来跨平台开发最实用的解决方案。
