سیستم عامل اندروید واقعاً چقدر بهینه است؟

[Gsm-Clinic 23]

سیستم عامل اندروید واقعاً چقدر بهینه است؟

 

 

از گوشه و کنار این جمله زیاد به گوش می رسد: «... اما اندروید بهینه سازی نشده است». این نظرات از آنجا منشا می گیرد که دستگاه های اپل بسیار بهینه شده اند زیرا اپل نه تنها سخت افزار، بلکه نرم افزار و کل اکوسیستم را تحت کنترل دارد. در مقابل، آنچه که درباره سیستم عامل اندروید تصور می شود این است که این سیستم عامل یک مخلوط درهم از اجزای متعدد ازسوی گروهی تولیدکننده و OEM ها (تولید کنندگان سخت افزار کم نام و نشان) است. مطمئنا، راهکار اپل باید بهینه تر باشد؛ اینطور نیست؟

 

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

 

نخستین حقیقتی که باید دریابیم این است که اساس این ادعاها و باورها در واقع در همان جنگ سنتی میان «مک» و «رایانه شخصی» قرار دارد و تا کنون هم همین طور بوده است. اپل، سخت افزار و نرم افزار را در آن واحد در اختیار گرفت و در نتیجه، طبق اعلام اپل، این کار «به خوبی جواب داده است». در مقابل، مایکروسافت تنها نرم افزار را تحت کنترل گرفت و سخت افزارهای خود را از کمپانی هایی چون Dell، HP، IBM و سایرین تامین کرد. حتی در درون کامپیوترهای Dell، HP، IBM و سایر رایانه های رومیزی، CPU هایی از تولیدکننده هایی چون اینتل یا AMD و GPU هایی از ATI (در حال حاضر AMD) و NVIDIA و یک دیسک سخت از تولیدکنندگان مختلف قرار دارد. در عوض، اپل از این ایده در کمپین های بازاریابی خود استفاده کرده است. بنابراین، تا حدی این ادعاها درست بوده است.

 

در تاریخ 20 سال گذشته ویندوز، همه اتفاقات حول محور «درایورهای درست» و «ارور مخوف صفحه آبی» یا «صفحه آبی مرگ» بوده است. خیلی سریع به اتفاقات امروز می رویم و می بینیم که موقعیت و وضعیت مشابهی با گذشته داریم. اپل، درست مانند مک، همچنان سخت افزار و نرم افزار آیفون را تحت کنترل دارد اما اندروید درست مانند ویندوز بوده است. گوگل، همانند مایکروسافت، تنها سیستم عامل را ارائه می کند و در مقابل، سخت افزارهای مورد نیاز خود را از طیف وسیعی از تولیدکنندگان و OEM ها، از کوالکام گرفته تا سامسونگ، سونی، ال جی، HTC، مدیاتک، هوآوی و... تامین می کند.

 

همچنین، وقتی در نظر می گیریم که موبایل های اندرویدی شامل طیف وسیعی از محصولات رده پایین با سطح قیمتی زیر 150 دلار و امکانات پایینی چون صفحه نمایش کوچک، پردازنده های ضعیف و حافظه اندک تا پرچمدارانی با سطح قیمتی 4 تا 5 برابر بالاتر، می شوند، به این نتیجه می رسیم که اگر دستگاه اشتباهی را انتخاب کنیم، به راحتی اسیر یک تجربه بد از اندروید خواهیم شد. اما این فرضیه تا چه اندازه درست است؟ برخی متخصصین باور دارند که این ادعا درست نیست و در واقع اندروید هم بهینه سازی شده و می توان این ادعا را اثبات کرد.

 

زبان برنامه نویسی جاوا در برابر زبان برنامه نویسی C

جاوا، زبان برنامه نویسی پیش فرض برای اندروید است. یک حقیقت وجود دارد که اپلیکیشن های نوشته شده توسط زبان برنامه نویسی جاوا کندتر از اپلیکیشن ها برنامه هایی هستند که توسط زبان های برنامه نویسی C و C++ (که با کدهای مادر ماشین تنظیم شده) نوشته می شوند. اما این تفاوت سرعت، در عمل چندان هم زیاد نیست چراکه یک اپلیکیشن معمولی برای اجرا، بیش از آنکه نیازمند محاسبات سنگین باشد تا بتواند اجرا شود، زمان انتظار بیشتری را برای دستورات کاربر یا ترافیک شبکه می طلبد.

 

در نمودار میله ای زیر، توضیح داده می شود که سرعت اپلیکیشن های نوشته شده توسط زبان های برنامه نویسی جاوا و C چه تفاوتی با هم دارد.

 

 

