By: mk 
on 6 December 2011 - 21:59
Tags:
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
Get latest news from Blognone
Follow @twitterapi
Hiring! บริษัทที่น่าสนใจ
Blognone Jobs Premium
Cloudnone
- NVIDIA จะไปหยุดที่ตรงไหน ทำไมครองโลกดาต้าเซ็นเตอร์ | Cloudnone EP.22
- ถึงคลาวด์เคราะห์: ทำอย่างไรเมื่อบริการคลาวด์ที่ใช้ถูกยกเลิก | Cloudnone EP. 21
- รู้จักอาชีพ Site Reliability Engineer สำคัญยังไง? | Cloudnone EP. 20
- อธิบาย CrowdStrike ทางเทคนิค ทำไมถึงทำพีซีจอฟ้าเป็นล้านๆ เครื่อง | Cloudnone EP.19
- Kubernetes [Part 2] ยี่ห้อไหนดี งานไหนต้องใช้ แล้วเลือกยังไง? | Cloudnone EP.18
Comments
เพราซอฟแวร์ ไม่ได้เกิดมาเพื่อฮาร์ดแวร์ มันร้อยพ่อพันแม่เกินไป ใครจะเขียนโปรแกรมครอบคลุมไหว
iOS ทดสอบกับฮาร์ดแวรไม่กี่รุ่น ถูกเขียนขึ้นมาโดยเฉพาะ เกิดมาเป็นคู่กันและกัน Perfect match
ผมว่า Windows Phone ก็หลายพ่อหลายแม่นะ? (แต่ก็ไม่เท่าแอนดรอยด์)
Windows Phone กำหนด สเปกและ อุปกรณ์ซะ ขนาดนนั้นไม่ลื่นก็ไม่รู้ว่าไงแล้ว ครับ
แทบจะไม่ได้ต่างกะ iOS เลย
กำหนด สเปก หรือ ผมว่า สเปก ของเครื่อง แอนดรอย ยังแรงกว่าของ วินโดว์โฟน อีก
Android ไม่เคยกำหนดขั้นต่ำสเปคนิครับ
ผมว่า HD7 ลื่นกว่า S2
รู้สึกจะมีกำหนดนะครับ แต่ไม่ทำตามก็ได้ แค่ไม่ได้แอพของกูเกิลไปใส่
แล้วก็เท่าที่ทราบ หลายเสียงบอกว่าขั้นต่ำของ WP7 ก็ทำงานได้ลื่นกว่าขั้นสูงของแอนดรอยด์นะ (ผมยังไม่มีโอกาสสอยมาใช้จริง แต่จากที่เล่น สเป็คระดับเดียวกับ WP7 ลื่นกว่า)
ผมเห็นข่าวลือเรื่องกำหนดขั้นต่ำสเปคถึงรุ่นใหม่ทีไร ก็มีข่าวแก้จาก GG ว่าไม่ใช่ทุกที ก็เลยเห็นว่ามันไม่มีสเปคขั้นต่ำน่ะครับ
ผมจำได้ว่ามีกำหนดอะไรสักอย่างครับ เพื่อให้ได้เอาแอพของกูเกิลไปใส่ ไม่ใช่กำหนดว่าต้องสเป็คขั้นต่ำเท่านี้ ถึงจะรันแอนดรอยด์ได้
มันเป็นแบบนี้เองหรอครับ อืมๆๆ.
ผมว่าข้ออ้างครับ ปัญหานี้มันเป็นระดับ Architecture ของ OS เป็นหลัก ไอ้ Hardware ร้อยพ่อพันแม่มันเป็นเรื่องรองๆๆๆมาก
จากที่ยกมาด้านบน Android เป็น Multitask 100% การที่จะเปิด HW Acceleration สำหรับทุก Process ต้องเสีย 8MB แต่ละ Process ซึ่งเปลือง RAM มาก และ OS ก็ไม่รู้ (อาจจะรู้แต่จัดการไม่ดี) ว่า App ไหนควรจะ Focus เทียบกับ iOS ที่เป็น Multitask เฉพาะ App ของระบบ ทำให้ CPU/GPU ได้ Focus กับ Process ของ App ที่กำลัง Run อยู่ได้เต็มที่ แต่ก็ต้องแลกมาด้วยสิ่งที่ User รำคาญในช่วงแรกๆคือเปิดโปรแกรมอื่นแล้วพอย้อนกลับมาใช้โปรแกรมที่แล้วต้องโหลดใหม่หมด ซึ่ง Apple ก็แก้เกมด้วยระบบ Multitask เทียม โดยใช้หลักการของ Process Hibernation แทน ซึ่งก็ช่วยให้ประสบการณ์ของ User ดีขึ้นมาก สามารถสลับ Process ได้ แต่ยังมีข้อดีของ Single Task อยู่
บทความอธิบายง่ายๆเรื่อง Multitask ของ iOS กับ Andriod
http://bit.ly/9CGSkq
คิดว่าส่วนอื่นก็คงจะเกี่ยว และอาจจะเป็นข้องอ้างจริง ๆ เหมือนกัน แต่ผมเคยมีประสบการณ์กับ PC ถึงจะไม่ใช่มือถือ แต่ก็มีประเด็นที่น่าสนใจว่า
เครื่องที่ผมประกอบเองนั้น มีอุปกรณ์ราคาแพง รุ่นสูงกว่าอีกเครื่องที่เป็นยี่ห้อ Dell ของอีกหน่วยงานหนึ่ง แต่แปลกที่ว่า โปรแกรมบางตัวนั้น ความลื่น ความคล่องตัวของเครื่อง Dell นั้น รู้สึกได้เลยครับ ผมคิดว่า hardware ที่ผ่านการทดสอบว่าเหมาะสม เข้ากันได้อย่างดี กับ software ที่ออกแบบให้เหมาะกับ hardware ที่กำหนดมานั้นช่วยตรงจุดนี้ได้ไม่แพงเครื่องแรง ๆ เลยละครับ
เพจตัวอย่างผลงานถ่ายภาพ / วีดีโอ
เดี๋ยวจะมี blogger เก๋ ๆ คนนึงออกมาบอกว่า ผมไม่สน ผมใช้อย่างเดียว ผมจะสนทำไม สนแค่มันไม่ลื่น
มีผู้บริโภคกากๆ มาทำหน้าที่แทนแล้วด้านล่าง :P
ต่อกันเลยทีเดียว ประโยคเดียวกันเปะๆ 55+
ผมไม่สน ผมใช้อย่างเดียว ผมจะสนทำไม สนแค่มันไม่ลื่น
จากผู้บริโภคกากๆจนๆที่อยากใช้เงินให้คุ้มค่าที่สุดคนนึง
ถ้าเป็น Steve Jobs แกคงบอกว่าไม่ต้องมาอธิบาย ไปทำมาใหม่ให้ลื่นๆซะ
+1 เลยทีเดียว
ไปทำใหม่ซะครับ ไม่ใช่ให้ยอมรับสภาพแบบนี้ ไอ้เทคนิคหลายๆ ตัวผมก็เห็นบน DirectX เป็นชาติเศษแล้ว
การเอามาอยู่บน Linux มันท้าทายขนาดนั้นเลยสินะ
I need healing.
Linux UI มันช้าตั้งแต่โครงสร้างข้างล่างละ ถึง Mac ดูเหมือนจะมาคล้ายๆกันแต่โครงสร้าง OS ที่จะรองรับ UI มันต่างกันลิบลับเลย
Mac กับ Linux มีบรรพบุรุษร่วมกันครับ ประดุจคนกับลิง
I need healing.
OS ไหนเป็นลิง เป็นคนหว่า
Mac กับ Linux ไม่ได้มีบรรพบุรุษร่วมกันเลยแอ้แต่นิดเดียวครับ Mac สืบสายตระกูลมาจาก UNIX ส่วน Linux ไม่ได้เอา code ใดๆ ในส่วนของ kernel มาจาก UNIX เลย
สงสัยผมจะใช้คำผิดจริงๆ
Linux = UNIX ของ Linus
แล้วผมต้องใช้คำยังไงดี?
I need healing.
ไม่เชิงนะครับ
Linux เลียนแบบ Unix แต่ Mac OS X พัฒนามาจาก UNIX ตระกูล BSD
+1
ถ้าจำเรื่องเสาอากาศกันได้ จะจำได้ว่าค่ายผลไม้เคยออกมาอธิบายยกใหญ่เหมือนกัน ;P
เพราะปัญหานั้นแก้ไม่ได้แล้ว ผลิตออกไปแล้ว เลยต้องแถกันหน่อย เอ๊ะ! หรือว่าปัญหาไม่ลื่นของ Android จะแก้ทาง software ไม่ได้แล้วเหมือนกัน :P
แก้ได้ แต่ไม่ได้เรียกคืนแล้วผลิตใหม่ให้ขาดทุนย่อยยับ เพราะตอนนั้นก็ยังขายได้ขายดีอยู่
ส่วนตัวที่แก้เรื่องเสาเสร็จแล้ว ก็ชุบตัวอัพสเปคใหม่เป็น 4S ชะละล่า (และขายดีตามเคย)
@mamuang
แก้ได้แต่คงต้องรื้อใหม่ตั้งแต่ kernel กันเลย
google คงไม่เลือกทำวิธีนี้แน่ๆ เพราะเท่ากับรีเซ็ท Android กลับไปที่ 1.0 ใหม่อีกรอบ
แอพต่างๆก็ต้องมาลุ้นว่าจะใช้ได้ไม่ได้ทุกตัว เสียความเชื่อมั่นลูกค้าไปเยอะ
พวก ROM cooker นี่เค้าเปลี่ยนเคอร์เนลกันเป็นว่าเล่นเลยนะครับ
ผมว่า ถ้ามีจังหว่ะ ยังไง Google ก็คงต้องทำ
เหมือนที่ MS เลือกที่จะกลบฝัง Windows Mobile
แม้จะเสียความเชื่อมั่น แต่เพื่อสิ่งที่ดีกว่า
ไม่งั้นในอนาคต Android ก็อาจตายไปเองก็ได้
กองทัพมดกับยักษ์พิการ อาจค่อยๆ โดน 2 ยักษ์ กระทืบตาย
แต่เขาก็ไปทำใหม่แล้วนะ
อย่าขี้เกียจ กลับไปแก้ไขให้มันดีซะ +222
เคยสงสัยอยู่เหมือนกันว่า hardware แรงๆระดับเทพ ทำไมบางทีมันกระตุก
แก้ algorithm ล้วนๆครับ
อีกหนึ่งเหตุผลคือ "เพราะมันไม่ใช่ Native แบบ iOS"
อีก 1 เหตุผล เพราะมันเป็น Java
คำตอบของข้า คือ ประกาศิต
บังอาจ!! จาวาเร็วส์!!!
+666
เย่~
555+
dalvik != jvm เน้อ
ภาษาฐานเดียวกัน ไม่มี struct ไม่มี pointer เป็น Virtual Machine อวดฉลาดเหมือนๆกัน จะให้รอดเรื่อง Performance คงยากครับ
ป.ล. Virtual Machine อวดฉลาด หมายถึงพวก Virtual Machine ที่พยายามช่วยคอมไพล์ให้คนเขียนไปซะทุกอย่าง พยายามไม่ให้คนเขียนคิดเองเลือกเอง แล้วชอบมาโม้ว่าฉลาดมากพอที่จะ Optimize ให้ แล้วปรากฏว่าไม่สามารถทำได้จริง ตัวอย่างเช่น JVM และเหล่า JavaScript Compiler ทั้งหลาย ต่างกับ Virtual Machine ที่ยอมรับความโง่ และเลือกที่จะมีเครื่องมือ Option ให้คนเขียนเลือกใช้ แลกกับความยุ่งยากเล็กน้อย
กำลังจะสื่อะไรอ่ะครับ งง... ไม่มี struct (แปลว่าอะไร?) ไม่มี pointer มันทำให้ช้าเหรอครับ?
virtual machine มันไม่เกี่ยวกับภาษานะครับ โดยหลักการแล้วคุณจะเขียนโปรแกรมเป็นภาษาอะไรก็ได้ ขอแค่ให้ compile มาเป็น bytecode ของ virtual machine นั้นเท่านั้น ใน android คุณสามารถเขียนโปรแกรมด้วยภาษา java แต่ก่อนจะออกมาเป็น app ที่รันได้บน android มันจะต้องผ่านการแปลงจาก
java -> java bytecode -> dalvik bytecode
การที่มันจะเร็วช้าอยู่ที่ virtual machine มัน "ฉลาด" แค่ไหนและเท่าที่ผมติดตามมา dalvik มันก็เพิ่มความฉลาดมาเรื่อยๆนะครับ แต่ถ้าจะบอกว่ามัน "อวดฉลาด" ผมก็ไม่เห็นด้วย ผมเห็นว่าการ optimize ต่างๆในตัว virtual machine มันเป็นวิธีที่ช่วยทำให้โค้ดที่เขียนขึ้นมารันบนตัวมันทำงานได้เร็วขึ้น แต่มันคงจะไม่สามารถเร็วได้เท่า native ในทุกกรณี และขณะเดียวกันมันก็ไม่ได้ช้ากว่า native ทุกกรณีเช่นกัน
ช่วยยกตัวอย่าง virtual machine ที่ "ยอมรับความโง่" ให้ดูซักตัวสิครับ
"และขณะเดียวกันมันก็ไม่ได้ช้ากว่า native ทุกกรณีเช่นกัน"
แค่เริ่มต้นก็ช้ากว่าละคับ เสียเวลาคอมไพล์เป็น Machine Code อีก ไหนจะเรื่องโครงสร้างของภาษาที่ไม่เอื้อต่อการแปลงเป็น Machine Code อีก ไหนจะใช้แรมมากกว่าอีก ไหนจะระบบ Garbage Collection อีก ฯลฯ ไม่มีอะไรเร็วกว่าสักอย่าง มีดีแค่เขียนง่าย พัฒนาเร็ว รันได้หลาย Architecture
เอามาจากไหนครับว่าโครงสร้างของภาษาไม่เอื้อต่อการแปลงเป็น machine code? virtual machine มันเกี่ยวอะไรกันกับโครงสร้างภาษา? ในเมื่อ virtual machine มันสนใจแต่ bytecode
แล้วอีกอย่างเขียนโปรแกรมบนไหนครับที่มันไม่ต้อง compile? ถ้าพูดถึง JIT มันไม่ได้ compile ทั้งโปรแกรมใหม่นะครับ มัน compile เฉพาะส่วนที่รันบ่อยๆเท่านั้น ส่วนที่เหลือก็เป็น interpreter ตามปกติ ซึ่งก็อย่างที่ผมบอกไว้ มันไม่ได้เร็วขึ้นทั้งหมด แต่ก็ไม่ได้ช้ากว่าไปซะหมดครับ
และอีกอย่างนึง ถึงแม้ว่า app จะเขียนให้รันบน virtual machine แต่ api call ส่วนใหญ่แล้วจะลงท้ายด้วยการรัน native code ใน library ต่างๆทั้งนั้นแหละครับ
แนะนำให้ดู Google I/O 2010 - A JIT Compiler for Android's Dalvik VM ครับ ถ้าสนใจเรื่อง JIT ของ dalvik
เพราะมันมีฟีเจอร์หลายอย่างเกินไปนั่นละคับ ถึงไม่เอื้อต่อการแปลงเป็น Machine Code ถ้าคุณจะตอบว่า มันก็แปลงเป็น Machine Code ได้เหมือนกัน ได้ Code ออกมาเหมือนพวกภาษา Native อยู่ดี แล้วส่วนที่มันเป็นฟีเจอร์ของภาษาที่เพิ่มขึ้นมาละคับ? มันไม่ต้องใช้งาน CPU เลยหรือ? ยกตัวอย่างเช่น Garbage Collection คุณคิดว่า CPU ไม่ต้องมาประมวลผลตรงนี้เลยงั้นเหรอ? สรุปง่ายๆคือมันมี Overhead เพิ่มขึ้นมานั่นละคับ
ดูเหมือนคุณจะเข้าใจอะไรผิดเรื่องการคอมไพล์ไปละ เอาเป็นว่า C ก็คอมไพล์เหมือนกัน แต่มันออกมาเป็น Native Code เลย การทำงานทุกอย่างควบคุมได้ด้วยตัวโปรแกรมเมอร์เอง อยากจะจอง Memory ตอนไหนก็เลือกได้ อยากจะ Free Memory ตอนไหนก็เลือกได้ ฯลฯ
ลงท้ายด้วยการรัน Native Code นั่นมันใช่คับ แต่พวก Code ที่ทำงานก่อนที่จะถูกเรียกมาใน Native API ละ?
ถ้าคุณมองในแง่ที่ว่า "การแปลงเป็น machine code" คือการแปลงทั้งโปรแกรมเป็น native code อันนี้ผมก็จะเห็นด้วยว่ามันไม่เอื้อ เพราะว่าตัว bytecode มันถูกออกแบบมาให้รันบน virtual machine ไม่ใช่ native CPU อยู่แล้ว แต่ก็อย่างที่ผมบอกไป การทำ JIT มันไม่ได้คอมไพล์ bytecode -> native code หมดทั้งโปรแกรม ถ้าเจาะจงมาที่ JIT ของ dalvik มันจะคอมไพล์เฉพาะโค้ดตรงส่วนที่มีการรันบ่อยๆ เท่านั้น ซึ่งถ้าดูจากตัวเลขที่ google ให้มา (ดูตามลิ้งค์ google IO ที่ผมแปะไว้ข้างบน) มันอยู่ที่ระหว่าง 2 - 10% ของ bytecode ทั้งหมดเท่านั้น ซึ่ง bytecode ที่ถูก JIT แปลงเป็น optimized native code แล้วก็จะถูกเก็บไว้ใน translation cache และถูกเรียกใช้โดยตรงเลยถ้ามีการเรียกใช้โค้ดส่วนนั้นซ้ำอีก
แน่นอนว่าส่วนที่เป็นฟีเจอร์ต่างๆของ virtual machine ไม่ว่าจะเป็๋น GC, exception handling, object reference counter, etc มันกิน CPU และก็เป็น overhead สำคัญที่อาจเป็นจุดที่ทำให้เกิดการกระตุกได้ แต่มันก็ได้ถูกพัฒนาให้ overhead ตรงส่วนนี้ลดลงอยู่ตลอดเวลาเช่นกัน
การเขียนโปรแกรมด้วย C ทำให้คุณสามารถควบคุมการรทำงานของโปรแกรมได้มากกว่าการใช้ภาษาที่รันบน virtual machine ก็จริง แต่ปกติแล้วคุณก็ไม่ได้ควบคุมมันทั้งหมดหรอก ยกตัวอย่างการ allocate memory ด้วย malloc/free คุณคงไม่ได้เขียน library เพื่อทำการ allocate/free เองใช่ไหม? คุณต้องเรียกผ่าน standard library แล้วทีนี้คุณควบคุมได้ไหมว่าจะให้มัน allocate memory ส่วนไหนมาให้? คุณป้องกันการเกิด memory fragmentation ได้ไหม?
ที่ผมพูดมาเพียงเพื่อจะบอกว่า การมี overhead มันไม่ได้ทำให้ระบบ "แย่ลง" เสมอไปครับ มันอยู่ทีการ compromise กันระหว่าง manageability กับ stability และ speed ครับ
นั่นแหละครับประเด็นที่ผมบอกว่า ทั้ง Java และ DALVIK มันคือ "Virtual Machine ที่อวดฉลาด"
การมี struct หรือ pointer มันเป็นทั้งในตัวภาษาและในตัว bytecode ครับ ผมขอยกตัวอย่าง C# นะ ภาษานี้มันรองรับ struct ทั้งในตัวภาษาและ bytecode จนถึง Virtual Machine .NET ของมัน ก็รองรับ struct
ซึ่งตรงจุดนี้ผมเรียกว่า "มันยอมรับว่ามันโง่" มันจะไม่พยายามเดาว่าตรงจุดไหนควรเป็น heap object ตรงจุดไหนควรเป็น stack allocation มันยอมรับว่า Garbage Collector ของมันไม่ได้ดีเท่าไหร่ ทำงานบ่อยไป Performance ก็ตก มันจึงเลือกที่จะให้อิสระกับ Programmer มาคิดเองว่า ถ้าอยากได้ Performance ก็ต้องบริหาร Memory ด้วยการใช้ struct และฟีเจอร์ option ต่างๆ
ในขณะที่ Java ไม่มี struct และทั้ง JVM และ DALVIK ไปจนถึง bytecode ไม่รองรับการมี struct และข้ออ้างของฝ่าย Java คือ Java มี JVM ฉลาด สามารถคาดเดาได้เองว่า object ไหนควรจะจัดการยังไงถึงจะมีประสิทธิภาพ รวมไปถึง GC ที่ดีสุดยอด เขียนมาเถอะ ปล่อยให้ Java ทำงานตรงนี้ให้เอง
แต่ปรากฏว่า สุดท้ายมันเป็นการ spoil โปรแกรมเมอร์ ในขณะที่ JVM มันไม่ฉลาดขนาดนั้น มันปล่อย performance drop บ่อยๆ มันไม่สามารถบริหาร Memory ได้อย่างที่ควรเป็นเสมอไป เพราะความซับซ้อนของโปรแกรมที่คนเขียนมันไม่ง่าย(และโดยเฉพาะคนเขียนที่โดนสปอยล์ยิ่งทำให้งาน Optimize ของ Java ยากขึ้น) แม้กระทั่ง GC ที่อวดนักหนา ก็เคยทำ Memory Leak มาแล้วในบางเวอร์ชั่น
สรุปคือ Virtual Machine ในปัจจุบันมันยังตามสมองคนไม่ทัน แต่ JVM ก็ยังจะอวดฉลาดอยู่ร่ำไป และที่ดำเนินรอยตามคือ DALVIK ผมก็ไม่เห็นว่ามันจะต่างกันได้ซักกี่มากน้อย
ผมเห็นด้วยกับประเด็น GC แต่ไม่เห็นด้วยกับกรณี Struct ที่อธิบายมานะครับ เดี๋ยวนี้น่าจะไม่ค่อยใช้ Struct กันแล้วครับ
เพราะ MSDN ก็บอกว่า Struct ใช้ดีแค่บางเคส เช่นกรณีมีข้อมูลไม่เกิน 16 Bytes, ถ้าใหญ่กว่านี้ Struct อาจจะแย่กว่า class..
หรือ Microsoft MVP เองก็บอกว่า "In reality it is incredibly rare to write a struct in .NET"
ดังนั้นตัวอย่างที่อธิบายมาเรื่อง Struct ผมไม่เห็นด้วย เพราะว่า Java ไม่มี Struct มันก็ไม่ได้แย่อะไร ในโลกแห่งความเป็นจริง ใช้ class กันหมดอยู่แล้ว
แต่ถ้าประเด็นเรื่อง GC, Dispose ใน C# ที่ให้อิสระ programmer clear memory เอง อันนี้ผมเห็นด้วย เพราะอยากให้ Java ทำเหมือนกันครับ
มันอยู่ที่ว่าใช้ struct ยังไงด้วยครับ
struct มันมี Characteristic ในการใช้ที่ต่างจาก class ถ้าศึกษาดูจะรู้ว่า ทำไมมันถึงสร้างปัญหาต่างๆที่ว่า และ ใช้ยังไงถึงจะไม่สร้างปัญหานั้น และจะเข้าใจได้ว่า ใช้ยังไงถึงจะเพิ่มประสิิทธิภาพได้
จุดสำคัญคือถ้าเรารู้ว่า struct มันไม่ควร copy บ่อยๆ เราพลิกแพลงไปเขียนโค้ดที่เหมาะสม เราสามารถ ref/out มันได้เวลาส่งเข้า function ตรงนี้ผมก็เรียกว่า มันยอมรับว่ามันโง่ มันไม่เดาให้เราว่าควรส่ง struct เข้าไปในฟังค์ชั่น แบบ reference หรือแบบ value มันให้เราบังคับมันเอง (ซึ่ง ถ้าขนาดของ struct ใหญ่กว่า 16 byte ก็ควรใช้ ref ในการโยนเข้าฟังค์ชั่น และไม่ควร Copy มัน นี่เป็นเรื่องที่รู้กันในคนเขียน C#)
จุดสำคัญอีกอย่างคือ struct มันลดการทำงานของ GC ครับ เพราะ struct ไม่ใช้ GC แต่เก็บข้อมูลได้ โดยหลักแล้วที่เห็นชัดมากๆ คือ array ครับ array ของ struct คือก้อนเมมโมรี่ ในขณะที่ array ของ class เป็นกองพอยน์เตอร์ ที่ต้องคอย new ทีละอัน แถมยังเสียประสิทธิภาพไปในการ reference หลายชั้น
เช่นเดียวกับการมี object ใน class ที่มันต้อง reference หลายชั้น แต่กับ struct มัน reference ชั้นเดียว แล้วมันก็จะชี้ตรงไปที่ memory ก้อนนั้น
และปัญหาสำคัญมากๆอีกอย่างในทางการโปรแกรมคือ struct มันคือ ValueType ครับ ใน Java เราต้องพยายามคิดว่าของทุกอย่างคือ object และต้องคอย clone มัน เวลาที่เราต้องการแค่ copy
คนใช้ Java อาจจะมองว่ายุ่งยากที่ต้องมานั่งดู ว่า variable ตัวไหนคือ struct ตัวไหนคือ class แต่สุดท้าย ถ้าชินแล้ว โค้ดมันจะไม่รก และตรงไปตรงมา ไม่ต่างกับการใช้ int หรือ float ใน Java (เทียบระหว่า Matrix m = object.Transform.Clone() กับ Matrix m = object.Transform)
ในโปรแกรมประเภทธุรกิจที่ไม่ต้องการ performance มาก ทุกคนก็เขียน C# แบบเดียวกับที่เขียน Java แหละครับ มีแต่ class ไม่ต้องไปทำอะไรกับ struct แทบไม่ต้องเขียนจริงๆนั่นแหละ
แต่คนที่ทำงานแบบที่เรียกว่า ใช้ C# แทน C++ ทำงานประเภท performance สูงๆ จะรู้ครับว่ามัน Critical มากๆ อย่างเช่นเกม ยิ่งเป็นเครื่อง XBox (ที่ GC มันกากมาก) การเขียนโปรแกรมแบบพลิกแพลงเพื่อ performance เป็นอะไรที่สำคัญครับ และ struct นี่ตัวจี๊ดเลย ขาดไปนี่แทบจะเรียกว่าทำไม่ได้
ซึ่ง การที่ C# มี struct ผมถึงชี้ว่า เป็น "การยอมรับว่ามันโง่" มันไม่รู้ว่ามันจะฉลาดขึ้นมาเมื่อไหร่ มันถึงให้อิสระว่า มีเครื่องมือให้เขียนโปรแกรมแบบล้วงลึกไปถึงระดับการควบคุม Memory ให้
การ "มี struct" และ "รู้จักใช้" เป็นข้อถกเถียงจากฝ่าย C# มานานแล้วครับว่า ต้องการให้ Java มี struct ไปเพื่ออะไร ลองไปหาอ่านดูได้ครับ มีคนอธิบายไว้เยอะมากว่าทำไม Java ถึงควรมี struct เหมือน C#
ถ้าต้องการ raw performance มันก็มี JNI ให้ใช้อยู่แล้วนี่ครับ??
รู้จักคำว่า OverHead มั้ยครับ?
ก็เป็นซะแบบนี้อะครับ สาวกจาว่า ต้องพยายามโยนไปโน่นมานี่เพื่อที่จะบอกว่า Java ใช้ได้อยู่แล้ว
นี่กำลังพูดกันถึงเรื่อง DALVIK/JVM มันช้า ไหนบอกว่า DALVIK ฉลาดนักหนา
สุดท้ายก็ต้องโยนไปหา Native อยู่ดี
ถามว่าผมรู้จัก overhead ไหม ก็รู้สิครับ ใน rep ข้างบนก็ยังพูดถึงอยู่เลย ว่าแต่ได้อ่านที่ผมเขียนหรือเปล่า?
แล้วก็มาอ้างเป็นเรื่องการเมืองอีกละ ก็ในเมื่อระบบมันมีช่องทางให้ใช้อยู่แล้วสำหรับบาง case ถ้าคุณดันไม่รู้จักจะใช้ซะเองแล้วจะมาบ่นหาพระแสงอะไรครับ?
ในความเห็นผม ทุกภาษาทุกระบบมันไม่มี perfect หรอกครับ ย่อมต้องมีข้อดีข้อเสีย ถ้าอ้างแบบคุณ งั้นทำไมไม่ใช้ assembly ไปให้มันรู้แล้วรู้รอดล่ะครับ?
ถ้ารู้จักคำว่า OverHead ก็แปลว่าควรจะรู้อยู่แล้วนะครับว่าการใช้ JNI มีปัญหาเรื่องการทำงานกับ struct เพราะในฝั่ง Native การมี struct เป็นเรื่องธรรมดา แต่ใน Java ใช้ JNI ก็ต้อง Serialize จาก class ซึ่งตรงนี้ก็เป็นปัญหา Performance อีกเช่นกัน
ซึ่งต่างกับ .NET ที่สร้าง struct ให้ Map กับ struct ใน Native ได้โดยตรง แถมยัง pass struct by reference ได้ตรงกับ Native ได้ด้วย พูดแบบไม่เกรงใจเลยว่าแม้แต่เรื่องนี้ .NET ก็ทำมาดีกว่า เพราะไม่ได้อวดฉลาดมาแต่แรก
แล้วด้วยฟีเจอร์เดียวกัน ในขณะที่ .NET ทำได้โดยตรง แต่ Java ต้องเลี่ยงไป Native นั่นผมไม่เรียกว่าช่องทางครับ ผมเรียกว่าเลี่ยงบาลี ไหนโม้นักหนาว่า มันจะเร็วแค่ไหนขึ้นอยู่กับความฉลาดของ Virtual Machine? สุดท้ายก็ต้องโยนเอาความเร็วไปวิ่ง Native แล้วที่โวยวายแทบตายว่า DALVIK ไม่ใช่ปัญหานั่นมันคืออะไร?
ก็ถึงได้เรียกว่า Virtual Machine อวดฉลาด สุดท้ายก็ต้องโยกไปใช้ Native ผ่าน JNI แต่พอถามถึงทีไรก็โม้ตลอดว่า Java เร็วส์
สรุปว่าปัญหาของคุณคือแค่ไม่มี struct ให้ใช้ใน java ใช่ไหมครับ ก็เลยจะเป็นจะตายเอา? แน่นอนว่าการมี struct ทำให้เขียนโปรแกรมให้เข้าใจได้ "ง่ายขึ้น" สำหรับคนที่ตีกรอบไว้แล้วว่าต้องการจะใช้ struct แต่กลับกันก็เมื่อรู้อยู่แล้วว่าภาษามันไม่มีให้ใช้ ก็ต้องไปหาทางแก้ปัญหาเดิมโดยที่ไม่ต้องใช้ struct สิครับ
เอาง่ายๆ native opcode มันมี struct ไหม? ท้ายที่สุดแล้ว C มันก็ต้อง compile ออกมาเป็นภาษาเครื่อง (native opcode) อยู่ดี แล้วทำไมมันทำงานได้ครับ?
แล้ว Java มีปัญญาเขียน Native OpCode ในรูปแบบเดียวกับที่ C หรือ C# เขียน struct แล้วคอมไพล์ออกมาเป็น OpCode แพทเทิร์นนั้นได้มั้ย? นี่แหละคือประเด็นว่าทำไม C หรือ C++ และ C# มี struct ให้ใช้ การที่มันเขียน struct ลงไป ก็ทำให้การ compile ออกมาเป็น OpCode แพทเทิร์นที่ Optimize ได้
นั่นคือสิ่งคน Java ฝันว่า JVM มันจะทำได้อัตโนมัติ แต่ความจริงคือรอไปชาติหน้าก็อาจจะยังทำไม่ได้ ในขณะที่ C# ทำได้เพราะปล่อยให้โปรแกรมเมอร์เลือกเอง
ถ้าหากว่า Java มีวิธีพลิกแพลงแก้ปัญหาให้เขียนโปรแกรม Simulation หรือ Graphic แบบ High Performance ได้ คงมีเกม 3D เน้นกราฟฟิค ทำด้วย Java เกร่อเต็มตลาดไปนานแล้วครับ (C# ยังพอมี)
ไอ้คำว่าภาษาไม่มีให้ใช้นั่นแหละประเด็น ทำไมภาษามันถึงต้องไม่ให้ใช้ล่ะ ทั้งๆที่จะทำมันก็ทำได้ ในขณะที่ภาษาอื่นเขามีให้ใช้ และทำไมพวกคุณต้องมาคอยแก้ตัวให้ภาษานี้ การที่ไม่มีฟีเจอร์ที่เขาใช้งานจริงมันควรจะถือเป็นจุดด้อยที่ควรแก้ไข ไม่ใช่แก้ตัวไปเรื่อยๆ
และนี่คือจุดที่ทำให้ผมเรียก Java ว่าอวดฉลาด มันต่างกันตั้งแต่พื้นฐานแล้วว่า Java อวดฉลาดไปหมดทุกอย่าง ไอ้นั่นก็ไม่ต้อง ไอ้นี่ก็ไม่ต้อง JVM เทพ ไม่ต้องห่วงปัญหา Performance แต่พอต้องใช้จริงๆกลับไม่มีปัญญาทำอะไรหลายอย่างอยากที่โปรแกรมเมอร์อยากให้มันเป็น สุดท้าย Performance ก็ไม่ถึงขั้น
ในขณะที่ C# .NET มีให้ใช้เท่าที่ Java มี แต่ยอมรับว่าตัวเองโง่ ไม่อวดฉลาดว่า ตัวข้าทำเองได้ โปรแกรมเมอร์ไม่ต้องยุ่ง แบบที่ Java ชอบทำ ก็เพิ่มฟีเจอร์ให้เลือกใช้ จะใช้ไม่ใช้ก็ได้แต่ถ้ารู้จักใช้ก็จะมีประโยชน์ ทำงานออกมาได้โปรแกรมที่มีประสิทธิภาพมากขึ้นได้
และอย่าลืมว่า JNI มันไม่ใช่ใช้ได้ทุกที่ ในขณะที่ struct เป็นของธรรมดาใน .NET คิดจะใช้ JNI แล้วพอร์ทไม่ได้ทุกที่ ที่โม้นักหนาว่า Run Anywhere ล่ะ?
สุดท้าย
คุณอย่าลืมว่าที่มาเถียงคนอื่นอยู่นี่เพราะตัวเองโม้ว่า DALVIK มันเจ๋งเมพ ประสิทธิภาพสูง Java เร็วส์ พอไล่เข้าจริงๆก็หนีไปอ้าง JNI แล้วมันเกี่ยวกับ DALVIK ตรงไหน? ไหนว่า DALVIK มัน MegaClever ฉลาดสุดๆ สามารถ Generate Code ออกมาได้มี Performance สูงสุดเทียบเท่า Native และ Garbage Collector ก็มีประสิทธิภาพ แล้วทำไมยังต้องพึ่ง JNI อีก?
อย่าพูดชุ่ยๆสิครับ ทำไมเอาสิ่งที่ผมไม่ได้พูดมายัดใส่ปากผมอย่างงี้ล่ะ? ผมไปบอกคุณตอนไหนว่า dalvik มันเจ๋งเทพ มันเร็วกว่าใคร มันฉลาด megaclever ไม่มีใครเหมือน? กลับไปอ่านดูก่อนไหมครับ?
แน่นอนมันไม่ได้เจ๋งเทพ แต่มันก็ไม่ได้ห่วยโคดๆแบบที่คุณว่าหรอกครับ แล้วก็ยังมีการพัฒนามาอย่างต่อเนื่อง app ที่เคยเขียนให้รันใน android เวอร์ชันเก่าๆ เมื่อมารันบน android เวอร์ชันใหม่ๆ แม้จะเป็นฮาร์ดแวร์เดิม มันก็เร็วขึ้น สิ่งเหล่านี้มันเกิดขึ้นได้จากการเขียน native code ไหมครับ?
JNI เป็นสิ่งจำเป็น เหตุผลสำคัญเป็นเพราะว่า java มันติดต่อ hardware โดยตรงไม่ได้ และอีกอย่างการที่มันมี JNI ยังไม่เป็นการบอกอีกหรือว่ามันไม่ได้ "อวดฉลาด"
ยังไงๆ ผมก็ยืนยันว่า Bytecode ห่วยกว่า Native แน่นอนครับ
ถ้าจะหักล้าง คงต้องทำให้ App ของ Android กับ Java มันเร็วเท่าๆ กับ Native app ให้ผมเห็นนะครับ
แต่พอดีผมยังไม่เคยเห็นว่า Bytecode ตัวไหนนอกจาก .NET ที่มันจะเร็วพอๆ กับ Native น่ะครับ
ถ้าพิสูจน์ให้คนทั้งโลกเห็นไม่ได้ ผมก็ยังจะบอกว่า Java เร็วส์ ตามเดิมครับ
บอกได้ร้อยแปดว่าทำไมมันไม่ลื่น แต่สรุปแล้วก็ไม่สามารถทำให้มันลื่นได้
แล้วจะบอกเพื่อ ?
หรือว่าจะได้ให้รู้ว่า มันไม่มีวันจะลื่นได้ เพราะเหตุผลร้อยแปดที่บอกมา
จงยอมรับ และอยู่กับมัน
เสียงจากนักศึกษาฝึกงาน Follow up to “Android graphics true facts”, or The Reason Android is Laggy
ผมอยากให้เขามาอธิบายบ้างว่าทำไมแอนด๋อยถึงสูบแบตมากกว่า ios
เพราะมันใช้พลัง CPU มากกว่าคับ และ CPU วิ่งที่เต็มความเร็ว ไม่เหมือน iPhone ที่ Under clock ลงมา
อยากให้กูเกิลพัฒนาอัลกอริทึมให้ทัดเทียม ios ไม่ต้องใช้ clock ไวสุดๆ ก็ทำงานได้ไวได้เหมือนกัน บางอย่างมันช้ากว่าขนาดน่าเกลียด แบบ export clip 1080p
ยกเว้นตวเลข cpu เป็นจุดขายของโทรศัพท์ทุกวันนี้ไปแล้ว ไม่ใช่ว่าใช้จริงเร็ว ลื่นขนาดไหน
สุดท้ายก็ kill ALL the process !!
twitter.com/djnoly
ปัญหาหลักตอนนี้มันไม่ได้อยู่ตรงนั้นคับ แต่มันอยู่ที่ Virtual Machine vs Native
มีคนที่อ้างตัวว่าเคยเป็นเด็กฝึกงานของ Google (แต่ตอนนี้ฝึกงานอยู่ Microsoft) บอกว่า เหตุผลที่มันไม่ลื่นเพราะ Android วาด UI Element บน Main Thread แทนที่จะมี UI Thread แยกออกมาเหมือน Mobile OS อื่น ๆ
ส่วนตัวผมไม่ค่อยเชื่อเท่าไหร่ เพราะ OS เก่า ๆ เขาก็วาดบน Main Thread กัน ก็ไม่เห็นกระตุกหนักมากเลย (โดยเฉพาะ Windows 555) แต่อาจจะจริงก็ได้ ใครจะไปรู้
หืมมมม ที่เค้าพูดมาก็ฟังดูมีเหตุผลเหมือนกันนะ (ถ้าเป็นแบบนั้นจริง)
เรื่อง priority ของ Thread ที่ render graphic ว่าของ iOS จะเป็น high แย่งทรัพยากรอันอื่นได้ หยุด process อื่นๆไว้ก่อน graphic มาก่อนเท่านั้น
แต่ของ android เป็น normal แล้วทำพร้อมๆกับอันอื่น(จับปลาสองมือ?) เลยไม่ลื่นเท่า iOS
คือ ผมเห็น Windows เองเนี่ยก็มีหลาย ๆ โปรแกรมที่มีงานที่ทำงานอยู่บน UI Thread (ซึ่งเอาเข้าจริง ๆ มันก็คือ Main Thread แหละ) แต่เราเองก็ยังเห็นอาการอืดระดับ Mouse กระตุกอยู่น้อยมาก (เคยเห็นบ้างแต่ไม่เยอะ ส่วนใหญ่ก็คือตอน CPU กินไป 100%) ถึงโปรแกรมจะค้างไปเลยก็เถอะ 555 คิดว่าตรงนี้ควรยกความดีความชอบให้ Thread Scheduler น่ะครับ
ถ้าเป็นอย่างที่เค้าว่าจริง ๆ วิธีแก้ก็คงเป็นออก Programming Model ใหม่ ให้โยกเอา Logic ทั้งหมดแยกไปอีก Thread ไปเลย แล้วก็เช็คเอาว่าเป็น Model ใหม่หรือเปล่า ถ้าใช่ก็ยกระดับความสำคัญของ Thread ขึ้นเป็น Real-time (ถ้าไม่ก็ทำตามวิธีปรกติไป)
สรุปสั้นๆ ณ เวลานี้ นี่คือเหตุผลที่ Android ยังไม่ลื่นเท่า iOS
ส่วนในอนาคตก็ยังไม่มีใครรู้
เห็น IOS มันลื่นหัวแตก มาตั้งแต่เกิด
WP7.5 ก็ลื่นหัวแตก ของผมตกพื้นไปแล้วรอบนึง ลื่นมากกก
คำตอบของข้า คือ ประกาศิต
เคยลองเล่น HD7 อยู่ซักแป้ป รู้สึกว่ามันเร็วกว่า iOS จริงๆ
เพื่อนผม ไม่ต้องแมงโก้เลย เดิมๆ 7.0 ก็ลื่นเหมือนกันนะครับ
ซื้อมาไม่กี่วันลื่นหล่นตกบันได เลย
ต้องขึ้นต้นด้วย
"A: วันก่อนครับ"
ด้วยหรือเปล่าครับ
+1 อิอิ
iPod Touch (Gen1) ของผมไม่ได้ลื่นมากนะครับ คือก็ลื่นแบบไม่กระตุก แต่ก็ไม่ได้เร็วชนะเลิศอะไร
ชื่อสกุลเท่มากครับ Hackborn
สงสัยเกิดมาเพื่องานสายนี้โดยเฉพาะ
นั่งอ่านมาหลาย Comment เพิ่งเจอคนที่คิดเหมือนกัน 555
Achievement Unlocked: Being a Blognone's Writer
ต้องหยอดน้ำมันถึงจะลื่น โดนตบ
แล้ว....แก้ยังอะ สรุปคือแก้ได้แล้ว หรือ ไม่ได้ 5555
"When you're the janitor, reasons matter," Jobs tells newly minted VPs, according to Lashinsky.
"Somewhere between the janitor and the CEO, reasons stop mattering," says Jobs, adding, that Rubicon is "crossed when you become a VP."
ปัญหาจริงๆน่าจะอยู่ที่ render architecture ของ android เองด้วยครับ จริงๆ เราสามารถถกกันได้ดีกว่านี้ถ้าเรามีข้อมูล render architecture ของ android แบบละเอียด
จะมีตอนต่อเปล่าหว่า ว่าทำไม iOS , Windows Phone ถึงลื่น
ส่วนมากก็เห็นคนใช้แอนดรอย์ดบอกว่าลื่นกว่า iOS ทั้งนั้นนิหว่า ชักงงๆ
ส่วนใหญ่ก็จะเป็น Custom ROM ที่โมฯมาไม่มากก็น้อยแหละครับ
Official ของค่ายที่ทำดีๆอย่าง HTC , SE ก็ยังมีหน่วงๆเป็นบางจังหวะให้เห็นชัดเจนกว่า iOS
ส่วนฝั่ง iOS ก็จะบอกว่า เอ็งใช้ CPU แรงกว่านี่
(เพราะตัวเทียบในปัจจุบันคือ 2 Core vs. 1 Core)
ป.ล. ยังไม่นับ 4S ครับ เพราะยังไม่แพร่หลาย
ลื่นจะตาย (Rom XDA) มีแต่ market ตัวใหม่ อืดมาก
+100 ชอบที่มันสวย แต่เกลียดตรงมันอืด
Destination host unreachable!!!
ลื่นไม่ลื่นมันอยู่ที่ใจ :P
ผมใช้ Galaxy Nexus มาสองวันแล้ว มันลื่นมากจริงๆ เท่ากับ iOS เลยครับ
เครื่องก่อนหน้านี้ไม่ต้องพูดถึง กระตุกกันเป็นนิจ
ปล.ผมใช้ iPhone4 คู่กันด้วยนะครับ
คนทั่วไปไม่มีใครอยากรู้หรอกว่าทำไมมันถึงไม่ลื่น คำตอบที่ให้มานี่ไม่ช่วยให้อะไรดีขึ้นมาเลย แถมยังย้ำแผลเดิมหนักกว่าเก่าว่าทั้งๆที่รู้แต่ก็ยังไม่มีปัญญาแก้ปัญหาอีกด้วยซ้ำไป
เค้าอยากได้คำตอบว่าเมื่อไหร่มันจะลื่นมากกว่า (เอ้ะ หรือจะเป็น มันจะลื่นได้มั้ย) ต่างหากล่ะ!
ชื่อ : Not Available at this Moment (N/A)
+1
กูเกิลควรทำ home screen ที่เป็นภาพ prerender เหมือน ios ออกมาบ้างนะ ถึงจะทำไรไม่ได้เลยนอกจากวางไอค่อน แต่มันก็ลื่นเหมาะกับการโชว์
5 5 5 เห็นภาพเลย
หายสงสัยละทำไม hardware แร๊งแรง แต่ทำไมเลื่อนๆละมันกระตุกๆนิดๆ
ใช้ iPhone ต่อไป กี่รุ่นๆก็ลื่นไม่มีกระตุกให้ขัดใจ ^^
เกี่ยวกับ android มีพวก Widget ต่าง ๆ และ Process เบื้องหลังที่ทำงานพร้อม ๆ กันเยอะกว่า iPhone หรือเปล่า? ของ iPhone ผมเปิดดูไม่เป็น แต่เห็นว่าของ Android มันเยอะมาก (คือสงสัยว่างานอย่างเดียวกันแต่ Android อาจใช้ Process ที่ซับซ้อนกว่า หรือใช้ทรัพยากรมากกว่า)
มีผิดตรง
iOS4 ผมมีประมาณ 30 Procress เวลาไม่เปิด App ใดๆเลยครับ
ชื่อ : Not Available at this Moment (N/A)
ไม่เกี่ยวครับ อันนั้นเป็นพวก system service
ที่ช้าจริงๆคือแอพที่รันเป็น service แล้วเขียนห่วยๆนี่แหละตัวปัญหา
ผมว่าอาจจะเกี่ยวเหมือนกันนะ เพราะถึงจะเป็น System service แต่ถ้ามันเขียนห่วยเหมือนกัน ก็อาจจะเป็นปัญหาได้หรือเปล่า?
จริง ๆ ปัญหานี้อาจจะเป็นเพราะ... คนใช้ iphone นิ้วมันกว่าเลยทำให้ลื่นกว่าก็ได้ :P
ปกติ system service ก็เขียนมาดีนะครับ อ้อ ยกเว้น home screen ของผู้ผลิตแต่ละห้อที่ขยันกันยัดเข้ามา อย่างเช่น touchwiz ตัวแรก ห่วยบรม
แต่ที่คุณ NA ว่ามาน่าจะหมายถึงตอนรันคำสั่ง ps มากกว่าครับ ซึ่งพวกนั้นเอามาวัดไม่ได้ครับ เพราะมันมีเยอะแยะตั้งแต่ init ยัน filesystem เลย แถมแต่ละตัวก็ไม่ค่อยได้ทำงานเท่าไหร่ครับ
ที่แน่ๆ ios มันลื่นกว่าชัวร์ เพราะนอกจากของ apple เองหรือที่ผ่านการตรวจสอบแล้ว app อื่นๆไม่สามารถรันเป็น background service ครับ อย่าว่าแต่ background service เลยครับ แค่จะสลับหน้าต่าง multitask ยังโดน freeze เลย ไม่ได้เป็น multitask จริงๆสักนิด
ชื่อเล่นน่ารักดีครับ NA (นา) ชื่อเต็มมันยาว :)
ย่อหน้าล่างที่ว่าผมก็คิดว่าน่าจะเกี่ยวเหมือนกัน
N/A ก็ยังดีนะ สั้นเกิ้นนน --"
ชื่อ : Not Available at this Moment (N/A)
ผู้ใช้เขาไม่ได้อยากรู้หรอกว่าเพราะอะไรถึงไม่ลื่น จงไปแก้มาให้มันลื่นซะ ทำไม iOS มันทำได้
Blognone ไม่ใช่เว็บสำหรับผู้ใช้ทั่วไปนะครับ อยู่ผิดเว็บหรือเปล่า?
แรงส์!
"With the first link, the chain is forged. The first speech censured, the first thought forbidden, the first freedom denied, chains us all irrevocably."
+1 T^T
ตอนแรกไม่มั่นใจครับ แต่ตอนนี้คิดว่าใช่แล้ว ที่นี่น่าจะเป็นโรงเรียนมัธยมแห่งหนึ่ง เพราะเห็นคนแถวนี้ชอบเอาชนะความเกรียนด้วยความเกรียนกว่าเสมอ ๆ
x
Russia is just nazi who accuse the others for being nazi.
someone once said : ผมก็ด่าของผมอยู่นะ :)
Android Fanboy เริ่มเข้าใกล้สาวกแอปเปิ้ลเข้าไปทุกวันแล้ว แตะต้องมิได้เลย
OS ขั้นเทพ Hardware ขั้นเทพ จับต้องควรระวัง
Android เล่นทำ หน้า Home แถมยังกดปุ่มให้เข้าไป Menu App ไว้อีก ก็ประมวลผลไป 2 ชั้น
แถมยังมี Widget / Shortcut นู้นนี่เยอะแยะ มีตัว Launcher ให้ประมวล หนักๆ - -*
ลืม Noticifation bar
ส่วนพวก iOS / WP7 / Meego 1.2 Harmattan มันลื่นๆ เพราะ ไม่ได้ซับซ้อนแบบ Android
ถ้าอยากเห็น Android ที่ลื่นๆ ลองดู Rom MIUI เค้าทำเป็นสไตล์ iOS เรียบๆ ง่ายๆ ไม่มีการกดเข้า Menu นู้นนี่
เลยทำให้มันลื่น (แต่เพราะไม่มีนี่แหละ มันเลยเหมือนไม่ใช่ Android)
OS แต่ละตัวก็มีเสน่ห์ของมันครับ
Android มันยืดหยุ่นดี ปรับเปลี่ยนได้ตามใจ แต่ความลื่นก็ขึ้นอยู่กับงบของเรา ได้เครื่องแรง ก็ใช้ OS ได้คุ้ม ยิ่งได้เห็น ICS ยิ่งดูดีขึ้นเยอะ ล้ำมาก
WP7 ก็แหวกแนว UI ลื่นดี เพราะมีแค่แท่ง 4 เหลี่ยมเลื่อนไปมา (ใช้ๆ ไปเบื่อเพราะมันปรับเปลี่ยนอะไรไม่ได้เลย -*-)
iOS ก็ดีที่ปรับเปลี่ยน Wallpaper รูปแบบหน้าจอ ต่างๆ UI ยังลื่นหัวแตก ยังไงก็ยกให้เค้าเป็นที่ 1 ทำทุกอย่างออกมาได้สวยงาม ตั้งแต่ Version แรกยันล่าสุด ยังไงก็ยังเหมือนเดิม (แถมยังเป็นที่รักของชาวโลก 555)
Meego 1.2 Harmattan ก็คล้าย iOS ผสมกับ WP7 เลย เรียบง่าย Meego 1.2 ได้แสดงให้เห็นว่า แม้ Spec เครื่องจะกาก แต่ก็ไม่มีหน่วงเลย Touch ได้ติดมือ แถมยังเด่นที่ MultiTasking ของเค้าดี (ตอนนี้ผมหยุดอยู่ที่ N9 ^^)
Meego ตัวธรรมดา เหมือนลอก Android กับ Symbian มาชัดๆ (อย่าพูดถึงเลย ตายไปแล้ว)
จริงๆ Live tiles ของ WP7 นี่ก็ดูไม่ต่างกับ Widget ของแอนดรอยด์มากนะครับ มันก็ปักอะไรลงไปได้ แล้วก็ทำงานดึงข้อมูลอะไรออกมาแสดงได้เหมือนกัน จริงๆมันก็เป็น Widget แบบสี่เหลี่ยม กินพื้นที่ช่องหรือสองช่อง แบบแอนดรอยด์นั่นแหละครับ
เมนูก็ต้องกดเข้าไปอีกขั้นเหมือนแอนดรอยด์
แค่อยากจะบอกว่า แท่งๆ ในหน้าจอหลักของ WP7 นั้นมันทำหน้าที่ทั้ง widget และ Notification ครับ ซึ่งมัน real time มากทีเดียว ดู FB จาก People hub ได้ทันที chat (FB,MSN,SMS) โดยไม่ต้องลงไรเพิ่มเลย
ที่ขัดใจตอนนี้ ผมว่าภาษาไทย
+1 ภาษาไทยโอเคเมื่อไหร่ ผมสอยทันทีเลย
ผมรอwp7ตัวที่รัน mkv ได้
คงไม่มีวันแล้วหล่ะครับ
เพราะ ทุกโปรแกรมที่ต้องการเล่น Music or Video ต้องเล่นผ่าน Zune ซึ่ง Zune ก็ทำงายได้แค่ WMV กับ MP4 ผ่าน DXVA อีกต่อนึง
ดูจาก โครงสร้างแล้ว ยากครับ สำหรับ Code แบบอื่น
ไม่ต้องรอแล้วครับ ซื้อเลย
Microsoft มีโปรแกรมสำหรับ Convert Video คือ Microsoft Expression Encoder 4 SP1 ซึ่งใช้ได้ฟรี ไฟล์เล็ก ภาพชัด แต่ ความยาว ไม่เกิน 10 นาที ถ้าอยากได้นานกว่านั้น ต้องเสียเงิน
ดราม่า