Droid Hub✨

:)

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

... حالا گوگل باید برای مشکلات ایجاد شده در ART راه حلی پیدا میکرد. اون ها متوجه شده بودن که غالب اپ هایی که روی یک دستگاه هست توسط کاربر اصلا استفاده نمیشه و صرفا تعداد کمی از اپ ها هستن که کاربر ها به صورت مداوم بهشون سر میزنه. این تئوری راهنمایی شد تا گوگل تصمیم بگیره تا همه ی بایت کد های همه ی اپ هارو روی دیسک نگه نداره. بازگشت JIT: از اندروید نسخه N، تکنیک JIT دوباره و با عنوان profile-guided compilation به ART برگشت. در تکنیک profile-guided compilation که ترکیبی از تکنیک های JIT و AOT هست بایت کد ها در زمان نصب ترجمه میشه و در هنگام اجرای اپ، قسمت های پر تکرار یک اپ مشخص میشه و صرفا بایت کد های همون قسمت روی دیسک cache میشه. در این روش، در چند بار اول اجرای یک اپ، سرعت برنامه پایین تره، اما هر چه یک اپ بیشتر ران میشه سرعتش هم بیشتر میشه. به این ترتیب گوگل به مشکل فضای دیسک بالا و طولانی شدن زمان نصب غلبه کرد اما همچنان سرعت کند اجرا در اولین دفعات اجرای یک برنامه به صورت یک مشکل باقی موند. راه حل نهایی با ART Cloud Profiles در اندروید P: طبق بررسی گوگل بیش تر اپ ها طبق یک پترن مشخص توسط کاربر ها اجرا میشه. گوگل این دیتاهارو جمع آوری و در گوگل پلی تحت عنوان Code Profile قرار داد. code profile شامل دیتایی هست که نشان می دهد کدام قسمت های یک اپ، تعداد دفعات بیشتری توسط کاربران استفاده میشود. هنگامی که یک اپ از گوگل پلی را دانلود میکنید، دیتای code profile نیز به همراه آن دانلود میشود. این دیتا، ART را راهنمایی میکند تا هنگام نصب اپ کدام بایت کد هارا ترجمه کند و از ترجمه ی تمام بایت کد ها جلوگیری میکند.

این جاست که Dalvik و ART وارد بازی میشن و این وظیفه رو به عهده میگیرن. (وظیفه ی تبدیل بایت کد به دستورات ماشین روی دستگاه های غیر اندرویدی توسط JVM انجام میشه، اما jvm اونقدر سنگین بود و مموری زیادی مصرف میکرد که عملا گوگل نمیتونست توی دستگاه های اندرویدی ازش استفاده کنه) تا قبل از اندروید L در اندروید از Dalvik استفاده میشد که بر مبنای تکنیک JIT یا (Just In Time) کار می کرد، یعنی هنگامی که اپلیکیشنی توسط کاربر ران میشد، Dalvik شروع میکرد به ترجمه ی کد های برنامه به زبان ماشین. بر مبنای تکنیک JIT، دالویک تنها کد هایی رو ترجمه میکرد که در حال حاضر در برنامه در حال استفاده هستند، یعنی همه ی بایت کد های برنامه رو یکجا ترجمه نمیکرد.(به طور مثال اگر در اکتیوتی Login هستید بایت کد های همون صفحه رو تبدیل میکرد و کاری به اکتیویتی Setting نداشت) دالویک چند تا مشکل داشت که گوگل باید فیکسش می کرد : یکی اینکه پرفورمنس دالویک خوب نبود و دیگه اینکه مصرف باطری زیادی هم داشت (منطقی هم هست چون به صورت رانتایم دائما درگیر ترجمه بود) بنابراین گوگل از اندروید L، ابزار ART یا Android Runtime رو معرفی کرد، ART دیگه بر مبنای JIT کار نمی کرد بلکه بر اساس تکنیک AOT و یا Ahead of Time عمل میکرد. تو این روش ترجمه ی بایت کد ها قبل از اجرای اپ اتفاق می افته یعنی دقیقا در مرحله ی نصب اپ وقتی یک اپ رو نصب میکنید، ART بایت کد هارو ترجمه میکنه و اون هارو در فضایی از disk ذخیره میکنه. به این صورت هنگام اجرای یک اپ تنها کد های ماشین از فضای دیسک بازخوانی میشه. به این ترتیب گوگل تونست به مشکل پایین بودن پرفورمنس در Dalvik غلبه کنه اما در ART چند تا مشکل دیگه به وجود اومد: اول اینکه زمان نصب اپلیکیشن ها طولانی تر شد دوم اینکه فضای بیش تری از دیسک اشغال میشد سوم هم اینکه زمان بوت شدن دستگاه طولانی تر شد باقیش رو انشالا فردا براتون مینویسم...

