يُعدّ استخدام جهاز الإرسال اللاسلكي لنقل البيانات أحد أهم الأسباب المحتملة لاستنزاف بطارية تطبيقك. للحدّ من استنزاف البطارية المرتبط بنشاط الشبكة، من الضروري فهم كيفية تأثير نموذج الاتصال في جهاز الإرسال الأساسي.
يعرض هذا القسم جهاز حالة جهاز الإرسال اللاسلكي ويشرح كيفية تفاعل نموذج الاتصال في تطبيقك معه. بعد ذلك، يقدّم القسم عدة تقنيات، إذا اتّبعتها، ستساعدك في الحدّ من تأثير استهلاك تطبيقك للبيانات على البطارية.
جهاز حالة جهاز الإرسال
يتضمّن جهاز الإرسال اللاسلكي على جهاز المستخدم ميزات مدمجة لتوفير الطاقة تساعد في الحدّ من مقدار طاقة البطارية التي يستهلكها. عندما يكون جهاز الإرسال اللاسلكي نشطًا بالكامل، يستهلك قدرًا كبيرًا من الطاقة، ولكن عندما يكون غير نشط أو في وضع الاستعداد، يستهلك قدرًا قليلاً جدًا من الطاقة.
من المهم أن تتذكّر أنّه لا يمكن لجهاز الإرسال الانتقال من وضع الاستعداد إلى وضع النشاط الكامل على الفور. هناك فترة وقت استجابة مرتبطة بـ "تشغيل" جهاز الإرسال. لذلك، تنتقل البطارية من حالات الطاقة الأعلى إلى حالات الطاقة الأقل ببطء للحفاظ على الطاقة عندما لا تكون قيد الاستخدام، مع محاولة الحدّ من وقت الاستجابة المرتبط بـ "تشغيل" جهاز الإرسال.
يتألف جهاز حالة جهاز إرسال شبكة الجيل الثالث النموذجية من ثلاث حالات طاقة:
- الطاقة الكاملة: تُستخدَم عندما يكون الاتصال نشطًا، ما يسمح للجهاز بـ نقل البيانات بأعلى معدّل ممكن.
- الطاقة المنخفضة: هي حالة وسيطة تقلّل استهلاك طاقة البطارية بنسبة %50 تقريبًا.
- وضع الاستعداد: هي حالة استهلاك الحد الأدنى من الطاقة التي لا يكون فيها أي اتصال بالشبكة نشطًا.
على الرغم من أنّ حالتي الطاقة المنخفضة والاستعداد تستنزفان قدرًا أقل بكثير من البطارية، إلا أنّهما تؤديان أيضًا إلى وقت استجابة كبير في طلبات الشبكة. يستغرق الرجوع إلى حالة الطاقة الكاملة من حالة الطاقة المنخفضة حوالي 1.5 ثانية، وقد يستغرق الانتقال من وضع الاستعداد إلى حالة الطاقة الكاملة أكثر من ثانيتَين.
للحدّ من وقت الاستجابة، يستخدم جهاز الحالة تأخيرًا لتأجيل الانتقال إلى حالات الطاقة الأقل. يستخدم الشكل 1 توقيتات AT&T لجهاز إرسال نموذجي لشبكة الجيل الثالث.
الشكل 1. جهاز حالة جهاز إرسال لاسلكي نموذجي لشبكة الجيل الثالث
سيختلف جهاز حالة جهاز الإرسال على كل جهاز، لا سيما فترة التأخير المرتبطة بالانتقال ("وقت الإيقاف") وفترة التأخير عند بدء التشغيل، استنادًا إلى تكنولوجيا جهاز الإرسال اللاسلكي المستخدَمة (الجيل الثالث وLTE والجيل الخامس وما إلى ذلك)، ويحدّدها ويضبطها مشغّل شبكة الجوّال الذي يعمل الجهاز على شبكته.
تصف هذه الصفحة جهاز حالة تمثيليًا لجهاز إرسال لاسلكي نموذجي لشبكة الجيل الثالث، استنادًا إلى البيانات التي قدّمتها AT&T. ومع ذلك، تنطبق المبادئ العامة وأفضل الممارسات الناتجة على جميع عمليات تنفيذ أجهزة الإرسال اللاسلكية.
يكون هذا النهج فعّالاً بشكل خاص لتصفّح الويب النموذجي على الأجهزة الجوّالة لأنّه يمنع وقت الاستجابة غير المرغوب فيه أثناء تصفّح المستخدمين للويب. يضمن وقت الإيقاف المنخفض نسبيًا أيضًا أنّه بعد انتهاء جلسة التصفّح، يمكن لجهاز الإرسال الانتقال إلى حالة طاقة أقل.
لسوء الحظ، يمكن أن يؤدي هذا النهج إلى تطبيقات غير فعّالة على أنظمة تشغيل الهواتف الذكية الحديثة، مثل Android، حيث تعمل التطبيقات في المقدّمة (حيث يكون وقت الاستجابة مهمًا) وفي الخلفية (حيث يجب منح الأولوية لعمر البطارية).
تأثير التطبيقات في جهاز حالة جهاز الإرسال
في كل مرة تنشئ فيها اتصالاً جديدًا بالشبكة، ينتقل جهاز الإرسال إلى حالة الطاقة الكاملة. في حالة جهاز حالة جهاز إرسال شبكة الجيل الثالث النموذجية الموضّح سابقًا، سيظل في حالة الطاقة الكاملة طوال مدة عملية النقل، بالإضافة إلى 5 ثوانٍ إضافية من وقت الإيقاف، تليها 12 ثانية في حالة الطاقة المنخفضة. لذلك، بالنسبة إلى جهاز نموذجي لشبكة الجيل الثالث، ستؤدي كل جلسة لنقل البيانات إلى استهلاك جهاز الإرسال للطاقة لمدة 18 ثانية على الأقل.
من الناحية العملية، يعني ذلك أنّ تطبيقًا ينقل البيانات لمدة ثانية واحدة، ثلاث مرات في الدقيقة، سيُبقي جهاز الإرسال اللاسلكي نشطًا باستمرار، ويعيده إلى حالة الطاقة العالية تمامًا عند دخوله وضع الاستعداد.
الشكل 2. استخدام الطاقة النسبي لجهاز الإرسال اللاسلكي لعملية نقل مدتها ثانية واحدة يتم تنفيذها ثلاث مرات كل دقيقة يستثني الشكل فترة التأخير "عند تشغيل" جهاز الإرسال بين عمليات النقل.
بالمقارنة، إذا كان التطبيق نفسه يجمع عمليات نقل البيانات، وينفّذ عملية نقل واحدة مدتها ثلاث ثوانٍ كل دقيقة، سيُبقي ذلك جهاز الإرسال في حالة الطاقة العالية لمدة 20 ثانية فقط في كل دقيقة. سيسمح ذلك لجهاز الإرسال بالبقاء في وضع الاستعداد لمدة 40 ثانية من كل دقيقة، ما يؤدي إلى انخفاض كبير في استهلاك البطارية.
الشكل 3. استخدام الطاقة النسبي لجهاز الإرسال اللاسلكي لعمليات نقل مدتها ثلاث ثوانٍ يتم تنفيذها مرة واحدة كل دقيقة
تقنيات التحسين
بعد أن فهمت كيف يؤثر الوصول إلى الشبكة في عمر البطارية، لنتحدث عن بعض الإجراءات التي يمكنك اتّخاذها للمساعدة في الحدّ من استنزاف البطارية، مع توفير تجربة مستخدم سريعة وسلسة في الوقت نفسه.
تجميع عمليات نقل البيانات
كما هو موضّح في القسم السابق، يُعدّ تجميع عمليات نقل البيانات لنقل المزيد من البيانات بشكل أقل تكرارًا من أفضل الطرق لتحسين كفاءة البطارية.
بالطبع، لا يمكن إجراء ذلك دائمًا إذا كان تطبيقك بحاجة إلى تلقّي البيانات أو إرسالها على الفور استجابةً لإجراء يتخذه المستخدم. يمكنك الحدّ من هذه المشكلة من خلال توقُّع البيانات وجلبها مسبقًا. تتلاءم السيناريوهات الأخرى، مثل إرسال السجلّات أو الإحصاءات إلى خادم وعمليات نقل البيانات الأخرى التي يبدأها التطبيق وغير العاجلة، بشكل جيد جدًا مع تجميع البيانات. راجِع تحسين المهام التي يبدأها التطبيق للحصول على نصائح حول جدولة عمليات نقل البيانات على الشبكة في الخلفية.
جلب البيانات مسبقًا
يُعدّ جلب البيانات مسبقًا طريقة فعّالة أخرى للحدّ من عدد جلسات نقل البيانات المستقلة التي ينفّذها تطبيقك. باستخدام ميزة الجلب المسبق، عندما يتخذ المستخدم إجراءً في تطبيقك، يتوقّع التطبيق البيانات التي من المرجّح أن تكون مطلوبة للسلسلة التالية من إجراءات المستخدم ويجلب هذه البيانات في عملية واحدة، عبر اتصال واحد، وبكامل السعة.
من خلال تحميل عمليات النقل مسبقًا، يمكنك الحدّ من عدد عمليات تنشيط جهاز الإرسال المطلوبة لتنزيل البيانات. نتيجةً لذلك، لن تحافظ على عمر البطارية فحسب، بل ستُحسّن أيضًا وقت الاستجابة وتُقلّل معدل نقل البيانات المطلوب وأوقات التنزيل.
يوفّر الجلب المسبق أيضًا تجربة مستخدم محسّنة من خلال الحدّ من وقت الاستجابة داخل التطبيق الناتجة عن انتظار اكتمال عمليات التنزيل قبل تنفيذ إجراء أو عرض البيانات.
في ما يلي مثال عملي.
تطبيق لقراءة الأخبار
تحاول العديد من تطبيقات الأخبار الحدّ من النطاق الترددي من خلال تنزيل العناوين الرئيسية فقط بعد اختيار فئة، والمقالات الكاملة فقط عندما يريد المستخدم قراءتها، والصور المصغّرة تمامًا عند ظهورها أثناء التمرير.
باستخدام هذا النهج، يُضطر جهاز الإرسال إلى البقاء نشطًا لمعظم جلسات قراءة الأخبار لدى المستخدمين أثناء تمريرهم العناوين الرئيسية وتغييرهم الفئات وقراءتهم المقالات. ليس ذلك فحسب، بل يؤدي التبديل المستمر بين حالات الطاقة إلى وقت استجابة كبير عند تبديل الفئات أو قراءة المقالات.
من الأفضل جلب قدر معقول من البيانات مسبقًا عند بدء التشغيل، بدءًا من المجموعة الأولى من العناوين الرئيسية والصور المصغّرة للأخبار، ما يضمن وقت بدء تشغيل منخفضًا، ومواصلة ذلك مع العناوين الرئيسية والصور المصغّرة المتبقية، بالإضافة إلى نص المقالة لكل مقالة متاحة من قائمة العناوين الرئيسية الأولية على الأقل.
هناك بديل آخر يتمثل في جلب كل عنوان رئيسي وصورة مصغّرة ونص مقالة مسبقًا، وربما حتى صور المقالات الكاملة، عادةً في الخلفية وفقًا لجدول زمني محدّد مسبقًا. يؤدي هذا النهج إلى استهلاك نطاق ترددي كبير وعمر البطارية لتنزيل محتوى لا يتم استخدامه مطلقًا، لذا يجب تنفيذه بحذر.
اعتبارات أخرى
على الرغم من أنّ جلب البيانات مسبقًا يحمل الكثير من المزايا، إلا أنّ استخدامه بشكل مفرط يؤدي أيضًا إلى زيادة خطر استنزاف البطارية واستخدام النطاق الترددي، بالإضافة إلى حصة التنزيل، من خلال تنزيل بيانات لا يتم استخدامها. من المهم أيضًا التأكّد من أنّ الجلب المسبق لا يؤخر بدء تشغيل التطبيق أثناء انتظار التطبيق اكتمال الجلب المسبق. من الناحية العملية، قد يعني ذلك معالجة البيانات تدريجيًا، أو بدء عمليات نقل متتالية يتم ترتيب أولويتها بحيث يتم تنزيل البيانات المطلوبة لبدء تشغيل التطبيق ومعالجتها أولاً.
يعتمد مدى الجلب المسبق للبيانات على حجم البيانات التي يتم تنزيلها واحتمالية استخدامها. كإرشادات تقريبية، استنادًا إلى جهاز الحالة الموضّح سابقًا، بالنسبة إلى البيانات التي تبلغ احتمالية استخدامها% 50 خلال جلسة المستخدم الحالية، يمكنك عادةً جلبها مسبقًا لمدة 6 ثوانٍ تقريبًا (غيغابايت واحد أو اثنان تقريبًا) قبل أن تتطابق التكلفة المحتملة لتنزيل البيانات غير المستخدَمة مع الوفورات المحتملة لعدم تنزيل هذه البيانات في البداية.
بشكل عام، من أفضل الممارسات جلب البيانات مسبقًا بحيث لا تحتاج إلى بدء عملية تنزيل أخرى إلا كل دقيقتَين إلى 5 دقائق، وبحجم يتراوح بين غيغابايت واحد و5 غيغابايت.
باتّباع هذا المبدأ، يجب تنزيل عمليات التنزيل الكبيرة، مثل ملفات الفيديو، على شكل أجزاء على فترات منتظمة (كل دقيقتَين إلى 5 دقائق)، ما يؤدي فعليًا إلى جلب بيانات الفيديو التي من المرجّح مشاهدتها في الدقائق القليلة التالية مسبقًا فقط.
أحد الحلول هو جدولة عملية التنزيل الكاملة بحيث تحدث فقط عند الاتصال بشبكة Wi-Fi، وربما فقط عندما يكون الجهاز قيد الشحن. تتيح واجهة برمجة التطبيقات WorkManager حالة الاستخدام هذه تحديدًا، ما يسمح لك بتقييد العمل في الخلفية إلى أن يستوفي الجهاز المعايير التي يحدّدها المطوّر، مثل الشحن و الاتصال بشبكة Wi-Fi.
التحقّق من الاتصال قبل تقديم الطلبات
يُعدّ البحث عن إشارة شبكة الجوّال من أكثر العمليات استنزافًا للطاقة على الجهاز الجوّال. من أفضل الممارسات للطلبات التي يبدأها المستخدم التحقّق أولاً من
الاتصال باستخدام
ConnectivityManager، كما هو موضّح في
مراقبة حالة الاتصال وقياس استخدام الاتصال
البيانات.
إذا لم تكن هناك شبكة، يمكن للتطبيق توفير البطارية من خلال عدم إجبار جهاز الإرسال على البحث. يمكن بعد ذلك جدولة الطلب وتنفيذه في مجموعة مع طلبات أخرى عند إجراء اتصال.
تجميع الاتصالات
هناك استراتيجية إضافية يمكن أن تساعدك بالإضافة إلى تجميع البيانات وجلبها مسبقًا، وهي تجميع اتصالات الشبكة في تطبيقك.
من الأفضل بشكل عام إعادة استخدام اتصالات الشبكة الحالية بدلاً من بدء اتصالات جديدة. تسمح إعادة استخدام الاتصالات أيضًا للشبكة بالردّ بشكل أكثر ذكاءً على الازدحام والمشاكل ذات الصلة ببيانات الشبكة.
HttpURLConnection ومعظم برامج HTTP
، مثل OkHttp، تتيح
تجميع الاتصالات تلقائيًا، وإعادة استخدام الاتصال نفسه لطلبات متعددة.
ملخّص ونظرة مستقبلية
في هذا القسم، تعرّفت على الكثير من المعلومات حول جهاز الإرسال اللاسلكي وبعض الاستراتيجيات التي يمكنك تطبيقها على نطاق واسع لتوفير تجربة مستخدم سريعة ومتجاوبة مع الحدّ من استنزاف البطارية.
في القسم التالي، سنلقي نظرة مفصّلة على ثلاثة أنواع مختلفة من التفاعلات مع الشبكة الشائعة في معظم التطبيقات. ستتعرّف على العوامل التي تؤدي إلى كل نوع من هذه الأنواع، بالإضافة إلى التقنيات وواجهات برمجة التطبيقات الحديثة لإدارة هذه التفاعلات بكفاءة.