تحسين الوصول إلى الشبكة

من المحتمل أن يكون استخدام الراديو اللاسلكي لنقل البيانات أحد أهم مصادر استنزاف البطارية في تطبيقك. لتقليل استهلاك البطارية المرتبط بنشاط الشبكة، من المهم أن تفهم كيف سيؤثر نموذج الاتصال في جهاز الراديو الأساسي.

يقدّم هذا القسم آلة حالة البث اللاسلكي ويوضّح كيفية تفاعل نموذج الاتصال في تطبيقك معها. ثم تقدم بعد ذلك العديد من التقنيات التي عند اتباعها ستساعد في تقليل تأثير استهلاك بيانات التطبيق على البطارية.

آلة حالة الراديو

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

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

تتألف آلة الحالات لجهاز راديو شبكة الجيل الثالث النموذجي من ثلاث حالات للطاقة:

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

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

للحدّ من وقت الاستجابة، تستخدِم آلة الحالات تأخيرًا لتأجيل الانتقال إلى حالات الطاقة المنخفضة. يستخدِم الشكل 1 أوقات AT&T لشبكة الجيل الثالث النموذجية.

الشكل 1. آلة حالة البث اللاسلكي النموذجية لشبكة الجيل الثالث

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

تصف هذه الصفحة آلة حالة تمثيلية لجهاز راديو لاسلكي نموذجي من الجيل الثالث (3G)، استنادًا إلى البيانات المقدَّمة من AT&T. ومع ذلك، تنطبق المبادئ العامة و أفضل الممارسات الناتجة على جميع عمليات تنفيذ البث اللاسلكي.

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

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

تأثير التطبيقات في آلة حالة الراديو

في كل مرة تنشئ فيها اتصالاً جديدًا بالشبكة، ينتقل جهاز الراديو إلى حالة الطاقة الكاملة. في حالة الجهاز اللاسلكي العادي لشبكة الجيل الثالث الموضح سابقًا، سيظل الجهاز قيد التشغيل بكامل طاقته طوال مدة النقل - بالإضافة إلى 5 ثوانٍ إضافية من وقت لاحق - متبوعًا بـ 12 ثانية في حالة انخفاض الطاقة. وبالتالي، بالنسبة إلى جهاز 3G عادي، ستؤدي كل جلسة لنقل البيانات إلى استخدام الطاقة في الراديو لمدة 18 ثانية على الأقل.

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

الشكل 2: استخدام الطاقة النسبي للراديو اللاسلكي لنقل البيانات لمدة ثانية واحدة يتم تنفيذه ثلاث مرات كل دقيقة لا يشمل هذا الرقم وقت الاستجابة في "بدء التشغيل" بين عمليات التشغيل.

في المقابل، إذا كان التطبيق نفسه يُجمِّع عمليات نقل البيانات، ويُجري عملية نقل واحدة مدّتها ثلاث ثوانٍ كل دقيقة، سيؤدي ذلك إلى إبقاء الراديو في حالة استخدام الطاقة العالية لمدة 20 ثانية فقط كل دقيقة. سيؤدي ذلك إلى إبقاء الراديو في وضع الاستعداد لمدة 40 ثانية من كل دقيقة، ما يؤدي إلى خفض استهلاك البطارية بشكلٍ ملحوظ.

الشكل 3. الاستخدام النسبي لطاقة الراديو اللاسلكي في عمليات النقل التي تبلغ ثلاث ثوانٍ يتم تشغيلها مرة كل دقيقة.

أساليب التحسين

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

حِزم نقل البيانات

كما هو موضّح في القسم السابق، إنّ تجميع عمليات نقل البيانات لكي تتم نقل المزيد من البيانات بمعدل أقل هو أحد أفضل الطرق لتحسين فعالية البطارية.

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

جلب البيانات مسبقًا

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

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

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

في ما يلي مثال عملي.

قارئ الأخبار

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

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

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

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

اعتبارات إضافية

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

يعتمد مدى سرعة تحميل البيانات مسبقًا على حجم البيانات التي يتم تنزيلها واحتمالية استخدامها. كدليل تقريبي، استنادًا إلى آلة الحالة الموضّحة سابقًا، بالنسبة إلى البيانات التي تبلغ احتمالية استخدامها% 50 خلال جلسة المستخدم الحالية، يمكنك عادةً إجراء التحميل المُسبَق لمدة 6 ثوانٍ تقريبًا (من 1 إلى 2 ميغابايت تقريبًا) قبل أن تتساوى التكلفة المحتملة لتنزيل data غير المستخدَمة مع التوفير المحتمل لعدم تنزيل هذه البيانات.

بشكل عام، من الممارسات الجيدة prefetching البيانات بحيث لا تحتاج إلا إلى بدء عملية تنزيل أخرى كل دقيقتين إلى 5 دقائق، وبترتيب من 1 إلى 5 ميغابايت.

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

أحد الحلول هو جدولة عملية التنزيل الكامل بحيث لا تحدث إلا عند الاتصال بشبكة Wi-Fi، وربما فقط عندما يكون الجهاز قيد الشحن. تتيح لك واجهة برمجة التطبيقات WorkManager API استخدام حالة الاستخدام هذه بالضبط، ما يتيح لك تقييد العمل في الخلفية إلى أن يستوفي الجهاز المعايير التي يحدّدها المطوّر، مثل الشحن والاتصال بشبكة Wi-Fi.

التحقق من الاتصال قبل تقديم الطلبات

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

عمليات الربط بمجموعة بيانات

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

من الأفضل بشكل عام إعادة استخدام اتصالات الشبكة الحالية بدلاً من بدء اتصالات جديدة. تسمح إعادة استخدام الاتصالات للشبكة أيضًا بالاستجابة بذكاء أكبر للازدحام ومشاكل بيانات الشبكة ذات الصلة.

تفعّل HttpURLConnection ومعظم برامج HTTP، مثل OkHttp، تجميع الاتصالات تلقائيًا، وتعيد استخدام الاتصال نفسه لطلبات متعددة.

ملخّص ونظرة مستقبلية

في هذا القسم، تعلمت الكثير عن الراديو اللاسلكي وبعض الاستراتيجيات التي يمكنك تطبيقها على نطاق واسع لتوفير تجربة مستخدم سريعة الاستجابة مع تقليل استنزاف البطارية.

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