امروز در مصاحبه از یکی از دوستانم درباره تفاوت Dalvik و ART پرسیده بودن و ایشون هم بلد نبوده که به سوال پاسخ بده. چیز خیلی ساده ای هست، بنابراین من اینجا براتون تفاوت هاش رو توضیح میدم: همونطور که مطلع هستید کد های جاوا و کاتلین ما در گرفتن خروجی apk، تبدیل به بایت کد های.dex میشه. (این جا داخل پرانتز بگم که هر فایل .dex میتونه فقط و فقط شامل 65536 متد بشه و اگر تعداد متد رفرنس ها از این عدد بیش تر بشه به طور خودکار فایل های dex بیش تری تولید میشه) اما نکته این جاست که بایت کد های dex در دستگاه اندرویدی به صورت مستقیم قابل استفاده نیست و باید به زبان ماشین ترجمه بشه.

یکی از راه حل هایی که برای این مشکل ارائه شده است استفاده از تکنیک TEE یا (Trusted Execution Environment) است. در این روش، سازنده، یک secure area روی main process ایجاد میکند. این فضا یک ناحیه ی isolated روی پردازنده است که مجزا از kernel اصلی عمل میکند و os مجزای خودش را دارد (trusty) کرنل اصلی ممکن است شامل weak links هایی باشد که توسط attacker ها قابل بهره برداری است اما در trusty یک محیط امن و secure ایجاد شده است تا توسط برنامه های untrusted قابل استفاده نباشد. در TEE پیاده سازی های متفاوتی وجود دارد به طور مثال در keystore system اندروید که برای مدیریت کلید ها استفاده میشود، یک برنامه (Trusted App - TA) ریکوستی را برای ایجاد کلید در ناحیه TEE ارسال می کند. در این مکانیسم برنامه ی Trusted برای عملیات های encryption و decryption دیگر به اصل کلید رجوع نمی کند بلکه درخواست های خودش را برای واسط TEE ارسال میکند و تمام عملیات ها در همین ناحیه امن انجام شده و خروجی به برنامه ی ما ارسال میشود. در این مکانیسم برنامه ی ما برای استفاده از TEE حتما باید تایید هویت شده باشند بنابراین سایر برنامه ها نمیتوانند دسترسی ای را به کلید ساخته شده در ناحیه TEE داشته باشند. اندروید اینگونه تضمین میکند که دسترسی سایرین به کلید های برنامه ی ما غیر ممکن باقی بماند و امنیت کلید حفظ شود. در تصویر بالا، REE محیطی است که برنامه ها به صورت معمول با کرنل اصلی اندروید در ارتباط هستند.

فرض کنید که قصد داریم دیتایی (مثل یک رشته) در اندروید را secure کنیم تا از دست attacker ها در امان بماند. برای حفاظت از این داده احتمالا به سراغ تکنیک های رمزنگاری میرویم. فرض کنید که احتیاج داریم تا هر گاه که این رشته احتیاج بود مقدار آن را بازگردانی کرده و از آن استفاده کنیم بنابراین باید آن را با یک کلید رمز (encrypt) کرده تا در صورت نیاز آن را رمزگشایی (decrypt) کنیم. اما در این مثال، همچنان اصل مشکل پابرجسات. اکنون مسئله ی ما این است که چگونه از کلید نگهداری کنیم تا از دست attacker ها در امان بماند، زیرا هر کسی با یافتن کلید میتواند تمام پیام ها را رمزگشایی کند. در سیستم عامل اندروید تمامی اطلاعات حساس آسیب پذیر هستند زیرا در صورت اجرای برنامه‌ها در محیطی ناامن (مثلا دستگاه روت شده)، جداسازی و استخراج اطلاعات مورد نیاز نسبتاً آسان است و برای دستیابی به اهدافشان، هکرها به تلاش زیادی نیاز ندارند.

