نظرة عامة على كيفية قتل الأنشطة من قبل النظام

Question

هل يمكن لأي شخص تقديم نظرة عامة قصيرة على الحالات متى وكيف يتم قتل النشاط في وقت التشغيل؟ أود أن أعرف الفرق بين الحالة المتوقفة والتوقف. ما الذي يمكن أن يجبر النظام على تدمير النشاط المتوقف مؤقتًا ، وهو نفس السبب (ذاكرة منخفضة) تمامًا كما لو تم إيقافه؟

أعتقد أنه إذا تم إيقاف النشاط بسبب مكالمة هاتفية واردة (مما يسبب فجأة حالة ذاكرة منخفضة) ، فإن النظام يفضل ببساطة إطلاق عمليات أنشطة متوقفة. لكن كيف يتم ذلك؟ متى "يسأل النظام" النشاط عن طريق استدعاء Finish () ومتى لا ، ومتى لا يزال يتم الاتصال بـ OnDestroy ()؟

Answer 1

تم وصف معظم ما طلبته جيدًا من خلال الوثائق ، لكنني أعتقد أنه يمكنني توضيح بعض الأشياء.

أود أن أعرف الفرق بين الحالة المتوقفة والتوقف.

الرؤية. الدولتتان متميزتان لأن النشاط الموقف قد يحجبه جزئيًا فقط من خلال نشاط آخر مثل النشاط الذي كان لديه Dialog موضوع تطبيق. يتطلب ذلك الحفاظ على أي موارد مطلوبة للحفاظ على الحالة البصرية. يمكن للأنشطة المتوقفة التخلص من تلك الموارد التي يمكن أن تحدث الفرق بين النشاط الذي يتم تدميره أو الحفاظ عليه إذا كانت الموارد ضيقة.

أعتقد ... النظام يفضل ببساطة إطلاق الأنشطة المتوقفة. لكن كيف يتم ذلك؟

من المفترض ان. الأنشطة المتوقفة غير مرئية تمامًا ، مما يجعلهم مرشحين أفضل للقتل أكثر من تلك التي لا تزال تساهم في شيء ما يراه المستخدم. لم أر أبداً Android نانكًا مؤقتًا مؤقتًا ولكنه مرئيًا من دون استئناف ، لكنني أفترض أنه يمكن أن يحدث في ظل الظروف المناسبة. يعرف النظام حالة كل نشاط لأنه ما يوجههم هناك.

متى "يسأل النظام" النشاط عن طريق استدعاء Finish () ومتى لا ، ومتى لا يزال يتم الاتصال بـ OnDestroy ()؟

سيؤدي النظام إلى تدمير منظم عندما يكون ذلك ممكنًا ، لكن واجهة برمجة التطبيقات فقط تضمن أن النشاط سيشاهد أي شيء على الإطلاق onPause() و onSaveInstanceState().

ETA: الأسباب الدقيقة التي تجعل الأنشطة من المكدس موجودة في المصدر. يجب ألا تعتمد على هذه الأسباب كونها الحقيقة العالمية ، لأنه قد يكون هناك نسخة مستقبلية من Android تجعل قراراتها مختلفة.

Answer 2

قدم المساواة للدورة ، أرى! أرى بعض المعلومات القيمة ، مختلطة مع معلومات مضللة باهظة الثمن. لا ، لا تحدد المستندات عبر الإنترنت كل ما في ظل الظروف التي تُقتل فيها العملية. هذا متعمد ، لأنه يخضع للتغيير دون إشعار. من المؤكد أن السبب الأكثر شيوعًا لاستدعاء OnDestroy () هو أن النظام ينفد من الذاكرة ، وهو أقل شيوعًا في الهواتف الأحدث (نظرًا لأن لديهم الكثير من الذاكرة). ولكن ليس هناك ما يضمن أن يكون هذا هو السبب الوحيد الذي يطلق عليه.

لكن نعم ، "العقد" بين Android والمطورين هو أنه إذا اتبعت القواعد ، فعليك تنفيذ عمليات عمليات الاسترداد لدورة الحياة المطلوبة عند الحاجة إليها ، فستنجح ، ولن تحتاج إلى معرفة بالضبط في ظل الظروف الوطنية () ، يسمى onsaveinstancestate () و ondestroy ().

الآن على عكس Google ، سأعترف بأن صياغة العقد غامضة إلى حد ما عند نقاط. هذا لأنه ، من بين أسباب أخرى أقل ، يستخدمون المصطلحات التي لها معنى للصناعة القياسية ، مثل "المقدمة" ، لكنهم يستخدمونها في الحواس التي تم تغييرها قليلاً. ويتم إما أن يتم شرح التغيير أو شرحه فقط في الأماكن الغامضة. كما أنه لا يساعد على أن يزعم الرسم البياني "المسارات التي قد يتخذها النشاط بين الدول" ، ومع ذلك فشل في إظهار أنه يمكن استدعاء ondestroy () في عدة مرات ، حتى تجاوز الانتقال من استئناف إلى التوقف. ومع ذلك ، يصف النص بوضوح هذا الاحتمال.

هذا هو السبب ، لسوء الحظ ، فإن قراءة قسم دورة حياة التطبيق في "أساسيات التطبيق" ليست ببساطة كافية. بدلاً من ذلك ، يجب على المرء أيضًا قراءة Javadoc لكل من عمليات الاسترجاعات تحت هذا النشاط ، وكذلك قسم "أساسيات التطبيق" على العمليات.

بعد ذلك ، من المفيد للغاية وضع عبارات Log.D في كل من عمليات الاسترجاعات ومشاهدة إخراج logcat أثناء ركوب التطبيق الخاص بك خلال دورة الحياة. ولكن حتى ذلك الحين ، لا تعتمد على أحداث دورة الحياة التي تحدث بالترتيب الذي تراه في Logcat ما لم تتمكن من العثور على مبرر لها في أحد مستندات الإنترنت المذكورة أعلاه.