什么是 KMP

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

而與諸如 Java / React 這類跨端方案不同，KMP 沒有采用所謂的虛擬機(jī)的思路，而是選擇直接將 kotlin 源碼編譯成目標(biāo)平臺(tái)代碼運(yùn)行的方案。

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

KMP 的優(yōu)勢(shì)：

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

KMP 的限制：

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

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

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

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

KMP 實(shí)現(xiàn)原理

跨平臺(tái)概述

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

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

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

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

Kotlin Native 編譯器

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

編譯流程

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

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

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

produce(Klib)

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

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

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

produce(Binary/CLibrary/ObjCFramework)

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

各步驟說明：

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

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

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

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

IR 轉(zhuǎn)換

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

package com.demo.kmp


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

其編譯后的 llvm ir 長(zhǎng)這樣：

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

// 沒錯(cuò)這個(gè)函數(shù)名就是這么長(zhǎng)
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í)行效率是非常高的（相當(dāng)于寫 C / C++ 代碼去運(yùn)行）。

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

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

Kotlin Native 運(yùn)行時(shí)

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

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

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

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

內(nèi)存管理

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

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

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

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

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

和 android 相比，有 3 點(diǎn)不同：

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

基礎(chǔ)類型

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

對(duì)象類型

class 包括幾部分：

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

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

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

GC 有三種類型，默認(rèn) pcms，cms 需要手動(dòng)配置

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

由于 cms 性能最好，目前 KMP 項(xiàng)目里面默認(rèn)使用 cms

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

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

和 android 相比：

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

小結(jié)

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