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等等的語言，寫久了就能習慣但是對新人來說學習壓力有點大，不過也算是跨平台的原罪吧