Kotlin Multiplatform Mobile — คืออะไร แนวคิดหลัก และสถาปัตยกรรม KMM

Kotlin Multiplatform Mobile คืออะไร?

Kotlin Multiplatform Mobile (KMM) เป็นเทคโนโลยีที่ช่วยให้เขียนลอจิกทางธุรกิจที่ใช้ร่วมกันของแอปพลิเคชันมือถือด้วย Kotlin และใช้งานบน iOS และ Android โดยไม่ต้องทำซ้ำโค้ด ต่างจาก Ionic หรือ Cordova KMM ไม่เรนเดอร์อินเทอร์เฟซใน WebView — อินเทอร์เฟซผู้ใช้ยังคงเป็นแบบดั้งเดิมอย่างสมบูรณ์และเขียนด้วย SwiftUI (iOS) และ Jetpack Compose (Android)

KMM ถูกประกาศโดย JetBrains ในปี 2019 โดยเป็นส่วนหนึ่งของกลยุทธ์ Kotlin Multiplatform ความแตกต่างหลักจากโซลูชันข้ามแพลตฟอร์มอื่นๆ คือเฟรมเวิร์กไม่ได้พยายามรวมอินเทอร์เฟซผู้ใช้เป็นหนึ่งเดียว แต่เน้นที่การแชร์โค้ดที่เหมือนกันจริงๆ สำหรับทั้งสองแพลตฟอร์ม: คำขอเครือข่าย โมเดลข้อมูล การตรวจสอบฟอร์ม กฎทางธุรกิจ และการดำเนินการฐานข้อมูล

ตามการสำรวจนักพัฒนา JetBrains (2025) นักพัฒนาแอปมือถือ 14% ใช้ KMM และตัวเลขนี้เพิ่มขึ้น 5% ต่อปี เทคโนโลยีนี้ถูกเลือกโดยบริษัทที่มีข้อกำหนดสูงด้านประสิทธิภาพและประสบการณ์ผู้ใช้แบบดั้งเดิม ซึ่งโซลูชันแบบไฮบริดไม่สามารถยอมรับได้

สถาปัตยกรรม KMM: โมดูลที่ใช้ร่วมกันและการใช้งานแพลตฟอร์ม

สถาปัตยกรรม KMM ประกอบด้วยสามโมดูล: shared (โค้ด Kotlin ร่วม), iosApp (แอปพลิเคชัน iOS ดั้งเดิมใน Swift) และ androidApp (แอปพลิเคชัน Android ดั้งเดิมใน Kotlin) โมดูลที่ใช้ร่วมกันถูกคอมไพล์เป็น JAR สำหรับ Android และเฟรมเวิร์กสากล (Apple Framework) สำหรับ iOS

โมดูลที่ใช้ร่วมกัน: สิ่งที่นำไปไว้ในโค้ดร่วม

โมดูลที่ใช้ร่วมกันประกอบด้วยเลเยอร์ที่ไม่ขึ้นกับแพลตฟอร์มทั้งหมด: เลเยอร์เครือข่าย ที่ใช้ Ktor Client, โมเดลข้อมูลพร้อมการทำซีเรียลไลเซชันผ่าน kotlinx.serialization, คลังเก็บสำหรับจัดการข้อมูล, การตรวจสอบฟอร์ม และกฎทางธุรกิจ (เช่น การคำนวณค่าจัดส่ง หรือการตรวจสอบสิทธิ์การเข้าถึง)

โมดูลที่ใช้ร่วมกันใช้ Gradle Multiplatform Plugin และประกอบด้วยชุดซอร์สสามชุด: commonMain (โค้ดร่วม), androidMain (การใช้งานเฉพาะ Android) และ iosMain (การใช้งานเฉพาะ iOS) คอมไพเลอร์ Kotlin/Native แปลงโค้ดร่วมเป็นไลบรารีดั้งเดิมสำหรับ iOS ซึ่งเชื่อมต่อกับโปรเจกต์ Swift ผ่าน XCFramework

โมดูลแพลตฟอร์ม

โมดูล Android — เป็นแอปพลิเคชัน Android มาตรฐานใน Kotlin ด้วย Jetpack Compose หรือ ViewBinding โมดูลที่ใช้ร่วมกันเชื่อมต่อเป็นการพึ่งพา Gradle ทั่วไป และคลาสทั้งหมดจาก commonMain สามารถเข้าถึงได้โดยตรง

