Runtime ในการพัฒนาแอปมือถือ: runtime system คืออะไรและทำงานอย่างไร

Runtime ในการพัฒนาแอปมือถือคืออะไร?

Runtime คือโครงสร้างพื้นฐานที่รับประกันการทำงานของโปรแกรมหลังจากที่มันเริ่มทำงาน ในบริบทของการพัฒนาแอปมือถือ runtime รวมถึงตัวโหลดคลาส ตัวจัดสรรหน่วยความจำ ตัวเก็บขยะ ตัวจัดส่งเมธอดและตัวจัดการข้อยกเว้น หากไม่มีชั้นกลางนี้ ระบบปฏิบัติการไม่สามารถทำงานไบต์โค้ด Dalvik หรือข้อความ Objective-C ได้

แพลตฟอร์มมือถือใช้การใช้งาน runtime ที่แตกต่างกัน Android ใช้ ART (Android Runtime) ด้วยการคอมไพล์แบบผสม AOT/JIT iOS ใช้ Objective-C Runtime — ระบบไดนามิกที่อิงตามการส่งข้อความและตัวระบุ SEL ทั้งสองแนวทางแก้ปัญหาเดียวกัน: ทำงานโค้ดของนักพัฒนาบนอุปกรณ์เฉพาะด้วยประสิทธิภาพสูงสุด

ตาม Google I/O 2024 Android Runtime ประมวลผลมากกว่า 10 พันล้านเมธอดต่อวันบนอุปกรณ์ทั่วโลก ประสิทธิภาพของ runtime ส่งผลโดยตรงต่อความเร็วในการเริ่มต้นแอปพลิเคชัน ความลื่นไหลของแอนิเมชันและการใช้แบตเตอรี่ ทุกการเรียกเมธอด ทุกการจัดสรรหน่วยความจำและทุกรอบการเก็บขยะผ่านชั้น runtime

ระบบ runtime: ประกอบด้วยองค์ประกอบอะไรบ้าง

ระบบ runtime ประกอบด้วยองค์ประกอบหลักห้าอย่าง: ตัวโหลดคลาส ตัวจัดการหน่วยความจำ ตัวแปลหรือคอมไพเลอร์ ตัวจัดส่งเมธอดและระบบรักษาความปลอดภัย แต่ละองค์ประกอบทำหน้าที่ที่กำหนดอย่างเคร่งครัดในกระบวนการทำงานของโค้ด

ตัวโหลดคลาสและการตรวจสอบ

เมื่อผู้ใช้เริ่มแอปพลิเคชัน ClassLoader โหลดไฟล์ DEX (Android) หรือไบนารี Mach-O (iOS) เข้าไปใน RAM ใน Android ขั้นตอนนี้รวมถึงการตรวจสอบไบต์โค้ด: runtime ตรวจสอบว่าโค้ดไม่มีคำสั่งที่ไม่ปลอดภัย ไม่เกินขอบเขตอาเรย์และปฏิบัติตามชนิดข้อมูล การตรวจสอบเป็นขั้นตอนความปลอดภัยที่สำคัญที่ป้องกันการทำงานของโค้ดที่เป็นอันตราย

ตัวจัดการหน่วยความจำและตัวเก็บขยะ

ตัวจัดการหน่วยความจำ จัดสรรและปล่อยหน่วยความจำสำหรับออบเจ็กต์ ใน Android ART ใช้ตัวเก็บขยะแบบพร้อมกัน (concurrent) กับการเก็บแบบรุ่น (generational collection): ออบเจ็กต์อายุน้อยถูกตรวจสอบบ่อยกว่า ออบเจ็กต์อายุมากถูกตรวจสอบน้อยกว่า Objective-C Runtime ใช้ Automatic Reference Counting (ARC) ซึ่งคอมไพเลอร์แทรกการเรียก retain/release โดยอัตโนมัติ

ตัวจัดส่งเมธอดและตารางเสมือน

ตัวจัดส่งเมธอด กำหนดว่าการใช้งานเมธอดใดจะถูกเรียก ในภาษาสแตติก (Kotlin, Swift) การจัดส่งทำผ่าน vtable — ตารางเมธอดเสมือน ในภาษาไดนามิก (Objective-C) ข้อความผ่าน objc_msgSend ซึ่งค้นหาการใช้งานในคลาสและคลาสแม่ของมัน ผลลัพธ์ถูกเก็บไว้ในแคช method cache เพื่อเร่งการเรียกซ้ำ

