من دانشجوی سال سوم لیسانس در رشته مهندسی نرم افزار هستم، که مدتی را با Romain Guy -- کسی که مسئول اصلی شتاب دهنده سخت افزاری بکار گرفته شده در Honeycomb بود -- روی اندروید کار کردم. البته من در تیم فریم ورک اندروید نبودم و هرگز کدهای اصلی رندرینگ اندروید را نخوانده ام. همچنین اطلاعات رسماً تأیید شده ای از اندروید ندارم، به همین دلیل نمی‌توانم  ضمانت کنم آنچه که می‌گویم صد در صد درست باشد اما سعی کرده‌ام هر آنچه که می دانم را برای شما به بهترین وجه ممکن توضیح دهم.

ضمناً  من اکنون در حال شروع به کارآموزی در بخش ویندوز فون مایکروسافت هستم و از این رو شاید آنچه که می گویم بصورت ناخواسته بر ضد اندروید گرایش داشته باشد، اما شما اگر از دوستان من بپرسید خواهید فهمید که من چقدر به اندروید علاقه دارم و شاید اگر جانبداریی باشد گرایش من در اصل به سمت اندروید است.

و در آخر این را هم بگویم که تمام نظرات مطرح شده در این پست، مربوط به خود من می‌شود و هیچ ارتباطی با کارفرمایان گذشته و حالم ندارد.

حال بیایید این بررسی را با نقل قول Dianne Hackbor (یکی از اعضای اصلی تیم برنامه نویسی اندروید) در مورد واسط کاربر اندروید آغاز کنیم. Dinne در ابتدای پست خود می گوید:

«در باب ترسیمات داخل یک پنجره (Window) در اندروید، لزوماً این طور نیست که برای رسیدن به سرعت رندرینگ 60 فریم بر ثانیه نیازمند انجام رندرینگ سخت افزاری باشیم بلکه این موضوع بستگی زیادی به تعداد پیکسل داخل صفحه و فرکانس پردازنده دارد. به طور مثال گوشی نکسوس اس می‌تواند به راحتی تمام کارهای معمولی مانند بالا و پایین کردن یک لیست و ... را با سرعت 60 فریم بر ثانیه انجام دهد.»

اما این موضوع چه طور ممکن است؟ هرکس که حداقل یک بار با گوشی نکسوس اس کار کرده باشد، می‌داند این گوشی در کوچک‌ترین کارها نیز کند است و به طور کاملاً روان اجرا نمی‌شود -- حتی اگر از مواردی نظیر کاهش سرعت در زمانی که برنامه ای در پس زمینه در حال اجرا است (مثلاً نصب یک برنامه یا به روز شدن واسط کاربر از روی دیسک) صرف نظر کنیم. در حالی که آی او اس در همه حال روان اجرا می شود، حتی زمانی که برنامه ای در حال نصب شدن باشد. خب همه ما می دانیم که Dianne Hackborn درباره توان پردازشی نکسوس اس دروغ نگفته است اما بیایید بررسی کنیم که چرا روان بودن بطور کامل محقق نمی‌شود.

ریشه مشکل در کجاست:

دلیل اصلی به وقفه مرتبط با Garbage Collection (پاکسازی خودکار حافظه از محتویات بلااستفاده) بر نمی گردد. دلیل اصلی را در این مقوله که اندروید Bytecode ها را اجرا می کند و آی او اس کد بومی (Native Code) را نباید جست. دلیل اصلی که آی او اس کاملاً روان اجرا می شود، آن است که در آی او اس تمامی عملیات رندرینگ واسط کاربر در thread اختصاصی واسط کاربر با اولویت Real-Time صورت می پذیرد. اما اندروید از سیستم قدیمی موجود در پی سی‌ها که در آن رندرینگ واسط کاربر در همان thread اصلی با اولویت عادی رخ می دهد، بهره می‌برد.