نخستین پله نردبان ادعای «اندروید بهینه سازی نشده»، این تفکر است که اپلیکیشن های قابل اجرا روی پلتفرم iOS، به دلیل عدم استفاده از زبان برنامه نویسی جاوا، سریعتر هستند. البته فراموش نکنید که چند سطر بالاتر درباره «سرعت واقعی» چه گفتیم؛ همچنین، اهمیتی ندارد که در بخش های زیادی از سیستم عامل اندروید، به جای زبان برنامه نویسی C از زبان جاوا استفاده شده باشد.

 

علاوه بر این، اگر نخواهیم بگوییم همه، بیشتر اپلیکیشن ها و بازی های سنگین که نیازمند CPU و GPU قوی هستند، برای سیستم عامل اندروید، به زبان برنامه نویسی C نوشته شده اند. به عنوان مثال، هر اپلیکیشن یا بازی که از یکی از موتورهای محبوب 3D، نظیر Unity یا موتور Unreal استفاده می کند، در واقع نه یک اپلیکیشن جاوا، بلکه یک اپلیکیشن بومی اندروید محسوب می شود.

 

از صحبت های بالا چه نتیجه ای می گیریم؟ نخست اینکه در حالی که نرم افزارها و اپلیکیشن های جاوا از اپلیکیشن های بومی در iOS کندتر هستند اما تفاوت سرعت در عمل و دنیای واقعی چندان محسوس نیست. دوم آنکه، ماشین مجازی جاوا (Java VM) اندروید دائما در حال بهبود است و در حال حاضر شامل برخی تکنولوژی های بسیار جذاب و استثنایی است که می تواند اجرای برنامه های تحت جاوا را سرعت بخشد. و در نهایت، نتیجه گیری سوم آنکه، بخش های بزرگتر اندروید شامل کرنل لینوکس، توسط زبان برنامه نویسی C نوشته شده اند.

 

شتاب سخت افزاری

 

 

اما دومین سوال این است که: آیا اپل عملکردهای خاصی را روی پردازنده های خود افزوده تا بتواند اجرای برخی عملیات را شتاب دهد؟ همچنین، اگر پاسخ مثبت است، پس چرا کوالکام و سامسونگ این کار را نکرده اند؟ در پاسخ به این سوال باید گفت که کمپانی اپل امتیاز مهندسی ساخت ARM را برای چیپ های خود در اختیار دارد که این نوع مهندسی به اپل اجازه می دهد تا بتواند پردازنده های سازگار با ARM را با استفاده از مهندسان و فناوری انحصاری خود تولید کند.

 

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

 

این بدان معناست که فرض را بر این بگیریم که اپل به وجود برخی عملیات مشخص و همیشگی پی برده باشد، در آن صورت می تواند به جای نرم افزار، سخت افزار خاصی را هم جهت اجرای این وظایف به پردازنده های خود بیافزاید. ایده اصلی در اینجا این است که وظایف انجام شده در سخت افزار سریع تر از مشابه نرم افزاری است. یک مثال خوب برای این ایده، «رمزنگاری» است. مثلا، در مجموعه دستورالعمل های ARMv7، هیچ دستورالعملی برای رمزنگاری AES وجود ندارد در حالی که در ساختار مجموعه عملکردهای ARMv8، عملکردهای خاصی برای اجرای رمزنگاری AES در سخت افزار تعریف شده است. این بدان معناست که رمزنگاری AES روی پردازنده های ARMv8 بسیار سریع تر از رمزنگاری روی پردازنده های ARMv7 است.

 

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

 

 

اما این تمام ماجرا نیست. راه دیگری که ممکن است اپل به کمک آن بتواند در پردازنده های خود شتاب سخت افزاری ایجاد کند، افزودن سخت افزار مخصوصی است که نیاز به برنامه دهی و اجرای برنامه به همان شیوه ای است که یک پردازنده از GPU و DSP استفاده می کند. به عبارت دیگر، کامپایلر و از همه مهم تر، SDK سیستم عامل iOS به شیوه ای نوشته شده که برخی کاربردها به واسطه تنظیم برخی پارامترها روی سخت افزار اجرا می شوند و سپس سخت افزار را وادار به پردازش این عملکرد می کنند.

 

این همان اتفاقی است که توسط GPU*می افتد. یک اپلیکیشن، اطلاعات سه گانه خود را در بخش هایی از حافظه پیاده سازی می کند و سپس به GPU دستور می دهد تا روی این اطلاعات کار کند؛ فرآیند مشابهی نیز در DSP یا یک ISP رخ می دهد.

 

به عنوان مثال، بیایید تصور کنیم که مهندسین اپل متوجه شوند که یک SDK همیشه باید یک سری پیام را معکوس منتشر کند. بنابراین، Apple باید به شکل elppA در آید. این کار به راحتی در نرم افزار امکانپذیر است اما اگر بتوان یک واحد سخت افزاری به خاص برای این کار درست کرد که می توانست روی بافرهای 16 بایتی کار کند، در آن صورت شاید بتوان آنها یک یا دو سیکل ساعت معکوس کرد.

 

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

 

