什么是 KMP

KMP（Kotlin multiplatform）是 Kotlin 語言的一項重要特性，允許將 kotlin 代碼運行在不同平臺上，通過『一碼多端』的方式來節(jié)省成本。

而與諸如 Java / React 這類跨端方案不同，KMP 沒有采用所謂的虛擬機的思路，而是選擇直接將 kotlin 源碼編譯成目標平臺代碼運行的方案。

KMP 的優(yōu)勢和限制

KMP 的優(yōu)勢：

相較傳統(tǒng)的跨平臺框架而言，由于 Kotlin 會將代碼編譯成目標平臺原生代碼執(zhí)行（可以簡單理解為將 Kotlin 源碼翻譯成 java/c++/js 代碼），其最大的優(yōu)勢在于進行 FFI（跨語言調(diào)用）時幾乎沒有性能折損，并且執(zhí)行性能接近于原生系統(tǒng)。

KMP 的限制：

由于早期的 kotlin 是基于 java / android 平臺，這些 kotlin 二/三方庫在設(shè)計時候也不可能考慮過跨平臺?？紤]到這些情況，kotlin 在編譯時使用了 Target Platform 概念，即 kotlin 每個類 / 方法 都是有對應(yīng)平臺的，早期的的 java / android 二三方庫只屬于 jvm 平臺，意味只能在 java / android 平臺調(diào)用，在其他平臺上調(diào)用會編譯報錯。

而對于系統(tǒng)接口，在 KMP 下也是有對應(yīng)平臺限制的，一個簡單的判定方法如下：

1. 所有 kotlin.*、kotlinx.*包名的接口，都是跨平臺的。
2. 所有 java.*、sun.* 包名的接口，只能在 jvm 平臺使用。
3. 所有 android.*包名的接口，只能在 android 平臺使用。
4. androidx.*比較特殊，部分庫可以（比如 Room），部分不行，需要自行查看文檔判斷。

因此，如果想要將 Android 代碼通過 KMP 直接編譯成其他平臺產(chǎn)物，那基本上是不可能直接成功的。如果沒有提前設(shè)計隔離層的話，工程中二、三方依賴，以及源碼中幾乎不可避免的含有 Android / jvm 的平臺接口，你很可能需要進行大量的抽象改造才可以完成。

KMP 實現(xiàn)原理

跨平臺概述

前面提到，KMP 核心思路，是直接將 kotlin 源碼編譯成目標平臺代碼運行。而實現(xiàn)這一能力的關(guān)鍵就是 Kotlin 編譯器，其核心職責就是將源碼翻譯成目標平臺代碼。

在實現(xiàn)上，kotlin 編譯器使用了前后端分離的思路。

簡單來說，前端負責語法解析&代碼分析、后端負責將前端產(chǎn)物翻譯成目標平臺代碼，二者職責清晰。未來如果如果需要支持一個新平臺，添加一個新后端即可。

至于 Optimizer，由于不同目標平臺的優(yōu)化方式不同，在 kotlin 編譯器中被放在了后端中。

Kotlin Native 編譯器

由于 Kotlin Jvm 大家相對比較熟悉，而 Kotlin JS 筆者還沒有看，因此本文只著重介紹 Kotlin Native 的相關(guān)分析

編譯流程

Kotlin Native 編譯入口通常為 Gradle Task 或者命令行（konanc），二者最終執(zhí)行代碼是共通的，最終會根據(jù)根據(jù)產(chǎn)物類型不同執(zhí)行不同邏輯。

產(chǎn)物分為四類：

• Klib：Kotlin Native Library，可以簡單理解為 Kotlin Native 版本的 jar / aar，只保存了 kotlin ir 信息。
• ObjCFramework：給 iOS 使用的 .framework.
• Binary：緩存 / 可執(zhí)行文件。
• CLibrary：動態(tài)庫 / 靜態(tài)庫。

produce(Klib)

Compile 作用是將 kt 編譯成 Klib（可以類比為 aar）。

Klib 解開后結(jié)構(gòu)如下：

所有 KN 模塊在編譯階段都會先編譯成 Klib，在 link 階段才會調(diào)用 c++ 工具鏈處理。

produce(Binary/CLibrary/ObjCFramework)

這三個基本流程都差不多，都是將多個 Klib 聚合編譯成一個二進制庫（類似于 C 的 link、或者 android 的打 apk），區(qū)別在于產(chǎn)物不同。核心為編譯器后端處理，用于將 kotlin ir 轉(zhuǎn)換為目標平臺的二進制庫，核心流程如下：