این تفاوت یک موضوع ذهنی پیچیده و غیر قابل فهم نیست، بلکه هر کسی که دارای یک آیفون یا آیپد باشد می‌تواند آن را به خوبی درک کند. برای درک این موضوع کافیست روی آیفون خود، سافاری را اجرا کنید و بعد یک صفحه وب سنگین را باز کنید، زمانی که حدوداً نیمی از لود صفحه طی شد، انگشتتان را روی صفحه نمایش بگذارید. در این حال خواهید دید که پروسه لود صفحه متوقف می‌شود و تا زمانی که دست شما روی صفحه قرار دارد، آن وب سایت لود نخواهد شد. این به آن دلیل است که در آی او اس thread مربوط به واسط کاربر تمامی رخداد ها را بصورت Real-Time دریافت کرده و رندرینگ را بصورت Real-Time انجام می دهد. بنابراین اگر کاربر انگشتش را روی صفحه نمایش بگذارد، پردازش‌های دیگر قطع می‌شود تا تمام توان پردازنده معطوف رندر کردن واسط کاربر شود.

ولی اگر شما این عمل را روی اندروید انجام دهید، خواهید دید که پردازنده سعی می‌کند هر دو کار رندر نمودن صفحه وب و حرکت صفحه را در آن واحد به گونه ای نسبتاً قابل قبول انجام دهد و این موضوع در بسیاری از مواقع باعث کند شدن کلی واسط کاربر می‌شود. در اینجا یک پردازنده دو هسته ای کارآمد می تواند مؤثر واقع شود و از همین رو گوشی Galaxy S II به خاطر روان بودنش شهره شده است.

در آی او اس اگر هنگامی که برنامه ای از فروشگاه برنامه های اپل در حال نصب شدن است شما انگشت خود را بر روی صفحه نمایش قرار دهید نصب برنامه موقتاً تا زمان به پایان رسیدن رندرینگ متوقف می شود. اما اندروید سعی می کند که هر دو کار را با یک اولویت انجام دهد، بنابراین سرعت نمایش فریم ها کاهش می یابد. شما این مورد را در جای جای سیستم عامل اندروید می بینید. چرا حرکت طوماری (Scrolling) در برنامه Movies کند است؟ به دلیل آنکه تصویر کوچک مربوط به هر فیلم بصورت پویا هنگام اسکرول نمودن به فهرست فیلم ها افزوده می شود در حالی که در آی او اس این عمل پس از طی شدن تمامی گام های حرکت طوماری رخ خواهد داد [در اینجا نویسنده مطلب برخی جزئیات را در مورد آی او اس نادیده گرفته]

دلایل دیگر:

هرچند سیستم اولویت ها و threading در رندرینگ واسط کاربر اندروید مسئول بسیار از کندی‌های موجود در واسط کاربر این سیستم عامل است، اما دلایل دیگری نیز وجود دارد که در این مشکل نقش دارند. دلیل اول نبود سیستم رندرینگ سخت افزاری یا Hardware Acceleration در [نسخه های قبل از Honeycomb] اندروید است. به طور مثال بعد از به روز رسانی اندروید روی گوشی نکسوس اس به نسخه 4، سرعت تمام قسمت‌ها تا حد زیادی افزایش یافت و این به دلیل وجود Hardware Acceleration در این نسخه از اندروید می‌باشد. Hardware Acceleration کمک می‌کند تا رندرینگ انیمیشن‌های یک سیستم عامل از حالت نرم افزاری به حالت سخت افزاری تغییر یابد و این هم به افزایش عمر باتری و هم سریع‌تر شدن و نرم‌تر شدن انیمیشن‌ها کمک زیادی می‌کند.

