Dianne Hackborn วิศวกรของทีม Android ออกมาอธิบายหลักการและแก้ความเข้าใจผิดเกี่ยวกับการประมวลผลกราฟิกของ Android หลายประการ
ประเด็นเรื่อง hardware acceleration ใน Android แต่ละรุ่น
Android มี hardware acceleration มาตั้งแต่รุ่น 1.0 โดยส่วนที่ใช้งานคือการเรนเดอร์ตัวกรอบหน้าต่าง (window compositing) ดังนั้นแอนิเมชันต่างๆ ที่เราเห็นในเมนูหรือชิ้นส่วน UI ต่างๆ เรนเดอร์ด้วยฮาร์ดแวร์ทั้งนั้น
แต่เนื้อในของหน้าต่างหรือ content ภายในแอพ จะใช้ซอฟต์แวร์ประมวลผลแทน ซึ่งประสิทธิภาพของการประมวลผลจะขึ้นกับพลังของฮาร์ดแวร์และจำนวนพิกเซลที่ใช้งาน เช่น Droid ตัวแรกจะมีปัญหากับความละเอียด 800×480 ในขณะที่ 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 เท่าของความละเอียด 1280×800 ที่ 60fps ซึ่งในความเป็นจริงแล้ว การแสดงผลกราฟิกไม่ได้วาดแค่ 1280×800 แต่ต้องวาดวัตถุต่างๆ บนหน้าจอซ้อนกันหลายๆ ชั้นแล้วค่อยนำมาประกอบเข้าด้วยกัน (compositing) ซึ่งลำพังแค่นี้ก็ใช้พิกเซลครบโควต้าของ GPU แล้ว
Android 3.0 ใช้เทคนิคหลายอย่างช่วยให้พลังของ GPU พอใช้สำหรับการแสดงกราฟิก เช่น การวาดหน้าต่างเฉพาะส่วนที่ไม่บังกัน (overlay) จะได้ไม่ต้องเรนเดอร์ภาพของหน้าต่างทั้งหมด, วาดภาพพื้นหลังเก็บไว้ในหน่วยความจำ เวลาเลื่อนจอก็เลื่อนภาพตาม จะได้ไม่ต้องวาดใหม่ทุกครั้งที่เลื่อน เป็นต้น
ยิ่งความละเอียดของหน้าจอเพิ่มขึ้น การแสดงผลหน้าจอที่ 60 fps จะยิ่งขึ้นกับพลังของ GPU และแบนด์วิธหน่วยความจำของ GPU ซึ่งเธอแนะนำว่านักพัฒนาควรใส่ใจกับแบนด์วิธตรงนี้ให้มาก ถ้าแอพที่ทำอยู่เกี่ยวข้องกับกราฟิก
http://www.pantip.com/cafe/mbk/topic/T11425849/T11425849.html
ผมอยากจะบอกว่า ที่ไม่ลื่นเท่า IOS ทั้ังๆ ที่ Hardware เหนือกว่า ก็เพราะ ความ Lazy ของนักพัฒนา
ที่มักใช้ Library ในการเขียน Code และ Library ที่ว่าก็มักทำแบบกวาดทั้งหน้าจอ ทั้งๆ ที่สามารถเขียน
Code ให้แสดงเฉพาะพิกเซลที่เปลี่ยนแปลงก็ได้ แต่ไม่ทำ เพราะความขี้เกียจ มักง่าย นั่นก็คือหนึ่งใน
เหตุผลของ Software อื่่นๆ อย่างเช่น Window Mobile หรือ Window XP, 7 ที่ ไปพึ่ง .NET และ Library
100% แถมยังสร้างวิธีการเขียน Code ที่เทอะทะกันไปใหญ่ที่เรียกว่า OOP นั่นก็เป็นเหตุผลว่าทำไม
Hardware แรงขึ้นแต่ทำไม การทำงานช้าลงก็เพราะความขึ้เกียจของนักพัฒนานั่นแหละ
สมัยก่อนโปรแกรมเมอร์จะเขียนให้กันตรงๆ ที่หน้าจอกันเลย กำหนดจุดต่างๆ แต่ละพิกเซลเลย
ซึ่ง IOS ยังคงยึดถือปฏิบัติอยู่ อย่างเข็มข้น
ที่ออกมาบอกนี้แสดงว่าจะไม่แก้ใช้ม่ะ แต่ถ้าแก้ผมว่าคงรื้อ OS ใหม่อ่ะ่