ผ่านไปแล้วกับ Keynote งาน Google I/O 2014 ที่เปิดตัวอะไรมามากมายนักก็ไม่รู้ ก็มีอะไรน่าสนใจอยู่หลายอย่างนะ เช่น Material Design, Android TV และ ART (ที่เหลือเฉยๆกับมันมาก) ถึงเราจะมีส่วนที่เป็น Geek อยู่ก็ตาม แต่จากประสบการณ์งาน I/O ที่ผ่านๆมา สิ่งที่ประกาศไปเมื่อวาน คงอีกนานกว่าจะได้ใช้

สำหรับ Material Design ชอบตรงที่มันสวยและมี Guideline ที่ละเอียดชัดเจนมาก สามารถทำตามได้ทันที และการเลือกใช้สีก็สดใส ไม่หม่นหมองซีดเซียวเหมือน Holo ใน Android รุ่นที่ผ่านๆมา แต่อีกนัยหนึ่ง ... ยังไม่รู้เหมือนกันว่าเจ้า Material Design ที่เราสามารถกำหนดระดับชั้นได้และสร้างเงาขึ้นมาอัตโนมัตินั้น จะสามารถเอาไปใช้ใน Android รุ่นก่อนหน้าได้มั้ย? ถ้าไม่ได้ ก็แปลว่าต้องแยกเวอร์ชั่นอีกสิ หรือถ้าได้ ต้องทำท่าไหน ยากมั้ย? ... จะ Maintain โค้ดยังไง? สุดท้ายหากเตรียมมาไม่ดี Fragmentation ก็ยังเป็นอะไรที่น่าปวดหัวอยู่ดี

ยังไงก็ตาม Blog นี้ขอโฟกัสไปที่ส่วนที่เราว่ามันสำคัญต่อ Geek พอสมควรอย่าง ART ที่ถูกนำมาใช้แทนที่คุณปู่ Dalvik อย่างสมบูรณ์ใน Android "L" มาทำความรู้จักกันว่า ART ทำงานอย่างไร แตกต่างจาก Dalvik อย่างไร และดีขึ้นมากมายเพียงใด

ART vs Dalvik / AOT vs JIT

Dalvik เป็น Runtime ที่ถูกใช้และพัฒนามาอย่างต่อเนื่องนับตั้งแต่ Android รุ่นแรก (ซึ่งกระตุกมาก)

จนกระทั่ง Android 2.2 ทีมแอนดรอยด์ก็พัฒนา JIT (Just in time compiler) ขึ้นมาบน Dalvik เพื่อทำให้ประสิทธิภาพโดยรวมดีขึ้นอย่างมีนัยสำคัญ หลักการทำงานของมันคือพอเรารันแอพฯขึ้นมา มันจะแปลง Bytecode ของแอพฯ "เฉพาะในส่วนที่ใช้งาน" และเก็บไว้ในไฟล์ DEX (Dalvik Executable) และ ODEX (Optimized Dalvik Executable)

เจ้า JIT ก็เลยจะทำงานแบบ "คอมไพล์ไป ทำงานไป" ข้อดีคือใช้พื้นที่เก็บ Cache น้อย แต่ข้อเสียคือใช้พลังงาน CPU เยอะ หรือก็คือแบตหมดเร็วขึ้น เพราะต้องทำงานสองขั้น

จึงเกิดเป็น Runtime ตัวใหม่นามว่า ART (Android Runtime) ที่แอนดรอยด์ซุ่มพัฒนาอยู่หลายปี ถูกนำมาเป็นตัวทดลองบน Android 4.4 ให้คนสลับไปลองเล่นได้ และถูกนำมาเสียบแทบ Dalvik โดยสมบูรณ์บน Android "L"

Dalvik ใช้เทคนิคที่ชื่อว่า JIT ส่วน ART ใช้เทคนิคที่ชื่อว่า AOT (Ahead of Time) หลักการทำงานคือ "คอมไพล์ทั้งแอพฯเป็น Binary ให้ตั้งแต่ตอนติดตั้งแอพฯ"

