此篇文章主要討論移動端-跨平臺技術：

你是否掌握了大部分Android開發需要的知識點呢？
你是否完整的看完過一本Android基礎入門的書呢？
你的技術棧是否還是片面的一角？

• Kotlin Multiplatform Mobile ？
• jetpack 中的 Compose Multiplatform ？
• 還是使用Dart 的 flutter ？
• 還是選擇html的方式 RN/Cordova /等……？？

1、html肯定沒人會選，就像用eclipse開發一樣，都是多少年前的事了。
2、如果你不會kotlin，可以選擇flutter學一下Dart。
3、但是如果你會kotlin，建議不要再學Dart了。掌握了kotlin這種先進的現代編程語言之后，再去學Dart會覺得很難受。Dart在kotlin面前就是個非常落后的語言，各種不支持。雖然也在持續優化迭代，但是和kotlin比就差的太遠了。如果你不會kotlin，一直在用Java或者js開發，學一下Dart也可以的。

Android技術日新月異，新技術層出不窮。一直在維護老項目的人已經很難再繼續干Android開發了。都2021年了，竟然有的人還在維護eclipse項目，不得不夸獎你一下。

---

面試時發現很多人的技術棧非常的窄，吸收新技術的能力非常差，學習能力幾乎沒有。

比如快手的XX，5年時間只做IM的中間層。收到TCP發來的消息，分類整理后包裝接口供UI層調用。自己不知道TCP是怎么創建并維護的，寫UI連個ViewPager都不會用，ViewPager2都沒聽說過，jetpack根本不知道是啥。只會自己那一點，找工作說自己是底層的開發，專業開發SDK，那得什么公司要你啊，入職后讓你干點啥？先學半年？

再比如新浪的XXX，7年只調用音視頻組供給的接口，自己包裝后實現播放功能。搭建UI的人員調用他的播放窗口，嵌入到自己頁面里。找工作時說自己是專業干音視頻的，不搞普通app開發，沒聽說過MVVM是啥。自己不懂C++，也不知道啥是視頻關鍵幀，變速、快進、濾鏡、都沒接觸過。只會調用開源的ijkplayer。問幾個工作內容的細節，一點都說不上來。常掛在嘴上特別欠抽的一句話：這是別的組做的，我們有專門寫個模塊的部門。

還有錘子的XX，錘子出來的人是過往面試中最菜的，菜中之菜。一個團隊5年只維護一個記事本，而且錘子倒閉出來找工作時，Android6.0之后的動態權限都不知道怎么申請，以前沒做過。知識匱乏到令人發指的程度。

還有58同城，我一個學建筑專業的鄰居，畢業后找不到工作，在村里賣了兩年化肥，然后在傳X播客培訓了三個月Java，混進了58同城，一個機構幾十個老師幫你應付背調電話，背調有啥用？真實？有效？ 工作時發微信問我，Java的類里為什么有一對大括號？連個代碼塊都不知道，基礎語法都不會就進了58同城 真是魚找魚，蝦找蝦。

很多公司面試問HashMap原理，問半小時的算法，實際開發用到的東西都不問。形成了一個封閉的怪圈，一個只會背面試題的彩筆集中營，這類怪癖的彩筆再招聘新的怪癖菜比。。很多人招聘只要和自己同類的人，或者自己能hold住的人，根本不關心項目需要什么人，從面試的問題看，顯而易見。。所以招進去一堆這類人。只在一線大廠實習過的人，沒經歷過中型企業，十之八九都是這類爛貨。 張口就是100-120K起。阿里辭職的，出來面試時眼神里都是傲慢，藐視一切。。那你出來惡心誰，在阿里巴巴好好待著不就完了。。

垃圾都不是一天練成的，很多大廠里的優秀人員都升職加薪或者經朋友內推，總是有更適合自己的位置，在市場上流浪的，像boss直聘中搜到的，又或者拉鉤、脈脈上給你投簡歷的，都是一群在大環境下，養成的螻蟻。。 很多公司的初面恰恰都被這類 螻蟻 擋著。初面都是一對一，你不符合 螻蟻們 的口味你根本沒機會見到第二個人。。

甚至很多面試被HR過濾掉： 你都結婚了？你都有孩子？你的簡歷直接進回收站了。
甚至被前臺過濾掉： 出來面試都不打扮一下的嗎？不打理頭發？襯衫都是褶皺，也不熨一下衣服？
跟你聊聊職業規劃人生理想，說一說你前公司的三個優點，再說一下它的三個缺點，好，回去等通知吧。你都沒機會見到技術。這種事常有，因為你被Office Lady給pass了。

---

咱們接著說正事

---

對比一下KMM 與 Flutter 的基本思路差異

與 Flutter 這種框架的思想相反，KMM 是用一套語言生成多個平臺特定的字節碼，所有的翻譯工作由 kotlinc 或 kotlin-nativec 編譯器來執行，從某種角度來講，是『從上到下』，而 Flutter 的思想是『從下到上』，這也決定了兩種框架適用的場景，Flutter 就適合繪制 UI，而 KMM 則是更適合與 UI 無關的邏輯代碼，比如：Model 層，網絡請求、數據解析、建模等

成本差異

體積：

使用 Flutter 需要在 App 包內部增加兩個引擎：

