ازسرگیری چندگانه

در Android 9 (و نسخه‌های پایین‌تر)، برنامه‌ها در شرایط زیر وارد حالت PAUSED می‌شدند:

• فعالیت جدید و نیمه‌شفافی روی برنامه راه‌اندازی شد، درحالی‌که برنامه همچنان قابل‌مشاهده بود (و بنابراین متوقف نشد).
• فعالیت تمرکز را ازدست داد، اما پوشیده نشد و کاربر می‌توانست با آن تعامل داشته باشد. برای مثال، در حالت چندپنجره‌ای، تعدادی فعالیت می‌توانند به‌طور هم‌زمان قابل‌مشاهده باشند و ورودی لمسی دریافت کنند.

این موقعیت‌ها در میزان توقف موقت که برنامه باید انجام دهد متفاوت است اما در سطح برنامه قابل تشخیص نیست.

در Android 10، همه فعالیت‌های قابل‌تمرکز برتر در پشته‌های نمایان در حالت RESUMED قرار دارند. این کار سازگاری با حالت‌های چندپنجره‌ای و MD را برای برنامه‌هایی که از onPause() به‌جای onStop() برای توقف بازآوری میانای کاربر و تعامل با کاربر استفاده می‌کنند بهبود می‌بخشد. این یعنی:

• هر دو فعالیت در صفحه تقسیم‌شده ازسر گرفته می‌شود.
• همه فعالیت‌های قابل‌مشاهده در حالت پنجره قالب آزاد ازسر گرفته می‌شوند.
• فعالیت‌های چند صفحه‌نمایش را می‌توان به‌طور هم‌زمان ازسر گرفت.

شکل ۱. ازسرگیری چندگانه در دستگاه تاشو

شکل ۲. ازسرگیری چندگانه در حالت رایانه

فعالیت‌ها می‌توانند در وضعیت PAUSED قرار بگیرند وقتی‌که نمی‌توان روی آن‌ها تمرکز کرد یا تاحدی مسدود شده‌اند، مثلاً:

• در صفحه دونیمه کوچک‌شده (با راه‌انداز در کنار)، فعالیت بالایی ازسر گرفته نمی‌شود زیرا قابل‌تمرکز نیست.
• در حالت «تصویردرتصویر»، فعالیت ازسر گرفته نمی‌شود زیرا قابل‌تمرکز نیست.
• وقتی فعالیت‌ها با فعالیت‌های شفاف دیگر در همان پشته پوشانده شده باشند.

این رویکرد به برنامه‌ها نشان می‌دهد که یک فعالیت فقط در حالت RESUMED می‌تواند ورودی از کاربر دریافت کند. قبل‌از Android 10، فعالیت‌ها می‌توانستند در حالت PAUSED نیز ورودی دریافت کنند (برای مثال، سعی کنید هر دو فعالیت را به‌طور هم‌زمان در حالت صفحه تقسیم در دستگاهی که Android 9 دارد لمس کنید).

برای حفظ سیگنال ازسرگرفته‌شده از نسخه‌های قبلی Android (و برای برقراری ارتباط زمانی که برنامه‌ها باید به منابع دسترسی انحصاری یا تک‌نمونه دسترسی پیدا کنند)، Android 10 شامل یک فراخوانی جدید است:

Activity#onTopResumedActivityChanged(boolean onTop)

وقتی فراخوانی می‌شود، این فراخوانی برگشتی بین Activity#onResume() و Activity#onPause() فراخوانی می‌شود. این برگشتی اختیاری است و می‌توان از آن رد شد، بنابراین فعالیت می‌تواند از وضعیت RESUMED به وضعیت PAUSED برود بدون اینکه در سیستم در بالاترین سطح قرار بگیرد. برای مثال، در حالت چندپنجره‌ای. ازآنجایی‌که این برگشت‌پذیر اختیاری است، بخشی‌از چرخه حیات فعالیت نیست و باید به‌ندرت استفاده شود.

فعالیت ازسرگرفته‌شده برتر قبلی، اجرای onTopResumedActivity(false) را قبل‌از اینکه فعالیت ازسرگرفته‌شده برتر بعدی onTopResumedActivity(true) را دریافت کند، دریافت و تکمیل می‌کند، مگراینکه فعالیت قبلی زمان زیادی برای رسیدگی به فراخوانی روش صرف کند و به مهلت ۵۰۰ میلی‌ثانیه‌ای برسد.

سازگاری

برای حفظ سازگاری هنگام پیاده‌سازی چندسرگیری، این راه‌حل‌ها را درنظر بگیرید.

چندین فعالیت ازسرگرفته‌شده در یک پردازش برنامه

