KMM(Kotlin Multiplatform Mobile)入门(一)简介与基本环境搭建

什么是KMM?

KMM 全称:Kotlin Multiplatform Mobile,是基于 Kotlin 语言进行多平台开发的一套技术框架,它和 Kotlin Native(简称 KN)有一定联系,但 KMM 主要面相移动端开发,即:Android、iOS、Web,而 KN 则主要面相 Linux、macOS、Windows 等

当然,KMM 在 iOS 平台的实现,离不开 Kotlin Native,Kotlin 代码最终会在 iOS 工程中生成一套 Framework 库,可供 Objective-C、Swift 进行调用

KMM 宗旨是使用 Kotlin 语言和技术栈,开发一套可以在多平台之间共享的代码库,用来构建统一的代码逻辑,而不用针对各个平台都去实现自己的一套,从而导致人力的浪费

这里引用 Kotlin 官网的一张图来说明 Kotlin 多平台的工作原理

Kotlin 多平台

Kotlin Mutiplatform 之间的关系

Kotlin 官方开发的多平台框架分为以下几种:

  • 标准 Kotlin(Kotlin Stdlib)

    即 Kotlin JVM,由于 Kotlin 最初是基于 JVM 运行的,所以可以使用 Java 的全部功能,同时还能支持 Kotlin 特有的各种语法糖

  • Kotlin Native

    简称 KN,内部对各平台(如:Windows、Linux、macOS、iOS、Android)Native API(不使用 Runtime 的)进行封装,底层使用 LLVM 进行编译,可以使用 Kotlin 调用各平台特定的 API 或基于一些 C/C++ 库的能力,如:OpenGL、OpenCV 等,使多平台共享一套 Kotlin 代码

  • Kotlin JS

    基本原理是将 Kotlin 代码翻译成 JavaScript,同时可以调用一些 JavaScript 特定的接口,从而进行 Web 开发,Kotlin JS 在功能和热度上远不及 TypeScript 这样的语言,后续发展方向目前尚不明确

几种框架的联系如下图所示:

与其他跨平台框架的简单对比

KMM 与 Flutter 的基本思路差异

与 Flutter 这种框架的思想相反,KMM 是用一套语言生成多个平台特定的字节码,所有的翻译工作由 kotlinc 或 kotlin-nativec 编译器来执行,从某种角度来讲,是『从上到下』,而 Flutter 的思想是『从下到上』,这也决定了两种框架适用的场景,Flutter 就适合绘制 UI,而 KMM 则是更适合与 UI 无关的逻辑代码,比如:Model 层,网络请求、数据解析、建模等

成本差异

  • 体积:

    1. 使用 Flutter 需要在 App 包内部增加两个引擎:

      • 一个是 Flutter 的渲染引擎,该引擎使用 C/C++ 开发,直接调用 OpenGL/Skia 的 API 进行绘制,从而摆脱 iOS 的 UIKit 以及 Android 的 View 组件直接渲染成需要的样式,保证样式高度统一

      • 另一个是 Dart 语言的 Runtime,用于解析并运行 Dart 语言编译的 Bundle

      这两者减小了开发者的适配成本,但增大了 APP 的包体积(其他类似的跨平台框架,如:React Native 等,也会内置 JavaScript Core 或 V8 引擎)

    2. 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(包括动画、转场等) 强烈不推荐,应该使用平台特定的代码

其他业界类似框架

  • Xamarin

    组织:Microsoft

    开发语言:C#

    基于 .NET Core 的跨平台开发框架,与 KMM 部分思想一致,适合有 WPF 或 UWP App 开发经验的开发者,需要理解 .NET 的开发模式,且复用现有代码逻辑比较困难,优点是对性能影响较小

  • Cordova

    组织:Apache 基金会

    开发语言:HTML5、 JavaScript

    本质是在一个 App 中运行优化过的 H5 页面,同时对一些 API 进行封装,可使用 JavaScript 调用,性能较差,和 KMM 思想相反

  • React Native

    组织:Facebook

    开发语言:JavaScript

    使用 JavaScript 调用原生 API 和控件,相对于 Cordova,性能有大幅提升,但受制于 React Native 框架的封装,很多能力无法调用,需要双端开发一系列 API,双端差异也比较大,有时候工作量反而增大,优点是对 Web 开发人员比较友好

跑一个 KMM Demo

安装完需要的工具、插件以后,打开 Android Studio,新建一个项目,即可选择新建 KMM 工程

新建工程

完成基本信息填写以后,可以选择是否使用 Cocoapods 来进行依赖 iOS 平台的依赖管理,如果不需要就选成『Regular Framework』

注意:使用 KMM Plugin 建立的工程,会默认使用 Kotlin(.kts 文件)的形式来进行 Gradle 配置,另外,其新建的 iOS 工程,也默认使用 Swift UI 进行开发,且这两项不可以配置,如果需要使用 Groovy,或者使用传统的 iOS UI 开发形式,需要以集成的形式来新建 KMM Module

工程创建完成后,在 Android Studio 顶部工具栏中,即可选择在 Android 或 iOS 设备(含模拟器)上运行

运行

如果需要在 iOS 设备上运行,KMM 模块会利用 Gradle 插件,自动调用 Xcode 进行构建,并调起 iOS 模拟器运行

KMM 工程文件结构

最后附上由 KMM 插件建立的 KMM 工程,默认的文件目录结构说明

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
├── 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 的配置