一個是 Flutter 的渲染引擎，該引擎使用 C/C++ 開發，直接調用 OpenGL/Skia 的 API 進行繪制，從而擺脫 iOS
的 UIKit 以及 Android 的 View 組件直接渲染成需要的樣式，從保證樣式高度統一

另一個是 Dart 語言的 Runtime，用于解析并運行 Dart 語言編譯的 Bundle

這兩者減小了開發者的適配成本，但增大了 APP 的包體積（其他類似的跨平臺框架，如：React Native 等，也會內置
JavaScript Core 或 V8 引擎）

KMM 針對不同平臺生成不同的二進制依賴包，根本上還是調用了 Android、iOS 的原生 API，并不會內置引擎這類文件，對 App
的體積影響相對較小，同時也保證了性能

技術棧：

Flutter 使用 Dart 開發，無論是 Web 開發者，還是原生 App
開發者，都需要抽時間去學習一門新的語言，理解新的開發模式，雖然 Dart 與 JavaScript、Java 有著類似之處，且開發形式和
React 相近，但仍有一定學習門檻

Kotlin 已經成為 Google 官方主推的 Android
開發語言（https://developer.android.google.cn/kotlin/first），且由于 Kotlin 與
Java 交互非常方便，目前大部分 Android 開發者已經完全切換到 Kotlin 來進行 App
開發，很多與平臺無關的工具類、算法、數據模型可以直接利用 KMM 實現跨平臺，與 Flutter 相比，至少 Android
開發者的門檻要求幾乎為零；

風險點：

眾所周知，App Store 對 App 的審核一直都是極為嚴格的，JSPatch、React Native
等框架的使用都有過審核被拒的情況，從某種角度來看，Flutter 與 Swift UI 在一定程度上目標相似，且繞開 iOS SDK 的
UIKit，Apple 雖沒有明確對 Flutter 表態，但按照 Apple 的風格，Flutter 在未來仍存在一定的被拒風險
KMM 會將 Kotlin 代碼編譯為標準的 Apple Framework，在不引入其他第三方庫的情況下，不存在調用高風險 API
的情況，故對 App Store 審核的影響較小，風險較低 適用場景：

由于 Flutter 采用類似 3D 游戲的渲染理念，統一了界面渲染引擎，利用 Dart
可以高度保證雙端樣式和交互邏輯一致，且幾乎不存在界面適配問題，完全抹平了 TextView 和 UILabel 這類控件之間的差異，所以
Flutter 適合于界面構建

而 KMM 并不適合 UI，雙端的組件，生命周期、API 差異都比較大，KMM 在技術上可以實現功能，但相當于寫了兩份代碼，失去了意義；

這里翻譯一把官方的建議：

架構層級是否推薦使用共享代碼

業務邏輯層	推薦
平臺數據訪問	可選，但需要調用平臺特定的代碼，行為可以共享
前端交互（輸入、通信等)	可選，可以考慮使用 MVI（Model-View-Intent，MVP 模式的衍生） 進行解耦，共享控制層代碼
UI（包括動畫、轉場等）	強烈不推薦，應該使用平臺特定的代碼

---

跑一個 KMM Demo

需要的工具：

• Android Studio（4.2 版本以上，需要安裝 KMM 插件）
• Xcode（最新即可）
• JDK（8 及以上）

其他參考資料：

Kotlin 官網環境配置文檔：https://kotlinlang.org/docs/mobile/setup.html

KMM 插件：https://plugins.jetbrains.com/plugin/14936-kotlin-multiplatform-mobile

安裝完需要的工具、插件以后，打開 Android Studio，新建一個項目，即可選擇新建 KMM 工程

完成基本信息填寫以后，可以選擇是否使用 Cocoapods 來進行依賴 iOS 平臺的依賴管理，如果不需要就選成『Regular Framework』

注意： 使用 KMM Plugin 建立的工程，會默認使用 Kotlin（.kts 文件）的形式來進行 Gradle 配置，另外，其新建的 iOS 工程，也默認使用 Swift UI 進行開發，且這兩項不可以配置，如果需要使用 Groovy，或者使用傳統的 iOS UI 開發形式，需要以集成的形式來新建 KMM Module

工程創建完成后，在 Android Studio 頂部工具欄中，即可選擇在 Android 或 iOS 設備（含模擬器）上運行。

https://github.com/Pangu-Immortal

KMM 工程文件結構

最后附上由 KMM 插件建立的 KMM 工程，默認的文件目錄結構說明

├── androidApp # 實際 Android APP Module ├── build.gradle.kts # 工程根 Gradle 配置 ├── gradle ├── gradle.properties ├── gradlew ├── gradlew.bat ├── iosApp # 實際的 iOS 工程根目錄 ├── local.properties ├── settings.gradle.kts └── shared # KMM 模塊代碼目錄├── build.gradle.kts # KMM 模塊 Gradle 配置（依賴、插件、構建 Task、cinterop 等配置）└── src # 內部模塊形式都為 Gradle 工程 Module├── androidMain # Android 差異化代碼，最終生成 AAR├── commonMain # 共享模塊 API 代碼├── iosMain # iOS 差異化代碼，└── nativeInterop # 默認不會創建，用來存放 *.def 文件，描述與 C/C++ 代碼，或 Apple Framework 交互時，構建 klib 的配置

---

總結

以上是生活随笔為你收集整理的对比Compose 、kotlin、flutter 移动端跨平台的未来。的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。