اتّباع أفضل الممارسات المتعلّقة بقفل التنشيط

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

ملاحظة: يمكن أن يكون لإنشاء أقفال التنشيط والاحتفاظ بها تأثير كبير في عمر بطارية الجهاز. يجب عدم استخدام عمليات قفل التنشيط إذا كانت هناك أي بدائل مناسبة. للاطّلاع على خيارات أخرى، يُرجى الاطّلاع على مستندات إبقاء الجهاز نشطًا. إذا كنت بحاجة إلى استخدام قفل تنشيط، احرص على الاحتفاظ به مدّة قصيرة قدر الإمكان.

يجب تسمية قفل التنشيط بشكل صحيح.

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

• يجب عدم تضمين أي معلومات تحدّد الهوية الشخصية في الاسم، مثل عنوان البريد الإلكتروني. إذا رصد الجهاز معلومات تحديد الهوية الشخصية في علامة قفل التنشيط، يسجِّل الجهاز _UNKNOWN بدلاً من العلامة التي حدّدتها.
• لا تحصل على اسم الفئة أو الطريقة آليًا، على سبيل المثال من خلال استدعاء getName(). إذا حاولت الحصول على الاسم آليًا، قد يتم تشويشه باستخدام أدوات مثل Proguard. بدلاً من ذلك، استخدِم سلسلة مكتوبة في الرمز البرمجي.
• لا تُضِف عدادًا أو معرّفات فريدة إلى علامات قفل التنشيط. يجب أن يستخدِم الرمز المبرمَج الذي ينشئ قفلًا لتنشيط الشاشة العلامة نفسها في كل مرة يتم تشغيله فيها. تتيح هذه الممارسة للنظام تجميع استخدام قيد التنشيط لكل طريقة.

التأكّد من أنّ تطبيقك مرئي في المقدّمة

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

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

يجب أن يكون المنطق بسيطًا.

تأكَّد من أنّ منطق الحصول على أقفال التنشيط وإلغائها بسيط بقدر الإمكان. عندما يكون منطق قفل التنشيط مرتبطًا بآلات حالات معقّدة أو مهلات أو مجموعات أدوات تنفيذ أو أحداث استدعاء، يمكن أن يؤدي أي خطأ بسيط في هذا المنطق إلى تثبيت قفل التنشيط لفترة أطول من المتوقع. يصعب تشخيص هذه الأخطاء وتصحيحها.

تأكَّد من أنّه يتم دائمًا إزالة قفل الاستيقاظ.

في حال استخدام قفل تنبيه، عليك التأكّد من أنّه يتم إزالة كل قفل تنبيه تحصل عليه بشكل صحيح. ليس من السهل دائمًا تنفيذ ذلك. على سبيل المثال، هناك مشكلة في التعليمة البرمجية التالية:

Kotlin

@Throws(MyException::class)
fun doSomethingAndRelease() {
    wakeLock.apply {
        acquire()
        doTheWork() // can potentially throw MyException
        release()   // does not run if an exception is thrown
    }
}

Java

void doSomethingAndRelease() throws MyException {
    wakeLock.acquire();
    doTheWork();         // can potentially throw MyException
    wakeLock.release();  // does not run if an exception is thrown
}

تكمن المشكلة هنا في أنّ الطريقة doTheWork() يمكن أن تُعرِض الاستثناء MyException. وإذا حدث ذلك، تُرسِل طريقة doSomethingAndRelease() الاستثناء إلى الخارج، ولا تصل أبدًا إلى طلب release(). النتيجة هي أنّه تم الحصول على قفل التنشيط ولكن لم يتم تحريره، وهذا أمر سيئ للغاية.

في الرمز المصحَّح، يحرص doSomethingAndRelease() على إزالة قفل الاستيقاظ حتى في حال حدوث استثناء:

Kotlin

@Throws(MyException::class)
fun doSomethingAndRelease() {
    wakeLock.apply {
        try {
            acquire()
            doTheWork()
        } finally {
            release()
        }
    }
}

Java

void doSomethingAndRelease() throws MyException {
    try {
        wakeLock.acquire();
        doTheWork();
    } finally {
        wakeLock.release();
    }
}