جهان مسطح است، چرا که بهطور فزایندهای متحرک، سریع، متصل و امن است. مردم انتظار دارند بهراحتی با دستگاههای تلفنهمراه خود به اطراف حرکت کنند و در عین حال ارتباطات نزدیک خود با شرکا و خانوادهشان را حفظ کنند و از همهی مدلها و محتویات بینهایت آن بدون هیچ گونه نگرانی در مورد دستگاه و مدیریت دادهها بهره ببرند. تمام این نیازها بر روی دستگاههای تلفنهمراه، که از سیستمعامل بهعنوان روح تلفنهمراه یاد میکنند، قرار داده شده است. براساس تجربهی ما در طراحی سیستمعامل تلفنهمراه و بررسی گستردهی وضعیت صنعت حاضر، معتقدیم مشترکاتی در معماری آینده سیستمعامل تلفنهمراه، مانند تجربه کاربران، مدیریت انرژی، طراحی امنیتی، پشتیبانی ابر و باز بودن طراحی وجود دارد. بنابراین یک مدل تجزیه و تحلیل برای هدایت تحقیقاتمان ارائه دادیم. در این مقاله، تحقیقات ما در روند معماری سیستمعامل تلفنهمراه تا دههی آینده با تمرکز بر مشترکات عمده توصیف شده است. براساس یافتهها، ویژگیهای سیستمعامل تلفنهمراه از دیدگاه روند معماری امروز را نیز بررسی کردهایم.
معرفی
طراحی سیستمعامل موبایل نیاز به تجربهی سه فاز تکامل دارد: از سیستمعامل مبتنی بر PC تا سیستمعامل تعبیه شده در سیستمعامل گوشیهای هوشمندگرا در دهه گذشته است. در طول این روند، معماری سیستمعامل تلفنهمراه از دشوار به ساده یا چیزی مابین این دو تغییر کرده است. روند تکامل بهطور طبیعی توسط پیشرفت فنآوری در سختافزار، نرمافزار و اینترنت است:
• سختافزار: صنعت موجب کاهش اندازهی ریزپردازندهها و لوازم جانبی برای طراحی دستگاههای واقعی همراه است. قبل از کاهش اندازهی دستگاهها، دستگاه تلفنهمراه نمیتوانست همزمان به هر دو قابلیت اندازهی کوچک و قابلیت پردازش برسد. ما تا بهحال لپتاپهایی هم اندازهی PC یا یک دستیار بسیار ضعیف اطلاعات شخصی (PDA) در اندازه تلفن داشتیم. سیستمعاملهای تلفنهمراه برای PDA ها معمولا لازم نیست کاملا چند وظیفهای باشد و یا از کارت گرافیکهای سه بعدی پشتیبانی کند. ویژگیهایی مانند حسگرها، شتابسنج و صفحه نمایش لمسی مبتنی بر خازن در سیستمعامل تلفنهمراههای گذشته در دسترس ننبود.
• نرمافزار: با یک کامپیوتر لپتاپ، نرمافزار عمدتا به بهرهوری کاربر تمرکز دارد، که برای حمایت از صفحهکلید و ماوس برای ورودیهای دقیق ضروری است. نرمافزار برای یک دستیار اطلاعات شخصی، همانگونه که از نام آن پیداست، کمک میکند تا کاربر اطلاعات شخصی خود مانند اطلاعات تماس، ایمیل و غیره را مدیریت کند. سیستمعامل تلفنهمراه برای پاسخگویی خوب یا صافی با یک رابط کاربری غنی (UI) از جمله صفحهنمایش لمسی و سنسور طراحی شده است.
• اینترنت: همراه با توسعهی اینترنت، بهویژه پس از وب 2.0، اطلاعات فراوانی در شبکه برای جستجو، سازمان یافتن، استخراج وجود دارد تا به کاربران فرستاده شود. مردم بهطور فزایندهای بهجای مرور وب با اینترنت زندگی میکنند. بیشتر مردم در توسعه درگیر هستند، از جمله سهم اطلاعات، توسعهی نرمافزار و تعاملات اجتماعی. سیستمعاملهای تلفنهمراه میتواند خود درگیر نشوند، بلکه سیستمها را باز کنند.
تجربه کاربری (UX)
عملکرد سنتی، برای توصیف دستگاههای مشتری مدرن ناکافی است. عملکرد بیشتر در مورد وضعیت اجرای مداوم یک پشته نرمافزار است و معمولا با یک نمرهی نهایی از توان کل پردازنده و یا زیرسیستمهای دیگر گزارش میشود. تجربهی کاربری بیشتر درمورد انتقال پویا از سیستم توسط ورودیهای کاربر است. کیفیت تجربه کاربری توسط چنین چیزهایی مانند درک پاسخگویی کاربر، صافی، انسجام و دقت و صحت تعیین میشود. عملکرد سنتی میتواند هر لینک از زنجیرههای تعامل با کاربر را اندازهگیری کند، درحالی که زنجیره کامل از تعامل با کاربر بهعنوان یک کل قابل ارزیابی نیست. بنابراین بهینهسازی عملکرد سنتی نمیتواند بهسادگی به بهینهسازی تجربه کاربری اعمال شود. بنابراین زمان سرمایهگذاری در دستگاه بهینهسازی تعامل با کاربر برای یک تجربه کاربری لذتبخش است.
تعامل کاربر با دستگاههای موبایل
اخیرا در اندازهگیری عملکرد با دستگاههای آندروید موجود در بازار، یک دستگاه X که بهطور یکنواخت بدتر از دستگاه Y با معیارهای رایج گرافیک، رسانهها و مرور رفتار میکند، یافتیم. اما درک تجربه کاربری با دستگاه X بهتر از دستگاه Y است. دلیل اصلی که مشخص کردیم این است که معیارهای سنتی و یا معیار طراحی در روشهای سنتی واقعا تعاملات کاربر را مشخص نمیکند، اما قابلیت محاسبات (مانند اجرای دستورات) و یا توان (مانند پردازش دیسک خوانده شده) از سیستم و زیر سیستم را اندازهگیری میکند.
بهینهسازی تعاملات با کاربر
همانطور که در آخرین بخش شرح داده شد، هیچ روش روشن و عینی برای اندازهگیری تجربه کاربری وجود ندارد. ما معیارهای زیر را برای اندازهگیری تعاملات کاربر ارائه کردیم:
• درک: متریک توسط انسان قابل درک است است. در غیر این صورت، با تجربه کاربری بیربط است.
• قابل اندازهگیری: متریک باید توسط تیمهای مختلف قابل اندازهگیری باشد. نباید به برخی از زیرساختهای خاص که فقط توسط تیم خاصی قابل اندازهگیری هستند بستگی داشته باشند.
• تکرار: نتیجهی اندازهگیری باید در اندازهگیریهای مختلف تکرار شود. انحرافات بزرگ در اندازهگیری به معنی یک متریک بد است.
• مقایسه: دادههای اندازهگیری شده باید در سیستمهای مختلف قابل مقایسه باشند. مهندسین نرمافزار میتوانند از متریکها برای مقایسهی سیستمهای مختلف استفاده کنند.
• معقول: متریک باید بهدلیل علیت رفتار پشته نرمافزار کمک کند. بهعبارت دیگر، متریک باید به رفتار نرمافزار نگاشته شود و ممکن است بر اساس اجرای پشته نرمافزار محاسبه شود.
• قابل اثبات: متریک میتواند برای بررسی بهینهسازی استفاده شود. نتیجهی اندازهگیری قبل و بعد از بهینهسازی باید تغییر تجربه کاربری را نشان دهد.
• Automatable: برای اهداف مهندسی نرمافزار، انتظار داریم که متریک تا حد زیادی بیمراقبت اندازهگیری کند. این امر بهویژه در آزمون رگرسیون و یا آزمون قبل از سپردن مفید است. این معیار بهدلیل آنکه بهطور مستقیم به تجزیهوتحلیل تجربه کاربری و بهینهسازی مربوط نیست، به شدت لازم نیست.
طراحی سیستمعامل تلفنهمراه برای تجربه کاربری
بر اساس تجربه ما با آندروید، به بهینهسازی UX بهنحوی مشابه با بهینهسازی موازی نرمافزار، تنها با پیچیدگی بیشتر، بنا به چهار دلیل زیر تمرکز میکنیم:
• UXشامل قطعات سختافزاری متعدد و چند فرآیند نرمافزاری و اثر متقابل آنها است.
• UX در یک دستگاه مشتری بهمنظور مصرف برق است، بنابراین UX شامل عمر باتری و دستگاه درجه حرارت است.
• UX به زمانبندی دقیق نیاز دارد، مانند صافی که در آن کاربر انتظار هیچ واریانس زمان قاب ندارد. نه سریعتر و نه کندتر قابل قبول است. هدف قرار دادن زمان دقیق مورد نیاز است. این بیشتر شبیه به یک زمان واقعی مورد نیاز است.
• UXشامل برخی از عوامل ذهنی است که در طراحی سیستمعامل تلفنهمراه مشخص شده است، از جمله اینکه آیا برخی از انیمیشنها فقط یک اشاره برای UXضروری است و آیا سیستم میتواند برخی از فریمها را برای پاسخ بهتر رها کند.
مدیریت انرژی (PM)
مدیریت انرژی همواره یک چالش کلیدی برای طراحان سیستمعامل تلفنهمراه با حرکت رو به جلو بوده و خواهد بود. خواستههای انرژی بهسرعت و بر روی دستگاههای تلفنهمراه در حال افزایش است. با این حال، رشد ظرفیت باتری با توجه به توسعهی آهسته فنآوری باتری و این واقعیت که مردم دستگاههایی جمع و جورتر میخواهند هرگز نمیتواند متوقف شود. مدیریت انرژی به یک مشکل پیچیده بر روی دستگاههای تلفنهمراه تبدیل شده است و یک رویکرد جامع برای رسیدگی به آن مورد نیاز است.
مدیریت توان پردازنده
سیستمعامل تلفنهمراه پیشرفت مداومی در مدیریت توان در دهه گذشته داشته است. در ابتدا کار تمرکز بر مدیریت توان سیستمعامل تلفنهمراه در مدیریت قدرت پردازنده بود زیرا پردازنده یک مصرفکننده مهم در پلتفرم توان بوده است. پردازندههای مدرن از فرکانس پویا و پوسته پوسته شدن ولتاژ مانند افزایش فناوری SpeedStep® اینتل پشتیبانی میکنند. از جمله قابلیتهای پردازنده، فعال کردن سیستمعامل تلفنهمراه برای تنظیم فرکانس پردازنده و/یا ولتاژ به صورت پویا در زمان اجرا بر اساس تقاضا از قدرت محاسباتی مورد نیاز حجم کار است که در حال حاضر بر روی پردازندهها در حال اجرا است. این موجب صرفهجویی مقدار قابل توجهی از قدرت پردازنده فعال میشود، زیرا مصرف قدرت متناسب با مربع ولتاژ فرکانس هسته است. زیر سیستم Cpufreq در کرنل لینوکس یک مثال از مدیریت قدرت پردازنده در وضعیت فعال است. علاوه بر فرکانس پویا و پوسته پوسته شدن ولتاژ، پردازندههای مدرن معمولا از پردازندههای متعدد بیکار با تفاوت مقدار برق مصرفی پشتیبانی میکنند. سیستمعامل موبایل میتواند پردازنده را بهطور مستقیم به حالت مناسب غیرفعال براساس پیشبینی بیکاری و محدودیتهای QoS مطرح شده توسط دیگر زیرسیستمها و فضای کاربر وارد کند. زیر سیستم cpuidle لینوکس یک مثال از قدرت مدیریت یک پردازنده در وضعیت غیرفعال است.
دستگاه مدیریت انرژی
تمرکز کار مدیریت انرژی سیستمعامل تلفنهمراه به دستگاه مدیریت انرژی منتقل میشود. بهطورخاص، یک مکانیسم برای مدیریت قدرت دستگاههای I/O در زمان اجرا معرفی شده است. مدیریت انرژی در زمان اجرا برای دستگاههای I/O میتواند بهطور خودکار دستگاههای I/O را به مناطق با انرژی کم زمانی که دستگاههای مربوطه در زمان اجرا بیکار شناسایی میشوند هدایت کند. علاوه بر مدیریت انرژی دستگاههای I/O درحالیکه آنها بیکار هستند، برخی از نوآوریهای فناوری برای صرفهجویی I/O زمانیکه فعال هستند وجود دارد. بهعنوان مثال، GPU های مدرن شروع به حمایت از ولتاژ پویا و فرکانس بر روی پردازنده میکنند. GPU ولتاژ پویا و فرکانس میتواند مصرف انرژی را به میزان 50 درصد برای گرافیکهای 3بعدی در برخی موارد کاهش دهد. علاوهبراین، دستگاههای I / O درحال تبدیل شدن هستند به این معنا که آنها میتوانند خودبهخود بدون مداخله CPUکارکنند. بهعنوانمثال، فنآوریهایی مانند panel self-refresh میتوانند مقدار قابل توجهی از انرژی را درحالیکه تصویر در مواردی ثابت است مانند زمانی که کاربر در حال خواندن یک کتاب در یک دستگاه تلفنهمراه است صرفهجویی کنند. پانل صفحهنمایش میتواند در این مورد رندر را از حافظه محلی خود نگه دارد و بسیاری از قطعات سختافزاری به طور سنتی کار کنند درحالیکه صفحه نمایش میتواند خاموش باشد، از جمله پردازنده، حافظه، موتور صفحه نمایش و پورتها.
موارد مدیریت انرژی سیستمعاملهای موبایل
آندروید قبل از معرفی زیرساختهای دستگاههای مدیریت انرژی زماناجرا به هسته لینوکس محبوب شد و با رویکرد دیگری بهنام opportunistic suspend بهمنظور رسیدن به هدف افزایش عمر باتری در دستگاههای آندروید ارائه شد. بدون قابلیت دستگاههای مدیریت انرژی زماناجرا، اندروید تلاش میکند هر زمان که هیچ کار جالبی وجود ندارد سیستم را به حالت تعلیق درآورد.
باز بودن
یکی روندهای عمدهی سیستمعامل تلفنهمراه باز بودن آن است. در این زمینه، باز بودن سیستمعامل تلفنهمراه بهمعنی سطحی از فرصت و آزادی است که مردم مجبور به استفاده، کمک، سفارشی کردن و نوآوری برای سیستمعامل تلفنهمراه برای اهداف خود هستند. در حال حاضر کاری وجود دارد [6] که به مسئلهی باز بودن از دیدگاه توسعهدهندگان پرداخته است. این تحقیق جنبههای تصمیم ادراک توسعهدهندگان از پلت فرم باز بودن را شناسایی میکند. در اینجا ما روند باز بودن از دیدگاه اکوسیستم را مورد مطالعه قرار میدهیم، از آنجا که ما معتقدیم مسائل باز بودن برای فعال کردن و پرورش اکوسیستم تلفنهمراه ضروری است.
باز بودن به کاربران اکوسیستمهای تلفنهمراه
کاربران اکوسیستمهای تلفنهمراه شامل تولیدکنندگان (OEM ها) که دستگاههای تلفنهمراه را تولید و به فروش میرسانند، ارائهدهندگان خدمات (اپراتور) که شبکه اتصال و سایر خدمات ارزش افزوده را ارائه میکنند، مصرفکنندگان (کاربران نهایی)، ISVها که برنامههای کاربردی تجاری را توسعه میدهند و توسعهدهندگان که برنامههای کاربردی را توسعه میدهند و در توسعه سیستمعامل تلفنهمراه کمک میکنند و تکامل میدهند اگر سیستمعامل تلفنهمراه منبع باز باشد.
تکامل باز بودن سیستمعامل موبایل
چند سال پیش، بیشتر دستگاههای تلفنهمراه گوشی بودند، و بیشتر افراد از تلفن برای تماسهای صوتی، بهعنوان یک دفترچه تلفن، و پیام استفاده میکردند. برای مصرفکنندگان، برنامههای کاربردی که آنها میتوانستند بازی کنند محدود به برنامههای کاربردی ساخته شده در دستگاهها بود زمانی که دستگاه از کارخانه خارج میشد. برای توسعهدهندگان نرمافزار و یا ISV های شخص ثالث، دسترسی به هر سطح از کد منبع بدون قرارداد با صاحب سیستمعامل وجود نداشت. مانند سیستمعامل تلفنهمراه که یک سیستم کاملا بسته بود و معمولا متعلق به سازنده تلفنهمراه بود. بنابراین اپراتورها، مجبور به همکاری نزدیک با توسعهدهندگان سیستمعامل بودند تا خدمات خود را ارائه کنند، چرا که تنها کسانی که سیستمعامل تلفنهمراه را توسعه میدادند چگونگی توسعه برنامههای کاربردی را میدانستند.
آمادگی ابر
ابر بهطور گستردهای توسط کاربران تلفنهمراه استفاده میشود و بسیاری از سرویسهای ابری بهعنوان وب سایتها معرفی میشود و توسط مرورگر ارائه شده در تلفنهمراه قابل دسترسی است. بیشتر خدمات ابر از طریق برنامههای کاربردی وب ارائه میشود، که از یک فروشگاه نرمافزار نصب شده و مانند برنامههای کاربردی بومی بر روی سرویسگیرنده تلفنهمراه اجرا میشود.
قابلیت HTML5
قابلیت HTML5 برای برنامههای کاربردی وب برای ادغام خدمات ابر و برای ارائه یک تجربه کاربری خوب ضروری است.
موتورهای وب استفاده میشود: ما موتورهای طرح وب و موتورهای جاوا اسکریپت را که بر روی مرورگرهای تلفنهمراه استفاده میشوند ذکر میکنیم. کروم * میتواند مرورگر پیش فرض آندروید شود و موفقیت خود را از کامپیوتر به تلفنهمراه ببرد. WebKit در iOS و اندروید استفاده میشود.
نرم افزار وب
برنامهکاربردی وب، توسعهی برنامههای کاربردی سمت سرویسگیرنده را با فنآوریهای وب تعریف میکند. که ویژگیهای غنی با ارائه رابطهای برنامه کاربردی برای توسعهی سمت سرویسگیرنده ارائه میکند. برنامهی وب میتواند حتی در دستگاههای آفلاین نصب و اجرا شود. برنامه وب میتواند به دستگاهها و منابع محلی به عنوان یک نرمافزار بومی دسترسی پیدا کند و میتواند در یک فروشگاه نرمافزار فروخته شود، که از ارائهی خدمات ابر و صدور صورتحساب سودآورتر است.
قابلیت cross-Platform
HTML5 بهخوبی برای قابلیت cross-Platform آن شناخته شده است. اما در واقعیت، سیستمعاملهای موبایلهای مختلف پشتیبانی متفاوتی از HTML5 ارائه میکنند و استاندارد HTML5 همچنان ادامه دارد. PhoneGap برای رسیدگی به پشتیبانی cross-Platform HTML5 با ارائه API های خود دستگاه توسعه داده شده است. iOS اپل، اندروید و ویندوز فون همگی از PhoneGap پشتیبانی میکنند.
کارآیی
کارآیی در موارد بسیاری توسط توسعهدهندگان نرمافزار تلفنهمراه شکایت شده است هنگامیکه آنها شروع به ساخت برنامههای کاربردی با HTML5 میکنند. بهینهسازی برای دستگاههای تلفنهمراه مهمترین کار برای انجام موفقیت HTML5 در حوزهی تلفنهمراه است. ما در زیر مهمترین مناطق برای انجام کار بهینهسازی برای سیستمعاملهای موبایل را شرح میدهیم:
• شتاب سختافزاری. گرافیک و فیلم باید توسط سختافزار شتاب گیرند. WebGL بر روی سیستمعاملهای بیشتری فعال است.
• پشتیبانی multithreading. کارگران وب باید بهعنوان یک ویژگی اساسی در HTML5پشتیبانی شوند.
• بهینهسازی موتور جاوا اسکریپت. JIT (تنها در زمان) در هر دو SFX و V8فعال است.
• پشتیبانی نرمافزارهای بومی و یا ترکیبی. قابلیت استفاده مجدد از کتابخانههای بومی موجود روش دیگری برای برنامههای کاربردی وب خواهد بود. آندروید NDK یک چنین توانمندی فراهم میکند و بهطورگستردهای در برنامههای کاربردی آندروید استفاده میشود. اما در برنامههای وب، بهطورگسترده استفاده نمیشود. NaCl با کروم گزینهای برای حمایت از آن است.
ادغام ابر
علاوه بر قابلیتهای قدرتمند ارائه شده توسط HTML5، ادغام بدون درز بین ابر و مشتری مهمتر است. این نه تنها برای برنامههای کاربردی وب است، بلکه برای برنامههای کاربردی بومی نیز است. دلایل مهم برای یکپارچهسازی شامل:
• ذخیرهسازی یکپارچه ابر بدون درز. مشتری باید از ذخیرهسازی ابر فقط بهعنوان استفادهی آن در ذخیرهسازی بومی استفاده کند. که نیاز به مشتری ذخیرهسازی ابر که بهطور محکم با سیستمعامل تلفنهمراه یکپارچه شده است دارد. اپل iCloud را که عمیقا به iOS5 پیوسته است ساخته است. گوگل درایو با خدمات گوگل وب یکپارچه شده است.
• دسترسی رابطهای برنامه کاربردی ابر. در سمت سرویسگیرنده ابر، سیستمعامل تلفنهمراه باید قادر به ارائهی کتابخانههای آسان برای برنامههای کاربردی وب و برای دسترسی به API های بومی مشتری ابر، که بهطور معمول SOAP، API های آرام، و یا پرسوجو هستند باشد.
• مدیریت حساب. با ادغام ابر، مشتریان متعدد با یک حساب، ابر را به اشتراک میگذارند و هماهنگسازی بین آنها باید مدیریت شود. حساب باید شدیدا در رابطهای برنامه کاربردی سیستمعامل ادغام شده باشد و حساب تلفنهمراه باید برای برنامههای کاربردی، دسترسی امن به خدمات ارائه شده یابر و منابع محلی را فراهم کند. هماهنگسازی و اطلاع رسانی از ویژگیهای کلیدی در سیستمعاملهای موبایل برای استفاده از قابلیت یکپارچهسازی ابر در سایز بزرگ است.
این مقاله در سال 2012 در مجله فناوری اینتل، توسط گروه نرم افزار و خدمات منتشر شده و در سایت ای ترجمه جهت دانلود ارائه شده است. در صورت نیاز به دانلود رایگان اصل مقاله انگلیسی و ترجمه آن می توانید به پست دانلود ترجمه مقاله چگونگی معماری سیستم عامل تلفن همراه در سایت ای ترجمه مراجعه نمایید.