START_STICKY و START_NOT_STICKY

لا يكون كلا الرمزين ذا صلة إلا عندما ينفد الهاتف وينفد الخدمة قبل أن ينتهي التنفيذ. يخبر START_STICKY نظام التشغيل بإعادة إنشاء الخدمة بعد أن تحتوي على ذاكرة كافية واتصل بـ onStartCommand() مرة أخرى بقصد فارغ. يخبر START_NOT_STICKY نظام التشغيل ألا يكلف نفسه عناء إعادة إنشاء الخدمة مرة أخرى. يوجد أيضًا رمز ثالث START_REDELIVER_INTENT يُخبر نظام التشغيل بإعادة إنشاء الخدمة وإعادة توجيه نفس القصد إلى onStartCommand().

أوضحت هذه المقالة التي كتبها ديان هاكبورن خلفية هذا أفضل بكثير من الوثائق الرسمية.

المصدر: http://Android-developers.blogspot.com.au/2010/02/service-api-changes-starting-with.html

الجزء الرئيسي هنا هو رمز النتيجة الجديد الذي تم إرجاعه بواسطة الوظيفة ، لإخبار النظام بما يجب أن يفعله بالخدمة إذا تم قتل العملية أثناء تشغيلها:

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

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

START_REDELIVER_INTENT يشبه START_NOT_STICKY ، إلا إذا تم قتل عملية الخدمة قبل أن تستدعي stopSelf () لغرض معين ، سيتم إعادة تسليم هذه النية إليها حتى تكتمل (إلا إذا لم تستكمل بعد عدد آخر من المحاولات ، عند هذه النقطة يستسلم النظام). هذا مفيد للخدمات التي تتلقى أوامر العمل للقيام بها ، وتريد التأكد من أنها في نهاية المطاف إكمال العمل لكل أمر إرسال.

قبلة الجواب

فرق:

START_STICKY

سيحاول النظام إعادة إنشاء خدمتك بعد قتلها

START_NOT_STICKY

سيقوم النظام لا بمحاولة إعادة إنشاء الخدمة بعد قتلها

مثال قياسي:

@Override
public int onStartCommand(Intent intent, int flags, int startId) {
    return START_STICKY;
}

وثائق START_STICKY و START_NOT_STICKY واضحة تمامًا.

START_STICKY:

إذا قُتلت عملية هذه الخدمة أثناء بدء تشغيلها (بعد العودة من onStartCommand(Intent, int, int))) ، فاتركها في حالة البدء ولكن لا تحتفظ بالنية المستلمة. في وقت لاحق ، سيحاول النظام إعادة إنشاء الخدمة. لأنه في البداية الحالة ، ستضمن الاتصال بـ onStartCommand(Intent, int, int) بعد إنشاء مثيل الخدمة الجديد ؛ إذا لم يكن هناك أي أوامر بداية معلقة لتسليمها إلى الخدمة ، فسيتم استدعاؤها بكائن هدف فارغ ، لذلك يجب توخي الحذر للتحقق من ذلك.

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

مثال: نموذج الخدمة المحلية

START_NOT_STICKY:

إذا قُتلت عملية هذه الخدمة أثناء بدء تشغيلها (بعد العودة من onStartCommand(Intent, int, int)) ، ولم تكن هناك نوايا بداية جديدة للتسليم إليها ، فقم بإخراج الخدمة من حالة البدء وعدم إعادة إنشاء حتى استدعاء صريح في المستقبل إلى Context.startService(Intent). لن تتلقى الخدمة مكالمة onStartCommand(Intent, int, int) مع نية null لأنه لن يتم إعادة تشغيلها إذا لم تكن هناك نوايا معلقة للتسليم.

هذا الوضع منطقي بالنسبة للأشياء التي ترغب في القيام ببعض الأعمال كنتيجة لبدء التشغيل ، ولكن يمكن إيقافه عندما يكون تحت ضغط الذاكرة وسوف يبدأ تشغيله مرة أخرى بشكل صريح لاحقًا للقيام بمزيد من العمل. مثال على مثل هذه الخدمة هو الذي يقوم باستطلاعات الرأي للبيانات من خادم: قد يقوم بجدولة إنذار لاستطلاع كل N دقيقة عن طريق تشغيل المنبه في بدء خدمته. عندما يتم استدعاء الدالة onStartCommand(Intent, int, int) الخاصة بها من المنبه ، فإنها تقوم بجدولة إنذار جديد لمدة N دقيقة فيما بعد ، وتفرز سلسلة رسائل للقيام بشبكتها. إذا قُتلت عمليتها أثناء إجراء هذا الفحص ، فلن تتم إعادة تشغيل الخدمة حتى يتم تشغيل المنبه.

مثال: ServiceStartArguments.Java