دانلود رایگان ترجمه مقاله معماری سیستم عامل موبایل (سال 2012)

مبتدی (مناسب برای درک مفهوم کلی مطلب) 

نگاهی به ارزیابی ویدیویی می‌اندازیم. معیار سنتی تنها عملکرد پخش ویدئو با برخی از معیارها مانند FPS (فریم در ثانیه) و یا میزان افت فریم را اندازه‌گیری می‌کند. این روش دارای حداقل دو مشکل در ارزیابی تجربه‌ی کاربری است. مشکل اول این است که پخش ویدئو تنها بخشی از تعامل کاربر در بازی‌های ویدئویی است. چرخه معمولی زندگی تعامل با کاربر معمولا شامل حداقل لینک‌های زیر است: ” راه‌اندازی بازیکن” “شروع به بازی” ” دنباله پیشرفت” “پخش ویدئو” “بازگشت به صفحه اصلی”. بااین‌حال عملکرد خوب در پخش ویدئو می‌تواند تجربه کاربری واقعی را در بازی‌های ویدئویی مشخص کند. ارزیابی تعامل با کاربر یک مجموعه از سنجش سنتی عملکرد است.
مشکل دیگر این است که، استفاده از FPS به‌عنوان کلید متریک برای ارزیابی صافی از تعاملات کاربران همیشه نمی‌تواند منعکس‌کننده‌ی تجربه کاربری خوب باشد. به‌عنوان مثال، زمانی که ما یک تصویر در نرم‌افزار Gallery3D ارائه می‌کنیم، دستگاه Y لکنت آشکاری در طول پیمایش تصویر دارد، اما ارزش FPS دستگاه Y بالاتر از دستگاه X بود. به‌منظور بیان تفاوت دو دستگاه، داده‌ی هر فریم در طول یک تصویر تحت عملیات نرم‌افزار Gallery3D در هر دو دستگاه X وY ، به‌ترتیب در شکل 2 و شکل 3 نشان داده شده است. داده‌های هر قاب در یک نوار عمودی داده شده است، که در آن محور x زمانی است که قاب کشیده شده است، و ارتفاع نوار، زمانی است که طول می‌کشد سیستم قاب را رسم کند. از آمار و ارقام، می‌توانیم ببینیم که دستگاه X مقدار FPS پایین‌تری نسبت به دستگاه Y، اما با کمترین حداکثر زمان قاب، قاب کوچکتری از 30 ms و واریانس زمان قاب کمتری دارد. این به این معنی است که، برای مشخص کردن تجربه کاربران از عملیات پرت کردن تصویر، متریک‌هایی مانند حداکثر زمان قاب و واریانس زمان قاب نیز باید در نظر گرفته شود.

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

نکته‌ی مهم دیگر این است که تجربه کاربری یک فرآیند ذهنی است؛ فقط تجربه را هنگام تماشای یک فیلم و یا موسیقی قدردانی در نظر می‌گیرد. تحقیقات دانشگاهی درحال حاضر، با استفاده از روش‌های مختلف مانند ردیابی کره چشم، نظارت ضربان قلب و یا فقط رای‌گیری به درک تجربه کاربری می‌رسند. برای هدف مهندسی نرم‌افزار ما، به‌منظور تجزیه‌وتحلیل و بهینه‌سازی تعاملات نظام‌مند کاربران، حالات تعامل را به چهار نوع دسته‌بندی می‌کنیم:
• ورودی دستگاه از کاربران، سنسور، شبکه و غیره: این دسته ارزیابی می‌کند که آیا ورودی می‌تواند دستگاه را به دقت عمل همانطور که انتظار می‌رود وادارد. برای ورودی صفحه نمایش لمسی، سرعت لمس، فشار، محدوده و غیره را اندازه‌گیری می‌کند.
• پاسخ دستگاه به ورودی: این دسته چگونگی پاسخگویی دستگاه به ورودی را ارزیابی می‌کند.
• انتقال حالت سیستم: این دسته به خصوص چگونگی انتقال صاف گرافیک بر روی صفحه نمایش را ارزیابی می‌کند. که می‌تواند یک پیگیری از پاسخ دستگاه به برخی از ورودی‌ها باشد.
• کنترل مداوم دستگاه: مردم این دستگاه را نه تنها برای یک ورودی، گاهی اوقات برای کنترل اشیاء گرافیکی در صفحه نمایش، مانند کنترل یک جت هواپیما بازی و یا کشیدن یک آیکون نرم‌افزار به‌کار می‌برند. این دسته برای ارزیابی کنترل دستگاه است.
در میان آنها، “ورودی به دستگاه” و “کنترل دستگاه” مربوط جنبه‌ی تجربه کاربری از چگونگی کنترل یک دستگاه توسط کاربر است. “پاسخ دستگاه به ورودی” و “انتقال حالت سیستم” از جنبه‌های مرتبط به چگونگی واکنش دستگاه به کاربر را نشان می‌دهد. ما می‌توانیم یک چرخه زندگی تعامل با کاربر به حالات نقشه نگاشت کنیم که در دسته‌های بالا قرار گیرد. سپس برای هر سناریو، می‌توانیم معیارهای کلیدی در پشته نرم‌افزار برای اندازه‌گیری و بهینه‌سازی را شناسایی کنیم.