ART บน Android ทำงานอย่างไร

Android Runtime (ART) คือเครื่องเสมือนที่ทำงานไบต์โค้ด DEX ของแอปพลิเคชัน Android ART แทนที่ Dalvik ใน Android 5.0 Lollipop โดยแนะนำการคอมไพล์ AOT: แอปพลิเคชันถูกคอมไพล์เป็นโค้ดเครื่องครั้งเดียวระหว่างการติดตั้ง สิ่งนี้กำจัดโอเวอร์เฮดของการคอมไพล์ JIT ทุกครั้งที่เริ่ม

ตั้งแต่ Android 7.0 Nougat ART ใช้แนวทางแบบผสม ระหว่างการติดตั้ง การคอมไพล์ JIT จะดำเนินการเฉพาะสำหรับเมธอดที่ใช้บ่อย (hot methods) ส่วนโค้ดที่เหลือถูกแปล โปรเซสพื้นหลัง (profile-guided optimization) วิเคราะห์ว่าเมธอดใดถูกเรียกบ่อยที่สุดและคอมไพล์ AOT ในช่วงเวลาที่อุปกรณ์ว่าง สิ่งนี้ลดเวลาในการติดตั้งในขณะที่รับประกันประสิทธิภาพสูง

ART ยังรวมถึง คอมไพเลอร์ AOT (dex2oat) ที่แปลงไฟล์ DEX เป็นไบนารี ELF ด้วยโค้ดเครื่อง ARM64 การคอมไพล์ดำเนินการด้วยระดับการปรับให้เหมาะสมสามระดับ: quicken (เร็ว), optimize (ปานกลาง) และ everything (สมบูรณ์) โดยค่าเริ่มต้น Android ใช้ optimize ซึ่งสร้างสมดุลระหว่างความเร็วในการคอมไพล์และประสิทธิภาพของโค้ด

class RuntimeExample {
    fun measureExecutionTime() {
        val start = System.nanoTime()
        // การเรียกเมธอดที่คอมไพล์โดย ART
        processData()
        val end = System.nanoTime()
        println("เวลาดำเนินการ: ${end - start} ns")
    }
}

ในตัวอย่างด้านบน System.nanoTime() เป็นเมธอดเนทีฟซึ่งการเรียกถูกจัดส่งผ่าน ART runtime ไปยังเคอร์เนล Linux ART แปลงไบต์โค้ด Kotlin เป็นคำสั่ง ARM64 ที่ทำงานโดยโปรเซสเซอร์ของอุปกรณ์ กระบวนการนี้เกิดขึ้นอย่างโปร่งใสสำหรับนักพัฒนา แต่การปรับให้เหมาะสมเป็นงานสำคัญของทีม Android Platform

Profile-Guided Optimization (PGO)

Profile-guided optimization เป็นกลไกของ ART ที่รวบรวมโปรไฟล์การใช้งานเมธอด ไฟล์ profiles/.primary.prof มีรายการของ hot methods ที่ถูกคอมไพล์ AOT ตาม Android Performance Team PGO เร่งการเริ่มต้นแอปพลิเคชัน 15–30% หลังจากใช้งานหลายวันเมื่อโปรไฟล์ถูกสะสม

นักพัฒนาสามารถเปิดใช้งาน baseline profiles ในโปรเจกต์ Gradle ของตน สิ่งเหล่านี้เป็นคำอธิบายประกอบด้วยตนเองที่บอก ART ว่าเมธอดใดควรคอมไพล์ AOT ทันทีหลังจากติดตั้ง Baseline profiles ลดการเริ่มครั้งแรกลง 40% โดยไม่ต้องรอการสร้างโปรไฟล์พื้นหลัง

Objective-C Runtime บน iOS ทำงานอย่างไร