各步驟說明：

1.  Add entry points：如果編譯可執(zhí)行文件，就加一個入口文件的 ir file，比較簡單。

2.  Lowering module && dependencies：將所有依賴庫合并，并針對合并后的每個 ir 文件（包括依賴的庫的 ir）執(zhí)行 Lowerings（對 Ir 進行前置優(yōu)化，比如內(nèi)聯(lián)，語法糖處理），每個 lowering 文件需要執(zhí)行 51 步，每一步都可以在 NativeLoweringPhases.kt 中找到對應(yīng)的定義。

3.  Run after lowering：即真正的 Native 編譯流程，主要通過 llvm 將 kotlin IR 翻譯為二進制產(chǎn)物，主要步驟：

• CodeGen：將 kotlin ir 『翻譯』成 llvm IR，這部分主要通過調(diào)用 llvm 的 c 函數(shù)實現(xiàn)
• Generate Export Api + Compile Export Api：生成一個對外 api 的 c++ 接口文件并編譯，用于暴露接口給外部調(diào)用。
• Post Processing ：在和底層依賴庫（Runtime）的 bit code 鏈接前，做一些優(yōu)化工作，比如去除無用代碼。
• Write BitCode：將所有 bitcode 鏈接完畢后，生成 out.bc
• Compile and link: 
• 調(diào)用 clang 將 .bc 編譯成 .o，這里會根據(jù) debug / release 添加不同編譯參數(shù)。
• 調(diào)用 lld 將 .o 文件 link 成目標平臺匯編代碼

IR 轉(zhuǎn)換

假設(shè)有如下源碼：

package com.demo.kmp


classHelloWorld{
    funhelloFun1(a: Int, b: Int)： Int {
        return a + b
    }
}

其編譯后的 llvm ir 長這樣：

除開一些流轉(zhuǎn)指令、調(diào)試指令外、其翻譯回 C / C++ 代碼大概是這樣。

// 沒錯這個函數(shù)名就是這么長
int"kfun：com.demo.kmp.HelloWorld#helloFun1(kotlin.Int;kotlin.Int){}kotlin.Int"(*struct.ObjHeader this,int a,int b) {
    return a + b;
}

可以看出和用 C / C++ 寫的代碼基本上差不多，所以執(zhí)行效率是非常高的（相當于寫 C / C++ 代碼去運行）。

其主要的『翻譯』邏輯如下：

1. kotlin 基礎(chǔ)類型會『翻譯』為對應(yīng)的 C 的基本數(shù)據(jù)類型，如： int / float / double / short / long / double。
2. Kotlin 類會『翻譯』成 llvm typeInfo 形式，用來記錄類名等信息。
3. Kotlin 對象會『翻譯』成 ObjHeader + 一段內(nèi)存空間形式，前者用于記錄 typeinfo，后者用來存放所有的類字段。
4. Kotlin 函數(shù)會『翻譯』成 C 函數(shù)，差別在于會多一個 ObjHeader* 參數(shù)，用作 $this 指針。
5. Kotlin 屬性會『翻譯』成 Get/Set 函數(shù)，這個跟 java 是一致的。
6. Kotlin 運算符會『翻譯』成對應(yīng)的 operator 函數(shù)（舉例來說，加號（+）會翻譯成 add 函數(shù)），一些類型（比如基礎(chǔ)類型）會進一步通過內(nèi)聯(lián)翻譯成 C 的運算符。
7. 其余類型則不再贅述，有興趣可以自行參考源碼（位于ir2bitcode.kt）實現(xiàn)。

Kotlin Native 運行時

為了實現(xiàn)內(nèi)存的自動回收，在 Kotlin Native 平臺上，會打包一套 Kotlin Runtime 到最終產(chǎn)物中，包含異常處理、線程管理、內(nèi)存管理等常規(guī)能力。

運行時包括如下幾個部分，創(chuàng)建線程或者已存在的線程都可以 initRuntime

• SetKonanTerminateHandler 為線程設(shè)置異常處理 Handler，這樣可以捕獲 kotlin excepiton
• globalData 初始化全局變量
• theaddata 初始化線程內(nèi)存分配器
• workInit 初始化線程消息隊列，用于執(zhí)行協(xié)程

和 android 相比，kmp 運行時不支持 synchronized 關(guān)鍵字，可以使用 atomicFu 來解決。

內(nèi)存管理

Kotlin Native 有 3 種內(nèi)存分配器：

