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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

تجميع عمليات نقل البيانات

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

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

الجلب المُسبَق للبيانات

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

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

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

إليك مثالاً عمليًا.

قارئ أخبار

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

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

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

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

اعتبارات أخرى

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

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

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

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

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

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

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

عمليات ربط أحواض التجميع

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

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

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

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

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

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