เนื้อหานี้มีความ Geek สูง ไม่เหมาะกับผู้ใช้แอนดรอยด์ทั่วๆไป เพราะนี่คือเบื้องหลังการทำงานของ Android OS ที่อยู่ในฝั่งของนักพัฒนา ดังนั้นอย่าแปลกใจถ้าอ่านเนื้อหานี้แล้วไม่เข้าใจ แต่ถ้าผู้อ่านอยากจะรู้ว่าจริงๆแล้วเบื้องหลังของแอนดรอยด์นั้นเป็นยังไงบ้าง ขอแนะนำให้ลองอ่านดูครับ ผมพยายามเขียนให้ผู้อ่านทั่วๆไปเข้าใจได้ง่ายมากที่สุดเท่าที่ทำได้แล้วนะ

Runtime คือหัวใจสำคัญในการทำงานของ Android OS

แอนดรอยด์นั้นถูกออกแบบมาให้ทำงานในลักษณะของ Virtual Machine ซึ่งทุกวันนี้นักพัฒนาแอนดรอยด์ต่างเขียนแอปพลิเคชันขึ้นมาด้วยภาษา Java หรือ Kotlin แต่ว่าภาษาเหล่านั้นไม่ได้ถูกนำไปใช้งานได้ทันที

เพราะจริงๆแล้วการที่ Android จะเอาโค้ดที่นักพัฒนาเขียนขึ้นมาไปเรียกใช้งานได้นั้นจะต้องผ่านขั้นตอนการแปลงโค้ดที่เขียนด้วยภาษาขั้นสูงให้กลายเป็นภาษาที่ Android OS เข้าใจเสียก่อน ซึ่งเป็นขั้นตอนการแปลงโค้ดให้กลายเป็นสิ่งที่เรียกว่า Bytecode นั่นเอง

ภาพแสดงการแปลงโค้ด Java ให้กลายเป็น APK ที่ใช้ติดตั้งในอุปกรณ์แอนดรอยด์

ถ้าดูจากภาพข้างบนก็จะเห็นว่าโค้ดที่นักพัฒนาเขียนขึ้นมานั้นอยู่ในรูปของไฟล์ .java (ถ้าเขียนด้วยภาษา Kotlin จะเป็น .kt) ซึ่งโค้ดดังกล่าวจะถูกแปลงให้เป็น .class แทน แล้วเอาไฟล์ .class ทั้งหมดที่นักพัฒนาเขียนขึ้นมารวมกันเพื่อทำเป็นไฟล์ที่มีชื่อว่า .dex และสุดท้ายก็จะถูกยัดไว้ในไฟล์ APK รวมกับไฟล์อื่นๆนั่นเอง

ถ้าผู้อ่านคนไหนเคยลองแงะไฟล์ APK ก็จะพบว่ามี .dex อยู่ด้วย นั่นล่ะครับ โค้ดที่นักพัฒนาเขียนไว้มันอยู่ในไฟล์นั้นแหละ

เมื่อไฟล์ APK ติดตั้งลงในเครื่องและผู้ใช้กดเปิดแอปขึ้นมา ซึ่งที่เกิดขึ้นใน Android OS ก็คือจะต้องมีคนเปิดไฟล์ .dex แล้วทำคำสั่งต่างๆที่อยู่ในนั้นตามที่นักพัฒนาเขียนไว้ ซึ่งเราจะเรียกกันว่า Runtime นั่นเอง ซึ่งเป็นรูปแบบการทำงานที่ผู้สร้างแอนดรอยด์เป็นคนออกแบบไว้ตั้งแต่ตอนแรก และเจ้า Runtime ที่เลือกใช้ในแอนดรอยด์นั้นมีชื่อว่า Dalvik นั่นเอง

รูปแบบการทำงานนี้จะคล้ายๆกับโปรแกรมที่เขียนขึ้นมาด้วยภาษา Java ที่จะต้องมี Runtime คอยเป็นคนอ่านโค้ดและทำงานตามคำสั่งต่างๆ แต่ของ Java เดิมจะใช้เป็น JVM

สาเหตุที่แอนดรอยด์เลือกใช้ Dalvik แทนที่จะเป็น JVM ก็เพราะว่า JVM นั้นใช้ทรัพยากรเยอะเกินไปสำหรับอุปกรณ์แอนดรอยด์ในยุคนั้น

ภาพเปรียบเทียบการแปลงโค้ดระหว่าง Java ทั่วไปกับ Java ในแอนดรอยด์

