Dianne Hackborn วิศวกรของทีม Android ออกมาอธิบายหลักการและแก้ความเข้าใจผิดเกี่ยวกับการประมวลผลกราฟิกของ Android หลายประการ
ประเด็นเรื่อง hardware acceleration ใน Android แต่ละรุ่น
- Android มี hardware acceleration มาตั้งแต่รุ่น 1.0 โดยส่วนที่ใช้งานคือการเรนเดอร์ตัวกรอบหน้าต่าง (window compositing) ดังนั้นแอนิเมชันต่างๆ ที่เราเห็นในเมนูหรือชิ้นส่วน UI ต่างๆ เรนเดอร์ด้วยฮาร์ดแวร์ทั้งนั้น
- แต่เนื้อในของหน้าต่างหรือ content ภายในแอพ จะใช้ซอฟต์แวร์ประมวลผลแทน ซึ่งประสิทธิภาพของการประมวลผลจะขึ้นกับพลังของฮาร์ดแวร์และจำนวนพิกเซลที่ใช้งาน เช่น Droid ตัวแรกจะมีปัญหากับความละเอียด 800x480 ในขณะที่ Nexus S ทำได้สบาย
- การประมวลผลเนื้อหาโดยใช้ hardware acceleration ถูกเพิ่มเข้ามาใน Android 3.0 แต่ปิดเอาไว้ไม่ใช้งาน เว้นเสียแต่ว่านักพัฒนาแอพจะระบุให้ใช้ GPU ช่วยประมวลผลเท่านั้น
-
Android 4.0 ใช้เอนจิน hardware acceleration ตัวเดียวกับ 3.0 แต่เปิดมาแต่แรก และถ้าแอพระบุว่าตัวมันเองทำงานบน Android 4.0 ได้ ตัวระบบปฏิบัติการก็จะเรียกใช้ hardware acceleration ทั้งหมด
ประเด็นเรื่องความช้า-เร็วของการแสดงผลใน Android
-
hardware acceleration ไม่ได้มีแต่ข้อดีเสมอไป เพราะโพรเซสของแอพจะต้องเปลืองแรมอีก 8MB ต่อโพรเซสสำหรับเรียกใช้ OpenGL ดังนั้นงานบางงานในตัวระบบปฏิบัติการ Android 4.0 จึงเลือกจะไม่ใช่ hardware acceleration เพื่อประหยัดแรม โดยเฉพาะงานที่เพียงซีพียูลำพังสามารถทำได้ดีอยู่แล้ว (เช่น ไม่ควรจะเรนเดอร์ status bar ด้วย OpenGL เพราะไม่คุ้ม)
- hardware acceleration ไม่ใช่ "คำตอบสุดท้าย" ที่ทำให้ Android ลื่นขึ้น เพราะยังมีประเด็นด้านเทคนิคอื่นๆ อีกมาก เช่น การปรับปรุงประสิทธิภาพของ scheduler ระหว่างเธร็ดที่ทำงานเบื้องหน้าและเบื้องหลัง (อยู่ใน 1.6) หรือการปรับปรุงระบบการป้อนข้อมูล (อยู่ใน 2.3) การปรับปรุง garbage collector เป็นต้น
- บางครั้ง hardware acceleration กลับทำให้การแสดงผลช้าลงด้วยซ้ำ โดยยกกรณีทีมงานของกูเกิลเคยพบว่าเลื่อนหน้าจอบน Nexus S/ICS ช้ากว่า Gingerbread ในบางกรณี ซึ่งค้นพบว่าเป็นปัญหาของ timing ของการประมวลผล ถึงแม้สมรรถนะในการประมวลผลจะสามารถวาดหน้าจอที่ 60 fps ได้ก็ตาม ก็ยังกระตุกเพราะเรื่องอื่น
- เวลาคนเปรียบเทียบการเลื่อนหน้าจอใน Android และ iOS เหตุผลส่วนมากที่ Android ช้ากว่าไม่ได้เป็นเพราะไม่มี hardware acceleration แต่เป็นเพราะวิธีการเรนเดอร์เว็บเพจของ Android ในอดีต มองว่ามันเป็น list ที่ต้องค่อยๆ วาดบนหน้าจอไปตามลำดับ ทำให้การเลื่อนหรือซูมมีปัญหากับส่วนที่ยังไม่ได้วาดบนจอ แต่ใน Android 3.0 เปลี่ยนมาเรนเดอร์แบบ tiles ที่แก้ปัญหาเรื่องนี้ได้
- hardware acceleration ไม่ช่วยแก้ปัญหาเรื่องประสิทธิภาพของกราฟิกทั้งหมด เพราะ GPU ก็มีข้อจำกัดทางสมรรถนะอยู่ ตัวอย่างเช่น Tegra 2 สามารถเรนเดอร์พิกเซลได้สูงสุด 2.5 เท่าของความละเอียด 1280x800 ที่ 60fps ซึ่งในความเป็นจริงแล้ว การแสดงผลกราฟิกไม่ได้วาดแค่ 1280x800 แต่ต้องวาดวัตถุต่างๆ บนหน้าจอซ้อนกันหลายๆ ชั้นแล้วค่อยนำมาประกอบเข้าด้วยกัน (compositing) ซึ่งลำพังแค่นี้ก็ใช้พิกเซลครบโควต้าของ GPU แล้ว
- Android 3.0 ใช้เทคนิคหลายอย่างช่วยให้พลังของ GPU พอใช้สำหรับการแสดงกราฟิก เช่น การวาดหน้าต่างเฉพาะส่วนที่ไม่บังกัน (overlay) จะได้ไม่ต้องเรนเดอร์ภาพของหน้าต่างทั้งหมด, วาดภาพพื้นหลังเก็บไว้ในหน่วยความจำ เวลาเลื่อนจอก็เลื่อนภาพตาม จะได้ไม่ต้องวาดใหม่ทุกครั้งที่เลื่อน เป็นต้น
- ยิ่งความละเอียดของหน้าจอเพิ่มขึ้น การแสดงผลหน้าจอที่ 60 fps จะยิ่งขึ้นกับพลังของ GPU และแบนด์วิธหน่วยความจำของ GPU ซึ่งเธอแนะนำว่านักพัฒนาควรใส่ใจกับแบนด์วิธตรงนี้ให้มาก ถ้าแอพที่ทำอยู่เกี่ยวข้องกับกราฟิก
รายละเอียดแบบเต็มๆ แนะนำให้อ่านต้นฉบับครับ
ที่มา - +Dianne Hackborn via The Verge