#اعماق_اندروید #معماری_اندروید #سید_حسن_هاشمی
در جلسات قبلی سری مقالات اعماق اندروید به بررسی Task ها در اندروید پرداختیم و اون بخش هنوز ادامه داره امروز معماری اندروید رو می خواهیم براتون شرح بدیم که هر برنامه نویس اندرویدی باید با معماری این سیستم عامل آشنا باشه تا بتونه براش برنامه های کاربردی بنویسه ... سری آموزش های معماری اندروید توسط آقای سید حسن هاشمی نوشته شده و با اجازه خودشون در اینجا قرار داده میشه .
شروع آموزش:
فکر نمی کنم نیازی باشه که بخوایم اهمیت درک معماری سیستم عاملی که داریم ازش استفاده و یا احیاناً داریم براش برنامه می نویسیم رو اثبات کنیم.
درک عمیق از کمپوننت های مختلف شکل دهنده ساختار سیستم عامل به ما کمک می کنه تا حداکثر استفاده رو از امکانات فراهم شده توسط اون رو داشته باشیم. که از قضا اندروید هست برای این پست.
برای مثال در سیستم عامل ویندوز درک درست و حسابی از process management برای تضمین امنیت نرم افزار مهمه.
و یا مدل مدیریت thread ها که توی Multi threading حیاتیه.
برای سیستم عامل اندروید هم از این مثال ها میشه زد.
اولش می خواستم توی یه پست اینکارو انجام بدم، اما دیدم دیاگرام توضیحات زیادی داره و توی یه پست خیلی طولانی میشه. در نتیجه به صورت چند پست می نویسمشون.
برای اولین میریم سراغ خاستگاه لینوکسی اندروید.
پس برای شروع دیاگرام رو میذارم:
در جلسات قبلی سری مقالات اعماق اندروید به بررسی Task ها در اندروید پرداختیم و اون بخش هنوز ادامه داره امروز معماری اندروید رو می خواهیم براتون شرح بدیم که هر برنامه نویس اندرویدی باید با معماری این سیستم عامل آشنا باشه تا بتونه براش برنامه های کاربردی بنویسه ... سری آموزش های معماری اندروید توسط آقای سید حسن هاشمی نوشته شده و با اجازه خودشون در اینجا قرار داده میشه .
شروع آموزش:
فکر نمی کنم نیازی باشه که بخوایم اهمیت درک معماری سیستم عاملی که داریم ازش استفاده و یا احیاناً داریم براش برنامه می نویسیم رو اثبات کنیم.
درک عمیق از کمپوننت های مختلف شکل دهنده ساختار سیستم عامل به ما کمک می کنه تا حداکثر استفاده رو از امکانات فراهم شده توسط اون رو داشته باشیم. که از قضا اندروید هست برای این پست.
برای مثال در سیستم عامل ویندوز درک درست و حسابی از process management برای تضمین امنیت نرم افزار مهمه.
و یا مدل مدیریت thread ها که توی Multi threading حیاتیه.
برای سیستم عامل اندروید هم از این مثال ها میشه زد.
اولش می خواستم توی یه پست اینکارو انجام بدم، اما دیدم دیاگرام توضیحات زیادی داره و توی یه پست خیلی طولانی میشه. در نتیجه به صورت چند پست می نویسمشون.
برای اولین میریم سراغ خاستگاه لینوکسی اندروید.
پس برای شروع دیاگرام رو میذارم:
توی این دیاگرام قسمت قرمز رنگ به زبان C و Assembly نوشته شده، قسمت سبز رنگ ++C و قسمت آبی هم کاملاً جاوا هست.
@androiddevelop
همونجور که می دونید اندروید مبتنی بر kernel 2.6 لینوکس هستش.
برای این که از بحث اصلی دور نشیم و هم یه یاد آوری بشه یه توضیح مختصری از کرنل:
kernel بخشی از سیستم عامل هست که دسترسی بخش های مختلف سیستم عامل رو به منابع سخت افزار فراهم و مدیریت می کنه. در ساده ترین حالت thread ی کد برنامه شما رو اجرا می کنه از قلب kernel رد میشه:) و به cpu میرسه.
به علاوه که kernel دسترسی شما رو به سخت افزار به صورت انتزاعی برآورده می کنه و از اونطرف خودش با استفاده از درایوارهایی که زمان اجرا لود می کنه به صورت واقعی به سخت افزار دسترسی پیدا می کنه. به صورت اختصاری به این کار می گن HAL .
توضیحات در مورد HAL در حیطه این پست نیست.
خب برگردیم به بحث اصلیمون، کرنل لینوکس مدیریت process، مدیریت حافظه و... رو فراهم می کنه. اما ...
اما اندروید از Linux kernel بیشتر به عنوان لایه ای که انتزاع کننده سخت افزار هست استفاده می کنه. (نه به این معنی که بقیه جاهاش رو بی خیال شده ) چون اگر واقع بین باشیم واقعاً خوب پیاده سازی شده و کاراییش در این بخث ثابت کرده.
در Kernel 2.6 بهینه سازی خیلی خیلی زیادی انجام شد تا بتونن برای دیوایس های با cpu و مموری پایین ازش استفاده کنند.
حالا این حرف هایی که زدیم به این معنیه که فی المثل اگه شما روزی خواستین یه Device بسازید که از سیستم عامل اندروید استفاده می کنه، اولین کاری که باید بکنید اینه که برای سخت افزارهایی مثل دوربین، یو اس بی ... درایورهایی بنویسید. که از قواعد کرنل لینوکس پیروی می کنن.
که در واقع توی ++C چیزی فراتر از یه سری header نیستن، توابع اجباری رو پیاده سازی می کنید و بعد اونا رو به عنوان module در اختیار کرنل لینوکس قرار بدید. بقیه اش با خودش؛ یه جورایی منو یاده windows service میندازه :)
@androiddevelop
همونجور که می دونید اندروید مبتنی بر kernel 2.6 لینوکس هستش.
برای این که از بحث اصلی دور نشیم و هم یه یاد آوری بشه یه توضیح مختصری از کرنل:
kernel بخشی از سیستم عامل هست که دسترسی بخش های مختلف سیستم عامل رو به منابع سخت افزار فراهم و مدیریت می کنه. در ساده ترین حالت thread ی کد برنامه شما رو اجرا می کنه از قلب kernel رد میشه:) و به cpu میرسه.
به علاوه که kernel دسترسی شما رو به سخت افزار به صورت انتزاعی برآورده می کنه و از اونطرف خودش با استفاده از درایوارهایی که زمان اجرا لود می کنه به صورت واقعی به سخت افزار دسترسی پیدا می کنه. به صورت اختصاری به این کار می گن HAL .
توضیحات در مورد HAL در حیطه این پست نیست.
خب برگردیم به بحث اصلیمون، کرنل لینوکس مدیریت process، مدیریت حافظه و... رو فراهم می کنه. اما ...
اما اندروید از Linux kernel بیشتر به عنوان لایه ای که انتزاع کننده سخت افزار هست استفاده می کنه. (نه به این معنی که بقیه جاهاش رو بی خیال شده ) چون اگر واقع بین باشیم واقعاً خوب پیاده سازی شده و کاراییش در این بخث ثابت کرده.
در Kernel 2.6 بهینه سازی خیلی خیلی زیادی انجام شد تا بتونن برای دیوایس های با cpu و مموری پایین ازش استفاده کنند.
حالا این حرف هایی که زدیم به این معنیه که فی المثل اگه شما روزی خواستین یه Device بسازید که از سیستم عامل اندروید استفاده می کنه، اولین کاری که باید بکنید اینه که برای سخت افزارهایی مثل دوربین، یو اس بی ... درایورهایی بنویسید. که از قواعد کرنل لینوکس پیروی می کنن.
که در واقع توی ++C چیزی فراتر از یه سری header نیستن، توابع اجباری رو پیاده سازی می کنید و بعد اونا رو به عنوان module در اختیار کرنل لینوکس قرار بدید. بقیه اش با خودش؛ یه جورایی منو یاده windows service میندازه :)
یه نکته مثبتی دیگه ای که کرنل لینوکس داره، و برمیگرده به ماهیت اوپن سورس بودن اینه که خیلی زیاد قابل سفارشی کردنه. یعنی تا جایی که من متوجه شدم و سورس های این دوتا رو (کرنلی که گوگل استفاده می کنمه وکرنل اورجینال لینوکس) خیلی جاهاش توی کرنل اندروید حذف شدن و منطقی هم هست چون کرنل لینوکس برای سیستم بزرگتری تدارک دیده شده در حالیکه کرنل اندروید امکانات محدودتری نیاز داره.
توی دیاگرام در بخش کرنل قسمت های دیگه ای هم هستن که فکر نمی کنم نیازی به توضیح داشته باشن:)
اما فکر می کنم Binder (IPC) Driver رو یه نگاهی باید بهش بکنیم.
یه خاصیت جالب دیگه کرنل لینوکس هم اینه که برای ارتباط بین دو تا process مکانیزمش تحمیل نمی کنه، یعنی لفظ کلمه driver همه چیز رو حل می کنه. یعنی داره میگه اگه مکانیزم پیش فرض لینوکس برای ارتباط خارج از process رو نمی پسندید کافیه یه درایور بنویسید.
در واقع سازندگان اندروید موقعی که می خواستن مکانیزم Binding رو برای Interprocess Communication پیاده سازی کنن تنها لازم بود یه درایور بنویسن. که همین کارو هم کردن به خاطر همین اسم مکانیزم فعلی اندروید برای اینکار Binder IPC Driver هست.
Binder واقعاً مکانیزم ساده ای هست که کارو برای برنامه نویسان اندروید راحت می کنه و یه جورایی داره سعی می کنه دردسرهایی که مکانیزم های ویندوز برای ارتباط خارج از process رو داشت رفع کنه. (البته چون ویندوز سیستم عامل گسترده تری اون دردسرها اجتناب ناپذیر هستن).
یه دیاگرام از مراحل عملکرد BInder رو که تو گوگل پیدا کردم براتون می ذارم:
توی دیاگرام در بخش کرنل قسمت های دیگه ای هم هستن که فکر نمی کنم نیازی به توضیح داشته باشن:)
اما فکر می کنم Binder (IPC) Driver رو یه نگاهی باید بهش بکنیم.
یه خاصیت جالب دیگه کرنل لینوکس هم اینه که برای ارتباط بین دو تا process مکانیزمش تحمیل نمی کنه، یعنی لفظ کلمه driver همه چیز رو حل می کنه. یعنی داره میگه اگه مکانیزم پیش فرض لینوکس برای ارتباط خارج از process رو نمی پسندید کافیه یه درایور بنویسید.
در واقع سازندگان اندروید موقعی که می خواستن مکانیزم Binding رو برای Interprocess Communication پیاده سازی کنن تنها لازم بود یه درایور بنویسن. که همین کارو هم کردن به خاطر همین اسم مکانیزم فعلی اندروید برای اینکار Binder IPC Driver هست.
Binder واقعاً مکانیزم ساده ای هست که کارو برای برنامه نویسان اندروید راحت می کنه و یه جورایی داره سعی می کنه دردسرهایی که مکانیزم های ویندوز برای ارتباط خارج از process رو داشت رفع کنه. (البته چون ویندوز سیستم عامل گسترده تری اون دردسرها اجتناب ناپذیر هستن).
یه دیاگرام از مراحل عملکرد BInder رو که تو گوگل پیدا کردم براتون می ذارم:
ین وسط تنها چیزی که می درخشه نقش Binder هست که توسط درایور در اختیار کرنل قرار گرفته.
واقعاً از اینجا یه درود به معمار کرنل لینوکس می فرستم:) (یه جور Dependency Injection رو توی اون سطح پیاده کرده.)
تنها کاری که Caller می کنه اینه که یه پروکسی بسازه و پیام ها رو دریافت کنه. اینکه سرویس کجاست و چجوری باید بهش وصل شه دیگه بر عهده Driver IPC Binder ی هست قبلاً نوشته شده.
انشالله در پست های بعد میریم سراغ Android runtime, Dalvik, Libraries ...
واقعاً از اینجا یه درود به معمار کرنل لینوکس می فرستم:) (یه جور Dependency Injection رو توی اون سطح پیاده کرده.)
تنها کاری که Caller می کنه اینه که یه پروکسی بسازه و پیام ها رو دریافت کنه. اینکه سرویس کجاست و چجوری باید بهش وصل شه دیگه بر عهده Driver IPC Binder ی هست قبلاً نوشته شده.
انشالله در پست های بعد میریم سراغ Android runtime, Dalvik, Libraries ...
http://afgdeveloper.com/fa/post/%D9%85%D8%B1%D9%88%D8%B1%DB%8C-%D8%A8%D8%B1-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D8%A7%D9%86%D8%AF%D8%B1%D9%88%DB%8C%D8%AF
لینک اصلی این آموزش در سایت شخصی ایشون .
اگر این آموزش براتون مفید بود حتما نظرتون رو در سایتشون بگین و یا اگر سوالی داشتین می تونین در سایت ازشون بپرسین . موفق باشین . 💖💖💖
#پایان_قسمت_اول_معماری_اندروید
#اعماق_اندروید
#سید_حسن_هاشمی
لینک اصلی این آموزش در سایت شخصی ایشون .
اگر این آموزش براتون مفید بود حتما نظرتون رو در سایتشون بگین و یا اگر سوالی داشتین می تونین در سایت ازشون بپرسین . موفق باشین . 💖💖💖
#پایان_قسمت_اول_معماری_اندروید
#اعماق_اندروید
#سید_حسن_هاشمی
سلام قسمت دوم بخش معماری اندروید رو الان میذاریم لطفا اول مطلب بالا رو بخونین👆👆👆
#اعماق_اندروید #معماری_اندروید_قسمت_دوم #سید_حسن_هاشمی
توی آموزش قبلی در مورد خاستگاه لینوکسی اندروید و همچنین kernel مورد استفاده در اندروید صحبت کردیم. این آموزش به صورت کلی قراره در مورد Dalvik و قسمت سبز دیاگرام باشه.
البته از قسمت سبز دیاگرام و بعد قسمت HAL یه مقداری مربوط به کرنل هست، اما ترجیح دادم اون رو توی این پست پوشش بدم پس اول میریم سراغ اون.
محض یادآوری بذارید یه بار دیگه دیاگرام رو بذارم:
توی آموزش قبلی در مورد خاستگاه لینوکسی اندروید و همچنین kernel مورد استفاده در اندروید صحبت کردیم. این آموزش به صورت کلی قراره در مورد Dalvik و قسمت سبز دیاگرام باشه.
البته از قسمت سبز دیاگرام و بعد قسمت HAL یه مقداری مربوط به کرنل هست، اما ترجیح دادم اون رو توی این پست پوشش بدم پس اول میریم سراغ اون.
محض یادآوری بذارید یه بار دیگه دیاگرام رو بذارم:
Hardware abstraction layer:
هدف از ایجاد این لایه در واقع این هست که این امکان رو به نرم افزار بده که سخت افزار روی دیوایس رو از طریق یه سری api عمومی استفاده کنه.
یعنی در واقع اون ذهنیتی که همیشه خودم ازش داشتم این بوده: لایه ای نرم افزاری که با سخت افزار ارتباط داره اما فقط از طریق درایورهای ارائه شده به کرنل.
در این لحظه ممکنه یه کم سردرگمی در مورد نحوه کار HAL و همچنین تداخلی احتمال با عملکرد کرنل براتون پیش بیاد، یه توضیح ساده از روال یه فراخوانی سخت افزاری روی میشه توی چند مرحله خلاصه کرد، توجه کنید که برای اینکه زیاد وارد جزئیات نشم تا خسته کننده نباشه براتون از یه مثال خیلی خیلی ساده شده و یکم هم فرضی استفاده می کنم:
1- کد جاوا که در لایه آبی رنگ و بالای دیاگرام قرار داره یه سرویس رو فراخوانی می کنه (مثلاً قدرت باطری فعلی که بهش وصله).
2- یه سری کلاس های بزگتری هستن که مجموعه از عملیات های مرتبط رو انجام میدن و رابط بین کد شما و HAL هستن، دوباره به صورت سنتی به این کلاس ها ServiceManager گفته میشه که البته از اسمش پیداست که دربردارنده تعدادی از متدها مرتبط هست.
به صورت سنتی توی گوگل نامگذاری این کلاس اینجوریه PowerManagerService.java.
3- سرویس های مرحله قبل با استفاده از مکانیزم JNA از یه کلاسی در PowermanagerService.cpp استفاده می کنند. خود PowerManagerService.cpp در قسمت Libraries دیاگرام قرار داره.
(یه مفهوم آشنایی هست بین تمامی زبان های مدیریت شده و امکان فراخوانی توابع native رو به جاوا میده و البته برای برنامه نویسای سی شارپ p-invoke نقطه مقابلش هست).
4 PowerManagerService.cpp حالا از کتابخانه HAL که مورد نظر ما هست Power.c رو مستقیماً میاره سر سفره :) و Power.c هم که درایور مورد نظر kernel رو تا حالا لود کرده، کد داخل درایور رو فراخوانی می کنه و اون هم که در نهایت یه pointer به یه مقدار عددی برمی گردونه که نشاندهنده مقدار باطری باقی مانده هست.
* موتور اجرایی جاوا حالا اون مقدار رو به صورت یه Managed Type به لایه هایی پایینی برمی گردونه.
هدف از ایجاد این لایه در واقع این هست که این امکان رو به نرم افزار بده که سخت افزار روی دیوایس رو از طریق یه سری api عمومی استفاده کنه.
یعنی در واقع اون ذهنیتی که همیشه خودم ازش داشتم این بوده: لایه ای نرم افزاری که با سخت افزار ارتباط داره اما فقط از طریق درایورهای ارائه شده به کرنل.
در این لحظه ممکنه یه کم سردرگمی در مورد نحوه کار HAL و همچنین تداخلی احتمال با عملکرد کرنل براتون پیش بیاد، یه توضیح ساده از روال یه فراخوانی سخت افزاری روی میشه توی چند مرحله خلاصه کرد، توجه کنید که برای اینکه زیاد وارد جزئیات نشم تا خسته کننده نباشه براتون از یه مثال خیلی خیلی ساده شده و یکم هم فرضی استفاده می کنم:
1- کد جاوا که در لایه آبی رنگ و بالای دیاگرام قرار داره یه سرویس رو فراخوانی می کنه (مثلاً قدرت باطری فعلی که بهش وصله).
2- یه سری کلاس های بزگتری هستن که مجموعه از عملیات های مرتبط رو انجام میدن و رابط بین کد شما و HAL هستن، دوباره به صورت سنتی به این کلاس ها ServiceManager گفته میشه که البته از اسمش پیداست که دربردارنده تعدادی از متدها مرتبط هست.
به صورت سنتی توی گوگل نامگذاری این کلاس اینجوریه PowerManagerService.java.
3- سرویس های مرحله قبل با استفاده از مکانیزم JNA از یه کلاسی در PowermanagerService.cpp استفاده می کنند. خود PowerManagerService.cpp در قسمت Libraries دیاگرام قرار داره.
(یه مفهوم آشنایی هست بین تمامی زبان های مدیریت شده و امکان فراخوانی توابع native رو به جاوا میده و البته برای برنامه نویسای سی شارپ p-invoke نقطه مقابلش هست).
4 PowerManagerService.cpp حالا از کتابخانه HAL که مورد نظر ما هست Power.c رو مستقیماً میاره سر سفره :) و Power.c هم که درایور مورد نظر kernel رو تا حالا لود کرده، کد داخل درایور رو فراخوانی می کنه و اون هم که در نهایت یه pointer به یه مقدار عددی برمی گردونه که نشاندهنده مقدار باطری باقی مانده هست.
* موتور اجرایی جاوا حالا اون مقدار رو به صورت یه Managed Type به لایه هایی پایینی برمی گردونه.
از همه اینها که بگذریم، حالا دیگه واقعاً نوبت Dalvik و Libraries هست.
Libraries در واقع خود اندروید هست! بخش های مختلف این قسمت وظایف حیاتی رو بر عهده دارن، مثلاً:
OpenGL: کتابخانه render گرافیکی مورد استفاده اندروید هست.
SurfaceManager: در واقع مسئول مدیریت خروجی گرافیکی پنجره های مختلف، در process مختلف هست. یعنی مثلا اگه شما 5 تا پنجره دارید یعنی هر کدوم یه thread دارن که داره گرافیک صفحه رو نقاشی می کنه. SurfaceManager سطوح مختلفی رو در اختیار این ها قرار میده تا روی اون کارشون رو انجام بدن و در پایان از Render نهایی نتیجه همه اونها اطمینان حاصل کنه.
یعنی نقاشی های هر thread میره توی یه buffer که خارج از صفحه هست و در اونجا توسط SurfaceManaer ترکیب میشن و تصویر نهایی رو تشکیل میدن.
@androiddevelop
و ... که مجال باز کردن هر کدوم توی این مطلب نیست.
(میدونم استفاده کردن از لفظ نقاشی اصلا جالب نیست اما جایگزین دیگه برای لغت Drawing توی ذهنم نبود :) ).
Libraries در واقع خود اندروید هست! بخش های مختلف این قسمت وظایف حیاتی رو بر عهده دارن، مثلاً:
OpenGL: کتابخانه render گرافیکی مورد استفاده اندروید هست.
SurfaceManager: در واقع مسئول مدیریت خروجی گرافیکی پنجره های مختلف، در process مختلف هست. یعنی مثلا اگه شما 5 تا پنجره دارید یعنی هر کدوم یه thread دارن که داره گرافیک صفحه رو نقاشی می کنه. SurfaceManager سطوح مختلفی رو در اختیار این ها قرار میده تا روی اون کارشون رو انجام بدن و در پایان از Render نهایی نتیجه همه اونها اطمینان حاصل کنه.
یعنی نقاشی های هر thread میره توی یه buffer که خارج از صفحه هست و در اونجا توسط SurfaceManaer ترکیب میشن و تصویر نهایی رو تشکیل میدن.
@androiddevelop
و ... که مجال باز کردن هر کدوم توی این مطلب نیست.
(میدونم استفاده کردن از لفظ نقاشی اصلا جالب نیست اما جایگزین دیگه برای لغت Drawing توی ذهنم نبود :) ).
Dalvik و Art:
Dalvik همون ماشین مجازی جاوا هست که توسط گوگل پیاده سازی شده، و اونجوری که خودشون اعلام کردن برای محیط های با حافظه پایین و محدودیت انرژی بهینه سازی شده.
که به ازای هر برنامه در حال اجرا یه نمونه از Dalvik لود میشه که چیز تعجب آوری نیست، چون همه runtime ها به منظور حفاظت و ایزوله سازی برنام ها از آسیب زدن به هم، مدیریت thread هایی که توسط خود dalvik ساخته میشن (نه thread ی که توسط بخش مدیریت حافظه و پردازش لینوکس ساخته میشه ) و... همین مکانیزم رو پیاده سازی می کنن.
Art هم که مخفف Android runtime هستش و جایگزین dalvik شد.
شاید بعد از چند ساعت برانداز کردن سورس Dalvik و ساختار ماژول هایی که تشکیلش می دادن متوجه میشدیم که واقعاً به زمان cpu های دو هسته ای و تک هسته ای تعلق داره :) یعنی GC و Multi Tasking ی که فراهم می کنه درخور پیشرفت های سخت افزاری حال حاضر نیست. در این نقطه چون هنوز بهتون نشون ندادم چجوری اندروید روی کامپیوتر خودتون build کنید، آزمون عملی ایرادهایی که عرض کردم قابل انجام نیست اما این یه مورد رو از من بپذیرین.
پس از اینجا به بعد تمرکز می کنیم روی ART.
هدف از معماری ART از ریشه، بهبود سرعت اجرای برنامه هاست. یعنی اگه دقت کنید
به نظرم نقطه بزرگ تغییر در art نسبت به Dalvik قابلیت Ahead of time compilation بود. (انقدر گسترده بوده که گوگل مجبور شده از Refactor کردن کد فعلی Dalvik صرف نظر کنه و با هزینه زیاد Art رو تولید کنه).
یعنی ART در زمان نصب برنامه، کد رو به کد ماشین compile می کنه.
این به این معنیه که شما باید انتظار زمان نصب طولانی برای برنامه های با حجم بالا رو داشته باشید اما حس اینکه دارید از سرعت native استفاده می کنید استفاده از دیوایس رو لذت بخش می کنه. :)
خیلی ساده س اما برای اینکه یه دید دقیق تری داشته باشید من یه شکلی رو که از ویکیپدیا میذارم:
Dalvik همون ماشین مجازی جاوا هست که توسط گوگل پیاده سازی شده، و اونجوری که خودشون اعلام کردن برای محیط های با حافظه پایین و محدودیت انرژی بهینه سازی شده.
که به ازای هر برنامه در حال اجرا یه نمونه از Dalvik لود میشه که چیز تعجب آوری نیست، چون همه runtime ها به منظور حفاظت و ایزوله سازی برنام ها از آسیب زدن به هم، مدیریت thread هایی که توسط خود dalvik ساخته میشن (نه thread ی که توسط بخش مدیریت حافظه و پردازش لینوکس ساخته میشه ) و... همین مکانیزم رو پیاده سازی می کنن.
Art هم که مخفف Android runtime هستش و جایگزین dalvik شد.
شاید بعد از چند ساعت برانداز کردن سورس Dalvik و ساختار ماژول هایی که تشکیلش می دادن متوجه میشدیم که واقعاً به زمان cpu های دو هسته ای و تک هسته ای تعلق داره :) یعنی GC و Multi Tasking ی که فراهم می کنه درخور پیشرفت های سخت افزاری حال حاضر نیست. در این نقطه چون هنوز بهتون نشون ندادم چجوری اندروید روی کامپیوتر خودتون build کنید، آزمون عملی ایرادهایی که عرض کردم قابل انجام نیست اما این یه مورد رو از من بپذیرین.
پس از اینجا به بعد تمرکز می کنیم روی ART.
هدف از معماری ART از ریشه، بهبود سرعت اجرای برنامه هاست. یعنی اگه دقت کنید
به نظرم نقطه بزرگ تغییر در art نسبت به Dalvik قابلیت Ahead of time compilation بود. (انقدر گسترده بوده که گوگل مجبور شده از Refactor کردن کد فعلی Dalvik صرف نظر کنه و با هزینه زیاد Art رو تولید کنه).
یعنی ART در زمان نصب برنامه، کد رو به کد ماشین compile می کنه.
این به این معنیه که شما باید انتظار زمان نصب طولانی برای برنامه های با حجم بالا رو داشته باشید اما حس اینکه دارید از سرعت native استفاده می کنید استفاده از دیوایس رو لذت بخش می کنه. :)
خیلی ساده س اما برای اینکه یه دید دقیق تری داشته باشید من یه شکلی رو که از ویکیپدیا میذارم:
همونجور که ملاحظه می کنید در ابتدا یه ابزاری بنام dex2oat فایل apk رو می گیره فایل دیگه به نام elf رو خروجی میده (وارد جزئیات این فایل نمیشیم چون مطلب زیاد داره). و بعد هم ادامه کار با موتور اصلی ART...
@androiddevelop
www.afgdeveloper.com
بعد از همه اینا میخوام یه نکته پایانی رو هم اضافه کنم و اون هم اینه که هر دو ماشین مجازی dvm و art از کتابخانه استاندارد C که به صورت اختصاصی برای اندروید طراحی شده به عنوان رابط با kernel استفاده می کنن. از جمله اینا همین مربع کوچک LibC تو لایه سبز رنگ کتابخانه ها رو مشاهده می کنید.
کتابخانه استاندارد C که در اندروید بهش Bionic گفته میشه دارای توابع mAlloc و ... هست که هر دو ماشین مجازی استفاده میکنن.
و تا جایی که من میدونم تنها تفاوتش با C Standard library اصلی، بهینه سازی های انجام شده برای کار با cpu های با سرعت پایین تر هستش.
@androiddevelop
www.afgdeveloper.com
بعد از همه اینا میخوام یه نکته پایانی رو هم اضافه کنم و اون هم اینه که هر دو ماشین مجازی dvm و art از کتابخانه استاندارد C که به صورت اختصاصی برای اندروید طراحی شده به عنوان رابط با kernel استفاده می کنن. از جمله اینا همین مربع کوچک LibC تو لایه سبز رنگ کتابخانه ها رو مشاهده می کنید.
کتابخانه استاندارد C که در اندروید بهش Bionic گفته میشه دارای توابع mAlloc و ... هست که هر دو ماشین مجازی استفاده میکنن.
و تا جایی که من میدونم تنها تفاوتش با C Standard library اصلی، بهینه سازی های انجام شده برای کار با cpu های با سرعت پایین تر هستش.
دوستان می تونین نظرات خودتون رو در مورد این مقاله در گروه اندرویدی ما
https://telegram.me/joinchat/B1f7ETv_ZoJDk2dr0ES0rQ
و همچنین رو در سایت شخصی آقای هاشمی با خودشون در میون بذارین :
http://afgdeveloper.com/fa/post/%D9%85%D8%B1%D9%88%D8%B1%DB%8C-%D8%A8%D8%B1-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D8%A7%D9%86%D8%AF%D8%B1%D9%88%DB%8C%D8%AF-%D9%82%D8%B3%D9%85%D8%AA-%D8%AF%D9%88%D9%85
https://telegram.me/joinchat/B1f7ETv_ZoJDk2dr0ES0rQ
و همچنین رو در سایت شخصی آقای هاشمی با خودشون در میون بذارین :
http://afgdeveloper.com/fa/post/%D9%85%D8%B1%D9%88%D8%B1%DB%8C-%D8%A8%D8%B1-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D8%A7%D9%86%D8%AF%D8%B1%D9%88%DB%8C%D8%AF-%D9%82%D8%B3%D9%85%D8%AA-%D8%AF%D9%88%D9%85
#روت #اندروید
سلام امروز آموزش تخصصی روت کردن انواع گوشی ها رو به صورت اختصاصی در کانال قرار می دیم .اگر از دوستانتون کسی هست که می خواد گوشیشو روت کنه حتما به کانال دعوتش کنین ممنون.
@androiddevelop
سلام امروز آموزش تخصصی روت کردن انواع گوشی ها رو به صورت اختصاصی در کانال قرار می دیم .اگر از دوستانتون کسی هست که می خواد گوشیشو روت کنه حتما به کانال دعوتش کنین ممنون.
@androiddevelop
#آموزش_روت_انواع_گوشی #اندروید #root #هادی_خدابنده_لو
همونطور که بهتون قول دادیم در این مقاله قصد داریم آموزش مختصری را برای روت گوشی های اندروید در اختیار شما دوستان قرار بدیم که با روت کردن گوشیتان در این مقاله لذت ببرید.
اما ابتدا سوالهای درذهن شما وجود دارد که ازاین قبیل است.
روت چیست؟ آیا روت مضر است؟ چرا باید روت کرد و چرا نباید روت کرد؟ گو شی روت شده بهتر است یا گوشی روت نشده؟ آیا روت کردن امنیت گوشی ما را پایین خواهد آورد؟
خوب اینها سوالاتی هست که جواب آنها رو به همراه آموزش تصویری روت کردن برای شما در پی دی اف زیر قرار دادیم .
*این آموزش توسط آقای هادی خدابنده لو و به طور اختصاصی توسط کانال @androiddevelop منتشر میشود.
👇👇👇👇👇
همونطور که بهتون قول دادیم در این مقاله قصد داریم آموزش مختصری را برای روت گوشی های اندروید در اختیار شما دوستان قرار بدیم که با روت کردن گوشیتان در این مقاله لذت ببرید.
اما ابتدا سوالهای درذهن شما وجود دارد که ازاین قبیل است.
روت چیست؟ آیا روت مضر است؟ چرا باید روت کرد و چرا نباید روت کرد؟ گو شی روت شده بهتر است یا گوشی روت نشده؟ آیا روت کردن امنیت گوشی ما را پایین خواهد آورد؟
خوب اینها سوالاتی هست که جواب آنها رو به همراه آموزش تصویری روت کردن برای شما در پی دی اف زیر قرار دادیم .
*این آموزش توسط آقای هادی خدابنده لو و به طور اختصاصی توسط کانال @androiddevelop منتشر میشود.
👇👇👇👇👇