พูดง่ายๆคือหลังจากติดตั้งแล้วโปรแกรมจะสามารถทำงานได้อย่างสมบูรณ์โดยไม่ต้องผ่านการคอมไพล์อะไรอีกเลย

ข้อดีที่เกิดขึ้นทันทีคือ (1) โปรแกรมจะโหลดเร็วขึ้นมาก กดปุ๊บมาปั๊บ (2) ใช้ CPU น้อยลงมาก นั่นแปลว่าใช้แบตลดลง (3) โปรแกรมทำงานเร็วขึ้น ลื่นขึ้น เพราะไม่ต้องคอมไพล์ระหว่างทำงาน

แต่ข้อเสียก็คือ การติดตั้งแอพฯอาจจะต้องใช้เวลานานขึ้นเพราะต้องคอมไพล์ทั้งแอพฯตอนติดตั้ง (ถึงในเอกสารจะบอกว่า install-time verification น้อยกว่า Dalvik ก็ตาม แต่ต้องดูระยะเวลาโดยรวมกันอีกที) จากที่มีคนทดลองให้ดู ก็นานขึ้นถึง 50% เลยทีเดียวนะ อีกข้อเสียนึงที่ยังไม่รู้ว่าจะเป็นยังไงคือพื้นที่ที่ใช้งานจะใช้มากขึ้นหรือเปล่า? จากข้อมูลที่ได้มาจากปีที่แล้ว พบว่า ART จะใช้พื้นที่ในการติดตั้งแอพฯมากขึ้นถึง 10-20% เพราะต้องคอมไพล์ทั้งแอพฯเก็บไว้เป็น Binary แต่ไม่แน่ใจว่า ART ตอนนี้พัฒนาไปถึงไหนแล้ว อาจจะมีเทคนิคอะไรที่ใช้พื้นที่น้อยลงก็เป็นได้ ต้องดูกันต่อไปครับ

Cross Platform Architecture

อย่างที่อธิบายไว้ด้านบน การทำงานของ AOT คือการคอมไพล์ตอนติดตั้ง มันจึงกลายเป็น Cross Platform Architecture ไปโดยปริยาย เพราะไม่ว่าจะบน CPU Architecture ตัวไหน ART ก็จะคอมไพล์เป็น Binary เพื่อ Architecture นั้นๆได้หมด

อย่างไรก็ตาม ไม่รวมถึง JNI ที่ต้องคอมไพล์แยกแพลตฟอร์มเหมือนเดิม เพราะ Input ของ ART AOT Compiler คือไฟล์ dex

Garbage Collector ดีขึ้นอย่างมีนัยสำคัญ

เมื่อ 5 ปีที่แล้วเราเคยพูดไว้ว่า

GC เป็นปัญหาที่ใหญ่ที่สุดของ Android

จวบจนถึงวันนี้ มันก็ยังเป็นปัญหาที่ใหญ่สุดอยู่ดี ถึงแม้มือถือจะแรงแค่ไหน การกระตุกก็ยังมีให้เห็นอยู่เรื่อยๆ เพราะเจ้า GC นี่เอง

เมื่อเราใช้งานไปเรื่อยๆ จะมี Memory ส่วนหนึ่งถูกเก็บไปโดย Garbage Collector ตามสไตล์ของ Java แต่ด้วยประสิทธิภาพอันต่ำต้อยของ GC บน Dalvik ทำให้มันเกิด Pause Time บ่อยมาก ที่เรา Scroll แล้วเห็นมันกระตุกๆ ส่วนใหญ่ก็เกิดจาก GC Pause Time นี่แหละ โดยใน Dalvik จะมี Pause Time สองครั้งต่อหนึ่ง GC

และภาพนี้ทำให้เราตาลุกวาวได้เมื่อคืนนี้

ART ตอบโจทย์ที่เป็นปัญหามานานของ Android เป็นที่เรียบร้อยแล้ว ด้วยการปรับปรุง GC อย่างมีนัยสำคัญ ลด Pause Time เหลือเพียง 1 ครั้งและกินเวลาน้อยลงมากอีกด้วย