اندروید استادیو رو به نسخه Jellyfish آپدیت کردم. همونطور که میدونید مهم ترین تغییر این نسخه اضافه شدن Gemini به اندروید استادیو بوده من تا الان یه خورده بررسیش کردم و باید بگم که واقعا خوبه و کد هارو به خوبی متوجه میشه و میتونه اونارو بهبود بده. یه ویژگی خیلی مهمش هم به نظرم اینه که context هر پروژه رو میفهمه و مطابق اون شمارو راهنمایی میکنه. البته برای این کار احتمالا به سورس پروژه دسترسی داره و در پروژه های مهم باید دسترسیش از پروژه رو حذف کنید. احتمالا چند وقت دیگه که حسابی کد های اندرویدی مختلف رو بررسی کنه، نسخه به نسخه بهتر میشه و کم کم دیگه جای خودمون کد بزنه 😁

🚀 Room بالاخره مالتی پلتفورم شد 🚀 https://developer.android.com/kotlin/multiplatform/room

عده ای عقیده دارن که اخبار این مدلی میتونه روی مارکت فعلی فلاتر تاثیر بذاره https://twitter.com/CreeCoder/status/1785332919663280178

خبر بد امروز https://techcrunch.com/2024/04/29/google-lays-off-staff-from-flutter-dart-python-weeks-before-its-developer-conference/

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

Adding @Stable annotation on every unstable composable function

یکی از api هایی که تیم توسعه ی برنچ androidx گوگل هر روز در حال توسعشه ای پی ای pdfViewer هست که احتمالا به زودی پابلیش میشه. عمده ی pdf viewer هایی که تا الان وجود داشت با تبدیل صفحات فایل pdf به bitmap و render کردن مستقیم اون کار میکردن (در واقع با pdf مثل image برخورد میکردن) که خود همین عامل باعث میشد که کاربر توانایی کاستومایز کردن فایل های pdf رو به طور کلی از دست بده. مثلا شما لینک های موجود در pdf رو نمیتونستید باز کنید یا اینکه متن اون رو نمیتونستید select ، copy و یا search کنید اما در pdfViewer Api ای که گوگل توسعه میده پیش بینی میشه خیلی از این مشکلات حل بشه و کاربر امکان مشاهده ، کاستومایز و ادیت Pdf رو داشته باشه.

بیلد سیستم Bazel بدترین چیزیه که میشه باهاش کار کرد خدا به زندگی سازندگان Gradle خیر و برکت روز افزون عطا کند.🤲 من به واسطه‌ی یکی از پروژه های اپن سورس گوگل مدتی رو درگیرش شدم اما واقعا یه بیلد درست و حسابی نمیشد باهاش گرفت. بازل یک بیلد سیستم اپن سورسه که توسط خود گوگل طراحی و توسعه داده میشه. بازل از طریق خواندن فایل های BUILD گراف اکشن ها (تسک ها) رو جنریت می‌کنه سپس از طریق ابزار هایی مثل clang و javac‌ تسک هارو اجرا می‌کنه. طبق ادعای گوگل بازل به دلیل کامپایل کردن فایل های BUILD از گریدل که فایل های build.gradle رو تفسیر می‌کنه سریعتر عمل میکنه اما تجربه من دربارش عملا خیلی خوب نبود. + گوگل یه برنامه هم داشت که تمام قسمت های Android Platform رو به سمت Bazel مهاجرت بده تا قسمت های مختلف سیستم عامل با این ابزار بیلد بشن که اخیرا به دلایلی که اعلام نکرده تصمیم گرفتن این پروژه رو متوقف کنن (خداروشکر)

سلام عزیزان ضمن عرض خوش آمد گویی 💫 اول یه توضیحی بدم در رابطه با تصویر کانال تصویر، مربوط به roman elizarov روسی هست که مدتی رو به عنوان Project Lead کاتلین در jetBrains فعالیت می کرد که البته اخیرا اعلام کرد به دلایل شخصی از این شرکت جدا شده و اونطور که من متوجه شدم فعالیت های دانشگاهیش رو از سر گرفته. احتمالا roman elizarov رو از ارائه های مختلفش در Kotlin conf شناخته باشید عمده ی contribute های roman روی kotlin coroutines بوده و بسیاری از زیبایی های کروتین به خاطره وجود این شخصه. همچنین نقش roman در طراحی و توسعه ی کامپایلر کاتلین هم نقش به سزایی بوده. پس هممون به نوعی مدیون تلاش ها و فعالیت های این شخص هستیم. ❣️ پیشنهاد میکنم اگر زمان دارید تمام ویدیو ها و مقاله هایی که roman منتشر کرده رو یکبار بررسی کنید. https://elizarov.medium.com/ https://github.com/elizarov https://x.com/relizarov https://www.youtube.com/results?search_query=roman+elizarov .