Objective-C Runtime คือไลบรารีไดนามิกที่ให้การทำงานของโค้ด Objective-C บน iOS และ macOS แกนกลางของมันคือฟังก์ชัน objc_msgSend ซึ่งใช้การส่งข้อความ: แทนที่จะเรียกเมธอดโดยตรง ออบเจ็กต์ส่งข้อความพร้อมตัวเลือก (selector) และ runtime กำหนดว่าการใช้งานใดควรทำงาน

แต่ละออบเจ็กต์ Objective-C มีพอยน์เตอร์ isa ไปยังคลาสของมัน และคลาสมี dispatch table ที่จับคู่ตัวเลือก (SEL) กับการใช้งาน (IMP) เมื่อเมธอดถูกเรียก objc_msgSend เดินทางตามลำดับโซ่: คลาส → คลาสแม่ → NSObject จนกว่าจะพบ IMP หากไม่พบการใช้งาน runtime จะเรียกกลไกการส่งต่อ (forwarding mechanism) ซึ่งสามารถสกัดกั้นข้อความหรือสร้างข้อยกเว้น

Objective-C Runtime ยังรองรับ method swizzling — การแทนที่ IMP ของตัวเลือกที่มีอยู่ในขณะทำงาน นี่เป็นกลไกที่ทรงพลังที่ใช้ในไลบรารี AOP และเครื่องมือตรวจสอบ แต่ต้องใช้ความระมัดระวังเนื่องจากผลกระทบต่อทั้งแอปพลิเคชัน

@interface RuntimeDemo : NSObject
- (void)printClassInfo;
@end

@implementation RuntimeDemo
- (void)printClassInfo {
    // objc_getClass — ฟังก์ชัน runtime
    Class cls = objc_getClass("RuntimeDemo");
    unsigned int count;
    Method *methods = class_copyMethodList(cls, &count);
    NSLog("จำนวนเมธอด: %d", count);
}
@end

โค้ดแสดงการเข้าถึงโดยตรงไปยัง Objective-C Runtime API: objc_getClass รับออบเจ็กต์คลาสตามชื่อ class_copyMethodList ดึงรายการของเมธอดทั้งหมด นี่คือ reflection ในการทำงาน — การเข้าถึงเมทาดาทาของคลาสในขณะทำงาน แนวทางนี้ใช้ใน XCTest สำหรับการลงทะเบียนทดสอบแบบไดนามิก

พอยน์เตอร์ isa และ tagged pointers

พอยน์เตอร์ isa คือพอยน์เตอร์ไปยังคลาสของออบเจ็กต์ที่เก็บไว้ใน 8 ไบต์แรกของแต่ละออบเจ็กต์ ตั้งแต่ iOS 12 Apple ได้นำ isa-swizzling มาใช้เพื่อการปรับให้เหมาะสม: บิตล่างของ isa เข้ารหัสข้อมูลเพิ่มเติมเกี่ยวกับสถานะของออบเจ็กต์ Tagged pointers เป็นการปรับให้เหมาะสมอีกแบบหนึ่งที่ค่าสูงถึง 60 บิต (NSNumber, NSDate) ถูกเก็บไว้โดยตรงในพอยน์เตอร์ โดยไม่ต้องจัดสรรออบเจ็กต์ในฮีป สิ่งนี้ลดภาระของตัวจัดการหน่วยความจำลง 30%

การคอมไพล์ JIT vs AOT: เปรียบเทียบแนวทาง

JIT (Just-In-Time) และ AOT (Ahead-Of-Time) เป็นสองแนวทางในการคอมไพล์ไบต์โค้ดเป็นโค้ดเครื่อง JIT คอมไพล์โค้ดระหว่างการทำงานของแอปพลิเคชัน วิเคราะห์จุดร้อนและปรับให้เหมาะสมทันที AOT คอมไพล์โค้ดทั้งหมดล่วงหน้า — ระหว่างการติดตั้งแอปพลิเคชันหรือฝั่งนักพัฒนา

แนวทางผสมของ ART (Android 7+) ถือว่าเหมาะสมที่สุด: แอปพลิเคชันใช้ตัวแปลสำหรับเมธอดที่ถูกเรียกน้อย JIT สำหรับ hot methods และ AOT สำหรับเมธอดจาก profile-guided optimization iOS ในทางตรงกันข้าม ใช้ AOT ที่เข้มงวดผ่าน LLVM: Swift และ Objective-C ถูกคอมไพล์เป็นโค้ดเครื่องในขั้นตอนการสร้างใน Xcode

