Keyword: Flutter 、React Native、KMM

对於只要一份Code就能部署到不同平台，所带来的成本降低，以及开发时间的减少，造成了跨平台框架一直是热门的话题．也因次市面上一直推出许多跨平台的框架，举例来说早期的Cordova，Xamarin，中期热门的React Native 到最近火热的Flutter等等．

各跨平台都有自己的优势，和想要解决的跨平台问题，我们已经介绍完KMM的基础应用，该来比较一下这些平台．以Flutter、React Native(RN)、KMM为代表

先说结论:我觉得选用哪个跨平台框架，有三个重要因素

1. 想做什麽
2. 语言好不好用
3. 爸爸强不强，会不会放生
   (这边都是我个人的主观看法 欢迎多加讨论)

想做什麽

如果是需要具有庞大的画面渲染的App，这时候可以选择跟原生有几乎相同甚至超越的Flutter，由於Flutter强大的Skia引擎，让Flutter在画面上独具一格．而传统使用JS再桥接原生Api的跨平台框架，如RN，就会在效能上略为逊色．而KMM由於是使用原生的View层，所以性能也跟原生相同．

但是相对的，到了较为复杂的商业逻辑，或是需要计算的场景，flutter所需要的效能就会直线上升，而RN类型的更是会等到天荒地老．KMM在Android端仍然是原生所以不受影响，iOS端就需要看KMM卷出的swift程序码效能如何了 (这边我是持悲观态度了)

所以如果是画面导向的应用，可以选择Flutter或是KMM．而业务导向的，则会推荐原生

画面应用：Flutter > KMM = 原生>>RN
业务应用：原生>>> KMM > Flutter > RN

语言

Flutter是使用Dart语言，这个语言目前主流仍然是Flutter在使用，Google未来推出的作业系统Fuchsia也是使用Dart语言，虽然还不知道葫芦里卖什麽药．但是如果未来Fuchsia大为流行的话，目前使用的Dart应该也能鸡犬升天．但相反的，若失败了Dart的使用场景比起RN的JS少了许多

RN的JS可以算是世界上最多人使用的程序语言之一了，基本上如果RN失去了竞争力，RN的工程师仍然可以靠着JS在市场上生存，在跨平台所使用的语言中最有前途的就是RN类型的

KMM所使用的Kotlin作为Android官方推荐语言，是基本不会被淘汰的，现在原生也有许多职缺使用Kotlin．另外目前也有不少公司使用Kotlin来建构後端，所以我对於Kotlin还是持乐观态度的．

语言优势: RN > KMM > Flutter(要看未来情况)

爸爸

Flutter和KMM背後都有Google爸爸支撑，虽然前几年(跟甲骨文公司的官司还没打完之前)Google很用力的在推Kotlin，但是在官司打完之後可以感觉到重心逐渐往Dart转移过去，所以爸爸这边我认为Flutter是略大於KMM的．但是Google并不是没有放生的前例．相反的，由於爸爸太有钱所以砍掉几个儿子也不心疼．

而RN目前的情况也不是很好，在AirBnb跳船宣布不再使用RN後，RN的火热程度逐渐冷却，只剩下亲爸爸FB在支撑．不过FB也是大公司啦，这边其实说的是那些没有超级老爸支撑的跨平台框架，例如:Cordova

老爸: Flutter > KMM > RN

KMM的优点

所以KMM相比其他的跨平台框架有什麽优势呢？

1. 可以在现有专案中使用
   与其他的跨平台框架比较起来，KMM可以轻松的引入现有的专案中，而不管是Flutter或是RN基本需要重写整个App，所以在转换成跨平台框架时所付出的成本非常高．但是KMM只要在原有的Android专案中添加模组，再让iOS指到同个位置，便可以使用共通的部分．

2. 可以和原生混用
   KMM并没有强迫使用者一定非要使用共通模组内的程序码，相对的，可以在任何喜欢的层级使用原生Code撰写，当然这时候就不能共用了．这弹性同时也支撑着在现有专案中使用的优点，可以不用一开始就把整个专案都搬进KMM中，而是利用混用的特性一点一滴的重构，也不会影响到正常的使用．

3. 可以使用官方推出的新组件
   由於可以和原生混用，所以跨平台框架最令人诟病的问题："Android或是iOS官方推出新组件必须等到跨平台框架实作後才能使用“这件事就得到了解决．当其他跨平台框架还在眼红新版本Android或是iOS的炫炮玩具，等着跨平台方跟上发布patch档时，KMM可以直接切换到原生模式，无缝接轨使用新功能．

4. 自带分层
   KMM的结构和一般的跨平台框架不同，一开始就将View层的实现与商业逻辑以下分开，大幅减少了不同平台在架构上分歧与冲突．就算平台实作的方法不同，也能利用expect/actual关键字分离，并且在commonMain内部仍然是乾净的，没有因此有所变化．

5. Clean Architecture

   由於要共用商业逻辑层，因此Android习惯用的LiveData与AndroidViewModel等等的组件在商业逻辑层是不能出现的，而反之iOS也不能在此使用一些Android所不了解的组件．无形中约束了程序设计师遵守Clean Architecture 的设计原则．

   KMM的缺点

   而KMM的缺点呢？

   1. 还是要懂原生的程序码
      View层的部分仍然要写原生View元件，各平台不同的实现也必需自己去撰写，也因此还是要了解一部分的原生．不过这算是大部分的跨平台框架共通的问题，不管是Flutter或是RN都会需要去撰写桥接来使用原生的一些功能，这是避免不了的．
   2. 专案结构复杂
      KMM的专案结构算是比较复杂的，像是gradle就至少有三个，负责不同部分的依赖．而shared部分分别有common/Android/iOS三部分，加上测试又要翻一倍到达六部分．然後expect与actual也需要专案结构相同，虽然现在Android Studio有支援跳转功能，但是会在许多package跳转追踪有时候还是蛮麻烦的．
      再加上原生的部分，专案里就会有Kotlin ，Kotlin DSL，Swift等等的语言，写久了就能习惯但是对新人来说学习压力有点大，不过也算是跨平台的原罪吧