จากรูปจะเห็นว่าใน Java แบบเดิมๆนั้นจะแปลงโค้ด Java ให้อยู่ในรูปของ Java Bytecode แล้วนำไปใช้งานทันที แต่สำหรับแอนดรอยด์นั้นจะนำ Java Bytecode ไปแปลงเป็น Dalvik Bytecode อีกทีก่อน ถึงจะนำไปใช้งานได้

แต่ Dalvik Bytecode ก็ยังไม่ใช่ภาษาที่ Android OS เข้าใจทันทีนะ แค่เป็นการแปลงจากโค้ดในภาษาขั้นสูงให้กลายเป็นโค้ดที่ใกล้เคียงกับที่ Android OS ทำงานนั่นเอง ดังนั้น Runtime จะต้องทำหน้าที่แปลง Bytecode ให้กลายเป็น Machine Code หรือ Binary อีกทีหนึ่ง

โดย Dalvik จะยังไม่ทำการแปลง Bytecode ให้กลายเป็น Binary ทันทีหรอกนะ มันเสียเวลาเกินไป ดังนั้นการทำงานของ Dalvik จึงเป็นรูปแบบของ Just-in-time Compile (เรียกกันสั้นๆว่า JIT) ซึ่งเป็นการอ่าน Bytecode เฉพาะส่วนที่ถูกเรียกใช้งาน ณ ตอนนั้น แล้วแปลง (Compile) ​โค้ดส่วนนั้นให้กลายเป็น Binary เพื่อให้ Android OS ทำงานตามคำสั่ง (Execute) ในทันที

ดังนั้น Dalvik จึงเปรียบเสมือนหัวใจสำคัญที่ทำให้แอปต่างๆในแอนดรอยด์สามารถทำงานได้ตามที่นักพัฒนาได้สร้างสรรค์ไว้นั่นเอง

การทำงานของ Dalvik นั้นดีมาก… สำหรับ 5 ปีที่แล้ว..

หลังจากที่แอนดรอยด์กลายเป็น OS ยอดนิยมและมีการพัฒนาขึ้นเรื่อยๆ ไม่ว่าจะเป็นขนาดหน้าจอที่คมชัดมากขึ้นเรื่อยๆ, หน่วยประมวลผลที่แรงขึ้นทุกๆปี, RAM ที่เยอะมากๆ และพื้นที่เก็บข้อมูลที่ให้มาเหลือเฟือกว่าเมื่อก่อน

กลายเป็นว่า Dalvik นั้นเป็นคอขวดสำหรับทรัพยากรเครื่องที่เพิ่มมากขึ้นเรื่อยๆ เพราะว่าไม่จำเป็นต้องทำงานอย่างจำกัดจำเขี่ยอีกต่อไป แถม Dalvik ก็ไม่เอื้ออำนวยกับการเติบโตของแอปในอนาคตอีกด้วย

ใครจะไปรู้ล่ะว่าวันข้างหน้าแอปมือถือจะทำอะไรได้บ้าง จากเดิมที่แอปตัวนึงมีขนาดไม่ถึง 10MB แต่ทุกวันนี้กลับกลายเป็น 30MB++ ที่เต็มไปด้วยฟีเจอร์มากมาย ลองนึกถึงฟีเจอร์และลูกเล่นต่างๆใน Facebook กับ LINE เมื่อ 5 ปีก่อนดูสิ

ถือกำเนิด ART ที่ Google พัฒนาขึ้นมาเอง

ART หรือชื่อเต็มๆคือ Android Runtime เป็น Runtime ตัวใหม่ที่ทาง Google สร้างขึ้นมาแทนที่ Dalvik เพื่อให้ปูทางให้กับแอปต่างๆในอนาคต ซึ่งถูกนำมาใช้งานตั้งแต่สมัย Android 5.0 Lollipop

ในสมัยนั้นที่อยู่ในช่วงเปลี่ยนผ่านระหว่าง Dalvik ไปเป็น ART ก็ได้เกิดคำถามต่างๆมากมายจากผู้ใช้ว่าจะเปลี่ยนไปเป็น ART ทำไม ในเมื่อเปลี่ยนไปก็ไม่เห็นความแตกต่าง แต่ในมุมมองของนักพัฒนานั้นการเปลี่ยนครั้งใหญ่นี้ถือว่าเป็นเรื่องสำคัญมาก เพราะมันส่งผลกับนักพัฒนามาจนถึงทุกวันนี้