ผลที่จะเห็นคือจากนี้แอพฯจะ "ลื่น" ขึ้นโดยที่นักพัฒนาไม่ต้องไปแก้อะไร เพราะปัญหาทั้งหมดก่อนหน้านี้มันเกิดจากตัวแอนดรอยด์เอง แต่ตอนนี้ไม่ใช่ปัญหาละ =)

แต่ปัญหาก็ยังดำรงต่อไปสำหรับคนที่ยังไม่ได้อัพ L และจะมีกี่ % กันน้าที่ได้อัพเจ้า L เร็วๆนี้ ...

Unified Stack

แอพฯแอนดรอยด์จะมีอยู่สองส่วนคือ Native และ Java บน Dalvik ทั้งสองตัวใช้ Stack คนละตัวกัน แต่บน ART ทั้ง Java และ Native จะใช้ Stack ตัวเดียวกัน

ไม่แน่ชัดเรื่องประโยชน์แบบที่เห็นได้ด้วยตาเปล่า แต่เชื่อว่าน่าจะช่วยให้การจัดการ Memory ดีขึ้น

Stricter JNI

หากใครใช้ JNI ในการพัฒนาแอพฯด้วยแล้วหละก็ อาจจะปวดหัวกับ ART ได้พอสมควร เพราะมีการเปลี่ยนแปลงอะไรมากมาย บางทีก็ถูก throw error ออกมาทั้งๆที่บน Dalvik ไม่เป็น อันนี้ให้ลองไปศึกษาและ Handle ทุกเคสให้ครับด้วยครับ อ่านรายละเอียดเพิ่มเติมเกี่ยวกับตัวนี้ได้ที่ Verifying Apps ART

ไม่ใช่ทุกแอพฯจะรันได้สมบูรณ์บน ART

ART เป็นตัวทดลองบน Android 4.4 และยังมีรายงานบั๊กออกมาเรื่อยๆ แต่สุดท้ายก็ถูกนำมาใช้จริงเสียแล้วใน Android 5.0

ดังนั้นอย่า Expect ว่าแอพฯทุกตัวต้องรันได้ ถึง Keynote เมื่อวานจะพูดว่าใช้โค้ดเดิมก็ตาม ซึ่งเค้าก็พูดถูกนะ แต่สุดท้ายโลกมันไม่ได้สวยขนาดนั้น

หากคุณเป็น Developer จงเทสต์แอพฯบน ART ให้เรียบร้อยตั้งแต่เนิ่นๆด้วยครับ สำคัญมาก

ลื่นไหล แบตหมดช้า เนื้อที่หมดเร็ว ข้อสรุปของ ART

หากให้สรุปเป็นข้อๆว่า ART ส่งผลอย่างไรต่อผู้ใช้บ้าง ก็คงได้สามข้อใหญ่ๆคือ

(1) ลื่นขึ้นจาก Pre-compiled Binary

(2) แบตหมดช้าลง จากการที่ไม่ต้องคอมไพล์ไปทำงานไปอย่างที่ JIT ทำใน Dalvik

(3) เนื้อที่หมดเร็วขึ้น จากการที่ ART กินพื้นที่มากขึ้น

และส่งผลต่อนักพัฒนาอย่างไรบ้าง?

ถ้าแอพฯไม่ได้ทำอะไรซับซ้อนซ่อนเงื่อนเพื่อนทรยศ ก็น่าจะสามารถใช้งานได้เลย ไม่มีปัญหา แต่ถ้าทำอะไรซับซ้อน ย้ำอีกทีว่าให้ทดสอบให้ดีก่อนนะครับ ไม่งั้นมีปัญหาแน่ๆ

จะได้อัพเมื่อไหร่

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

สำหรับ Android L ก็คงต้องดูกันต่อไปว่าจะได้อัพกันเมื่อไหร่ ส่วนนักพัฒนา วันนี้เค้าจะปล่อยตัว SDK ให้ลองกันแล้ว รอโหลดกันได้ครับที่ Android Developer =)

สวัสดีครับ