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

你是否掌握了大部分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專案，不得不夸獎你一下，

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

1. 比如快手的XX，5年時間只做IM的中間層，收到TCP發來的訊息，分類整理后包裝介面供UI層呼叫，自己不知道TCP是怎么創建并維護的，寫UI連個ViewPager都不會用，ViewPager2都沒聽說過，jetpack根本不知道是啥，只會自己那一點，找作業說自己是底層的開發，專業開發SDK，那得什么公司要你啊，入職后讓你干點啥？先學半年？
2. 再比如新浪的XXX，7年只呼叫音視頻組供給的介面，自己包裝后實作播放功能，搭建UI的人員呼叫他的播放視窗，嵌入到自己頁面里，找作業時說自己是專業干音視頻的，不搞普通app開發，沒聽說過MVVM是啥，自己不懂C++，也不知道啥事視頻關鍵幀，變速、快進、濾鏡、都沒接觸過，問幾個過去作業內容涉及點之外的，一個字都說不對，常掛在嘴上特別欠抽的一句話：這是別的組做的，我們有專門寫個模塊的部門，
3. 還有錘子的XX，錘子出來的人是過往面試中最菜的，菜中之菜，一個團隊5年只維護一個記事本，而且錘子倒閉出來找作業時，Android6.0之后的動態權限都不知道怎么申請，以前沒做過，知識匱乏到令人發指的程度，
4. 很多公司面試就問個HashMap原理，問JVM，問半小時的演算法，實際開發用到的東西都不問，形成了一個封閉的怪圈，一個只會背書的彩筆集中營，這類怪癖的彩筆再招聘新的怪癖菜比，很多人招聘只要和自己同類的人，根本不關心專案需要什么人，從面試的問題看就顯而易見了，，所以招進去一堆這類人，只在一線大廠干過的人，十之八九都是這類爛貨， 張口就是100-120K起，

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

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

咱們接著說正事

對比一下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 在技術上可以實作功能，但相當于寫了兩份代碼，失去了意義；

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

跑一個 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 設備（含模擬器）上運行，

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 的配置