همونطور که میدونید گوگل کروم ار ابتدا برپایهٔ وبکیت ساخته شده بود، اما فقط از بعضی قسمتهاش استفاده میکرد (تفسیر صفحات HTML و CSS و مشخص کردن ساختار صفحات) و کارهایی مثل networking و نمایش/رندر فانتها (
http://www.chromium.org/developers/desi ... s-and-skia که در مقایسه با سافاری واقعاً افتضاحه!) رو خودشون نوشته بودند و تحت پروژهٔ Chromium منتشر میکردند، و صدالبته موتور پردازش جاوااسکریپت V8 که از جواهراتِ دنیای کامپیوتره و برخلاف ادعاهای اپل در کنفرانسهاش، همیشه سرعت بسیار بسیار بیشتری از JavaScriptCore (یا Nitro) اپل داشته و هنوز هم داره و خواهد داشت.
اگر اشتباه نکنم حدود سال ۲۰۰۹ بود که به کرومیوم چند ویژگی خیلی مهم اضافه شد: multiprocess رندرینگ (منظور ایجاد پراسسهای مختلف در سطح سیستمعامل برای رندر و پردازش هم صفحه جدا از صفحات دیگهست، تا اگر فرضاً یکی کرش کرد بقیه آسیب نبینن. و البته با multiprocess در سیپییوها نباید اشتباهش بگیرید که کلاً یه چیز دیگهست!) و sandboxing (برای ایزوله کردن این پراسسها). این دو قابلیت باعث شدند که کروم از نظر سرعت و ثبات و امنیت بهمراتب از سافاری بهتر باشه (هرچند، من همون موقع و همین الآن سافاری رو از نظر اینترفیس ترجیح میدم و براوزر اصلیمه)، و اپل برای عقب نماندن بیشتر پروژهٔ WebKit2 رو راهاندازی کرد که سعی میکرد sandboxing و رندرینگ مبتنی بر پراسس رو وارد وبکیت بکنه. این مربوط به دورهٔ تلخِ حدوداً یک سالهای میشه که بعد از آمدن سافاری ۵، دائم پراسسِ رندرینگ کرش میکرد و لازم میشد تا «تمام» تبهای سافاری ریلود بشن! بعد از حدود ۱ سال اپل مشکل رو تا حد زیادی حل کرد، و الآن در موریکس دیگه این مشکل وجود نداره (و بهبودهای خوبی هم در زمینهٔ امنیتی داده شده).
(قسمتی اطلاعات بالا رو از یک مقالهٔ خیلی مطرح Paul Irish که پارسال منتشر شد کپی کردهام:
http://www.paulirish.com/2013/webkit-for-developers - در مورد وبکیت۲ هم شاید این مقاله مفید باشه:
http://arstechnica.com/apple/2010/04/we ... -renderer/)
همونطور هم که یادتونه سال قبل گوگل از پروژهٔ وبکیت خارج شد و Blink رو راهاندازی کرد و همهٔ چیزهای خوبش رو هم با خودش برد
این مقدمهٔ طولانی و خستهکننده بود از داستان وبکیت۲. حالا داستان کرشهای زیاد سافاری در iOS 7 جریانش چیه؟ راستش نمیدونم، و وقتی به لاگ کرشها هم نگاه میکنم چیزی دستگیرم نمیشه جز این که بیشتر کرشهای آیپد من در قسمت event-dispatcher هستند، که شاید مربوط به XPC باشه. دقیقترش رو ولی نمیدونم. چیزی که مهمه اینه که این اتفاق واقعاً میافته. تاپیک زیر رو مثلاً ببینید:
http://forums.macrumors.com/showthread.php?t=1672010، یا چهل صفحۀ
https://discussions.apple.com/thread/53 ... 0&tstart=0 - اینها دیگه مشکلات اینترنت ایران رو هم ندارند که بخواهیم تقصیر رو گردن اون بیاندازیم.
در مورد اینکه چرا در iOS 7 تعداد ریلودها انقدر بالاست هم راستش نظر دقیقی ندارم (هرچند فرضیه کلی دارم که در ادامه توضیح میدم!) - فقط میدونم که من روی همین دستگاه و زمان iOS 6 میتونستم ۱۰-۱۲ تا تب سنگین رو باز کنم و برم به مثلاً برنامهٔ Documents و بعد که برمیگشتم تبها سر جاشون بودن. اما الآن اگر ۵ تا تب از ایرماگ باز کنم تب اولی نیاز به ریلود داره! اگر سویچ کنم به یه برنامهٔ دیگه که حتی اگر یک تب هم باشه ریلود میشه. این تنها دلیلش همین «کمبود رم» میتونه باشه.
در آیپد حافظهٔ بین پردازشگر گرافیکی و «رم» عادی مشترکه (shared memory). این یعنی سیستم ۱ گیگابایت فضا برای ذخیرهٔ اطلاعات برنامهها نداره - بسته بهاینکه چقدر پردازش گرافیکی در اون لحظه نیاز باشه میزان رمی که برای برنامهها میمونه کاهش پیدا میکنه. از طرف دیگه، بهخاطر ساختار composite ـی که اینترفیس آیفون و مک دارند (Quartz)، پردازشگر گرافیکی ممکنه حجم خیلی زیادی رم اشغال بکنه - مثلاً فرش کنید در Home Screen داخل یک فولدر رفتهاید و Notification Center رو باز کردهاید. الآن حافظهٔ پردازشگر گرافیکی شامل خیلی چیزها، از جمله موارد زیره:
۱) یک تصویر ۲۰۴۸×۱۵۳۶ پیکسلی (بدون کانال آلفا) از عکس پسزمینه
۲) یک لایهٔ تقریباً ۱۰۰۰×۱۰۰۰ پیکسل که پسزمینهٔ فولدره، و textture ـش محتوای لایهٔ قبلی (پسزمینه) با اعمال افکتِ blur ـه
۳) تصویر آیکنهای فولدر (هر کدام یک لایه)
۴) تصویرلیبلِ آیکنها (هر کدام یک لایه)
۵) تصویر سایهٔ لیبلها (هر کدام یک لایه)
۶) تصویر نهایی، که در هر لحظه باید نشون داده بشه. اگر آیپد رو کمی بچرخونید تا افکت parallex ـش فعال بشه، این تصویر از اول ساخته میشه.
اینجا تصاویر مثلاً با JPEG فشرده نشدهاند، و وقتی تصویری ۲۰۴۸×۱۵۳۶ پیکسله با عمق ۳۲ بیتی، رسماً نیاز به ۱۲ مگابایت رم داره!
این اتفاق در تمام سیستمعامل میافته. مثلاً در Settings، تمام آیکنها و دکمهها و view ـها هر کدوم یک لایه هستند. وقتی تعداد لایهها زیاد بشه، سیستم به رم بیشتری برای پردازش گرافیکی نیاز پیدا میکنه و ناچار باید اطلاعاتی رو از رم تخلیه کرد. چون در iOS چیزی به اسم virtual memory نداریم، اطلاعاتی که از روی رم باید پاکشون بکنیم «واقعاً» پاک میشن و مثل مک روی دیسک نوشته نمیشن! و وقتی دوباره بهشون نیاز هست باید از اول از اینترنت دانلود و پردازش و نمایش بشن؛ یعنی، اگر سیستم مموری کم بیاره تبهای سافاری رو از بین میبره و نیاز به ریلودشون هست
این compositing/layered windowing system در آکوا رمز زیبایی OS X و iOS ـه، و رمز کندی سرعت OS X در سالهای اولیه (که خوشبختانه من اون موفع مک نداشتم).
حالا چه اتفاقی در iOS 7 افتاده که جدیده؟ تصاویر زیر بهخوبی نشون میدن که چه چیزی جدیده:
لایهها در UIDateTimePicker در iOS 6:
لایهها در UIDateTimePicker در iOS 7 (تصویر رو باید در صفحهٔ جدید باز کنید تا دقیق بتونید ببینیدش):
(تصویر از
http://blog.ittybittyapps.com/blog/2013 ... s-uipicker، بحث بیشتر در
https://news.ycombinator.com/item?id=6416045)
همانطور که در تصویر بالا دیده میشه، برای نمایش افکتهای «قشنگ» iOS 7، نیاز به لایههای بیشتر (یا «خیلی خیلی بیشتر»!) ـی هست، حتی برای چیز سادهای مثل date picker. همین خودش کلی حافظهٔ بیشتر رو اشغال میکنه.
مسألهٔ دیگه بازتر شدن API ـهای multitasking هستند، که باعث میشه برنامهها و سرویسهای بیشتری در پسزمینه اجرا بشن (اگر هر روز ساعت ۱۰ صبح میل رو باز میکنید، حتی اگر الآن میل رو از قسمت multitasking بستهاید باز هم ممکنه میل باز بشه و در پس زمینه حافظه و سایکل CPU مصرف بکنه).
چرا در آیفون مشکل انقدر حاد نیست؟ شاید چون آیفون صفحهٔ کوچکتری داره (آیپد صفحهش ۳۳۰ درصد بزرگتر، یا معادل ۴٫۳ برابر آیفونه)، اما آیفون ۵/۵سی/۵اس و آیپد ۴/ایر/مینیرتینا همهشون ۱ گیگ رم دارن! آیپد شدیداً به رم ۲ گیگ نیاز داره، خصوصاً با iOS 7، اما اضافه کردن رم بیشتر هم باعث میشه هزینهٔ ساخت هر آیپد ۱ تا ۲ دلار گرونتر بشه
(که خیلی برای اپلی که بدون شرم هنوز بعد از این همه سال نهتنها مدل ۱۶ گیگی آیفون/آیپد رو حذف نکرده، بلکه مدتی پیش در چین و اروپا مدل ۸ گیگی رو هم دوباره شروع کرد به فروختن، سنگین خواهد بود!)، و هم روشن نگه داشتن میلیاردها ترانزیستور دیگه انرژی بیشتری مصرف میکنه و باطری آیپد زودتر تموم میشه.