Kotlin Multiplatform: คืออะไร, shared module และ expect/actual

Kotlin Multiplatform คืออะไร?

Kotlin Multiplatform คือเทคโนโลยีการคอมไพล์ข้ามแพลตฟอร์มที่ช่วยให้เขียนโค้ดที่ใช้ร่วมกันใน Kotlin และคอมไพล์สำหรับแพลตฟอร์มต่าง ๆ: JVM (Android), LLVM (iOS, macOS, watchOS), JavaScript (Web) และไบนารีดั้งเดิม (Linux, Windows) KMP ไม่ใช่เฟรมเวิร์ก UI — มันแก้ปัญหาการนำโลจิกทางธุรกิจกลับมาใช้ใหม่ ไม่ใช่อินเทอร์เฟซ

สถาปัตยกรรม KMP สร้างขึ้นรอบ shared module — โมดูล Gradle ที่มี commonMain พร้อมโค้ดที่ไม่ขึ้นกับแพลตฟอร์มและ source sets สำหรับแต่ละเป้าหมาย (androidMain, iosMain, desktopMain) ตามข้อมูลของ JetBrains ปี 2025 กว่า 40% ของโปรเจกต์ Kotlin ใหม่ใช้ KMP เพื่อแชร์โค้ดระหว่างแพลตฟอร์ม

Kotlin Multiplatform Mobile (KMM) — ชื่อเดิมสำหรับสถานการณ์มือถือ iOS+Android ตั้งแต่ Kotlin 2.1+ คำว่า KMM ถูกแทนที่ด้วย Kotlin Multiplatform เนื่องจากเทคโนโลยีก้าวข้ามการพัฒนามือถือ Netflix, McDonald's และ VMware ใช้ KMP ในระบบผลิตเพื่อแชร์โค้ดระหว่างแอปพลิเคชันมือถือ

กลไก expect/actual: สถาปัตยกรรม

Expect/actual — กลไกสำคัญของ KMP สำหรับการทำงานกับโค้ดเฉพาะแพลตฟอร์ม ใน commonMain มีการประกาศ expect declaration (ฟังก์ชัน, คลาส, พร็อพเพอร์ตี้) และในแต่ละ source set เฉพาะแพลตฟอร์ม (androidMain, iosMain) จะมีการนำไปใช้แบบ actual คอมไพเลอร์จะตรวจสอบว่าสำหรับแต่ละ expect มี actual ในแต่ละแพลตฟอร์มเป้าหมาย

// commonMain — การประกาศ API ของแพลตฟอร์ม
expect fun getPlatformName(): String

expect class PlatformContext(val appVersion: String)

// androidMain — actual สำหรับ Android
actual fun getPlatformName(): String = "Android \${Build.VERSION.SDK_INT}"

// iosMain — actual สำหรับ iOS
actual fun getPlatformName(): String =
    UIDevice.currentDevice.systemName

ลำดับชั้นของ source sets ใน KMP ช่วยให้สร้างระดับกลางได้: ตัวอย่างเช่น iosArm64Main (อุปกรณ์ iOS จริง) และ iosSimulatorArm64Main (ซิมูเลเตอร์) พร้อม iosMain ที่ใช้ร่วมกัน โค้ดจาก commonMaster พร้อมใช้งานสำหรับทุกแพลตฟอร์ม ในขณะที่โค้ดจาก iosMain พร้อมใช้งานเฉพาะเป้าหมาย iOS เท่านั้น ซึ่งช่วยลดความซ้ำซ้อนเมื่อการนำไปใช้แตกต่างกันไม่ใช่ในแต่ละแพลตฟอร์ม แต่สำหรับกลุ่มของแพลตฟอร์ม

