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