• custom：kotlin 自己開發(fā)的內(nèi)存分配器，也是默認的內(nèi)存分配器
• std：標準庫內(nèi)存分配器，在鴻蒙上是 jemalloc
• mimalloc：微軟開源的 native 分配器

目前 std/mimalloc 在最新版本已經(jīng)去掉了，kmp 未來會持續(xù)優(yōu)化 custom 內(nèi)存分配器。

custom 內(nèi)存分配器是 kotlin 自己實現(xiàn)的內(nèi)存分配器，包括幾個部分：

• Safealloc mmap 虛擬內(nèi)存，每次大小256k，分配后檢查是否需要觸發(fā) alloc gc
• CreateObject 分配對象，每個對象額外增加16字節(jié)內(nèi)存，包括 objectData/objectHeader
• CreateObject 分配對象時，如果類（typeInfo）加了 TF_HAS_FINALIZER 標記，會通過 extraObject 增加對象弱引用，gc 后調(diào)用對象 finialize 方法，objectHeader 指向 extraObject
• CreateArray 分配 array，每個 array 額外增加24字節(jié)內(nèi)存，包括 objectData/ArrayAHeader，ArrayHeader 12字節(jié)按照8字節(jié)對齊到16字節(jié)

和 android 相比，有 3 點不同：

• Kotlin Native 只支持 Weakreference，不支持 SoftReference
• Kotlin Native 對象分配支持逃逸分析，除了在堆上分配，還可以在編譯時通過靜態(tài)代碼分析決定哪些變量在棧上分配
• Kotlin Native 把 Array 類型單獨拿出來了，Android 認為所有類型都是 Object

基礎(chǔ)類型

基礎(chǔ)類型包括 Byte/Short/Int/Float/String 等，和 android 一致。

對象類型

class 包括幾部分：

• instanceSize_：對象大小，如果是 array，instanceSize_ 為每個元素大小
• superType： 父類
• objOffsets：成員變量 offset 數(shù)組，根據(jù) offset 查找成員變量
• objOffsetCount_：成員變量數(shù)量
• interfaceTableSize：interface 數(shù)量
• interfaceTable：interface 表，指向 interface 實現(xiàn)

和 android 相比，Kotlin Native 將 interface 方法和 abstract 方法都通過 interfacetable 存儲，android 是分開存儲的。

內(nèi)存回收（GC）

GC 有三種類型，默認 pcms，cms 需要手動配置

• cms 是并發(fā)標記的，只在遍歷 gc root 時暫停線程，性能最好
• Stms 需要 stop the world 暫停線程，性能很差
• 默認 pcms 可以支持多線程 gc，也會 stop the world 暫停線程

由于 cms 性能最好，目前 KMP 項目里面默認使用 cms

cms 類型主要包括幾個功能，在在 gc root 收集完成后，會 resume the world 喚醒線程。

• StopTheWord 所有線程將線程暫停執(zhí)行
• collectRootSet 收集 gc root
• resumeTheWorld 喚醒線程
• Mark 會根據(jù) gc root 標記存活對象
• processWeaks 處理 weakReference
• heap.Sweep 釋放非存活對象
• finalizerProcessor 調(diào)用對象 finialize 方法，之前會收集所有線程的 finalize 對象

和 android 相比：

• heap 默認10M，android 是大對象/小對象各512M，導(dǎo)致比較容易觸發(fā) alloc gc，目前已經(jīng)優(yōu)化
• concurrent gc 通過定時10s觸發(fā)實現(xiàn)，在空閑時容易造成 cpu 浪費，目前已經(jīng)優(yōu)化
• cms 目前不會做內(nèi)存碎片整理，會導(dǎo)致內(nèi)存占用過高，目前在優(yōu)化中
• cms mark 階段產(chǎn)生的對象都是存活對象
• gc 不支持分代，目前已經(jīng)優(yōu)化

小結(jié)

Kotlin Multiplatform 在經(jīng)歷了這么多年迭代后，目前現(xiàn)在已經(jīng)是一個相對成熟的解決方案了。雖然在內(nèi)存管理方案還有一些瑕疵，但其『IR 翻譯成 Native』設(shè)計理念使得整個系統(tǒng)的性能上限很高，理論上能達到接近原生的執(zhí)行性能。而 Jetbrain 的號召力也使得整個研發(fā)生態(tài)非常有想象力，目前 androidx 已經(jīng)在開始逐步適配 KMP 中，可以預(yù)見的將來會非常有潛力。