هل يستهلك VPN البطارية فعلاً؟ ما الذي ينبغي قياسه أولاً
استنزاف البطارية بعد تشغيل VPN هو عادةً تغيّر في عبء العمل. افصل تكلفة النقل عن اضطراب إعادة الاتصال وقارن المهام المتطابقة قبل تعديل الإعدادات.
استنزاف البطارية الذي يظهر بعد تشغيل VPN هو عادةً تغيّر في عبء العمل يرتدي تسمية مختلفة. نفق يبقى خاملاً، ونسخ احتياطي ليلي، وعميل يعيد الاتصال كل بضع دقائق، تستهلك كميات مختلفة جداً من الطاقة. ولا تستطيع الأيقونة في شريط الحالة أن تخبرك أيّاً من هذه تنظر إليه.
افصل النفق عمّا ينقله
النسخ الاحتياطي للصور أو مكالمة الفيديو يدفع بيانات على VPN أن يشفّرها ويصادق عليها ويمرّرها بعد ذلك. جزء من تكلفة الطاقة هذه يعود إلى التطبيق الذي أنتج حركة المرور، وجزء منها فقط يعود إلى النفق نفسه. وقراءة تقرير البطارية إلى جانب إحصاءات الشبكة والشاشة هي طريقة فصل الاثنين. ابدأ من هناك قبل أن تغيّر إعداداً واحداً.
كما تنسب تقارير المنصة العمل بطريقتها الخاصة. فقد يتضمن مكوّن مُسمّى VPN وقت راديو كان سيُستهلك على أي حال، وهو نادراً ما يعزل الحمل التشفيري بمفرده. تعامل مع النسبة المئوية كنقطة بداية لا كقياس.
adb shell dumpsys batterystats --charged com.example.vpn | head -60 adb shell dumpsys netstats detail | head -40
الأمر الأول يطبع نسبة الطاقة لكل مكوّن في دورة الشحن الأخيرة. والثاني يُظهر الواجهات التي نقلت كميات البيانات، وهذا هو السياق الذي يحوّل نسبة مئوية إلى وصف لعبء العمل. قارن الاثنين قبل استخلاص استنتاج عن النفق.
إذا سخن الجهاز أثناء النقل، فقارن العملاء أو إعدادات البروتوكول في ظروف متطابقة. إن إضعاف التشفير لمطاردة رقم طاقة يقايض تكلفة معروفة بأخرى غير معروفة.
إعادة الاتصال تُبقي الراديو مستيقظاً
شاشة تبدو خاملة لا تعني شبكة خاملة. فالرسائل والمزامنة وفحوص التحديث ما تزال ترسل حزماً، وكل تبادل صغير يمكن أن يوقظ الراديو لمدة أطول بكثير من مدة الحزمة نفسها. وهذا الفرق بين مدة الحزمة ووقت تشغيل الراديو هو المكان الذي يختبئ فيه الاستنزاف الخامل. وهو يفسّر أيضاً لماذا يمكن لنفق خامل أن يكلّف أكثر من جهاز خامل.
رسائل الإبقاء موجودة لسبب: فهي تُبقي تعيين NAT مفتوحاً أو تكشف قريناً قد اختفى. ويعود الفاصل الزمني الخاص بها إلى البروتوكول والشبكة المستخدمة. وقد يقلّل تعطيلها النشاط بينما يجعل النفق غير صالح للاستخدام بعد فترة خمول.
grep -i keepalive /etc/wireguard/wg0.conf wg show wg0 latest-handshakes
الأول يُظهر ما إذا كانت رسالة إبقاء دائمة مُهيّأة وبأي فاصل زمني. والثاني يُظهر متى حدث آخر مصافحة، وهو ما يفصل نفقاً هادئاً عن نفق يعيد بناء نفسه باستمرار.
سجل الاتصال يهم أكثر عندما يبدأ الاستنزاف بعد الانتقال بين الشبكات. وإصلاح الاستعادة المتكررة يستحق عادةً أكثر من التبديل بين مواقع الخروج، لأن العميل الذي يعيد الاتصال باستمرار ينفق الطاقة على الاستعادة لا على النقل.
عندما توقف المنصة النفق
تقيّد أنظمة التشغيل التنفيذ في الخلفية، وقد يكون نفق يختفي عند إطفاء الشاشة ضحية لتلك السياسة لا عطلاً في الخادم. ومن جهة المستخدم يبدو الاثنان متطابقين، ولهذا يهم سجل المنصة.
إعفاء كل تطبيق من إدارة الطاقة يغيّر عبء العمل ويجعل أي مقارنة لاحقة بلا معنى. أعفِ عميل VPN والتطبيق الوحيد الذي يحتاجه، ثم قِس مرة أخرى مقابل خط الأساس نفسه.
قرّر بشكل منفصل ما ينبغي أن يحدث بعد النوم. فالتشغيل الدائم، وقاعدة الحجب عند غياب VPN، وتحسين البطارية العادي تجيب عن أسئلة مختلفة، والإعداد الذي يوفّر الطاقة بإسقاط التغطية المطلوبة بصمت لم يلبِّ المتطلب الأصلي.
قارن المتماثل بالمتماثل، ثم قرّر
استخدم المهمة نفسها والشبكة نفسها والمدة نفسها في التشغيلين، وسجّل الحجم المنقول وعدد إعادات الاتصال ودرجة الحرارة وقوة الإشارة. التغيّرات القصيرة في نسبة البطارية مشوّشة، لذا فالنمط المتكرر في ظروف استخدام قابلة للمقارنة هو الدليل الوحيد الجدير بالتصرف بناءً عليه. التشغيل الواحد حكاية فردية.
انقل عمليات النقل الكبيرة الاختيارية إلى الشاحن وشبكة غير محدودة حيث يسمح الجدول. ثم انظر إلى اليوم كله مرة أخرى، لأن نفقاً يبقى خاملاً ساعات يكلّف أقل بكثير من نفق يبقى مشغولاً عشرين دقيقة.
دوّن ما غيّرته وما أظهره التشغيل الثاني. وبدون ذلك السجل تبدأ المقارنة التالية من خط أساس مختلف ويُستأنف الجدل نفسه من الصفر.