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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

قارئ الأخبار

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

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

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

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

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

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

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

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

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

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

التحقّق من إمكانية الاتصال بالإنترنت قبل تقديم الطلبات

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

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

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

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

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

ملخّص ونظرة إلى المستقبل

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

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