確かシンプル バッテリー グラフが突然駄目になった時だったと思うが、スマフォのWi-Fiの消費電力を減らせば更に電池が持つようになるかと思って測ってみたら、意外に食うことが分かった。まず、GSam Battery Monitorで、家で長時間アイドル状態での全体に対するWi-Fiの電池使用率の割合を調べてみた。約9時間で調べたところ、主な要素の使用率は以下のようになった(→ )。

  • 電池使用量(減った率): 6%/8:51 (→ 平均電力消費率: 0.68%/h)
    • 画面: 0%
    • Wi-Fi: 31%
    • アプリ: 46%

これより、Wi-Fiは平均0.21%/h、アプリは平均0.31%/hを消費していると考えられる。だから、仮にWi-Fiを常にoffにしたら、平均電力消費率は(0.68-0.21=)0.47%/hに、onの時間を半分にできたら0.58%/hになるはずだ。

Wi-Fiを停める(停めたい)状況は、以下の2とおりある。

  • 外出時: モバイルしか使われないから全くの無駄なので、Wi-Fiを(自動で)offにしたい。
  • 在宅時: 常時onだと待機(アイドル)時は無駄なので、必要な時だけonにしたい。

外出時に関して、以前はWiFi Maticという、モバイルの基地局情報で位置を判定してWi-Fiをon/offするアプリを使って、外出時は自動でoffになるようにしていたのだが、どうしてか、少し前から誤動作するようになり、家でもoffになってしまったので止めた(既に公開されていない(同名のものはあるが、別物である)ことも、止めるきっかけになった)。確かに、止めた時には外出時の電力消費率が若干増えたのを覚えている。

それで、代わりのアプリを探したのだが、どうしても僕の要望に合うものはなかった。惜しいものはいくつかあったのだが、ネットワーク位置情報(Googleに自分の位置を送る)を使うものは却下した。候補の中で良さそうだったものを以下に列挙する。

  • Smart WiFi Toggler (2015): ネットワーク位置情報を使う。
  • Wifi Toggle (per Funkzelle) (2017): 新しい基地局を手で登録しなければならない(自動学習ではない)。
  • AutoWiFiOnOff (2018): いろいろイマイチ(惜しい)。
  • WiFi Auto (open source) (2018): ネットワーク位置情報を使う。
  • WiFi Automatic (2018): 位置はGPSを使う(しかも、位置での判定は動かない)。

一番良かったのは最後のWiFi Automaticだった※が、なぜか位置での判定はできなかった(テストで結構歩いたのに無駄だったw)。ただ、仮に(他のアプリを使って)位置(基地局)で判定できても、基地局が増減するたびに誤動作する可能性があるので、位置での判定は諦め、WiFi Automaticの機能の、APの有無での判定を使うことにした。具体的には以下のような設定にした。

  • 15分ごとにWi-Fiをonにする。
  • 2分間Wi-Fi APに接続できない時、Wi-Fiをoffにする。

※(4/13 14:20) その後更にアプリを探したところ、以下の2つも良かった。あとでそれぞれの評価結果を投稿する予定である。

    • Wifi matic (2017): 最初に使っていたものと同じような名前だが、別物。
      • 機能はWiFi Automaticのサブセット的で、僕が使ううえではほぼ同じことができる。位置でのon/offはできないが、WiFi Automaticの位置判定もうまく動かないので、こちらの方が軽量そうでいい。また、ルータの情報が見えたり、動作ログが見やすいなどの点も便利。
      • 簡単に動作したところ、問題なさそうだった。
      • 下のWayfiが駄目なら、WiFi Automaticでなくこちらを使う予定。
    • Wayfi - Automatic WiFi Toggle Service (2018): 名前はサービスっぽいが、独立したアプリのようだ。
      • GPSを使うが、ネットワーク位置情報は使わなくても良く、機能が僕の要望に合っているので、消費電力が大きくなければ使いたいと思った。
      • 基本動作は概ね問題ない。
      • 外ではWi-Fiが完全にoffになり、帰宅したら即座にWi-Fiに接続されるのが気持ちいい。
      • 「外出」を模擬(「家」の位置をずらし、ルータのWi-Fiをoff)した長時間静止・アイドル時の消費電力は全く問題なかった(0.6-0.7%/h程度)。
      • 実際の外出時の消費電力を確認中(少なくはないが、いつもと同様な感じ(3%/h前後)で、すごく多くはない)。
      • 少し使ってみたら、家に居るのに、時々Wi-Fiがoffになる(すぐにはonにならず、5分くらいしないと繋がらない)。「家」の範囲を200mと大きくしても直らなかった。そうでなくても、家の近くの外に居る時も、頻繁にon/offしていたので余り気分が良くない。確かに、GPSには誤差(揺らぎ)があるし、室内だと受信状況が悪いから、本質的に良くない気がした(基地局の方がまだましだ)。それで、Wayfiは止めてWifi maticを使ってみることにした。 (4/13 20:32)