بهینه‌سازی تعاملات با کاربر
همانطور که در آخرین بخش شرح داده شد، هیچ روش روشن و عینی برای اندازه‌گیری تجربه کاربری وجود ندارد. ما معیارهای زیر را برای اندازه‌گیری تعاملات کاربر ارائه کردیم:
• درک: متریک توسط انسان قابل درک است است. در غیر این صورت، با تجربه کاربری بی‌ربط است.
• قابل اندازه‌گیری: متریک باید توسط تیم‌های مختلف قابل اندازه‌گیری باشد. نباید به برخی از زیرساخت‌های خاص که فقط توسط تیم خاصی قابل اندازه‌گیری هستند بستگی داشته باشند.
• تکرار: نتیجه‌ی اندازه‌گیری باید در اندازه‌گیری‌های مختلف تکرار شود. انحرافات بزرگ در اندازه‌گیری به معنی یک متریک بد است.
• مقایسه: داده‌های اندازه‌گیری شده باید در سیستم‌های مختلف قابل مقایسه باشند. مهندسین نرم‌افزار می‌توانند از متریک‌ها برای مقایسه‌ی سیستم‌های مختلف استفاده کنند.
• معقول: متریک باید به‌دلیل علیت رفتار پشته نرم‌افزار کمک کند. به‌عبارت دیگر، متریک باید به رفتار نرم‌افزار نگاشته شود و ممکن است بر اساس اجرای پشته نرم‌افزار محاسبه شود.
• قابل اثبات: متریک می‌تواند برای بررسی بهینه‌سازی استفاده شود. نتیجه‌ی اندازه‌گیری قبل و بعد از بهینه‌سازی باید تغییر تجربه کاربری را نشان دهد.
• Automatable: برای اهداف مهندسی نرم‌افزار، انتظار داریم که متریک تا حد زیادی بی‌مراقبت اندازه‌گیری کند. این امر به‌ویژه در آزمون رگرسیون و یا آزمون قبل از سپردن مفید است. این معیار به‌دلیل آ‌ن‌که به‌طور مستقیم به تجزیه‌وتحلیل تجربه کاربری و بهینه‌سازی مربوط نیست، به شدت لازم نیست.
بنا به هدایت با معیارهای اندازه‌گیری، ما به جنبه‌های تجربه کاربری تمرکز می‌کنیم، چگونه یک کاربر یک دستگاه را کنترل می‌کند و چگونه یک دستگاه به یک کاربر واکنش نشان می‌دهد. چگونه یک کاربر یک دستگاه را که به‌طور عمده دو مورد اندازه‌گیری دارد کنترل می‌کند:
• دقت/فازی: این‌که چگونه دقت، ابهام، وضوح تصویر، و محدوده‌ توسط سیستم برای ورودی صفحه نمایش، حسگرها و منابع دیگر لمسی پشتیبانی می‌شود، ارزیابی می‌شود. به‌عنوان مثال، چه سطح فشاری توسط سیستم پشتیبانی می‌شود، چگونه مختصات حوادث لمسی نمونه، نزدیک به آهنگ حرکت نوک انگشتان بر روی صفحه نمایش هستند، چه تعداد از انگشتان دست را می‌توان در زمان یکسانی به‌کار برد و غیره.
• هماهنگی: فاصله‌ی تاخیر کشیدن بین نوک انگشتان و شی گرافیکی کشیده در صفحه نمایش ارزیابی می‌شود. همچنین انسجام بین عملیات کاربران و اشیاء تحت کنترل سنسور، مانند تفاوت درجه زاویه بین کنترل کج جریان آب و دستگاه زاویه مورب ارزیابی می‌شود.
چگونگی واکنش یک دستگاه به یک کاربر همچنین دارای دو حوزه اندازه‌گیری است:
• پاسخگویی: زمان بین یک ورودی که به دستگاه تحویل داده می‌شود و واکنش دستگاه ارزیابی می‌کند. همچنین شامل زمان صرف شده برای به پایان رساندن عمل نیز است.
• صافی یا همواری: این حوزه صافی گذار گرافیکی با حداکثر زمان قاب، واریانس قاب زمان، FPS، نرخ رها کردن فریم و غیره را ارزیابی می‌کند. همانطور که بحث شد، FPS به‌تنهایی نمی‌تواند به‌دقت منعکس‌کننده‌ی تجربه کاربران در مورد صافی باشد.
برای این چهار حوزه اندازه‌گیری، یک متریک بتن برای استفاده مشخص می‌کنیم، ما نیاز به درک چگونگی ربط تجربه کاربری “خوب” به این متریک هستیم. از آنجا که تجربه کاربری یک موضوع ذهنی است که به شدت به وضعیت فیزیولوژیکی بودن انسان و سلیقه شخصی آن بستگی دارد، بنابراین هیچ نتیجه‌ی علمی در مورد ارزش یک متریک به‌منزله‌ی یک تجربه کاربری “خوب” وجود ندارد. برای این موارد، ما فقط ارزش تجربه در صنعت را لحاظ می‌کنیم. جدول 1 چند نمونه از ارزش تجربه در صنعت را نشان می‌دهد.