ยกตัวอย่างเช่น ในสมัยที่ยังใช้ Dalvik อยู่ โค้ด .java ทั้งหมดที่นักพัฒนาเขียนขึ้นมานั้นจะถูกแปลงให้เป็นไฟล์ .dex เพียงไฟล์เดียวเท่านั้น และไฟล์ .dex ที่ว่านั้นก็ดันเก็บชุดคำสั่ง (Method) ไว้ได้สูงสุดแค่ 65,536 ชุดคำสั่งเท่านั้น

ถ้านักพัฒนาเขียนโค้ดเกิน 65,536 ชุดคำสั่ง อาจจะทำให้เกิดปัญหาเมื่อทำงานบน Dalvik ได้ (ในปัจจุบันมีวิธีแก้ปัญหาดังกล่าวแล้ว แต่ก็ไม่ได้สมบูรณ์มากนัก)

แต่ ART นั้นถูกออกแบบมาให้ทำงานกับ .dex ได้มากกว่า 1 ไฟล์ได้ ดังนั้นต่อให้นักพัฒนาเขียนโค้ดเยอะมากแค่ไหนมันก็จะกลายเป็น .dex หลายๆไฟล์และทำงานได้ปกติสุขบน ART นั่นเอง

แล้ว 65,536 ชุดคำสั่งนี่มันต้องเป็นแอปประมาณไหน?

ถ้าลองหยิบแอปในตลาดบ้านเรามาทดสอบดูก็จะได้ออกมาประมาณนี้ (ทดสอบเมื่อวันที่ 02/01/2019)

  • 7-Eleven : 75,129
  • AirPay : 122,161
  • BTS Skytrain : 71,638
  • DTAC : 200,745
  • Facebook Lite : 478
  • Facebook : 664,605
  • Joox : 288,311
  • K+ : 122,161
  • Lazada : 165,083
  • LINE : 432,842
  • LINE Mobile : 66,842
  • Netflix : 124,686
  • NU Mobile : 45,394
  • QueQ : 51,928
  • SCB Easy : 318,776
  • Shopee : 200,346
  • Twitter : 258,083
  • Twitter Lite : 10,174
  • VSCO : 124,493
  • Wongnai : 116,078
  • YouTube : 189,116

จะเห็นว่าแอปส่วนใหญ่นั้นทะลุเกิน 65,536 ชุดคำสั่งอย่างง่ายดาย ด้วยฟีเจอร์และลูกเล่นของแอนดรอยด์ในเวอร์ชันใหม่ๆที่เพิ่มเข้ามามากมาย จึงเป็นเรื่องธรรมดาที่แอปส่วนใหญ่นั้นจะมีจำนวนชุดคำสั่งเกินที่ Dalvik จะรับไหว

เรียกได้ว่า ถ้าไม่เปลี่ยนมาเป็น ART ตั้งแต่เนิ่นๆในสมัยนั้น การพัฒนาแอปสมัยนี้ก็คงไม่มีลูกเล่นหวือหวามากเท่านี้ก็ว่าได้

ความสามารถเบื้องต้นของ ART

หลักๆเลยคือแก้ปัญหาการทำงานแบบ JIT Compile ของ Dalvik ให้กลายเป็น AOT Compile (Ahead-of-time Compile) แทน ซึ่ง ART จะทำการแปลง Bytecode ให้กลายเป็น Binary (Machine Code) ตั้งแต่ตอนติดตั้งแอปลงในเครื่องแทน ดังนั้นเวลาที่แอปทำงานก็ไม่ต้องเสียเวลาแปลงโค้ดเหมือนตอน Dalvik อีกต่อไปแล้ว

ภาพเปรียบเทียบการแปลงโค้ดใน Dalvik กับ ART

ซึ่งทีมงานเคลมว่าการเปลี่ยนรูปแบบการทำงานนี้จะช่วยให้แอปทำงานได้เร็วขึ้นกว่าเดิมประมาณ 20 เท่าเลยล่ะ

และนอกจากนี้ยังรองรับการทำงานของ CPU ที่เป็นแบบ 64-bit ด้วย จากเดิมที่ Dalvik ไม่ได้รองรับ (เป็นผมก็คงนึกไม่ถึงหรอกว่าในอนาคต CPU บนมือถือมันจะเปลี่ยนมาเป็น 64-bit ทั้งหมดแบบนี้)

