PDA

توجه ! این یک نسخه آرشیو شده میباشد و در این حالت شما عکسی را مشاهده نمیکنید برای مشاهده کامل متن و عکسها بر روی لینک مقابل کلیک کنید : از لگ های اندروید خسته شده اید ؟



r_you168
29-12-2011, 23:14
این مقاله برای فرم دیگه نوشتم گفتم اینجا هم بزارن شاید سطح افت کرده علمی سایت تکونی بخوره از این وضع . یه ادامه هم در مورد این که چرا UI اندروید GPU قوی تری نیاز داره هم باید اضافه کنم که فعلا وقت ندارم



ابتدای امسال Charles Ying (دولوپر بFlipboard) به طور منصفانه و دقیق pipeline نابالغ گرافیک اندروید و عواقب آن براجرای ضعیف drawing مورد انتقاد قرار داد


Android’s UX architecture needs work. UI compositing and the view system are both primarily done in software. Garbage collection and async operations frequently block UI rendering.



متن کامل
(http://www.satine.org/archives/2011/01/01/the-care-and-feeding-of-the-android-gpu/)





Android pre-3.0 (http://en.wikipedia.org/wiki/Skia_Graphics_Engine) جایی که مشگل شروع می شود




همان طور که Charles در مقاله اشاره کرده , عناصر اولیه 2d (جعبه عکس متن خط نمودار .....) استفاده شده برای ساختن نمای یک برنامه در اندروید , همگی drawn/rasterised انجام شده روی CPU به وسیله موتور گرافیک Skia هستند (قبل از pre-3.0 ) و محتوا ی هر نما قبل از ارسال به صفحه نمایش در GPU ترکیب و ساخته می شود
Drawing روی CPU به تنهایی مشگل ساز نیست . همان طوری که Quartz 2D (معادل Skia در IOS) اکثرrasterisation ها را روی CPU انجام می دهد و اینترفیس کاملا روان در IOS مشاهده می شود . خوب اگرمشگل از drawing روی CPU نیست, پس کجاست ؟



http://forum.mobilestan.net/attachment.php?attachmentid=670477&stc=1&d=1325188873



تمامی سلسله مراتب رسم مجدد یا redrawn روی CPU انجام می شود. برای هر تکه کوچک از چرخه رندر,( اگر نما تغییر کند) این کار تکرار می شود
Scroll لیست و Pinch & zoom و .... احتیاج به رسم مجدد ( redrawn ) برای هر نما دارند.
تا این قسمت هم مشگلی نیست در صورتی که توانایی انجام این عمل به طور پیوسته باشد . شما باید نما های کشیده شده روی CPU و کپی پیکسل ها رو با سرعتی به GPU انتقال بدید که سکته یا Lag در صفحه نمایش با ریت 60hz مشاهده نشود.اکثر گوشی های اندروید دارای سخت افزار پردازشی قوی با پهنای باند حافظه بالا (pipeline ) برای انتقال , توانایی انجام این کار را دارند (یا حداقل بیشتر مواقع ). این جواب داده شده به این سوال توسط گوگل است ! (شاید این راه حل برای گوگل ایده ال باشد ولی روانی کمترنسبت به رقبا با این روش کاملا مشهود است )
حالا اندروید را روی صفحه بزرگتر تبلت و TV اجرا کنید . صفحه بزرگتر مساوی با پیکسل بیشتر و پیکسل بیشتر مساوی با مشگل جدی با pipeline
این مشگل به روشنی توسط Romain Guy’sدر گوگل I/O 2011 (معرفی هانی کامب) توسط این گراف توضیح داده شد.




http://forum.mobilestan.net/attachment.php?attachmentid=670478&stc=1&d=1325188937



نکته جالب این گراف مشخص شدن عدم پهنای باند حافظه کافی برای انتقال pixel buffers به GPU در نکسوس وان هم هست .نکسوس اس با توجه به سخت افزار بهتر تا حدی بهتر از نسل ها قبلی خود بود و در عمل هم روانی نکسوس اس تاییدی بر این گراف هست. ,وضعیت XOOM در این گراف روشن کرد که برای حل این مشگل باید کاری کرد و جواب قبلی گوگل کافی نیست

راه حل چیست ؟

وقتی شما یه لیست را scroll می کنید پیکسل های موجود در نما تغییر نمی کنند بلکه خیلی ساده جا به جا می شوند .این یعنی GPU تمام پیکسل های نما را به صورت texture دارد.خوب چرا این texture را حرکت ندهیم ؟!!
این دقیقا همان کاری است که در IOS انجام می شود و هیچ وقت از عواقب rasterisationروی CPU اثر دیده نشده (LAG)




http://forum.mobilestan.net/attachment.php?attachmentid=670479&stc=1&d=1325189397




در مثال scrollingنما خیلی ساده بالا پایین می رود ولی همچنین می توان نما را (که به صورت texture برای GPU در آمده ) چرخاند , به شکل سه بعدی در آورد , کوتاه کرد ..... یا حتی pixel shaders استفاده کرد . همه این کار ها بدون نیاز به دوباره رسم شدن نما ( redraw ) توسط CPU و فرستادن textureجدید به GPU می توان انجام داد و در نتیجه پهنای باند حجیم برای این انتقال لازم نیست و دیگر از لگ هم خبری نخواهد بود و کلیه عملیات توسط GPU انجام می شود




http://forum.mobilestan.net/attachment.php?attachmentid=670480&stc=1&d=1325189298




اولین قدم اندروید



در معرفی هانی کامب اولین قدم برای کاهش این فاصله بین اندروید و IOS بر داشته شد. API level 11 همراه هانی کامب به دولوپرها این امکان را می داد که پهنای باند hardware accelerated استفاده کنند البته این API دارای محدودیت های بود وبه صورت پیش فرض غیر فعال
در معرفی ایسکریم , hardware accelerated برای اولین بار به گوشی های اندرید راه پیدا کرد و به طور پیش فرض توسط API level 14 در تمام قسمت های سیستم عامل فعال است .نسخه ایسکریم از این جهت اولین نسخه از اندروید است که hardware accelerated در آن استفاده شده و API level 14 اصلاح شده در اختیار سیستم عامل قرار گرفته.

یک قدم جلو تر !

Skia علاوه بر آماده کردن bitmap در طی عملیات CPU-rasterised , یک لیس مرتب شده نیز از عملیات های انجام شده را آماده می کند.هر نما حاوی یک لیست از این عملیلت ها هست (Displaylist)
در اندروید نسخه هانی کامب OpenGL-ES Skia backend معرفی شد که هر کدام از این لیست ها (Displaylist) ر ا گرفته و عملیات ها روی GPU انجام می دهد . این تکنیک نگه داری لیست مرتب شده عملیات رسم (drawing) , تقریبا مکانیزمی شبیه گراف PDF مورد استفاده اپل در Mac OS X 10.4 دارد .
Quartz 2D Extreme در مک OS این عمل را در شکلی دیگر نزدیک به OpenGL-ES Skia backend در اندروید انجام می دهد . هنوز این قابلیت به IOS به ارث نرسیده ولی انتظار زیاد طولانی نخواهد بود

توضیح بیشتر

گراف زیر بهبود سرعت حاصل از استفاده از این روش را نشان می دهد




http://forum.mobilestan.net/attachment.php?attachmentid=670481&stc=1&d=1325189168



نتیجه گیری :

بعد معرفی جینجربرد و انتقادات بسیار دولوپرها به تغییر نکردن نوع سیستم قدیمی گرافیک اندروید و جواب سربالای گوگل مبنی برا اکثر گوشی های اندروید در اغلب موارد می توانند ! بدون استفاده از gpu به 60 فرم در UI برسند ....., نسخه هانی کامب اندروید اولین قدم گوگل برای پذیرش این مشگل و حل آن بود و همان طور که در سایت اختصاص داده شده به دولوپرها اندروید ذکر شده , قدم اول در هانی کامب برداشته شده و در ایسکریم اصلاحات جزیی برای قابل استفاده کردن این قابللیت برداشته شده و اصلاحات درنسخه بعدی ادامه خواهد شد
باید دید این جمله اندی رابین هنگام معرفی بی صدای ایسکریم چقدر در عمل حس خواهد شد (یک فیلم کوتاه از ایسکریم روی گلاکسی نکسوس)


We want everything to be smooth as butter
ما می خواهیم همه چیز به روانی کره باشد !




برداشت آزاد از منایع :

Skia Graphics Engine - Wikipedia, the free encyclopedia
satine.org – The Care and Feeding of the Android GPU
Android Developers Blog: Android 3.0 Hardware Acceleration
Android Developers Blog: Android 4.0 Graphics and Animations
Cocoa with Love: Mac QuartzGL (2D drawing on the graphics card) performance

luckylock_2005
30-12-2011, 00:13
این لگ ها واقعا مشکل قابل چشم پوشی نیستن.وقتی مقایسه می کنید و میبینید آیفون 3gs با سخت افزار مربوط به 3 سال پیش از 2 هسته ای های آندروید اسموث تر هستش یعنی این واقعا یه مشکل بزرگه.امیدوارم این شتاب دهنده ی سخت افزاری که توی ui ازش استفاده شده در ایس کریم واقعا بتونه مشکلو حل کنه.

mido-mido
30-12-2011, 10:16
این لگ ها واقعا مشکل قابل چشم پوشی نیستن.وقتی مقایسه می کنید و میبینید آیفون 3gs با سخت افزار مربوط به 3 سال پیش از 2 هسته ای های آندروید اسموث تر هستش یعنی این واقعا یه مشکل بزرگه.امیدوارم این شتاب دهنده ی سخت افزاری که توی ui ازش استفاده شده در ایس کریم واقعا بتونه مشکلو حل کنه.

این ویژگی اگه اشتباه نکنم توی هانی کامب هم گفتن استفاده شده...ولی من روی تبلتم با اینکه اخرین ورژن رو دارم ولی بازم لگ دارم....گمون نکنم زیاد جواب بده این ویژگی...

luckylock_2005
30-12-2011, 11:30
این ویژگی اگه اشتباه نکنم توی هانی کامب هم گفتن استفاده شده...ولی من روی تبلتم با اینکه اخرین ورژن رو دارم ولی بازم لگ دارم....گمون نکنم زیاد جواب بده این ویژگی...

آره منم روی ترنسفورمر بازم لگ رو احساس می کنم. اگه Live wallpaper استفاده کنم که دیگه شدید تر هم میشه. ولی ظاهرا باز اومدن API level رو آپدیت کردن و به صورت دیفالت توی اینترفیس آیس کریم این قابلیت استفاده از شتاب دهنده رو گذاشتن.ویدیو های گلکسی نکسوس رو دیدم واقعا اسموت بودش.