با توجه به ماهیت انسان، دو یادداشت برای مهندسین نرم‌افزار با توجه به بهینه‌سازی تجربه کاربری وجود دارد که به آن بپردازند.
ارزش یک متریک معمولا دارای یک طیف برای تجربه کاربری “خوب” است. ارزش “بهتر” از محدوده لزوما تجربه کاربری “بهتر” را به‌همراه ندارد.
ارزش در اینجا تنها دستورالعمل خشن برای موارد مشترک با انسان معمولی است. به‌عنوان مثال، یک بازیکن بازی ممکن است با 120 فریم انیمیشن در ثانیه راضی نشود. از سوی دیگر، یک کارتون با طراحی خوب یک صافی مناسب با 20 فریم انیمیشن در ثانیه را به‌همراه دارد.
درحال‌حاضر ما می‌توانیم روشمان را برای بهینه‌سازی تجربه کاربری به‌کار ببریم. که می‌تواند در مراحل زیر خلاصه شود.
مرحله 1: دریافت رؤیت تجربه کاربری از کاربران و یا شناسایی مسائل تعامل با عملیات دستی. این مسئله می‌توان با کمک دوربین‌های با سرعت بالا و یا دیگر روش‌های موجود مشخص شود.
مرحله 2: تعریف سناریوهای پشته نرم‌افزار و معیارهایی که موضوع تجربه کاربری را به نشانه نرم‌افزار تبدیل می‌کنند.
مرحله 3: توسعه‌ی حجم کار نرم‌افزار برای تکثیر دوباره‌ی موضوع به‌روش اندازه‌گیری و تکرار. حجم کار، مقادیر متریک را که منعکس‌کننده تجربه کاربران است گزارش می‌کند.
مرحله 4: از حجم کار و ابزار مرتبط به تجزیه‌وتحلیل و بهینه‌سازی پشته نرم‌افزار استفاده می‌کند. حجم‌کار بهینه سازی را نیز تایید می‌کند.
مرحله 5: گرفتن بازخورد از کاربران و سعی بیشتر برای بهینه‌سازی برنامه‌های کاربردی برای تایید تجربه کاربری بهبود یافته.
بر اساس این روش، یک مجموعه حجم‌کار آندروید(AWS) [33] توسعه دادیم که تقریبا شامل تمام موارد استفاده معمولی از دستگاه های آندروید است. همچنین یک ابزار به نام UXtune[34] که به تجزیه‌وتحلیل تعامل با کاربر در پشته نرم‌افزار کمک می‌کند توسعه دادیم. متفاوت از عملکرد سنتی ابزار تنظیم، UXtune با حوادث قابل مشاهده کاربر و سیستم حوادث کم سطح ارتباط برقرار می‌کند. به‌عنوان گام بعدی، ما در حال انتقال کار از آندروید به دیگر سیستم‌ها هستیم.
طراحی سیستم‌عامل تلفن‌همراه برای تجربه کاربری
بر اساس تجربه ما با آندروید، به بهینه‌سازی UX به‌نحوی مشابه با بهینه‌سازی موازی نرم‌افزار، تنها با پیچیدگی بیشتر، بنا به چهار دلیل زیر تمرکز می‌کنیم:
• UX شامل قطعات سخت‌افزاری متعدد و چند فرآیند نرم‌افزاری و اثر متقابل آنها است.
• UX در یک دستگاه مشتری به‌منظور مصرف برق است، بنابراین UX شامل عمر باتری و دستگاه درجه حرارت است.
• UX به زمان‌بندی دقیق نیاز دارد، مانند صافی که در آن کاربر انتظار هیچ واریانس زمان قاب ندارد. نه سریعتر و نه کندتر قابل قبول است. هدف قرار دادن زمان دقیق مورد نیاز است. این بیشتر شبیه به یک زمان واقعی مورد نیاز است.
• UX شامل برخی از عوامل ذهنی است که در طراحی سیستم‌عامل تلفن‌همراه مشخص شده است، از جمله اینکه آیا برخی از انیمیشن‌ها فقط یک اشاره برای UX ضروری است و آیا سیستم می‌تواند برخی از فریم‌ها را برای پاسخ بهتر رها کند.
یک درس مهم که از تجربه ما بدست آمد درک مسیر انتقادی از عملیات خاصی است. متفاوت از تنظیم برنامه موازی، طراحی سیستم‌عامل تلفن‌همراه همیشه هماهنگ‌سازی صریح بین اجزای سخت‌افزاری و موضوعات نرم‌افزار را ندارد. برای مثال:
• هر نرم‌افزار از یک حلقه رویداد برای رسیدگی به درخواست‌ها استفاده می‌کند. هنگامی که یک نخ A درخواستی به نخ B می‌فرستد، ممکن است به طور مستقیم به تابع استناد نکند، اما به‌جای آن یک پیام به نخ B ارسال کند. سپس پیام در صف حلقه‌ی نخ B برای به‌کار برده شدن منتظر می‌ماند. پس از آن از کنترل تماس‌گیرنده خارج است که رویداد با چه سرعتی می‌تواند به‌کار گرفته شود اگر رویدادهای متعددی در صف وجود داشته باشند.
• مثال دیگر زمانی است که نخ A دنباله‌ای از عملیات را اجرا می‌کند و پس از آن یک پیام، به نخ B برای اقدامات و پیگیری پاسخ به کاربر ارسال می‌کند. همه‌ی دنباله عملیات نباید توسط نخ A به‌ترتیب انجام شود. برای مثال، می‌تواند یک پیام به نخ B ارسال کند به‌طوری که نخ B تا می‌تواند به کاربر زودتر پاسخ دهند.