• مشکل. در Android 9 و پایین‌تر، فقط یک فعالیت در سیستم در هر زمان ازسر گرفته می‌شود. همه گذارها بین فعالیت‌ها شامل توقف موقت یک فعالیت قبل‌از ازسرگیری فعالیت دیگر است. برخی‌از برنامه‌ها و چارچوب‌ها (مثل Flutter یا Android's LocalActivityManager) از این واقعیت استفاده می‌کنند و وضعیت فعالیت ازسرگرفته‌شده را در تک‌نمونه‌ها ذخیره می‌کنند.
• راه‌حل. در Android 9 و نسخه‌های پایین‌تر، اگر دو فعالیت از یک فرایند هر دو ازسر گرفته شوند، سیستم فقط فعالیتی را ازسر می‌گیرد که در ترتیب Z بالاتر است. برنامه‌هایی که Android 10 را هدف‌یابی می‌کنند می‌توانند از چندین فعالیت که به‌طور هم‌زمان ازسر گرفته می‌شوند پشتیبانی کنند.

دسترسی هم‌زمان به دوربین

• مشکلات. این مشکلات در Android 9 و نسخه‌های پایین‌تر نیز وجود دارد. برای مثال، فعالیت تمام‌صفحه و ازسرگرفته‌شده می‌تواند تمرکز دوربین را به فعالیت متوقف‌شده در بالا در حالت «تصویردرتصویر» ازدست بدهد، اما با پذیرش گسترده‌تر حالت‌های چندپنجره‌ای و چندنمایشگری، بیشتر درمعرض دید قرار می‌گیرد.
  • به‌دلیل تغییراتی که در وضعیت RESUME ایجاد شده است، ممکن است برنامه‌ها از دوربین حتی درحین ازسرگیری قطع شوند. برای رفع این مشکل، برنامه‌ها باید قطع اتصال دوربین را بدون ازکار افتادن مدیریت کنند. وقتی اتصال قطع می‌شود، برنامه‌ها یک فراخوانی برگشتی قطع اتصال دریافت می‌کنند و همه تماس‌ها با API شروع به برگرداندن CameraAccessException می‌کنند.
  • resizeableActivity=false تضمینی برای دسترسی انحصاری به دوربین نیست، زیرا برنامه‌های دیگری که از دوربین استفاده می‌کنند می‌توانند در نمایشگرهای دیگر باز شوند.
• راه‌حل‌ها. توسعه‌دهندگان باید منطقی را برای زمانی که اتصال برنامه از دوربین قطع می‌شود درنظر بگیرند. اگر اتصال برنامه‌ای از دوربین قطع شود، باید بازخوان‌های دردسترس بودن دوربین را مشاهده کند تا بتواند دوباره متصل شود و به استفاده از دوربین ادامه دهد. علاوه‌بر CameraManager#AvailabilityCallback#onCameraAvailable() پاسخ‌گویی موجود، در Android 10 CameraManager#AvailabilityCallback#onCameraAccessPrioritiesChanged() اضافه شده است، که حالتی را پوشش می‌دهد که در آن تمرکز (و اولویت دوربین) بین چندین فعالیت ازسرگرفته‌شده جابه‌جا می‌شود. توسعه‌دهندگان برنامه باید از هر دو این فراخوان‌های برگشتی استفاده کنند تا زمان مناسبی را برای تلاش جهت دسترسی به دوربین تعیین کنند.

ازسرگیری چندگانه

در Android 10، وضعیت چرخه حیات فعالیت براساس رؤیت‌پذیری و ترتیب Z تعیین می‌شود. برای اطمینان از اینکه وضعیت صحیح پس‌از به‌روزرسانی‌های نمایان بودن در یک فعالیت تنظیم شده است و برای ارزیابی اینکه کدام وضعیت چرخه حیات قابل‌اعمال است، روش ActivityRecord#makeActiveIfNeeded() را از مکان‌های مختلف فراخوانی کنید. در Android 10، فعال به این معنی است که یا RESUMED یا PAUSED و فقط در این دو مورد کار می‌کند.

در Android 10، ازسر گرفتن فعالیت در هر پشته به‌طور جداگانه پیگیری می‌شود به‌جای اینکه در مکان واحدی در سیستم پیگیری شود. دلیلش این است که در حالت‌های چندپنجره‌ای، چندین انتقال فعالیت می‌تواند به‌طور هم‌زمان انجام شود. برای جزئیات، ActivityStack#mInResumeTopActivity را ببینید.

بازخوانی فعالیت ازسرگرفته‌شده برتر

پس‌از کنش‌هایی که می‌توانند منجر به تغییر فعالیت برتر شوند (مثل راه‌اندازی فعالیت، ازسرگیری، یا تغییر ترتیب Z)، ActivityStackSupervisor#updateTopResumedActivityIfNeeded() فراخوانی می‌شود. این روش بررسی می‌کند که آیا فعالیت ازسرگرفته‌شده بالایی تغییر کرده است یا نه و درصورت نیاز به‌روزرسانی را انجام می‌دهد. اگر فعالیت قبلی که از سر گرفته شده است وضعیت ازسر گرفته شدن را آزاد نکرده باشد، پیام ازدست رفتن وضعیت ازسر گرفته شدن به آن ارسال می‌شود و در سمت سرور مهلت زمانی برنامه‌ریزی می‌شود (ActivityStackSupervisor#scheduleTopResumedStateLossTimeout()). گزارشی از وضعیت ازسر گرفته شدن پس‌از اینکه فعالیت قبلی وضعیت را آزاد کرد یا مهلت زمانی به‌پایان رسید به فعالیت بعدی ارسال می‌شود (موارد استفاده را ببینید:

ActivityStackSupervisor#scheduleTopResumedActivityStateIfNeeded()

مورد تراکنش TopResumedActivityChangeItem جدیدی اضافه شد تا تغییرات وضعیت ازسرگیری برتر را به کارخواه‌ها گزارش دهد و از معماری ActivityLifecycler از Android 9 بهره می‌برد.

وضعیت ازسرگیری‌شده برتر در سمت کارخواه ذخیره می‌شود و هر بار که فعالیت به RESUMED یا PAUSED منتقل می‌شود، بررسی می‌کند که آیا باید با onTopResumedActivityChanged() تماس برگشتی برقرار شود یا نه. این کار باعث جداسازی خاصی در ارتباط حالت‌های چرخه حیات و حالت ازسرگرفته‌شده برتر بین طرف‌های سرور و کارخواه می‌شود.