این مثال دو معنای متفاوت دارد؛ نخست، ساختمان و مهندسی ARM هم اکنون متشکل از عملکردهای پیچیده ای است که با عنوان NEON شناخته می شود و می تواند به روش موازی روی داده ها کار کند. این عملکرد تکی و عملکردهای داده ای چندگانه (SIMD) برای اجرای یک وظیفه مشابه، به موازات روی اجزای چندگانه، هم اندازه و هم نوع داده از یک عملکرد استفاده می کنند.

 

دوم آنکه، پردازنده های موبایل، هم اکنون دارای قطعات سخت افزاری مجزایی هستند که عملیات اختصاصی نظیر GPU، DSP، ISP و امثال آن را اجرا می کنند.

 

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

 

یکپارچگی سیستم

یکی از جنبه های اصلی «بهینه سازی»، حصول اطمینان از فعالیت درست و دقیق اجزای اصلی با یکدیگر است تا بدین ترتیب، یک سیستم به صورت یکپارچه عمل کند. هر چقدر هم که GPU بسیار سریعی داشته باشیم اما اگر پردازنده اصلی (CPU) از طریق یک پورت کند سریال BUS که از درایورهای بهینه نشده بهره می گیرد ، به این سخت افزار متصل شده باشد، هیچ سودی ندارد. این موضوع برای DSP، ISP و سایر اجزای سیستم هم صدق می کند.

 

برای تولیدکنندگان سیستم روی تراشه (SoC)، نظیر کوالکام و طراحان GPU/CPU، نظیر ARM، تضمین بهینه بودن نرم افزار درایورهای مورد نیاز برای استفاده از محصولات آنها، از ضروریات اصلی محسوب می شود.

 

سیستم عامل

 

اما می رسیم به خود سیستم عامل اندروید، تشکیلات داخلی، زیرشاخه های سیستم و چارچوب آن؛ آیا همه اینها بهینه شده اند؟ پاسخ ساده این است که خیر! دلیل آن هم واضح است؛ سیستم عامل اندروید از سال 2008 میلادی تاکنون درحال توسعه بود است. این سیستم عامل طی این سال ها رشد کرده و به بلوغی جدی رسیده است. برای درک این نکته کافیست اندروید نسخه 2 را با اندروید نسخه 7 مقایسه کنید. این سیستم عامل همچنین روی پردازنده های ARM، اینتل و MIP اجرا شده و مهندسان گوگل، سامسونگ، ARM و بسیاری دیگر، در موفقیت اندروید نقش داشته اند. از همه اینها مهم تر، هسته اصلی اندروید متن باز است و این بدان معناست که کدهای مرجع آن در دسترس عموم مردم جهان قرار دارد تا بتوانند هر طور که دوست دارند آنها را تغییر داده یا مورد بررسی قرار دهند.

 

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

 

 

اما از سوی دیگر، مشکل سیستم بهینه سازی گسترده نیز وجود دارد و آن چگونگی ادغام سیستم با هم است.

 

وقتی به سیستم «ردیاب گوگل» (Google Track) در تبلیغات و جست و جو توجه یا به زیرساخت پشت یوتیوب نگاه می کنیم یا پیچیدگی های تجاری سیستم «ابری گوگل» (Google Cloud) را در نظر می گیریم، خیلی مضحک است که تصور کنیم گوگل مهندسینی در اختیار ندارد که با نحوه طراحی و ساخت یک ساختار سیستمی کارآمد و با راندمان بالا آشنایی ندارند. نتیجه می گیریم که کدهای مرجع و همینطور طراحی سیستم اندروید، همگی بهینه شده و کارآمد هستند.

 

جمع بندی

با در نظر گرفتن همه موارد، از طراحی SoC ها گرفته تا طراحی سخت افزار، درایورها، سیستم عامل اندروید و مهندسینی که تمامی این اجزا را در کنار هم قرار داده اند، به سختی می توان توجیه و دلیلی منطقی برای این ادعا که «اندروی بهینه نشده»، آورد. با اینحال، این بدان معنا نیست که این سیستم عامل دیگر جایی برای بهتر شدن نداشته باشد یا اینکه تمامی تولیدکنندگان اسمارتفون ها، حداکثر زمان و پول خود را برای اطمینان از بکارگیری بهترین درایورها و بالاترین سطح ادغام این سیستم، صرف کرده اند.

سوال اینجاست، پس چرا این برداشت وجود دارد که «اندروید بهینه سازی نشده است؟» شاید بتوان به شکلی ساده پاسخ را در سه بخش داد:

 

اپل سالهاست که دنباله رو مفهوم «به سادگی کار می کند»، است که این مفهوم از جنبه بازاریابی قطعا یک پیام قدرتمند محسوب می شود.

اپل، در لحظه، برنده رقابت بر سر راندمان است. بنابراین، کل باور کاربران مبنی بر «بهینه نبودن اندروید»، به نظر واکنشی در برابر این اتفاق است.

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

 

منبع:android authority