ตาม Apple Developer Documentation, 2024 Swift runtime เพิ่มประมาณ 15 MB ให้กับขนาดแอปพลิเคชัน Flutter ใช้ Dart VM ของตัวเอง โดยที่การคอมไพล์ JIT ทำงานในโหมดดีบักสำหรับ hot reload และ AOT ในโหมดรีลีสสำหรับประสิทธิภาพสูงสุด React Native ใช้ Hermes — เครื่องยนต์ JavaScript พร้อมการคอมไพล์ AOT ที่ลดเวลาเริ่มต้นลง 50%

ARM64 Runtime และโค้ดเครื่อง

ARM64 Runtime คือระดับที่โค้ดเครื่องโต้ตอบกับโปรเซสเซอร์ของอุปกรณ์ อุปกรณ์มือถือสมัยใหม่ส่วนใหญ่ทำงานบนโปรเซสเซอร์ ARM64 (aarch64) Runtime แปลไบต์โค้ดหรือการเรียกเนทีฟเป็นคำสั่ง ARM64 ที่ CPU ทำงาน

รีจิสเตอร์ ARM64 หลักที่ใช้โดย runtime: x0–x7 (พารามิเตอร์ฟังก์ชัน), x8 (ผลลัพธ์ทางอ้อม), x30 (ที่อยู่ส่งกลับ), sp (พอยน์เตอร์สแต็ก), fp (พอยน์เตอร์เฟรม) ART สร้างโค้ดที่ปฏิบัติตาม ARM64 Procedure Call Standard: การเรียกเมธอดทั้งหมดผ่านโปรโตคอลที่กำหนดโดยสถาปัตยกรรมโปรเซสเซอร์

การเข้าใจ ARM64 ABI สำคัญสำหรับการปรับให้เหมาะสมด้านประสิทธิภาพ: inline caching, branch prediction และการจัดตำแหน่งโค้ดในหน่วยความจำส่งผลโดยตรงต่อความเร็วของ runtime เครื่องมือสร้างโปรไฟล์ (Android Studio Profiler, Instruments) แสดงว่าส่วนโค้ดใดใช้เวลามากที่สุดใน runtime — การปรับให้เหมาะสมกับส่วนเหล่านี้ให้การปรับปรุงมากที่สุด

// ตัวอย่าง ARM64 assembly ที่สร้างโดย ART
// การเรียกเมธอดที่มีสองพารามิเตอร์

mov    x0, x23            // self (this)
mov    x1, x24            // param1
mov    x2, x25            // param2
bl     methodEntryPoint   // เรียกผ่าน runtime
str    x0, [sp, #8]      // บันทึกผลลัพธ์

ในตัวอย่างนี้ คำสั่ง ARM64 mov ส่งอาร์กิวเมนต์ไปยังรีจิสเตอร์ x0–x2 bl เรียกจุดเริ่มต้นของเมธอด และ str เก็บค่าส่งกลับ Runtime สร้างคำสั่งดังกล่าวสำหรับทุกการเรียกเมธอด ปรับลำดับให้เหมาะสมผ่าน devirtualization และ inlining

ผลกระทบของ runtime ต่อประสิทธิภาพ

Runtime โอเวอร์เฮด คือราคาที่หลีกเลี่ยงไม่ได้ของการจัดส่งแบบไดนามิก แต่ละการเรียกเมธอดผ่าน runtime ต้องการ: ค้นหาการใช้งานใน dispatch table, ตรวจสอบชนิด, เรียก IMP และส่งคืนผลลัพธ์ การวัดแสดงว่า runtime เพิ่ม 10–50 ns ต่อการเรียกใน Objective-C และ 5–20 ns ใน ART

เพื่อลดโอเวอร์เฮด นักพัฒนาใช้ monomorphic inlining (ART) และ method caching (Objective-C) Kotlin/Native และ Swift คอมไพล์ตรงไปยัง ARM64 กำจัดชั้น runtime โดยสมบูรณ์ แต่สูญเสียความสามารถแบบไดนามิก — reflection, swizzling, การโหลดคลาสแบบไดนามิก