รวมไปถึงการทำงานของ Garbage Collector (GC) ที่คอยจัดการกับข้อมูลใน Memory ที่ไม่ได้ใช้งานแล้ว (เวลาที่เครื่องมี Memory ไม่พอต่อการใช้งาน เจ้า GC ก็จะออกล่าหาข้อมูลใน Memory ที่ไม่ได้ถูกเรียกใช้งานแล้วเพื่อกำจัดทิ้ง เพื่อให้มีพื้นที่ว่างใน Memory เพียงพอต่อการทำงาน ณ ตอนนั้น) ก็ถูกปรับปรุงใหม่เพื่อให้ทำงานได้ดีขึ้น รบกวนการทำงานในส่วนแสดงผล (UI) ให้น้อยลง เพราะว่าการทำงานใน GC ของเดิมที่อยู่บน Dalvik นั้นก็เป็นอีกหนึ่งปัญหาที่ทำให้แอปกระตุกหรือค้าง ถึงแม้ว่าปัญหาส่วนใหญ่จะมาจากนักพัฒนาที่เขียนโค้ดไม่ค่อยดีก็ตาม แต่ส่วนหนึ่งก็มาจากการที่ GC ทำงานได้ไม่ดีพอเช่นกัน

การพัฒนาของ ART ไม่ได้จบเพียงแค่นี้

เพราะว่า ART ที่เพิ่มเข้ามาใหม่ใน Lollipop นั้นก็ไม่ได้ทำงานได้อย่างสมบูรณ์แบบซักเท่าไร จะเรียกว่าหนีปัญหาของ Dalvik มาเจอปัญหาของ ART แทนก็ว่าได้ ดังนั้นทีม Google จึงมีการปรับปรุงการทำงานของ ART ให้ดีขึ้นเรื่อยๆเมื่อมีแอนดรอยด์เวอร์ชันใหม่ๆ

การเปลี่ยนแปลงที่สำคัญของ ART ในแต่ละเวอร์ชันจะมีดังนี้

ART ใน Lollipop

  • AOT Compilation
  • Generational GC

อย่างที่อธิบายไปก่อนหน้านี้ถึงความสามารถเบื้องต้นของ ART ที่ถูกแทนที่ Dalvik ใน Android 5.0 Lollipop

และด้วยการทำงานแบบ AOT Compile ที่จะทำการแปลงโค้ดให้กลายเป็น Binary เตรียมไว้ตั้งแต่ตอนติดตั้งแอปลงในเครื่อง จึงทำให้ขนาดของแอปเมื่อติดตั้งลงในเครื่องมีขนาดใหญ่ขึ้นไปด้วย (ใช้พื้นที่ติดตั้งเยอะกว่าขนาดไฟล์ที่ดาวน์โหลดพอสมควร) รวมไปถึงระยะเวลาในการติดตั้งก็นานมากขึ้นด้วย

ถ้าผู้อ่านเคยอยู่ในยุค Android 5.0 Lollipop ก็น่าจะคุ้นเคยความรู้สึกนี้กันเป็นอย่างดี

ART ในยุคแรกจะต้องมีการ Optimizing App ทุกครั้งที่มีการอัพเดทเฟิร์มแวร์ ถึงแม้ว่าจะเป็นแค่อัพเดทเล็กๆน้อยๆเท่านั้น (บอกเลยว่ารอนานมากกกกกก)

นั่นก็เพราะว่าการทำงานของ Android OS ทั้งหมดในตอนนั้นเป็นแบบ AOT Compile แม้กระทั่งตอน Boot ด้วยเช่นกัน จึงทำให้ ART เสียเวลาแปลงโค้ดที่มีการเปลี่ยนแปลงไปซะทุกอย่าง

ART ใน Nougat/Oreo

  • Profile-guided compilation
  • Concurrent GC
  • JIT on first use

การเปลี่ยนแปลงครั้งใหญ่ของ ART ในเวอร์ชันนี้การแก้ปัญหา ART ใน Lollipop ด้วยสิ่งที่เรียกว่า Profile-guided compilation ซึ่งเป็นหัวใจสำคัญในการทำงานของ ART มาจนถึงปัจจุบันนี้เลยก็ว่าได้

JIT ก็ทำงานช้าเกิน กิน CPU และเปลืองแบตเตอรี ส่วน AOT ก็ใช้พื้นที่เครื่องเยอะ และใช้เวลาติดตั้งนานแทน

