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