ในทางปฏิบัติ expect/actual ใช้สำหรับ: การเข้าถึงพื้นที่เก็บข้อมูลในเครื่อง (SharedPreferences vs NSUserDefaults), เครือข่าย (HttpEngine ต่อแพลตฟอร์ม), การเข้าถึงระบบไฟล์, การเข้ารหัส และการวิเคราะห์ JetBrains แนะนำให้ลดจำนวนการประกาศ expect/actual และย้ายโค้ดให้มากที่สุดเท่าที่เป็นไปได้ไปยัง commonMain

Shared module: โครงสร้างและ Gradle

Shared module — โมดูล Gradle มาตรฐานที่มีปลั๊กอิน org.jetbrains.kotlin.multiplatform ประกอบด้วยโค้ดที่ใช้ร่วมกันใน src/commonMain/kotlin/ และการนำไปใช้เฉพาะแพลตฟอร์มใน src/androidMain/kotlin/ และ src/iosMain/kotlin/ โปรเจกต์ KMP ยังรวม androidApp และ iosApp ซึ่งขึ้นอยู่กับ shared module

// build.gradle.kts — shared module
plugins {
    kotlin("multiplatform")
    id("com.android.library")
}

kotlin {
    androidTarget()
    
    listOf(
        iosX64(),
        iosArm64(),
        iosSimulatorArm64()
    ).forEach {
        it.binaries.framework {
            baseName = "shared"
            isStatic = true
        }
    }

    sourceSets {
        val commonMain by getting {
            dependencies {
                implementation("io.ktor:ktor-client-core:3.1.0")
                implementation("org.jetbrains.kotlinx:kotlinx-serialization-json:1.7.3")
            }
        }
        val androidMain by getting {
            dependencies {
                implementation("io.ktor:ktor-client-okhttp:3.1.0")
            }
        }
        val iosMain by creating {
            dependencies {
                implementation("io.ktor:ktor-client-darwin:3.1.0")
            }
        }
    }
}

การกำหนดค่า Gradle สำหรับ KMP ต้องการการประกาศเป้าหมาย iOS อย่างชัดเจน — x64 (ซิมูเลเตอร์ Intel), arm64 (อุปกรณ์จริง) และ simulatorArm64 (ซิมูเลเตอร์ Apple Silicon) Apple framework ที่แยกต่างหากจะถูกสร้างขึ้นสำหรับแต่ละเป้าหมาย ปลั๊กอิน kotlin("multiplatform") จะกำหนดการคอมไพล์สำหรับ JVM และ LLVM โดยอัตโนมัติตามเป้าหมายที่ประกาศไว้

Ktor และ kotlinx.serialization — ไลบรารี KMP มาตรฐานที่รองรับโค้ดที่ใช้ร่วมกัน Ktor ให้ไคลเอนต์ HTTP พร้อมเอ็นจินสำหรับแต่ละแพลตฟอร์ม (OkHttp สำหรับ Android, Darwin สำหรับ iOS) kotlinx.serialization ทำงานบนทุกแพลตฟอร์มโดยไม่ต้องใช้ expect/actual ต้องขอบคุณการนำไปใช้แบบหลายแพลตฟอร์มใน commonMain

การรวม iOS ผ่าน Kotlin/Native

Kotlin/Native — คอมไพเลอร์ Kotlin สำหรับโค้ดดั้งเดิมผ่าน LLVM สำหรับ iOS shared module จะถูกคอมไพล์เป็น Apple framework (.framework) ที่เชื่อมต่อผ่าน Xcode การเรียกโค้ดที่ใช้ร่วมกันจาก Swift/Objective-C เกิดขึ้นผ่านส่วนหัว Objective-C ที่สร้างขึ้น ดังนั้น API ของ shared module จะต้องเข้ากันได้กับ Objective-C

ข้อจำกัดของการรวม iOS: คอลเลกชัน Kotlin (List, Map) จะถูกแปลงเป็น NSArray/NSDictionary ฟังก์ชันที่มีพารามิเตอร์เริ่มต้นจะไม่ถูกส่งออก — จำเป็นต้องมี overloads สำหรับฟังก์ชัน suspend เมธอดแบบ callback จะถูกสร้างขึ้นพร้อม @ObjCName และการรองรับ async/await ตั้งแต่ Kotlin 2.0+

