Talaga bang nauubos ng VPN ang baterya? Ano ang unang dapat sukatin

Ang pagbaba ng baterya na lumilitaw pagkatapos buksan ang VPN ay karaniwang pagbabago sa karga ng trabaho na may ibang pangalan. Isang tunnel na nakaupo lang, isang gabing backup at isang client na muling kumokonekta tuwing ilang minuto ay kumokonsumo ng ibang-iba ang dami ng enerhiya. Hindi masasabi ng icon sa status bar kung alin sa mga ito ang tinitingnan mo.

Ihiwalay ang tunnel sa dinadala nito

Ang backup ng mga larawan o video call ay nagtutulak ng data na kailangan pang i-encrypt, i-verify at ipasa ng VPN. Bahagi ng gastos na iyon sa enerhiya ay pagmamay-ari ng app na gumawa ng trapiko, at bahagi lamang ang pagmamay-ari ng tunnel mismo. Ang pagbabasa ng ulat ng baterya sa tabi ng estadistika ng network at screen ang paraan upang ihiwalay ang dalawa. Magsimula doon bago baguhin kahit isang setting.

Ang mga ulat ng platform ay nag-uukol din ng trabaho sa sarili nilang paraan. Ang isang bahagi na may label na VPN ay maaaring may kasamang oras ng radyo na gagastusin pa rin, at bihira nitong ihiwalay nang mag-isa ang dagdag na gastos sa kriptograpiya. Ituring ang porsiyento bilang panimulang punto at hindi bilang sukat.

adb shell dumpsys batterystats --charged com.example.vpn | head -60
adb shell dumpsys netstats detail | head -40

Ang unang utos ay naglilimbag ng paghahati ng enerhiya bawat bahagi para sa huling siklo ng pag-charge. Ang pangalawa ay nagpapakita kung aling mga interface ang naglipat ng gaano karaming data, at iyon ang kontekstong nagiging paglalarawan ng karga ng trabaho ang isang porsiyento. Ihambing ang dalawa bago magpasya tungkol sa tunnel.

Kung umiinit ang aparato habang naglilipat, ihambing ang mga client o setting ng protocol sa magkatulad na kondisyon. Ang pagpapahina ng kriptograpiya upang habulin ang isang numero ng enerhiya ay nagpapalit ng alam na gastos sa hindi alam.

Pinapanatili ng muling pagkonekta na gising ang radyo

Ang screen na mukhang walang ginagawa ay hindi nangangahulugang walang ginagawa ang network. Ang mga mensahe, sync at pagsusuri ng update ay nagpapadala pa rin ng mga packet, at ang bawat maliit na palitan ay maaaring gumising sa radyo nang mas matagal kaysa tagal ng packet mismo. Nasa agwat na iyon sa pagitan ng tagal ng packet at ng oras na bukas ang radyo nakakubli ang pagbaba sa panahon ng pahinga. Ipinapaliwanag din nito kung bakit ang isang tunnel na walang ginagawa ay maaari pa ring gumastos nang higit sa isang aparatong walang ginagawa.

May dahilan ang keepalive: pinapanatili nitong bukas ang isang NAT mapping o natutukoy ang isang kapareha na umalis. Ang pagitan nito ay kabilang sa protocol at sa network na ginagamit. Ang pag-off nito ay maaaring magbawas ng aktibidad, ngunit ginagawang hindi magamit ang tunnel pagkatapos ng panahon ng pahinga.

grep -i keepalive /etc/wireguard/wg0.conf
wg show wg0 latest-handshakes

Ipinapakita ng una kung may naka-configure na permanenteng keepalive at sa anong pagitan. Ipinapakita ng pangalawa kung kailan nangyari ang huling handshake, na naghihiwalay sa isang tahimik na tunnel mula sa isa na patuloy na nagtatayo ng sarili.

Ang kasaysayan ng koneksyon ay pinakamahalaga kapag nagsimula ang pagbaba pagkatapos lumipat sa pagitan ng mga network. Ang pag-aayos ng paulit-ulit na pagbawi ay karaniwang mas sulit kaysa sa pagpapalit ng mga lokasyon ng labasan, dahil ang client na patuloy na muling kumokonekta ay gumagastos ng enerhiya sa pagbawi at hindi sa paglilipat.

Kapag sinuspinde ng platform ang tunnel

Nililimitahan ng mga operating system ang pagpapatakbo sa background, at ang isang tunnel na nawawala kapag naka-off ang screen ay maaaring biktima ng patakarang iyon at hindi ng sira ng server. Sa panig ng gumagamit, magkamukha ang dalawa, kaya mahalaga ang log ng platform.

Ang pagbibigay ng exemption sa bawat app mula sa pamamahala ng enerhiya ay nagbabago sa karga ng trabaho at ginagawang walang saysay ang anumang susunod na paghahambing. Bigyan ng exemption ang VPN client at ang nag-iisang app na nangangailangan nito, pagkatapos ay sukatin muli laban sa parehong baseline.

Magpasya nang hiwalay kung ano ang dapat mangyari pagkatapos ng pagtulog. Ang laging-naka-on na operasyon, ang patakaran ng pagharang nang walang VPN at ang ordinaryong optimisasyon ng baterya ay sumasagot sa magkaibang tanong, at ang isang setting na nagtitipid ng enerhiya sa pamamagitan ng tahimik na pagtatapon ng kinakailangang saklaw ay hindi natupad ang orihinal na pangangailangan.

Ihambing ang magkatulad sa magkatulad, pagkatapos ay magpasya

Gamitin ang parehong gawain, parehong network at parehong tagal sa dalawang pagsukat, at itala ang dami ng nailipat, bilang ng mga muling pagkonekta, temperatura at lakas ng signal. Ang maiikling pagbabago sa porsiyento ng baterya ay maingay, kaya ang paulit-ulit na pattern sa maihahambing na paggamit ang tanging ebidensiyang sulit kilosan. Ang isang pagsukat ay isang anekdota.

Ilipat ang opsyonal na malalaking paglilipat sa charger at sa network na walang limitasyon kung pinapayagan ng iskedyul. Pagkatapos ay tingnan muli ang buong araw, dahil ang tunnel na walang ginagawa nang maraming oras ay mas mura nang malaki kaysa sa isang abala nang dalawampung minuto.

Isulat kung ano ang binago mo at ano ang ipinakita ng ikalawang pagsukat. Kung wala ang talaan na iyon, ang susunod na paghahambing ay magsisimula sa ibang baseline at ang parehong pagtatalo ay magsisimula muli sa zero.