دلیل دوم وجود Garbage Collection -- که مسئول پاکسازی حافظه از محتویات بلااستفاده است -- در این سیستم عامل می باشد. به طور مثال اگر شما با تبلت های Honeycomb کار کرده باشد می‌دانید زمانی که گالری را در این نسخه از اندروید باز کرده و شروع به ورق زدن عکس‌ها می‌کنیم، متوجه سرعت بسیار پایین واسط کاربر خواهیم شد که با وجود پردازنده های دو هسته ای، این سرعت پایین باعث تعجب است. دلیل این کندی، اعمال محدودیت در رندر کردن عکس‌ها است که تمام پروسه‌ها را روی سرعت 30 فریم بر ثانیه قفل می‌کند. دلیل این اعمال محدودیت سرعت، آن است که در صورت نبود آن، پروسه ورق زدن عکس با سرعت 60 فریم بر ثانیه انجام می‌شد اما این سرعت بالا موجب فعال شدن عملیات پاکسازی حافظه شده و وقفه هایی محسوس را در عملکرد ایجاد می کرد. اما قفل کردن سرعت روی 30 فریم بر ثانیه مانع به وجود آمدن این وقفه ها می‌شود و این به قیمت از دست دادن انیمیشن های روان و بالا رفتن مصرف باطری در برخی اوقات تمام می شود.

دلیل سوم، وجود محدودیت سخت افزاری در بعضی از گوشی ها و تبلت هاست. به طور مثال پردازنده های تگرا 2، برعکس ادعاهای شرکت انویدیا ، از پهنای باند حافظه بسیار کمی برخوردارند و در کنار آن از مجموعه دستورات NEON پشتیبانی نمی کنند (مجموعه دستورات NEON در پردازنده های ARM، معادل با فناوری SSE در پردازنده های اینتل است که سرعت عملیات ریاضی بر روی ماتریس‌ها را تا حد زیادی افزایش می‌دهد) که این خود باعث کاهش سرعت در نسخه Honeycomb می‌شود. اگر به طور مثال بجای استفاده از پردازنده های تگرا 2، حتی از پردازنده های Hummingbird سامسونگ (پردازنده تک هسته ای که از نظر تئوری از برخی جنبه ها از پردازنده تگرا 2 ضعیف تر است) استفاده شده بود، این مشکل تا حدودی قابل حل بود و سرعت رندر نسبت به تبلت های کنونی بیشتر و بهتر بود.

دلیل چهارم نوع عملکرد اندروید در سر هم کردن (Compositing) واسط کاربر است که با کارآیی بالا فاصله بسیاری دارد. در آی او اس، هر بخش واسط کاربر به طور جداگانه رندر شده و در داخل حافظه ذخیره می‌شود، بنابراین اکثر انیمیشن‌ها تنها به پردازنده گرافیکی جهت سر هم کردن این بخش های آماده نیاز دارند و پردازنده های گرافیکی به خوبی از پس این عمل بر می‌آیند. اما در اندروید اجزای واسط کاربر همه با هم رندر شده و بخش های مختلف واسط کاربر به صورت از پیش رندر شده در حافظه وجود ندارد. بنابراین برای متحرک سازی لازم است که کلیه بخش های متحرک دوباره ترسیم شوند.

دلیل پنجم مربوط Dalvik VM (ماشین مجازی اندروید) است که در مقایسه با JVM (ماشین مجازی جاوا) که در رایانه های دسکتاپ به کار گرفته می شود کمتر به تکامل رسیده است. جاوا در کل به ضعیف بودن در بخش گرافیکی معروف است، هرچند بسیار از مشکلات جاوا به Dalvik منتقل نشده است. فناوری Swing دشواری های خاصی را به همراه دارد، چرا که این فناوری از یک لایه مستقل از پلتفرم در بالای لایه API های بومی (Native) پلتفرم های مختلف استفاده می کند. جالب است بدانید هسته اصلی واسط کاربر ویندوز فون، به صورت کدهای بومی این بستر نوشته شده است. با اینکه مایکروسافت از ابتدا می‌خواست این واسط کاربر را روی سیلورلایت طراحی کند اما خوشبختانه به این نتیجه رسید که برای رسیدن به یک واسط کاربر نرم و روان کدها باید به صورت بومی نوشته شوند. مشاهده تفاوت میان کدهای بومی و Bytecode ها بر روی ویندوز فون 7 به سادگی امکان پذیر است، چرا که برنامه هایی که توسط دیگران برای ویندوز فون 7 توسعه می یابند تحت سیلورلایت نوشته شده و می توان مشاهده نمود که از کارآیی به مراتب پائینتری برخوردارند (نسخه های NoDo و Mango این مشکل را تا حد زیادی حل کرده اند و اینک واسط های کاربر سیلورلایت عموماً بسیار روان هستند).