// แอป iOS: การเรียก shared module จาก Swift
import shared

class ViewModel: ObservableObject {
    let repository = UserRepository()
    
    func loadUsers() {
        repository.fetchUsers(completionHandler: { result, error in
            if let users = result as? [User] {
                print("Users: \(users.count)")
            }
        })
    }
}

การรวม shared module ใน Xcode เกิดขึ้นผ่าน embed-and-framework — .xcframework ที่สร้างขึ้นจะถูกเพิ่มลงในโปรเจกต์ Xcode ปลั๊กอิน Gradle สามารถอัปเดต framework โดยอัตโนมัติระหว่างการ build ผ่าน embedAndSignAppleFrameworkForXcode สำหรับการทดสอบบนซิมูเลเตอร์ ไบนารี iosSimulatorArm64 หรือ iosX64 ก็เพียงพอ

KMP vs Flutter vs React Native

การเลือกระหว่าง KMP, Flutter และ React Native ขึ้นอยู่กับลำดับความสำคัญ: การนำโค้ดกลับมาใช้ใหม่หรือข้ามแพลตฟอร์มแบบเต็มรูปแบบ KMP ให้ UI ดั้งเดิมบนแต่ละแพลตฟอร์มแต่ต้องการฐานโค้ดสองชุดสำหรับอินเทอร์เฟซ Flutter และ React Native ใช้ UI เดียวแต่เสียสละความเป็นดั้งเดิม

เมื่อใดควรเลือก KMP: โปรเจกต์ต้องการ UI ที่มีประสิทธิภาพสูง (เกม แผนที่ แอนิเมชัน) ต้องนำโค้ดดั้งเดิมที่มีอยู่กลับมาใช้ใหม่ ทีมรู้จัก Kotlin และแพลตฟอร์มดั้งเดิมอยู่แล้ว เมื่อใดควรเลือก Flutter/RN: MVP หรือสตาร์ทอัพที่มีงบประมาณจำกัด ทีมโปรไฟล์เดียว UI ไม่ต้องการการปรับแต่งดั้งเดิมเชิงลึก

เครื่องมือและไลบรารี KMP

ระบบนิเวศเครื่องมือ KMP รวมถึงไลบรารีสำหรับทุกชั้นของแอปพลิเคชัน: เครือข่าย (Ktor), การทำให้เป็นอนุกรม (kotlinx.serialization), ฐานข้อมูล (SQLDelight), การนำทาง (Decompose), DI (Koin) และการจัดเก็บข้อมูล (multiplatform-settings) JetBrains รองรับ Compose Multiplatform — เฟรมเวิร์ก UI ใน Kotlin ที่ทำงานบนทุกแพลตฟอร์ม

// พื้นที่เก็บข้อมูล KMP พร้อม SQLDelight + Ktor
class UserRepository(
    private val httpClient: HttpClient,
    private val db: AppDatabase
) {
    suspend fun syncUsers(): List<User> {
        val remote = httpClient.get("https://api.example.com/users")
            .body<List<UserDto>>()
        
        db.userQueries.replaceAll(remote.map { it.toDomain() })
        
        return db.userQueries.selectAll().executeAsList()
    }
}

Compose Multiplatform — เฟรมเวิร์ก UI สำหรับ KMP ที่อิงจาก Jetpack Compose ช่วยให้เขียนอินเทอร์เฟซใน Kotlin สำหรับ Android, iOS, Desktop และ Web ในปี 2025 Compose Multiplatform บรรลุสถานะเสถียรสำหรับ Android และ Desktop; เป้าหมาย iOS อยู่ในรุ่นเบต้า สำหรับโปรเจกต์การผลิตที่มี UI ดั้งเดิม ข้อได้เปรียบของ KMP ยังคงเป็นความแตกต่างหลักจาก Flutter