外出時に上記の処理(「Wi-Fi間欠on」と呼ぶ)をする場合としない場合(「Wi-Fi連続on」)および在宅時(Wi-Fiは連続on=常時接続)を想定した条件(実際には、いずれも家の中で測定した。「外出時」の環境は、ルータのWi-Fiを停めて実現した)での電力消費率を測定した。

以下に、外出時のWi-Fi間欠on時()と連続on時()、在宅時の連続on時()のWi-Fiの動作状況や電池残量のグラフを示す。電池残量は水色の線で、Wi-Fiの電源on/off状況は"WiFi"の左のオレンジ色の点・線で示されている。基本的に想定どおり動いている(16時以降の部分)。ただし、Wi-Fi onの間隔が指定と異なっており(約11分になっている)、アプリの不具合なのか機能の制限なのか、私が仕様を誤解しているのかも知れない。

それぞれの電力消費率は以下のようになった。

  • 外出時 (モバイルデータ通信, Wi-Fiは常に非接続)
    • Wi-Fi間欠on(on時間率: 13%): 0.53%/h以下
    • Wi-Fi連続on: 1.5%/h
  • 在宅時 (Wi-Fiは常に接続): Wi-Fi連続on: 0.53%/h以下

上で、「以下」というのは、測定時間を充分長くできなかったため、電池残量がきりのいい値にならず(残量の最小単位は1%)、1%未満の残量が切り捨てられているために、多目の電力消費率になっていることを示す。

外ではモバイルデータ通信をするためか、ほぼWi-Fiだけで通信する在宅時よりも約1%電力消費率が大きい。そして、Wi-Fi間欠onにした場合には電力消費率を約1%/h減らせて、連続onの約1/3にすることができた。これは当初の期待以上である。測定誤差などはあるだろうが、外出時の消費電力を多少下げられることが分かった。

実際には、外出時には上のテストのように何もしないで居る訳ではなく、GPSロガーを動かしたり、写真を撮ったり、地図を見たり、音楽を聴いたりする。それらの消費電力はかなり大きい(そもそも、画面点灯の消費電力ですら大きい)ので、Wi-Fiでの削減が本当に体感できるかは疑問だ。ただ、消費電力を可能な限り減らすに越したことはないだろうし、それが目的だ。

もちろん、外では基本的にWi-Fiを使わないのだから完全にoffにしたいが、上述のとおりいいアプリがない。Automagicで自分で作ろうとも思ったが、基地局のIDを見てみると、数時間ごとに3-4個が切り替わっていて、これからも新しいものが出て来そうだ。そのため、基地局が増えたら自動的に登録するようにするとしても、かなり広いエリアが「家」と見なされることになり、家の付近ではWi-Fiがoffにならなそうだ。基地局での「家」の判定と上記の間欠onを組み合わせれば良さそうだが、なかなか複雑なので保留した。

余談: 基地局で位置を判定するタイプの自動Wi-Fi on/offアプリに対して「ちゃんと動かない」と言う方が結構居るが、上記のような基地局の変化のせいではないかと思う。基地局を自動学習できるアプリはほとんどなく、最初に設定した基地局だけがずっと来る訳ではないから、そのうち「家でない」と判断されてoffになってしまうのではないだろうか。まあ、こういうことは普通は分からないから仕方ないだろう。アプリの作者ですら想定してなさそうだ(大抵のアプリは、「家」には基地局を1個しか登録できない)。

次に、在宅時の消費電力削減も可能か試してみた。基本的には、普段はWi-Fiをoffにしておき、通信する時にWi-Fiをonにすればいい(Wi-Fi APがなければ諦める)。書くとシンプルで簡単そうだが、実際にはとても難しい。WiFi Maticの代わりを探していた時にそういうのがあったのだが、その時はそれが目的でなかったので閉じてしまったら、その後、いくら探しても全然出て来なくなってしまった。僕の見間違いだったのか幻だったのか、全く不思議だ。

それで、この方式(「Wi-Fi自動on」と呼ぶ)の実用性を検討するためにAutomagicとWiFi Automaticを使ってプロトタイプを作ってみた。基本的には以下のような処理である。

  1. Wi-Fiがoffになったイベントを待つ。
  2. モバイルデータ通信が始まるのを待つ(1000バイト以上送受信されるのを待つ)。
  3. Wi-Fiをonにする。
  4. Onにしてから一定時間(6分)後、または、一定時間(2分)以内にAPに接続できない場合はoffにする。

