في هذه المقالة ، سوف نتحدث عن مشكلة واحدة مع JobIntentService ، والتي توجد بها أسئلة كثيرة حول الموارد والتقارير المقابلة في Google bug tracker. وأيضًا حول السبب ، وفقًا لكل شيء ، لا تعتبر Google خطأً وتغلق هذه التقارير.
مقدمة
تم إنشاء JobIntentServices للعمل في الخلفية. كانت تستخدم على نطاق واسع في Android 8 وما فوق ، عندما اختفت القدرة على استخدام الخدمات في الخلفية.
في الواقع ، فإنها تحل محل الخدمات في الخلفية ، وتخضع أيضًا لسيطرة جدولة المهام (JobScheduler).
وبالتالي ، فإن النظام لديه القدرة على التحكم في تقدم المهام في الخلفية والتحكم أيضًا في wakelocks نفسه ، مما جعل من الممكن تحسين استهلاك البطارية للجهاز وتجنب الاستخدام غير الصحيح ل wakelocks من قبل المطورين. أدت هذه الخطوات إلى تقليل الموقف إلى الحد الأدنى عندما يتعذر على الجهاز الغطس في وضع السكون (وضع الغفوة) ، مما يؤثر مرة أخرى على توفير البطارية.
باختصار حول JobIntentService
في جوهرها ، JobIntentService هو نفس IntentService تحت سيطرة جدولة المهام (JobScheduler).
يعمل في موضوع الخلفية AsyncTask ل.
في إصدارات Android 4.4 والإصدارات الأحدث ، يتم استخدام IntentService المعتاد.
يمكن العثور على وصف مفصل في الوثائق.
دورة الحياة والمزالق
كلا النوعين من المهام لها نفس دورة الحياة. يتم التحكم في المهام من قبل المعالج ولها دول.
على الرغم من أن هذه الحالات لا يمكن الوصول إليها خارجيًا ، إلا أنه في ظل ظروف معينة ، يلقي النظام استثناءات يتعطل فيها التطبيق. هذه السلوكيات هي مشكلة وصداع للعديد من المطورين وللأسف ليس لديهم حل بسيط. بادئ ذي بدء ، ندرس حالة ودورة حياة المهام ، ومن ثم النظر في الحلول الممكنة.
تسلسل حالة المهمة
BINDING - مهلة حالة إنشاء المهمة (ربط الخدمة) 18 ثانية.
بدء - حالة إطلاق المهمة ، مهلة 8 ثوان.
تنفيذ - حالة تنفيذ المهمة ، مهلة 10 دقائق.
التوقف - حالة توقف المهمة (على سبيل المثال ، بعد استدعاء إلغاء ()) ، مهلة 8 ثوانٍ.
انتهى - الحالة النهائية للمهمة المكتملة ، وآخر حالة في دورة حياة المهمة.
مخطط دورة حياة مهمة مبسطة
كل حالة مهمة لها مهلة خاصة بها. بعد انقضاء المهلة ، تتم مقاطعة المهمة بغض النظر عن حالتها. في الواقع ، هذه هي آلية مهلة وهي مأزق منذ ذلك الحين بعد انتهاء المهلة ، يلقي النظام استثناء من النوع java.lang.SecurityException ويتعطل التطبيق مع الرسالة التالية Caller no longer running, last stopped +1s600ms because: timed out while starting حيث يكون +1s600ms هو الوقت الذي انقضى منذ انتهاء المهلة في اللحظة التي تم فيها طرح الاستثناء ، يشير "السبب" ( because: timed out while starting مهلته because: timed out while starting ) إلى الحالة التي كانت فيها المهمة عند انتهاء المهلة.
الاستنتاجات
كما تظهر التجربة ، تم العثور على هذه الاستثناءات في التطبيقات المحملة إلى حد ما.
لدعم هذه المشكلة ، يمكن للمرء أن يلاحظ على حد سواء على الأجهزة ضعيفة وعلى أعلى. تتم الإشارة إلى هذه المشكلة أيضًا عن طريق استثناءات مع رسائل المهلة. وفقًا لذلك ، فإن قرار إلغاء تحميل التطبيق وتحسين استخدام JobIntentServices يوحي بنفسه ، على سبيل المثال ، لتجنب المواقف عند بدء تشغيل العديد من JobIntentServices بالتوازي. الحل الثاني ، في بعض الحالات أكثر تافهة ، وأحيانا أكثر تعقيدا من الخيار الأول ، هو استخدام JobService.
أيضًا ، إذا كنت غوغل هذه المشكلة ، فيمكنك التعثر على الخيارات "المشكوك فيها" الأخرى لحل هذه المشكلة ، على سبيل المثال ، يمكنك رؤية الروابط التالية:
الخيار 1
الخيار 2
الخيار 3
PS
في الوقت الحالي ، تعد Google بديلاً جيدًا لـ JobService و JobIntentService - هذا هو Worker و WorkManger من حزمة androidx.work.
لسوء الحظ ، لم تعد هذه الأدوات جاهزة للإنتاج ولديها عدد من الأخطاء ، ولكن الآن ، كما أظهرت الاختبارات ، فإنها تحل المشكلة الموضحة أعلاه.