ถ้าแบบนั้นก็เอา JIT และ AOT มาใช้ร่วมกันไปเลยสิ!! จึงทำให้การแปลงโค้ดให้กลายเป็น Binary ของ ART ตั้งแต่ Android 7.0 Nougat จนถึงปัจจุบันนี้จึงกลายเป็นแบบไฮบริดที่ผสมกันระหว่าง JIT กับ AOT นั่นเอง

ในตอนที่ผู้ใช้ดาวน์โหลดแอปมาติดตั้งลงในเครื่อง ART จะไม่แปลงโค้ดในทันที และเมื่อผู้ใช้เปิดแอปขึ้นมาครั้งแรก ART จะทำงานเป็น JIT ทั้งหมดเพื่อจดจำว่าโค้ดตรงไหนเป็นการทำงานสำคัญของแอปนั้นๆ แล้วสร้างเป็น Profile เก็บไว้ เมื่อผู้ใช้ไม่ได้ใช้งานและชาร์จทิ้งไว้ (มักจะเป็นตอนกลางคืนที่ผู้ใช้นอนหลับเนอะ) เจ้า ART ก็จะแอบแปลงโค้ดเฉพาะส่วนนั้นให้กลายเป็น Binary ซะ เพื่อที่แอปจะได้ทำงานเร็วขึ้นเมื่อใช้งานในครั้งต่อไป จากนั้นก็จะจดจำโค้ดใหม่เพื่อดูว่ายังมีตรงไหนที่สำคัญอีก จะได้แอบแปลงโค้ดในโอกาสถัดไป

ภาพอธิบายการทำงานของ Profile-guided compilation

ซึ่ง ART จะแอบแปลงโค้ดเฉพาะจุดสำคัญล่วงหน้าไว้เรื่อยๆจนกว่าจะครบ ซึ่งจะอยู่ที่ประมาณ 10%-20% ของทั้งหมด ดังนั้นโค้ดที่เหลือก็คือโค้ดที่จะไม่ถูกแปลงและทำงานแบบ JIT เหมือนเดิมนั่นเอง (ไม่ค่อยได้ใช้ก็เสียเวลาแปลงโค้ดทีหลังดีกว่า จะได้ไม่เปลืองพื้นที่เครื่องโดยใช่เหตุ) ซึ่งเป็นที่มาว่าทำไมเมื่อติดตั้งแอปไปซักพักแล้วมันใช้พื้นที่เยอะขึ้น เพื่อแลกกับ Startup Time ที่เร็วขึ้นกว่าเดิม

กราฟเปรียบเทียบระยะเวลาที่ใช้ในการเปิดแอป Google Maps ในแต่ละเวอร์ชันเมื่อมีการใช้งานระยะเวลาหนึ่ง

จากข้อมูลกราฟของ Google Maps จะเห็นว่าในเวอร์ชัน 9.69 ที่ตอนแรกใช้เวลาเปิดแอปนานเกือบ 1 วินาที แต่เมื่อใช้งานไปซักพักก็จะใช้เวลาเปิดแอปลดลงจนเกือบจะถึง 0.75 วินาที

และเมื่อ Profile-guided compilation ช่วยลดระยะเวลาในเริ่มทำงานของแอปได้ ดังนั้นหน้าต่าง Optimizing App ใน Lollipop ที่น่ารำคาญจึงหายไปนั่นเอง เพราะแทนที่จะให้ผู้ใช้รอตอนเปิดเครื่อง ก็ใช้การทำงานแบบ JIT ก่อนดีกว่า แล้วค่อยแอบ Optimizing App ทีหลังตอนที่มือถือไม่ได้ใช้งานก็ได้

นอกจากนี้ยังมี Concurrent GC ที่จะช่วยลดข้อมูลที่อยู่กระจัดกระจายใน Memory ให้น้อยลงกว่า GC แบบเก่าได้อีกด้วย

ART ใน Pie

  • Compact Dex
  • Uncompressed Dex
  • Profiles in cloud

การมาของ Android 9.0 Pie นั้นเป็นช่วงเดียวกับที่ Google มีโปรเจค Android Go จึงทำให้ทีม Google เริ่มเน้นไปที่การประหยัดพื้นที่และ Memory ในเครื่องเพื่อให้ทำงานบน Android Go ที่มี RAM แค่ 512MB และ ROM แค่ 4-8GB ได้