โมดูล iOS เป็นโปรเจกต์ Xcode ใน Swift หรือ Objective-C โมดูลที่ใช้ร่วมกันเชื่อมต่อผ่าน CocoaPods, Swift Package Manager หรือ XCFramework Kotlin/Native สร้างส่วนหัว Objective-C สำหรับส่งออกชนิด Kotlin ทำให้สามารถเข้าถึงได้จาก Swift

กลไก expect/actual ใน KMM

expect/actual เป็นกลไกของ Kotlin Multiplatform ที่ช่วยให้สามารถประกาศ API ในโค้ดที่ใช้ร่วมกัน (การประกาศ expect) และให้การใช้งานแยกต่างหากสำหรับแต่ละแพลตฟอร์ม (การประกาศ actual) คอมไพเลอร์ตรวจสอบให้แน่ใจว่ามี actual สำหรับทุกแพลตฟอร์มเป้าหมาย

กรณีการใช้งานทั่วไปของ expect/actual: การรับเวลาปัจจุบันพร้อมโซนเวลา การทำงานกับ SharedPreferences (Android) / UserDefaults (iOS) ฟังก์ชันการเข้ารหัส และการสร้าง UUID แต่ละแพลตฟอร์มใช้ API ระบบของตนเอง

หากไม่มี expect/actual จะเป็นไปไม่ได้ที่จะมีโค้ดลอจิกทางธุรกิจที่เป็นหนึ่งเดียว เนื่องจาก API สำหรับทำงานกับระบบไฟล์ เครือข่าย และพื้นที่จัดเก็บแตกต่างกันระหว่าง iOS และ Android ในระดับการเรียกระบบ กลไกนี้รับประกันว่านักพัฒนาจะไม่ลืมที่จะใช้งานส่วนเฉพาะแพลตฟอร์ม

สำหรับการเรียกแพลตฟอร์ม เช่น การทำงานกับกล้องหรือไบโอเมตริกซ์ KMM นำเสนอกลไก expect/actual รวมกับปลั๊กอินที่คล้ายกับ Cordova แต่บน Kotlin/Native JetBrains ยังได้เผยแพร่ไลบรารี kotlinx-datetime ซึ่งทำให้การจัดการวันที่และเวลาเป็นนามธรรม

ตัวอย่างโค้ด KMM

มาดูโครงสร้างพื้นฐานของโปรเจกต์ KMM พร้อมการประกาศฟังก์ชัน expect สำหรับการสร้าง UUID และการใช้งานสำหรับ iOS และ Android

// commonMain — การประกาศร่วม
expect fun generateUUID(): String

// androidMain — การใช้งานสำหรับ Android
actual fun generateUUID(): String {
    return java.util.UUID.randomUUID().toString()
}

// iosMain — การใช้งานสำหรับ iOS
actual fun generateUUID(): String {
    return platform.Foundation.NSUUID().UUIDString
}

ในโค้ดที่ใช้ร่วมกัน มีการประกาศ expect fun generateUUID() Android ใช้ java.util.UUID ในขณะที่ iOS ใช้ NSUUID จากเฟรมเวิร์ก Foundation ในโค้ดส่วนที่เหลือของโมดูลที่ใช้ร่วมกัน ฟังก์ชันนี้ถูกเรียกโดยไม่คำนึงถึงแพลตฟอร์ม

ตัวอย่างคำขอเครือข่ายโดยใช้ Ktor Client ในโค้ดที่ใช้ร่วมกัน:

import io.ktor.client.*
import io.ktor.client.request.*
import io.ktor.client.statement.*
import kotlinx.serialization.*
import kotlinx.serialization.json.*

@Serializable
data class User(
    val id: Int,
    val name: String
)

class UserRepository {
    private val client = HttpClient()

    suspend fun getUser(id: Int): User {
        val response: HttpStatement =
            client.get("https://api.example.com/users/$id")
        return Json.decodeFromString(response.bodyAsText())
    }
}

โค้ดนี้ทำงานบนทั้งสองแพลตฟอร์มโดยไม่ต้องเปลี่ยนแปลง Ktor Client ใช้ OkHttp บน Android และ NSURLSession บน iOS โดยอัตโนมัติ โดยไม่ต้องกำหนดค่าเพิ่มเติม การทำซีเรียลไลเซชัน JSON ผ่าน kotlinx.serialization ก็เป็นแบบข้ามแพลตฟอร์มเช่นกัน

