เนื้อหานี้มีความ Geek สูง ไม่เหมาะกับผู้ใช้แอนดรอยด์ทั่วๆไป เพราะนี่คือเบื้องหลังการทำงานของ Android OS ที่อยู่ในฝั่งของนักพัฒนา ดังนั้นอย่าแปลกใจถ้าอ่านเนื้อหานี้แล้วไม่เข้าใจ แต่ถ้าผู้อ่านอยากจะรู้ว่าจริงๆแล้วเบื้องหลังของแอนดรอยด์นั้นเป็นยังไงบ้าง ขอแนะนำให้ลองอ่านดูครับ ผมพยายามเขียนให้ผู้อ่านทั่วๆไปเข้าใจได้ง่ายมากที่สุดเท่าที่ทำได้แล้วนะ
Runtime คือหัวใจสำคัญในการทำงานของ Android OS
แอนดรอยด์นั้นถูกออกแบบมาให้ทำงานในลักษณะของ Virtual Machine ซึ่งทุกวันนี้นักพัฒนาแอนดรอยด์ต่างเขียนแอปพลิเคชันขึ้นมาด้วยภาษา Java หรือ Kotlin แต่ว่าภาษาเหล่านั้นไม่ได้ถูกนำไปใช้งานได้ทันที
เพราะจริงๆแล้วการที่ Android จะเอาโค้ดที่นักพัฒนาเขียนขึ้นมาไปเรียกใช้งานได้นั้นจะต้องผ่านขั้นตอนการแปลงโค้ดที่เขียนด้วยภาษาขั้นสูงให้กลายเป็นภาษาที่ Android OS เข้าใจเสียก่อน ซึ่งเป็นขั้นตอนการแปลงโค้ดให้กลายเป็นสิ่งที่เรียกว่า Bytecode นั่นเอง
![](https://images.droidsans.com/wp-content/uploads/2019/01/evolution_of_art_in_android-001-1024x281.jpg)
ภาพแสดงการแปลงโค้ด 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 นั้นใช้ทรัพยากรเยอะเกินไปสำหรับอุปกรณ์แอนดรอยด์ในยุคนั้น
![](https://images.droidsans.com/wp-content/uploads/2019/01/evolution_of_art_in_android-002-1024x303.jpg)
ภาพเปรียบเทียบการแปลงโค้ดระหว่าง 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 อีกต่อไปแล้ว
![](https://images.droidsans.com/wp-content/uploads/2019/01/evolution_of_art_in_android-003-1024x295.jpg)
ภาพเปรียบเทียบการแปลงโค้ดใน 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 ซะ เพื่อที่แอปจะได้ทำงานเร็วขึ้นเมื่อใช้งานในครั้งต่อไป จากนั้นก็จะจดจำโค้ดใหม่เพื่อดูว่ายังมีตรงไหนที่สำคัญอีก จะได้แอบแปลงโค้ดในโอกาสถัดไป
![](https://images.droidsans.com/wp-content/uploads/2019/01/evolution_of_art_in_android-005-1024x551.jpg)
ภาพอธิบายการทำงานของ Profile-guided compilation
ซึ่ง ART จะแอบแปลงโค้ดเฉพาะจุดสำคัญล่วงหน้าไว้เรื่อยๆจนกว่าจะครบ ซึ่งจะอยู่ที่ประมาณ 10%-20% ของทั้งหมด ดังนั้นโค้ดที่เหลือก็คือโค้ดที่จะไม่ถูกแปลงและทำงานแบบ JIT เหมือนเดิมนั่นเอง (ไม่ค่อยได้ใช้ก็เสียเวลาแปลงโค้ดทีหลังดีกว่า จะได้ไม่เปลืองพื้นที่เครื่องโดยใช่เหตุ) ซึ่งเป็นที่มาว่าทำไมเมื่อติดตั้งแอปไปซักพักแล้วมันใช้พื้นที่เยอะขึ้น เพื่อแลกกับ Startup Time ที่เร็วขึ้นกว่าเดิม
![](https://images.droidsans.com/wp-content/uploads/2019/01/evolution_of_art_in_android-006-1024x512.jpg)
กราฟเปรียบเทียบระยะเวลาที่ใช้ในการเปิดแอป 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 แบบเก่า เพราะว่ามีจำนวนโค้ดที่น้อยลงแต่ยังมีสามารถทำงานได้เหมือนเดิม
![](https://images.droidsans.com/wp-content/uploads/2019/01/evolution_of_art_in_android-007-1024x523.jpg)
กราฟเปรียบเทียบประสิทธิภาพในการทำงานของ 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)
ขอบคุณมากครับ ไม่ได้เป็นDev แต่อ่านแล้วเพลินดีครับ
อ่านแล้วรู้เลยว่าทำไมใช้ไปนาน ๆ ข้อมูลมันบวมขึ้นจนเมมเครื่องเต็ม
"และด้วยการทำงานของ Profile-guided compilation จึงทำให้ ART แอบ Uncompressed ข้อมูลในไฟล์ Dex ออกมาเตรียมไว้บางส่วน ทำให้ใช้พื้นที่ในเครื่องเยอะมากขึ้น เพราะต้องเก็บทั้ง Dex ต้นฉบับที่ Compressed และ Dex ที่แอบ Uncompressed ทิ้งไว้ ดังนั้นการทำ Uncompressed Dex ตั้งแต่แรกจึงช่วยลดการใช้พื้นที่ในเครื่องให้น้อยลงไปได้"
ย่อหน้านี้ Uncompressed Dex ตั้งแต่แรก ความหมายคือใช้พื้นที่น้อยลงใช่ไหมครับ
ใช่ครับ ถึงแม้ว่า Uncompressed Dex จะมีขนาดใหญ่กว่า Compressed Dex ก็จริง แต่ของเดิมคือแอนดรอยด์เก็บไว้ทั้ง Compressed Dex และ Uncompressed Dex (ที่ได้จาก Profile-guided compilation) ทั้งคู่ครับ
ขอบคุณสำหรับข้อมูลครับ 😀
ดีครับที่กู๊กเกิ้ลพยายามพัฒนาตัวแอนดรอยด์ แต่ผมว่าปัญหาจริงๆก็คือเครื่องไม่ได้รับการอัพเดตเป็นเวอร์ชั่นใหม่ ถึงแม้จะมีโปรเจค Treble แต่มันก็ไม่ได้รับรองว่าเครื่องของเราจะได้อัพเดต
ผมมี Moto G รุ่นแรกอยู่ ตัวเครื่องยังใช้ได้ดีแต่เขาหยุดอัพเดตตั้งนานแล้ว…แม้แต่ตัวเดตด้านความปลอดภัยก็ไม่มี
ขอบคุณครับ
Moto G1 ได้รับ android version ยาวสูสีกับ nexus 4 เลยนะครับ แถม security patch ก็ยาวมาก
ผู้ผลิต คงวิเคราะห์มาแล้วว่าช่วงอายุของมือถือ ประมาณ 3 ปี เลยปล่อยไปเท่านั้น ไม่เหมือน windows ที่ต้องใช้กันยาวเป็นหลัก 10 ปี
ผมมองกลับกันนะ ว่า cpu 64bit น่าจะแพร่หลายกว่า เพราะมันเกิดมาในยุคที่มี 64bit แล้ว แถมโดน apple บังคับอีกว่าจะหยุด support 32bit ทำให้บ. ผลิตน่าจะเลือกพัฒนาแบบ 64 มาเลย
ต่างกับ windows อีกเช่นกันที่ทุกวันนี้ ยังเห็น windows 32bit เก่าๆ ใช้งานอยู่ในระบบปิดหลายๆ ที่
ขอบคุณสำหรับบทความครับ อธิบายเข้าใจง่ายมาก