خوشبختانه این پنج مشکل بدون نیاز به تغییرات بنیادین در اندروید قابل حل است. Hardware Acceleration بالاخره در نسخه 4 اندروید اضافه شده، بهبود کارآیی Garbage Collector در Dalvik ادامه دارد، پردازنده های تگرا 2 دیگر استفاده نمی‌شوند، راه حل هایی برای دورزدن مشکلات ترکیب عناصر صفحه (Compositing) وجود دارد و هر نسخه جدید Dalvik نسبت به نسخه قبلی، ماشین مجازی سریع تری است.

خب پس آیا مشکل کندی واسط کاربر اندروید حل خواهد شد؟

خیر. با وجود تمام این تغییرات، باز هم سیستم عامل اندروید هرگز کاملاً نرم و روان نخواهد شد، چرا که به دلیل اولویت معمولی واسط کاربر و انجام شدن رندرینگ در thread اصلی برنامه، حتی پردازنده های چهار هسته ای نیز قادر نخواهند بود واسط کاربر اندروید را کاملاً نرم و روان اجرا کنند و به توانی برابر توان گوشی گالاکسی نکسوس برای آنکه واسط کاربر اندروید در حد آیفون سه سال پیش روان باشد نیاز خواهیم داشت.

حال با وجود توضیحات بالا یک سوال مطرح می‌شود و آن اینکه چرا تیم اندروید فریم ورکی این گونه را برای رندرینگ طراحی نموده؟

کار روی اندروید زمانی آغاز شد که هنوز آیفونی وجود نداشت، برای همین اندروید از ابتدا برای رقابت با بلک‌بری ساخته شد. به همین دلیل هسته اصلی اندروید برای گوشی های لمسی طراحی نشده بود، بلکه برای گوشی های دارای trackball و صفحه کلید سخت افزاری ساخته شده بود. اما زمانی که آیفون معرفی شد، برنامه‌نویسان اندروید به سرعت تغییر استراتژی دادند و این سیستم عامل را با عجله برای استفاده با صفحات لمسی تغییر دادند، اما آن زمان دیگر خیلی دیر شده بود و فرصتی برای تغییر سیستم واسط کاربر اندروید نمانده بود. این دقیقاً همان دلیلی است که چرا ویندوز موبایل 6.5، سیمبیان و بلک‌بری او اس نیز در مقایسه با آی او اس و ویندوز فون کند هستند. چرا که هسته اصلی آن‌ها برای صفحات لمسی طراحی نشده بود.

سوال دیگری که ممکن است در ذهن بسیاری از شما مطرح شده باشد، این است که چرا تیم اندروید هسته اصلی آندروید را برای صفحات لمسی بهینه سازی نمی‌کنند؟ و سیستم رندرینگ اندروید را به Real-Time تغییر نمی‌دهند؟

جواب این سوال را می‌توان در یکی از نقل قول‌های Romain Guy -- یکی از برنامه‌نویسان اصلی اندروید -- جستجو کرد.

«بسیاری از کارهایی که ما امروز انجام می‌دهیم به خاطر انتخاب‌هایی هست که در گذشته انجام دادیم.... .... واگذار کردن انیمیشن‌ها به thread واسط کاربر، بزرگ‌ترین اشتباه ما بود. البته ما در حال حاضر در حال بررسی گزینه‌ها و راه حل‌های دیگری هستیم تا این مشکل را حل کنیم. یکی از ساده‌ترین راه حل‌ها، ایجاد یک UI Toolkit جدید است اما این راه حل نیز معایب بسیاری دارد»

البته Romain Guy در مورد معایب این روش صحبتی نکرده اما حدس زدن مشکلات این راه حل، کار سختی نیست:

• تمام برنامه های اندروید باید از ابتدا نوشته شود تا از فریم ورک جدید پشتیبانی کنند
• اندروید نیازمند مد عملیاتی ویژه ای برای پشتیبانی از برنامه های قدیمی خواهد بود
• حین ساخت فریم ورک جدید، تمام بخش‌های مربوط به توسعه اندروید متوقف خواهد شد

البته به نظر من دوباره نوشتن فریم ورک اندروید حتی با وجود تمام این مشکلات حتماً باید انجام شود و من به عنوان شخصی که در این حوزه دستی بر آتش داشته ام وجود کندی در اندروید را نمی‌توانم تحمل کنم و معتقدم این موضوع باید در اولویت اول تیم برنامه نویسی اندروید باشد.

زمانی که بحث اندروید میان من و دوستان فنی و غیر فنیم مطرح می‌شود، به دفعات می‌شنوم که آنها از وجود تأخیر و کندی در اندروید شکایت می‌کنند. واقعیت آن است که اندروید می تواند با همان سرعت آی او اس یا حتی سریع تر از آن برنامه ها را باز کرده و صفحات وب را رندر نماید، اما حس منتقل شده هنگام تعامل با سیستم بیشترین اهمیت را دارد. حل کردن مشکل کندی واسط کاربر می تواند به بهتر کردن چهره اندروید کمک بسزایی نماید.

جدای از این موضوع، سرعت همیشه شعار اصلی گوگل بوده است و این شرکت معتقد است که همه چیز باید سریع باشد، تمام بخش‌های گوگل از موتور جستجو گرفته تا کروم و جی میل، همه بر مبنای همین طرز فکر ساخته شده‌اند و این مشکل در اندروید برخلاف استراتژی اصلی گوگل است.

برجسته ترین دلیلی که کندی واسط کاربر اندروید را غیر قابل تحمل می‌کند، مربوط به حوزه تعامل انسان با کامپیوتر است (Human-Computer Interaction یا HCI). واسط‌های کاربری جدید مانند آنچه در آی او اس و ویندوز فون می‌بینید، همه بر مبنای تناظر میان حرکت انگشتان بر روی صفحه و متحرک سازی اجزای واسط کاربر طراحی شده‌اند. برای همین حالت کشسانی آی او اس (زمانی که صفحه به پایان می‌رسد) بسیار لذت بخش و جذاب بوده و تعاملی شهودی و طبیعی دارد.

حال در یک واسط کاربر کند و غیر روان، این رابطه گسسته می شود و آن زمان دیگر گوشی یا تبلت به نظر زنده و جادویی نمی‌آید. در این حالت کاربر از این رابطه متقابل خارج شده و به تدریج خود از این واسط کاربر خسته می شود. زمانی که من با یک آیپد کار می‌کنم، در آن گم می‌شوم ولی زمانی که از تبلت اندرویدی زوم استفاده می‌کنم در زمان تأخیرها و کندی‌های واسط کاربر، خسته و دل زده می‌شوم. 200 میلیون کاربر اندروید شایسته چیزی بهترند.

البته این را هم بگویم که واسط کاربر اندروید در دستان یکی از بهترین تیم‌های برنامه نویسی جهان است و این تیم با داشتن افرادی چون Dianne Hackborn و Romain Guy قطعاً خواهد توانست راه حلی برای این مشکل بزرگ پیدا کند.

و در آخر این را اضافه کنم که هدف از نوشتن این پست، برطرف کردن سؤالات در ذهن کاربران اندروید بود که امیدوارم مورد توجه واقع شده باشد. در عین حال امیدوارم که در اندروید 5، بالاخره بتوانیم واسط کاربر نرم و روانی را که از ابتدا آرزویش را داشتیم، ببینیم. در این مدت هم من در مایکروسافت بر روی ویندوز فون کار خواهم کرد تا واسط کاربر زیباتر و بهتری را برای کاربران ارائه کنیم.