การเปรียบเทียบ KMM กับ Flutter และ React Native

KMM ครองตำแหน่งที่ไม่เหมือนใครในบรรดาเทคโนโลยีข้ามแพลตฟอร์ม เนื่องจากไม่ได้พยายามแทนที่อินเทอร์เฟซดั้งเดิม ต่างจาก Flutter และ React Native KMM เป็นโซลูชันสำหรับแชร์ลอจิก ไม่ใช่สำหรับรวมอินเทอร์เฟซ

ข้อได้เปรียบหลักของ KMM คือการควบคุมอินเทอร์เฟซผู้ใช้อย่างสมบูรณ์ หากแอปพลิเคชันจำเป็นต้องดูและทำงานแบบดั้งเดิมบนแต่ละแพลตฟอร์ม (เช่น การใช้ iOS TabBar และ Android BottomNavigation พร้อมแอนิเมชันเฉพาะแพลตฟอร์ม) KMM เป็นโซลูชันข้ามแพลตฟอร์มเดียวที่ให้สิ่งนี้โดยไม่ต้องใช้วิธีแก้ปัญหาเฉพาะหน้า

ข้อเสียคือทีมต้องรู้ Kotlin, Swift, Jetpack Compose และ SwiftUI พร้อมกัน ซึ่งทำให้การจ้างงานซับซ้อน Flutter และ React Native ต้องการความรู้เพียงภาษาเดียวและเฟรมเวิร์กเดียว

ข้อดีและความท้าทายของการนำ KMM มาใช้

Kotlin Multiplatform Mobile เป็นเทคโนโลยีที่ทรงพลัง แต่การนำมาใช้ต้องใช้แนวทางที่สมดุล มาดูข้อดีหลักและความท้าทายทั่วไปที่ทีมต้องเผชิญ

ข้อดีของ KMM

ข้อดีข้อแรกและสำคัญที่สุดคือ การลดการทำซ้ำโค้ด ตามกรณีศึกษาของ JetBrains (2024) ทีมที่นำ KMM มาใช้ลดโค้ดที่ซ้ำกันลง 60–80% สำหรับเลเยอร์เครือข่าย และ 40–50% สำหรับลอจิกทางธุรกิจโดยรวม สิ่งนี้ส่งผลโดยตรงต่อความเร็วในการพัฒนาและจำนวนข้อบกพร่อง

ข้อดีข้อที่สองคือประสิทธิภาพในระดับแอปพลิเคชันดั้งเดิม ต่างจากเฟรมเวิร์กแบบไฮบริด KMM ไม่เพิ่มเลเยอร์สิ่งที่เป็นนามธรรมระหว่างอินเทอร์เฟซผู้ใช้และระบบ โค้ดลอจิกทางธุรกิจทำงานได้เร็วเท่ากับที่เขียนด้วย Swift หรือ Kotlin สำหรับแต่ละแพลตฟอร์มแยกกัน

ความท้าทายในการนำมาใช้

ความท้าทายหลักคือ คุณสมบัติของทีม นักพัฒนาต้องรู้ Kotlin (สำหรับโมดูลที่ใช้ร่วมกัน) รวมถึง Swift และ Jetpack Compose (สำหรับอินเทอร์เฟซผู้ใช้) การหาผู้เชี่ยวชาญรอบด้านเป็นเรื่องยาก ดังนั้นทีมจึงมักประกอบด้วยนักพัฒนา Android และ iOS ที่ดูแลโมดูลที่ใช้ร่วมกันร่วมกัน

ความท้าทายที่สองคือเครื่องมือ KMM ต้องการการกำหนดค่า Gradle, CocoaPods หรือ Swift Package Manager รวมถึงการรวมเข้ากับ Xcode ในช่วงแรกของโปรเจกต์ ปัญหาการกำหนดค่าการ build เป็นเรื่องปกติ โดยเฉพาะเมื่อทำงานกับไลบรารี C

ความท้าทายที่สามคือการดีบัก เมื่อเกิดข้อบกพร่องที่จุดเชื่อมต่อระหว่าง Kotlin/Native และ Swift การระบุสาเหตุทำได้ยากกว่าในแอปพลิเคชันแบบเสาหิน JetBrains ปรับปรุงเครื่องมือดีบักอย่างต่อเนื่อง แต่ในทางปฏิบัติ ทีมใช้เวลาถึง 20% ไปกับงานโครงสร้างพื้นฐาน