จึงได้มีการพัฒนาไฟล์ Dex แบบใหม่ที่เรียกว่า Compact Dex ขึ้นมา ซึ่งใช้ Memory น้อยกว่า Dex แบบเก่า เพราะว่ามีจำนวนโค้ดที่น้อยลงแต่ยังมีสามารถทำงานได้เหมือนเดิม

กราฟเปรียบเทียบประสิทธิภาพในการทำงานของ Dalvik และ ART ในแอนดรอยด์แต่ละเวอร์ชัน โดยทดสอบด้วยการทำงานต่างๆบน Google Sheets บน Nexus 5

อีกทั้งยังพัฒนาให้ไฟล์ Dex ไม่จำเป็นต้อง Compressed (บีบอัดไฟล์) เพื่อให้มีขนาดเล็กอีกต่อไป เพราะของเดิมนั้นจะนำไฟล์ Dex ที่ได้จากการแปลงโค้ด Java มาบีบอัดอีกทีเพื่อให้ได้ขนาดไฟล์ที่เล็กลง ทำให้ตอนที่นำไปใช้งานจริง ก็จะต้องเสียเวลา Uncompressed (คลายไฟล์ที่ถูกบีบอัดไว้) ออกมาก่อนที่จะเรียกใช้งาน

และด้วยการทำงานของ Profile-guided compilation จึงทำให้ ART แอบ Uncompressed ข้อมูลในไฟล์ Dex ออกมาเตรียมไว้บางส่วน ทำให้ใช้พื้นที่ในเครื่องเยอะมากขึ้น เพราะต้องเก็บทั้ง Dex ต้นฉบับที่ Compressed และ Dex ที่แอบ Uncompressed ทิ้งไว้ ดังนั้นการทำ Uncompressed Dex ตั้งแต่แรกจึงช่วยลดการใช้พื้นที่ในเครื่องให้น้อยลงไปได้

นอกจากนี้ใน Android 9.0 Pie ยังมี Profiles in cloud ที่จะรวบรวมข้อมูลที่ได้จาก Profile-guided compilation ของอุปกรณ์ที่อยู่ใน Ecosystem ทั้งหมดเพื่อที่จะได้ส่งข้อมูลให้กับผู้ใช้งานคนใหม่ในตอนติดตั้งแอปบนเครื่องนั้นๆ ซึ่งจะช่วยให้เครื่องของผู้ใช้คนนั้นสามารถเปิดแอปที่ความเร็วสูงสุดเลย ไม่ต้องรอให้ Profile-guided compilation ทำงานอีกต่อไป

ยังชื่อ ART เหมือนเดิม แต่เพิ่มเติมด้วยการทำงานที่ดีขึ้น

นับจากสมัย Android 5.0 Lollipop ที่ทีม Google ได้นำ ART มาใช้งานจริงหลังจากซุ่มพัฒนามาอยู่หลายปีและได้พัฒนาความสามารถขึ้นเรื่อยๆ ถึงแม้ว่าผู้ใช้งานจะไม่ค่อยรู้สึกถึงความเปลี่ยนแปลงซักเท่าไร เพราะไม่ได้เห็นผลจากความเร็วในการใช้งานได้โดยตรง แต่การพัฒนาของ ART นี้จะส่งผลทั้งเรื่องการใช้ Memory, การใช้แบตเตอรี และการใช้พื้นที่ในเครื่องด้วย ซึ่งเป็นหัวใจสำคัญที่จะสามารถรองรับกับความสามารถใหม่ๆของแอนดรอยด์และการทำงานแอปพลิเคชันในอนาคต

จริงๆแล้วยังมีรายละเอียดปลีกย่อยของ ART ในแต่ละเวอร์ชันอีกมากมาย อันนี้ผมหยิบเฉพาะส่วนที่สำคัญๆมาเล่าเท่านั้น เพื่อให้ผู้อ่านได้เข้าใจภาพรวมของการทำงานและการเปลี่ยนแปลงของ ART ที่เป็นหัวใจสำคัญในการทำงานของ Android OS ทุกวันนี้ครับ 😉

แหล่งข้อมูลอ้างอิง

รู้จัก ART รันไทม์ตัวใหม่ของ Android L ที่จะถูกใช้แทน Dalvik, ประสิทธิภาพดีกว่าเดิม

ทำความรู้จัก ART ผู้มาแทน Dalvik บน Android “L”

Deep Dive into the ART Runtime (Android Dev Summit ’18)