يمكن أن يكون لحركة بيانات الشبكة التي ينشئها التطبيق تأثير كبير في عمر بطارية الجهاز. لتحسين هذه الزيارات، عليك قياسها وتحديد مصدرها. يمكن أن تأتي طلبات الشبكة مباشرةً من إجراء للمستخدِم، أو من رمز تطبيقك، أو من خادم يتواصل مع تطبيقك.
يوضّح لك هذا الموضوع كيفية مراقبة حركة بيانات الشبكة وتصنيفها، ويقدّم إرشادات حول تحديد المشاكل وحلّها.
استخدام "أداة تحليل الشبكة" لمراقبة الطلبات
استخدِم أداة تحليل الشبكة لتتبُّع طلبات الشبكة في تطبيقك. يمكنك مراقبة كيفية نقل تطبيقك للبيانات ووقت نقلها وتحسين الرمز البرمجي الأساسي بشكلٍ مناسب.
الشكل 1. تتبُّع حركة بيانات الشبكة يشير نمط حركة بيانات الشبكة إلى إمكانية تحسين الكفاءة بشكل كبير من خلال الجلب المسبق للطلبات أو تجميع التحميلات.
ومن خلال مراقبة معدل تكرار عمليات نقل البيانات ومقدار البيانات التي يتم نقلها خلال كل عملية اتصال، يمكنك تحديد مناطق التطبيق التي يمكن جعلها أكثر كفاءة في استخدام البطارية. بشكل عام، ستبحث عن الارتفاعات القصيرة التي يمكن تأخيرها.
لتحديد سبب الارتفاعات المفاجئة في عمليات النقل بشكل أفضل، تتيح لك واجهة برمجة التطبيقات Traffic Stats API تمييز عمليات نقل البيانات التي تحدث من مقبس ضمن سلسلة محادثات معيّنة باستخدام TrafficStats.setThreadStatsTag()
.
لا يؤدي استدعاء هذه الدالة إلى وضع علامة تلقائيًا على جميع الزيارات لسلسلة محادثات معيّنة، بل يجب تطبيق العلامات على مآخذ التوصيل.
بعد ضبط علامة سلسلة المحادثات، يمكنك وضع علامة على مقابس فردية وإزالتها يدويًا
باستخدام
TrafficStats.tagSocket()
و
TrafficStats.untagSocket()
.
يتم تطبيق علامة أيضًا إذا تم فتح مقبس في سلسلة المحادثات، أو إذا تقبل مقبس الخادم
اتصالاً.
سيؤدي الوصول المتزامن إلى المقبس نفسه من خلال سلاسل مهام متعددة إلى استخدام أي علامة كانت للمقبس عند إرسال حزم الشبكة أو استلامها (قد يختلف ذلك عن وقت كتابة المستخدم للبيانات أو قراءتها، بسبب التخزين المؤقت وعمليات إعادة الإرسال).
على سبيل المثال، يمكنك تحديد ثوابت لتمثيل أنواع مختلفة من زيارات الشبكة، كما هو موضّح في نموذج الرمز البرمجي التالي:
Kotlin
const val USER_INITIATED = 0x1000 const val APP_INITIATED = 0x2000 const val SERVER_INITIATED = 0x3000
Java
public static final int USER_INITIATED = 0x1000; public static final int APP_INITIATED = 0x2000; public static final int SERVER_INITIATED = 0x3000;
يمكنك بعد ذلك الإشارة إلى طلبات الشبكة وفقًا لذلك:
Kotlin
TrafficStats.setThreadStatsTag(USER_INITIATED) TrafficStats.tagSocket(outputSocket) // Transfer data using socket TrafficStats.untagSocket(outputSocket)
Java
TrafficStats.setThreadStatsTag(USER_INITIATED); TrafficStats.tagSocket(outputSocket); // Transfer data using socket TrafficStats.untagSocket(outputSocket);
تُضيف مكتبة HttpURLConnection
علامات تلقائيًا إلى المقابس استنادًا إلى قيمة
TrafficStats.getThreadStatsTag()
الحالية. تُضيف المكتبة أيضًا علامات إلى مآخذ التوصيل وتزيلها عند إعادة استخدامها من خلال مجموعات
إبقاء الاتصال مفتوحًا كما هو موضّح في نموذج التعليمات البرمجية التالي:
Kotlin
class IdentifyTransferSpikeTask { @WorkerThread fun request(url: String) { TrafficStats.setThreadStatsTag(APP_INITIATED) // Make network request using HttpURLConnection.connect() ... TrafficStats.clearThreadStatsTag() } }
Java
public class IdentifyTransferSpikeTask { @WorkerThread public void request(String url) { TrafficStats.setThreadStatsTag(APP_INITIATED); // Make network request using HttpURLConnection.connect() ... TrafficStats.clearThreadStatsTag(); } }
تحليل أنواع حركة بيانات الشبكة
عند الاطلاع على حركة بيانات الشبكة الناتجة عن تطبيقك، تحتاج إلى فهم مصدر الزيارات حتى تتمكن من تحسينها بشكل مناسب. قد يكون نشاط الشبكة المتكرّر الذي يُنشئه تطبيقك مناسبًا تمامًا إذا كان يستجيب لإجراءات المستخدم، ولكنّه غير مناسب تمامًا إذا كان تطبيقك ليس في المقدّمة أو إذا كان الجهاز في جيب أو محفظة.
تحليل الزيارات التي بدأها المستخدِمون
قد يتم تجميع عدد الزيارات إلى الشبكة التي بدأها المستخدم بفعالية أثناء تنفيذ مستخدم مهام معيّنة داخل تطبيقك، أو قد يتم توزيعها بشكل غير متساوٍ عندما يطلب المستخدم معلومات إضافية يحتاج تطبيقك إلى الحصول عليها. هدفك من تحليل عدد زيارات الشبكة التي بدأها المستخدم هو البحث عن أنماط استخدام الشبكة المتكرّر بمرور الوقت ومحاولة خفض معدّل تكراره من خلال تجميع الطلبات معًا.
إنّ عدم إمكانية توقّع طلبات المستخدمين يجعل من الصعب تحسين هذا النوع من استخدام الشبكة في تطبيقك. بالإضافة إلى ذلك، يتوقّع المستخدمون تلقّي ردود سريعة عند استخدامهم للتطبيق بشكل نشط، لذا فإنّ تأخير الطلبات لتحقيق الكفاءة يمكن أن يؤدي إلى تجربة سيئة للمستخدمين. وبشكل عام، يجب إعطاء الأولوية للرد السريع للمستخدم على الاستخدام الفعّال للشبكة بينما يتفاعل المستخدم مباشرةً مع تطبيقك.
للحصول على اقتراحات لتحسين الزيارات التي بدأها المستخدم، اطّلِع على مقالة تحسين requests التي بدأها المستخدم.
تحليل عدد الزيارات التي يبدأها التطبيق
عادةً ما تكون زيارات الشبكة التي يبدأها التطبيق هي المجال الذي يمكنك فيه أن تُحدث أثرًا كبيرًا في الاستخدام الفعّال لسعة النطاق في الشبكة. عند تحليل نشاط تطبيقك على الشبكة، ابحث عن فترات عدم النشاط وحدِّد ما إذا كان يمكن زيادتها. إذا لاحظت أنّ تطبيقك يتصل بالشبكة بشكلٍ متكرّر، حاوِل تجميع هذه البيانات للسماح لجهاز البث بالعودة إلى وضع استهلاك الطاقة المنخفض بين فترات النشاط.
للحصول على اقتراحات لتحسين الزيارات التي تبدأ من التطبيق، اطّلِع على مقالة تحسين requests التي تبدأ من التطبيق.
تحليل الزيارات التي بدأها الخادم
إنّ نشاط الشبكة الذي تبدأه الخوادم التي تتواصل مع تطبيقك هو أيضًا عادةً مجال يمكنك من خلاله التأثير بشكل كبير في الاستخدام الفعال لعرض النطاق للشبكة. خدمة المراسلة عبر السحابة الإلكترونية من Firebase (FCM) هي أسلوب خفيف الوزن يُستخدَم لنقل البيانات من خادم إلى مثيل تطبيق معيّن. باستخدام ميزة "المراسلة عبر السحابة الإلكترونية من Firebase"، يمكن للخادم إرسال إشعار إلى تطبيقك قيد التشغيل على جهاز معيّن بتوفّر بيانات جديدة لهذا الجهاز.
للحصول على اقتراحات لتحسين عدد الزيارات التي يبدأها الخادم، يُرجى الاطّلاع على تحسين الطلبات التي بدأها الخادم.
استخدام Battery Historian لعرض تأثيرات عدد زيارات الشبكة
البطارية Historian هي أداة تصور استهلاك بطارية الجهاز خلال فترة زمنية. يمكنك استخدام هذه الأداة لتحليل مدى تأثير نشاطك على الشبكة في استهلاك البطارية. على سبيل المثال، يمكن أن يُظهر لك Battery Historian ما إذا كان تطبيقك يستخدم شبكة الجوّال بوتيرة أكبر مما تتوقّع. لمزيد من المعلومات حول استخدام Battery Historian، راجِع مقالة التعرّف على استخدام البطارية في الملف الشخصي باستخدام Batterystats وBattery Historian.