簡単に書いたが、実装には苦労した。しかも、動かしてみると効率が悪く、消費電力を削減するどころか増えてしまった。原因は、上記2番の実装が悪くて、条件が満たされるまで延々と繰り返し待っている(ポーリングしている)からである。本当は1番のようなイベントにしたかったのだが、Automagicではできないので、とりあえずこのようにしてみた。

以下に、Wi-Fi自動on時()と連続on時()のWi-Fiの動作状況や電池残量のグラフを示す。2つを比較すると分かるように、Wi-Fi自動on時はWi-Fiは断続的に(上の間欠onと異なり、モバイル通信を契機にonになるので一定間隔ではない)onになっており、想定どおり動いていることが分かる。

ただ、電池残量(水色線)の傾きを見ると分かるように、Wi-Fi自動onでの電力消費率(1.7%/h)は連続on(0.53%/h)の3倍以上にもなってしまった。上にも書いたように、モバイル通信の状態のポーリングで常にアプリが動いているのが悪いようだ。更に、そのためにDoze(ディープスリープ)状態にもなれないようで(本方式ではDozeの線が破線になっているが、連続onではほぼ繋がっている)、消費電力が大きくなったのだろう。

それ以外に想定外のことも分かって、この方式自体がイマイチな可能性があることが分かった。それは、当たり前のことだが、通信は時間的に分散している(まとまっていない)。それまでoffになっていたWi-Fiをonにしたからといって、途端にいろいろなアプリが通信をし出すことはないのだ。そのため、Wi-Fiのon/offが頻繁になって、まとまったoffの時間ができない(実際、グラフではほとんどのWiFiの点の隙間は広くない)。それでは消費電力が低いoffの時間が稼げないうえに、onにする時に消費電力が増えるため、消費電力を削減する効果が低い。これを何とかするにはOSの対応が要る(例: アイドル時は通信をまとめる、アイドル中は各種アプリを一括して動かす: どちらも難しそうだ)。

いつものように、「やる前に気付けよ!」って話ではあるが、やってみないと分からないことはあるものだ。それに、後述のように、Googleだってやっているのだから、それほど間違ってはいないはずだ。

それから、最初から分かってはいたが、モバイルデータ通信が始まった後でWi-Fiをonするので、契機となった通信のデータは全部モバイルになる(一つの通信の途中から切り替えることはできない)ため、モバイルデータ通信量が通常の約4倍に増えてしまった(最初の通信は量が小さいだろうと思い込んでいたが、実際にはそうでもなかった)。これを解消するにもOSの対応が要る(これは容易だ)。

これに関しては、以前も書いたように、トレードオフがある。もし、モバイルデータをふんだんに使えるなら、これは全く無視していい。ただ、僕のように500MB/月というケチケチプランだとそうも行かない。この件ではいつも悪あがきしている。今回だってその一環だw

結局、現段階では「いいことなし」なのかも知れない。ただ、アイデアとしては悪くないはずだ。実際、Android 9 (Pie)にはこの機能(Wi-Fi自動on)が入っているとのことなので、それに期待したい。ただ、上記のように通信が分散したままだと、いつもonになってしまって余り効果がなさそうだ(そのためにPixel以外の8(Oreo)には入っていないのかも知れない)。まあ、どうなるか楽しみではある。

それに、そもそも、在宅時はいくらでも充電できるのだから、すごく苦労してまで消費電力を下げる必要はないことにも後から気づいたw それでPieに更新されるのを待つことにした。

という訳で一勝一敗(一敗一分?)となったが、若干にせよ、消費電力削減できた(気がする: まだ実際に使って、「お、使用可能時間が*時間も伸びた!」などとは実感できていない)ので、気分(だけ?)はいいw

 

おまけ: 今日の午後に実際に外出した時のグラフを載せる。Wi-Fiは、外出中はちゃんと間欠onになっている(今回は、指定どおりの15分間隔になっているようだ)。GPSロガーを動かしていたのでGPSも動いているし(移動中は意外に頻繁だ)、画面も点灯している。電力消費率は1.7%/hだった。いつもは3%/h前後なので少なくなった気はするが、使い方にもよるので、まだ何とも言えない。

床屋に行った時の動作状況

(4/12 8:59 わずかに加筆; 4/13 14:20, 20:32 追加アプリについて追記)

  •  1
  •  0

コメントを書く

名前    

メール 

URL