Archive for the ‘Android’ Category

先日からの、Wi-Fiに接続できる環境でもモバイルデータが使われる問題への対処の続きのまとめを書いていたら、新しいアイデアが浮かんで、それがうまく行ったので書く。前半はそのアイデアが浮かぶ前に書いていたものを加筆・修正したもので、後半がそのアイデアと結果である(前半を飛ばしたい場合はここ)。

ディープスリープ回避による同期間隔の改善

当初は、Automagicで定期的にカレンダーなどの特定アプリの同期を行うようにし、その時にWi-Fiが切れていたら再接続するようにしていた。ただ、システムがディープスリープする(Dozeモードになる)のか、アイドル時間が長くなると、Automagicでの同期間隔が(設定は30分なのに)3時間前後に伸びる傾向にあった。それは消費電力の削減には効くので諦めようとした。とは言え、やっぱり、できれば同期間隔が伸び過ぎないようにしたくなった。ただ、前回も書いたように、消費電力削減と定期的な同期間隔とモバイルデータ量の削減は相反するので、うまく共存させる必要がある。

それまでに分かった問題点は、

  1. ディープスリープ(Dozeモード)のために同期間隔が伸びる。
  2. 要求した同期の実行が遅れることがある。(同期の実行遅れ)

なので、それらを解消(軽減)できればいいと考えた。

それで、同期間隔が長くなり過ぎることを改善するためのポイントは、スマフォを「寝させ過ぎない」(ディープスリープさせ過ぎない)ことだろうと考えた。ディープスリープし過ぎると同期間隔が伸び、更に、Wi-Fiが切れる(offになる)可能性も高くなって、モバイルデータ量も増えてしまう。一方で、全然ディープスリープしなかったら消費電力が増えてしまう。だから、Androidを「適度に突っついて」、目を覚まさせればうまく行きそうな気がした。

いろいろ試したのだが、前回気付いた「ディープスリープを回避する方法」をヒントにしたら、結構うまく行った感じだ。そのアイデアは以下である。

Periodic Timer(オプション= "Like alarm clock")をセットすると、ディープスリープにならなくなるが、セットしたままだと消費電力が増えてしまう。そこで、短時間だけPeriodic Timerをセットして解除すれば、消費電力はそれほど増えないのではないか。

これにより、上記の2つの問題が改善できることを期待した。1番は、定期的にディープスリープにならない状態を作ることで、ほとんどの同期間隔を支配しているPeriodic Timer Inexactの精度が向上することを(この間にPeriodic Timer Inexactが「動き出す」ことを期待する)、2番は、ディープスリープにならない状態を作ることでAndroid内部に溜まっている同期要求が実行(flush)されることを、それぞれ期待した。それで、以下のようなPeriodic Timerの設定で試してみた。

  • Periodic Timerの周期(= ディープスリープにしない時間): 2分
  • Periodic Timerを解除するまでの待ち時間: 30秒

理論的には、Periodic Timerのイベントが起こったらすぐに解除してもいいはずだが、解除する前に何かの処理を入れたほうがいいかと考えて、少し待ち時間を入れた(後で分かったが、待ち時間は要るようだ)。

すると、1番(同期間隔)については効果があったが、意外なことに、2番(同期の実行遅れ)にはほとんど効果がなかった。ディープスリープにしない時間が短かかったのかも知れないし、他の要因があるのかも知れないと思っていたのだが、その後、要求を溜めているのは、OSでなく同期アプリ自体なのかも知れない(同期アプリがスリープしていたら、要求を受けても実行できないのだろう)と考え、同期アプリがスリープしないように、「電池の最適化」をoffにして試したら、同期の実行遅れもなくなった。

基本的な処理の流れは以下である。

  1. 同期の契機となるイベント(例: Periodic Timer Inexact)を待つ。
  2. 同期する時期(例: 前回の同期から30分以上経過)だったら以下を行う。
    1. ディープスリープ回避処理を有効にする(= Periodic Timerを起動する)。 → ディープスリープの回避が始まり、Periodic Timerの周期の経過後に解除される。
    2. 同期処理を行う(基本的には前回書いたのと同じ内容)。

本当は本体のプログラム中でPeriodic Timerの作成や起動をしたかったのだが、Automagicに適当な機能はなかったので(アラームやタイマーなどは可能だが、本当にアラームが設定されて音が鳴ったりするので、実用には向かない)、別のプログラムにした。もしかしたら、ディープスリープ回避処理で行っているスリープ(オプション= "Keep device awake")をするだけでもいいのかも知れないが、確かではない(Periodic Timerには"Like alarm clock"オプションが必要なので、たぶん駄目だと思う)。

ディープスリープ回避処理は以下である。

  1. Periodic Timer(周期= 1分, オプション= "Like alarm clock")のイベントを待つ。
  2. 以下を並行して行う。
    1. 一定時間(30秒間)Sleepする(オプション= "Wake up from idle/doze": Doze(ディープスリープ)状態から復帰させる)。
    2. 一定時間(35秒間)Sleepする(オプション= "Keep device awake": この間はディープスリープさせない)。
  3. 自分を無効にする(= Periodic Timerを無効にする)。

2種類のSleepは、Sleepの2種類のオプションのうちどちらがディープスリープの回避に効果的なのか分からなかったので、念のため両方入れた(Periodic Timerによってディープスリープは既に回避されているのだから、おそらく後者だけで充分だと思うし、なくてもいいかも知れない)。

上記の仕組みを実装し、試してみたところ、管理しているアプリが同期する時にWi-Fiが切れていても確実に接続できるようになり、なかなか良い結果が得られた。要するに、僕の要求のほとんどを満たし、期待以上の効果が得られた。ただ、このプログラムとサーバのログやモバイルデータ通信の状態や使い勝手をチェックしていたら、以下の問題が見付かった。

Wi-Fiが切れている間にこの仕組みが管理していないアプリ(= 外部から同期開始できないもの。例: AquaMailやGoogle Play)やOSの通信が始まった場合は、モバイルが使われてしまう。

特に、AquaMail(メールアプリ)はデータ量が多いうえに外部から同期を開始させられないのでモバイルデータ量が増える要因なので、外部からの同期が可能なBlueMail(= TypeApp)に換えたのだが、使い勝手や好みではAquaMailの方が良い。

Wi-Fi接続のモニタリングと自動(強制)再接続

それで思い付いたのは、同期する仕組みの中の、「Wi-Fiが切れていたら再接続する」処理だけを定期的に実行することである。本来、Wi-Fiの再接続はOSが自動的に行うから自分でする必要はないのだが、ディープスリープ中はそれが結構長く遅れることがあり、その間に通信が発生するとモバイルが使われるので、それを回避するため、切断後なるべく速やかに再接続したい。AutomagicはWi-Fiの切断イベント(WiFi Disconnected)を受けられるので、それを契機にすれば切断後即座に接続できそうだ。また、何らかの理由(例: 帰宅時、ディープスリープ中)でWiFi Disconnectedがない・受け損ねた場合に備えて、定期的なチェックも行う。

基本的な処理の流れは以下である。

  1. 契機となるイベント(例: WiFi Disconnected, Periodic Timer Inexact)を待つ。
  2. 再接続処理を行う時期(例: 前回の処理から30分以上経過)だったら、以下を行う。
    • Wi-Fiを使用する設定になっていて、Wi-Fiが切れていて(WiFi Connectedが偽)、
      • 指定のAP(= 家のルータ)が利用可能(WiFi Available)なら、再接続(WiFi Reassociate)を行う。
      • イベントがWi-Fiの切断(WiFi Disconnected)で、指定のAPが利用可能でないなら、Wi-Fi APのスキャン(WiFi Scan)を行う。
      • イベントがWi-Fi APのスキャン結果(WiFi Scan Results Available)で、結果(AP一覧)が空の場合には、再接続(WiFi Reassociate)を行う※。
  3. ディープスリープ回避を行う時期(例: 前回の回避から30分以上経過)だったら、以下を行う。
    • ディープスリープ回避プログラムを起動する(実際にはプログラムを「有効」にすることでPeriodic Timerが起動され、ディープスリープの回避が始まる)。

※ 下にも書いたが、Wi-Fi APがあるにも関わらずWiFi Scanの結果が空の場合があり、その時に切断されたままの状態が長引いてしまうため、スキャン結果が空の場合にも再接続してみるようにした。ただ、画面を点灯すると自動的にスキャンが行われるようなので、外出時に無駄に再接続しようとして消費電力を増やす可能性はある。

実装後、さまざまな調整を行い、最終的には以下のような設定(動作条件)にした。

  • 処理の契機とするイベント
    • Periodic Timer Inexact, WiFi Disconnected, WiFi Scan Results Available, WiFi State Enabled, Automagic Startup
  • 再接続処理を行う最小間隔: 10分 (Periodic Timer InexactとAutomagic Startupのみ。それ以外は無条件に実行する)
  • Periodic Timer Inexactの周期: 15分
  • ディープスリープを回避する間隔: 30分
  • ディープスリープの回避
    • Periodic Timerの周期(= ディープスリープにしない時間): 1分
    • Periodic Timerを解除するまでの待ち時間(Sleep(Keep device awake)): 35秒

Periodic Timer Inexactの周期やディープスリープ回避の間隔を長くすると消費電力が減るが、切断時(Wi-Fiの鍵の期限切れなどで起こる)や帰宅時に再接続するまでの時間が長くなる可能性が高い。また、Periodic Timerを解除するまでの待ち時間は必要で、ないとディープスリープしてWi-Fiが切れてしまう。

当初は、基地局(セル)への接続イベント(Phone Cell GSM: Connected to CIDs)を使って帰宅の判定をしようとしたのだが、基地局の範囲は広いために家から離れたところ(Wi-Fiは繋がらない)で「帰宅」と判定してしまうのと、基地局の変化(増減)を常にフォローすることはできないから、いつまで今の判定条件が有効なのか分からないので止めた。

それから、画面を点灯させるとWi-Fiのスキャンが行われてWiFi Scan Results Availableイベントが発生するから、その時はPeriodic Timer Inexactの周期を待たずに素早く再接続できる(実際には、この場合はOSも再接続すると思われる)。

なお、同期間隔が伸びるのを防ぐために無効にしていた、カレンダー同期アプリの「電池の最適化」は有効に戻した。ディープスリープ回避の効果のようだ。

最終的な性能(特性)は以下のようになり、概ね要求を満たせたように思う。

Wi-Fiが利用可能な場所(家)で、約7時間(2/25 21:13 - 2/26 4:17)のアイドル時の性能:

  • 消費電力率: 0.6%/h (2/26 1:50までは0.4%/h)
  • モバイルデータの使用量(← Wi-Fiの再接続が遅れた期間): 約60KB (Wi-Fiの使用量: 約3MB)
  • Wi-Fiの再接続が遅れた回数: 3回 (再接続回数: 4回)
  • カレンダーの平均同期間隔: 約32分 (13回/7時間)

ディープスリープ回避処理により、Wi-Fiが長時間停まることはなくなったようだが、Wi-Fiの鍵の期限切れの時の再接続が数十秒遅れることがあるために※、モバイルデータが使われるのを完全には防げてはいない。ただ、OSを含むすべてのアプリからの通信をほぼWi-Fiにすることができたので、前回よりはモバイルデータ量が減ったはずだ。消費電力は以前より大きくなっているが*、低い期間もあるので他の要因が関係しているのではないかと思う。この点はもう少し様子を見たい。また、同期間隔は申し分ない。

※ Wi-Fiの再接続が遅れることがある問題の詳細な原因は不明なのだが、その時はWi-Fi APのスキャン(WiFi Scan)を行ってもAP一覧が空になっているので、スマフォ(AQUOS sense lite)の仕様(作り)に起因するものではないかと思っている。OSはWi-Fiデバイスは使える状態(「生きている」)だと思って使おうとするのだが、実際にはスマフォが停めていて、使われる時に陰で起動させるのだが、その立ち上がりに時間が掛かるために、最初のスキャンで結果が得られないのではないかと推測している。あるいは、Wi-Fiデバイスの立ち上がりが遅く、OSはそれを待ちきれなくて、モバイルが使われるのかも知れない。

* 消費電力増加の影響を考えてみる。: アイドル状態を継続(使わずに放置)できる時間を考えると、今回の消費電力率(0.6%/h)では前回(最小で0.3%/h)より約7日短くなる。が、実際にはそういう状況はなく、毎日使って充電しているので、その値は余り意味がない。それで、1日当たりの消費電力の差を求めると7.2%程度となる。そして、当然ながら、使っている時の消費電力はそれよりずっと大きい(数十%)ので、この処理による消費電力の増加はそれほど問題ではなさそうだ(と思ったが、通常は1日で20%くらいしか減らないから、7.2%の増加は大きいかも知れない)。

この作業はなかなか根気が要り、動作確認すると不具合が見付かって調整し、再度確認するという手順を何度も繰り返していた。動作確認は深夜などの長時間使わない時に放置することでしかできないので、なかなか時間が掛かり、3週間くらい掛かったが、ようやく終わったようだ(消費電力と再接続の遅れに我慢すればね・・・w)。

わずかなモバイルデータ使用量や電池使用量を減らすだけの、重箱の隅をつつくような改良ではあるのだが、Androidのいろいろなことが分かって(大体は想像)おもしろかった。それから、Automagicを使えば(いくつか不満はあるものの)ものすごくいろいろなことができるので、感心した。結構昔に買ったのだが、全く損はない。

(3/1 6:51) 月が変わったので、モバイルデータ使用量削減処理の効果を調べてみた。削減処理の作成を始めたのは大体2月からなので、1月と2月のモバイルデータ量を比較すれば分かりそうだ。

  • 1月: 134MB → 4.3MB/日
  • 2月: 81.8MB → 2.9MB/日

見かけ上は1日約1.4MBの節約となった。ただし、1月には設定誤りによるカレンダーの再取得や地図アプリ比較のための利用があったので、その分が多くなっているはずだから、過去のログからそれらのデータ量(カレンダー: 約16MB、地図: 11.8(1月分)-2.7(2月分)= 9.1MB)を引くと、以下のようになる。

  • 1月: 109MB → 3.5MB/日
  • 2月: 81.8MB → 2.9MB/日

1日600KB(27MB/月)の節約と、効果はかなり微妙(気分の問題??)だ。ただ、データ量削減処理は2月の半ば頃から動き出したし、処理の作成や修正による増分もありそうなので、今月の分を見てみないと本当の効果は分からない。ただ、劇的に減ることはなさそうだ。

それでも、現在のモバイルデータの残量は1GB(契約は500MB)になっているので、まあ、全体としては目論見どおりである(良く考えると、繰り越しできるのは前月分だけだと思っていたが、そうではない? それならなおありがたいが・・・)。

 

PS. この作業中に他の問題も見付かったので、書いておく。

○同期アプリごとの問題

  1. 同期が不安定なもの: Androidの再起動後にカレンダーの予定がほとんどなくなって、同期がうまく行かなくなった。
  2. 同期のデータ量が多いもの: 同期は調子いいのだが、常に数十KB(上の約10倍)のデータを取得する。取得するデータの選択がインテリジェントでない?

不安定なのは良くないのだが、最初だけ何とかすればあとはうまく動くから、データ量を減らしたいので、1番を使うことにした。

○Wi-Fi matic(位置に基づいて自動的にW-Fiを有効・無効にするアプリ)の問題

なぜか、Wi-Fiを有効にする場所なのに無効にされてしまうことがある。有効・無効はモバイルの基地局(セル)で判定しているのだが、家に居ても基地局がたまに変わる(3つくらいあった)のに、1つしか記憶しないために無効にしてしまうようだ。元々なのか、設定を変えてしまったせいだろうか? しかも、このアプリはGoogle Playからなくなってしまっているので、使い続けるのは好ましくない。Wi-Fi maticは家以外に居る時(外出時)の消費電力を減らすために使っているのだが、とりあえず、使うのを止めることにした。

それから、複数の基地局に対応したWi-Fi maticの代わりを作ろうとしたのだが、難しかったので止めて、常にWi-Fiを有効にしたままにすることにした。問題になるのは、外出時に無駄にWi-Fiが有効であるために消費電力が増えることだが、外出時は操作やモバイルデータの消費電力の方が大きいので、大きな問題ではなさそうだ。

PS2. この、Wi-Fiが途切れる(勝手にoffになる、再接続が遅れる)現象は僕のスマフォ・環境(ルータとの相性)だけで起こるのか、それともAndroidなら他でも起こるのか気になるところだ。何となく前者の気はするが、実は後者だけど、細かい話だから誰も気にしていないのかも知れない。

PS3. モバイルのデータ残量を見たら、月末だというのに690MB(→ 先月の繰り越し分が190MB余った)も余っている。繰り越しできるのは1か月だろうから、節約し過ぎても意味がないのかも知れない。であれば、多少の接続遅延を許して(= Wi-Fi時でも少しモバイルが使われる)省電力に振る方が得策なのか? 「そんなのどっちでもいい」というのが真実のような気はするがw、まあ、ちょっと考えてみよう。

という具合に、"Never ending story"になる。。。 (2/27 18:58)

  •   0
  •   0

ドラレコの設置場所に迷った。フロントガラス上部よりダッシュボードの上の方が手軽そうでいいと思っているのだが、下部が良く映らないという情報があった。考えても分からないので、買って試そうと思っていたのだが、まず今(無料で)できることをやってみようと、段ボールで台を作り、ダッシュボードに古いスマフォ(Nexus 4)を仮置きして、どのくらいの視野で撮影できるか試してみた。もちろん、実際のドラレコとは視野角は違うだろうが、下部の切れ方は設置する高さや角度の影響の方が大きいと思うので、実際(予定)に近く設置すればスマフォでも確認はできると思った。

設置時に、作ったままでは高過ぎる気がしたので、下の箱を外した(実はこの箱は、「高さが足りないかも」と思って後から追加したものだ)。

意外にちゃんと撮影できていて、観てみたら予想以上に良く、視野はまず問題なさそうだった。写りも良くて、途中で観た時は「これでいいじゃん!」と思い掛けたのだが、帰ってから調べたらものすごく電池を食っていた(約35%/h)ので驚いた。これでは3時間も持たない。まあ、アプリ(今回はアウトガードというのを使った)や設定を選べば減るかも知れないし、SIMを入れていないために、例の「セルスタンバイ」も電池を食っていたから、ダミーのSIMを入れれば減るかも知れない。それに、常時USBから給電すれば、電源は問題はないだろう(が、電池はすぐに寿命になりそうだ)。

それでも、何となく無理があって実用には向かない気はする。あと、スマフォが大きくて若干目障りな問題もあった。その点では外部カメラが使えればいいが、USB 2.0でまともに動画が転送できるかとか、OSやアプリが対応しているかどうかが疑問だ・・・ それから、後方が撮影できないという欠点もある(スマフォを2台使えばできないことはない。確かに2台余ってはいるけど・・・)。

以下に、市街地での撮影例を示す。

※エンジンや排気の音が結構迫力あるのだが、元々そういう車(改造はしていない)なのと、構図やマイクなどのせいで更に迫力が出ているのだと思う。暴走している訳ではないので、誤解せぬよう・・・

サンプルは再エンコードしたためにぼやけているが、元の動画は以下のようにかなり鮮明で、(縮小しても)他車のナンバーがはっきり読める。

スマフォドラレコで撮影した動画のキャプチャ

それから、やる前は、カメラの固定をかなりちゃんとしないとブレて駄目だと思っていたのだが、こんないい加減な台(若干傾いてさえいる)でもそれなりに見えるし、そもそも、僕が使いたいのは事故などの問題のあった時だけなので、多少振動しても問題ないことに気付いた。ただ、衝撃でカメラが動いてしまったら、肝心の場面が映らない可能性もあるので、それなりにしっかり固定する必要はあるだろう。

あと、スマフォなら、部屋に持ち帰れば簡単にドライブ中の映像をPCに取り込めるのもいい。ドラレコだといちいちmicro SDを抜くのが面倒だから、問題のあった時だけ使うことを想定していたが、手軽にできるのなら欲も出て来る。なお、動画ファイルのサイズは意外に小さかった。5分で200MB以下だった(いや、これは実は1時間で2GBを超えるから、大きいのだw)。

という訳で、試してみたらいろいろなことが分かった。そして、スマフォドラレコの手軽さ・安さも捨てがたいので、もう少し考えてみたい。

以下のように進めようと思う。 (16:27)

  1. 夜の撮影具合を試す。
    • (2/25 5:36) アウトガードの消費電力が大きかったのでAutoBoy Dash Camを試してみた。
      • まれに焦点がボケた以外は、大きな問題はなかった
      • 電力消費率は約10%/hだった。
      • 今回はダミーSIMを入れていたので、再度、アウトガードの電力消費率を測りたい。
      • スマフォドラレコでの撮影例3 (夜間, アプリ: AutoBoy Dash Cam)
  2. 良さそうなら、ドラレコにも使えそうなスタンドを買い、スマフォを正式に設置して使ってみる。
    • 良さそうなら、外付けのカメラ(webカメラ?)を付けてみる。(ただし、いいものは結構高いので、要検討)
  3. 駄目そうなら、本物のドラレコを買って取り付ける。

(2/25 9:46) 今、別のアプリを試に行こうかと思っていたら、根本的なことに気付いた。スマフォドラレコは確かに手軽だが、本物同様の信頼性は望めないということに。例えば、以下のような問題で正常に動作しなくなる可能性は結構大きいから、「いざという時に記録されていなかった」ということはあり得る。ドライブの記録ならがっかりするだけだからいいが、事故などの証拠用としては論外である。

  • 夏の高温、冬の寒さ、結露
  • 連続書き込みでのストレージの劣化
  • 電池寿命
  • アプリやOSのハングなど

そのような問題を防ぐには、定期的に(毎回?)正常動作を確認するべきのだろうが、それは現実的でない。忘れなければやるかも知れないが、そもそも面倒だ。本物でも原則的には動作確認は要るが、スマフォはより信頼性は高そうだから、確認の必要性は低いことが期待できる。定期的なmicro SDの交換を忘れず、使用時は警告が出なければ正常動作が期待できる。

という訳で、やっぱり本物をポチっとするかな・・・

いろいろ試したのが無駄になった気はするが、そもそも、スマフォドラレコは「本物」の設置方法を検討するために始めたのだから、こういう結論になっても無駄ではなかったのだ。まあ、プロトタイプとか実証実験のようなものだったのだ。それで設置方法だけでなく、実際に使う時に外せない条件に気付けたのだから、本当に成功と言えよう(と、自画自賛してみるw)。

 

PS. テストで走っているだけでも気持ちが良くて、気付いたら1時間半、30kmくらい走っていた。

PS2. さすがにNexus 4は古いせいか(2013年に購入)、側面のゴムのような部分が劣化してベタベタになっていた。最初はケースが劣化したのかと思っていたのだが、本体まで劣化していた。ケースは貼り薬(例: トクホン)のような臭いまで出していた。。。 まあ、これなら心置きなく使い倒せるw

PS3. ダミーのSIMは、iPhone 6sを買った時に、本物のSIMが届くのが待ち切れなくて、すぐアクティベートしたくて買った未契約のものがあったのだが、サイズが違っていた(Nexusはmicro, iPhoneはnano)。ただ、セロハンテープでうまく誤魔化したらなんとか認識した。位置合わせと接触をちゃんとする以外に、挿入する前か後に一旦電源を切る必要があるようだ。これでセルスタンバイの消費電力は減るだろうか? (何となく、関係ない気がする・・・)

PS4. Nexusよりは新しいiPhone 6sも余っているから、ドラレコアプリを探したのだが、検索しても無料でまともなものがなさそうなうえに、App Storeは(昔からそうだが、)webでは全く使いものにならないので、呆れ果てて使う気が失せた。まったく、煮ても焼いても食えない腐った林檎だ。まだ人気はあるようなイメージだが、開発者は段々逃げつつあるのかも知れない。

(3/10 20:53 動画のサイズがかなり大きい(3個で25MB)ことに気付いたので、リンクに変更)

  •   0
  •   0

モバイル通信のデータ量の節約には余念がないのだが、通信データ量を調べていたら、思わぬことが分かった。前にも書いたが、家に居るのにWi-Fiでなくモバイルが使われることがある(以下、「家でもモバイル問題」)のだ。それで、それを何とかしたいと思って試行錯誤していたら、僕の要求が相反していて、同時に全部は満足できないことに気付いた。要求を以下に示す。

  • 電池消費率を削減する。
  • モバイル通信のデータ使用量を削減する。
  • (スケジュールなどの)同期を可能な限り定期的にする。

全部を満足させるのは無理で、どれを優先すべきなのか、それぞれをどういうふうに配分するのかの「さじ加減」が難しい。どれが一番重要かはいつも変わるのだが、(とりあえず今は)電池だということになった。その次はデータ量だ(上のリストの順に優先度が高い)。

その方針で、「家でもモバイル問題」に対処した。予想以上に大掛かりになり、うまく動くまでには結構(1週間くらい)時間が掛かった。以下に内容を示す。

現象

接続可能なWi-Fiルータがあっても、モバイルデータが使われてしまうことがある。

原因

Androidのディープスリープ(Dozeモード)に関係しているようだ(他に、アプリごとのディープスリープ"App standby"というのもあるらしい: 参考)。Androidのディープスリープ中はWi-Fi機能が停まり※、何かのアプリが通信する時に自動で再接続されるようなのだが、再接続が遅い(間に合わなかった?)場合にモバイルが使われるようだ。

※Wi-Fi機能の停止以外に、Wi-Fiの鍵の期限切れによる切断もある。

対処

基本的には、通信する時にWi-Fiが接続されていなかったら接続するようにすればいい。が、Androidにはそんな機能はないし(そうしているつもりなのだろうが、抜けがあるのか、「少しくらい(のモバイル)は大目に見て」いるから、この問題が起こっている)、調整するアプリもなさそう(調べてはいない)なので、Androidのグラフィカルなプログラミング言語Automagicでスクリプトを作った。ただ、Automagicではアプリの通信要求を検知することはできないし、その通信を保留することもできないので、以下のようにした。

注: 以下は私のスマフォ・OS・環境(AQUOS sense lite, Android 8)での確認結果に基づいており、すべての場合で同じであるとは言えない(スマフォのHW・ファームやOSが違えば、動作は異なる可能性が高い)。また、私はAndroidに関して詳しく調べた訳ではなく、Automagicのマニュアルの記述と実際の動作から推測したので、Androidの公式の仕様とは異なる可能性がある。以下で用いている単語(例: "Request Sync")はAutomagicで使われているものだが、Andoridでも同じかは不明である。

準備

Wi-Fiが停まっている時にも通信(同期)しそうなアプリ(例: メール、カレンダー、アドレス帳、Evernote)の設定を、自動で同期しないように変える(例: バックグラウンドデータや自動同期・受信をoffにする)。

注: Androidの、アプリに外部から同期要求を出す機能(Request Sync)を使うため、それに対応するアプリでしか対処できない。

定期同期処理

Automagicで以下の処理を実行する。

  1. なるべく頻繁に、かつ、ディープスリープ中も発生しそうな、しかも消費電力が少ないイベントを待ち受ける。
  2. イベント発生時に以下を実行する。
    1. 前回の処理からの経過時間が最小同期間隔(例: 30分)より短かったら、何もしない。
    2. Wi-Fiが有効な状態で、APに接続されていなかったら、再接続(WiFi Reassociate)する。
    3. Wi-Fiが使用可能(Active Network Type= WiFi)になるまで待つ。
      • Wi-Fiが無効だったり接続できなかったり使用可能にならなかったら諦める(→ モバイルが使われる)。
    4. 対象のアプリに同期の要求(Request Sync)を出す。

リストで書くとシンプルなのだが、Automagicはプログラムを図で描くのと、デバッグ用の機能を入れたため、実際のプログラムは大規模になった。普通の言語のようにテキストで書くならそうでもないが、図(しかもスマフォの画面でいじる)だとデバッグや保守がなかなか困難だ。。。 ただ、並行処理がたやすく書ける・実現できるのは、とても楽でいい感じだった。

Automagicでの定期同期実行+Wi-Fi再接続プログラム (概観)

以下に設定や条件などを書く。

対象のアプリは以下とした。通信状況の調査結果から、最も通信頻度・量が多そうで、外部から同期できるものを選んだ。

  • メール(TypeApp): それまで使っていたAquaMailは外部から同期できないので換えた。いくつか試したうちでは一番良かった。 : TypeAppが原因の確証はないが、先ほどセキュリティ上の問題(GoogleのID・パスワード漏洩の可能性)が起こったので、使うのを止めた。AquaMailに戻し、この機能での同期は諦めることにした。詳細は追って書く予定。 (16:18) ← いろいろ調べたが、原因はTypeAppではなさそうだ。というのは、TypeAppにはGoogleのパスワードを入れていないからだ。余りにもタイミングが良かったので、誤解した。まとまったら書く。ただ、別件でも怖くなったので、TypeAppは止めることにした。 (21時) → 詳細をPS2に書いた。 (2/5 13:34)
  • Evernote
  • カレンダー同期アプリ
  • アドレス帳同期アプリ

待ち受けるイベントは以下にした。

  • Periodic Timer Inexact (定期的な(ただし正確でない)タイマー)
  • Display State: On (画面が点灯したら)
  • Notification on Statusbar (ステータスバーに通知が出たら)
  • WiFi State: Enabled (Wi-Fiがonになったら: 帰宅時にWi-Fi Maticがonにした場合に起こる)
  • WiFi Connected (Wi-Fiが接続されたら)
  • Phone Cell GSM: On every cell change (モバイルの基地局が変わったら)
  • Periodic Location Update (30min) (位置が変わったら: 注: 消費電力を増やさないため、GPSでなくNetworkのみを使う)
  • Calendar Event (予定の通知が出たら)
  • Automagic startup (Automagicの起動時)

基本的にはPeriodic Timer Inexactで同期間隔を実現するのだが、ディープスリープ中には間隔が長くなってしまう(例: 2時間)。そこで、なるべく同期間隔を正確にするため、ディープスリープ中も発生しそうなものを追加したので多くなった。が、実際にはPeriodic Timer InexactとDisplay Stateが同期の契機になることが多い。他のものはディープスリープ中にはほとんど発生しない感じだ。

同期間隔は30分としたが、アドレス帳はあまり変化しないので6時間にした。この間隔の種類を増やしてそれに対応する処理を追加すれば、アプリごとに間隔を変えることができるし、細かい処理を調整することもできる(ただし、プログラムは更に複雑になる)。

それから、Periodic Timer Inexactは発生間隔がアバウトなので、ある程度早目にイベントが起こった場合でも処理するようにした。

プログラムは概ねできて、今は動作確認・調整中である。なお、上にも書いたように、Periodic Timer Inexactはディープスリープ中は発生間隔がかなり長くなるため、同期間隔も長くなってしまう。これを解消できる方法も見つけた(下記「簡単にディープスリープを回避する方法」)のだが、消費電力が若干増えるので採用を見送った。これが、最初に書いたさじ加減の難しさの一つである。

ただ、実際に使う場面を考えると、家ではほぼPCしか使わないので、スマフォの通知が出なくても問題はないし、外では頻繁にスマフォを開くので、そのたびに同期が行われる可能性があるから、大きな問題ではなさそうだ。ちょっとした問題は、寝る前に作った予定や夜中に来たメールが朝になっても同期・受信されていない可能性があり、それに気付いて気分が悪くなる程度である。

以下、この過程で見つけた問題などについて書く。

通信遅延問題

ディープスリープの関係なのか、上記プログラムのログに書かれた同期時刻より遅れて実際の同期(通信)が行われることがある(サーバのログと比較して分かった)。呼び出す方(Automagic)からは同期処理が実行されたように見えているのだが、実際にはどこかに貯められていて、あとでまとめて実行されるような感じだ(→ 参考)。左の参考ページによれば、回避策はGCMを使うことらしい(が、それは廃止になり、FCMに移行すべきのようだ)。。。 いずれにしても、クライアントプログラムが非互換なので、そのままでは使えない。

簡単にディープスリープを回避する方法

今まではどうしてもディープスリープを回避できなかったのだが、偶然、方法が分かった。Periodic timer (Like alarm clock)を設定れば良い※。間隔は、例えば1時間でも2時間でも大丈夫だった。ただ、ステータスバーやロック画面にマークやアラーム時刻が表示されるので、紛らわしいし鬱陶しい。

※これはAutomagicだから可能なのか、Android全般に有効なのかは分からない。時計アプリにアラームを設定すれば確認できそうではある。

これより、Periodic timer (Like alarm clock)を待ち受けるイベントに追加すれば、同期間隔がかなり正確に保てることが分かった。しかし、消費電力が若干増える(例: 使用しない場合: 0.3-0.5%/h, 使用した場合: 0.5-0.6%/h)ために見送った。

 

PS. これの発端を調べたら、「(ディープスリープ時に)同期間隔が長くなるので、改善できないか」だった。結局は、同期間隔は諦めてモバイルデータ量の削減となった。やっぱり優先順位が変動しているw そして、こうやって書いておかないと、あとでまた同じことを気にし出す可能性が高いから、困ったものだw

PS2. セキュリティの問題を疑った件について

2/4に、何もしていないのにGoogleから確認コードの電話とSMSが来た。それで、Googleのパスワードが漏れたのかと思って心当たりを考えたところ、数日前にTypeAppをインストールしたので、そこから漏れたのかと思って検索したところ、件数は少ないものの、いくつかの悪い情報があった(→ )。それによれば、TypeApp(BlueMailと同じもの)はIDとパスワードを彼らのサーバに送っているとのことで、それが漏れたのかも知れないと思ってTypeAppを使うのは止め、登録したすべてのアカウントのパスワードを変更した。

ただ、そのあとで良く考えたら、TypeAppからGmailへのアクセスにはIDもパスワードも入れていない(Androidで「アクセス許可」をしただけ)ので、それらが漏れることはないのに気付いた。その他には、昨日インストールした別のアプリにも幅広く権限を得るものがあって疑わしかったのだが、それにしてもパスワードが漏れることは考えにくい。一方、昔、Linuxで使ったメールアプリにパスワードを入れた覚えがあるので、そこからの漏洩は考えられた。その他には、前述の疑わしいアプリがパスワードを総当りで推測した可能性はあるが、何度もログインに失敗したら警告が来そうだ。それでも、念のため、疑わしいアプリは削除した。

更に調べたら、他の人が自分のGoogleアカウントに2段階認証を設定する時などに電話番号を間違えて入れると、間違った電話番号にコードが届くそうだ(これは間違いであることが分かるように欲しいが、良く考えるとどうしようもない(SMSに本人の名前などを入れたらセキュリティリスクだ)。ただ、いたずら電話の道具になりそうで、嫌な予感がする)。他に、僕のメールアドレスはわかっているので、そのパスワードをリセットしようとしていることも考えられたが、その時には再設定用のアドレスにメールが届くようだからから分かる。

確かに、Googleのアカウントページには何も異常の記録がなく、警告のメールもなかったので、電話番号を間違われた可能性が高い。そういえば、どういう訳か、僕のところには以前から何度か間違い電話が掛かって来ているので、押し間違えやすい番号なのかも知れない。あるいは、ずっと僕(のアカウント)を狙っている人が居て、その工作の痕跡なのかも知れない。別に大したものはないから考え過ぎだろうが、ハインリッヒの法則からすれば、安心し過ぎるのも良くなさそうだ。注意一秒怪我一生。 (2/5 13:34)

  •   0
  •   1

イオンモバイルに移ってから1か月経ったので、先月のモバイルデータの使用状況を確認したところ、約216MB(制限: 500MB)だった。事前検討した時の見込みでは約250MB/月だったので、それより少なくて安心した。残量は繰り越されて、今月の使用可能データ量は800MB近くになった(このまま無制限に貯まるとうれしいのだが、そうではないのが残念だw)。

モバイルデータの使用量の変化 (2019年1月)

ただ、少し前に気付いたのだが、家に居ても(Wi-Fiでなく)モバイルが使われることがあり、それがデータ量を増やしているかも知れないし、そうでなくても気に入らないので、その対策をしている。謎が多くてかなり苦労したが、大体うまく行くようになった(あとで書く予定 → 書いた)。

使用量の多かったアプリ(上位5個)

  1. Evernote: 約28MB
  2. カレンダー・アドレス帳同期アプリ: 約16MB※
  3. メールアプリ(AquaMail): 約15MB
  4. 地図アプリ(いつもNAVI): 約12MB
  5. Google Playストア: 約7.7MB

サーバソフトの移行テスト中に、間違ってモバイルでカレンダー・アドレス帳をフルに同期してしまったので、特に多かったと思われる。

  •   0
  •   1

通信データ量が少ないのでいつもNAVIを試して来たのだが、以下のような欠点が見付かった。

  • [解決済み] 使わない時は地図表示モードを解除しないと(アプリ一覧で閉じても駄目)、電池が減る。
    • 地図モード中はずっとGPSを使い続けるのだろうか。
    • → 設定のアプリの「バックグラウンドアクティビティ」とモバイルデータの「バックグラウンドデータ」をoffにしていたからのようだ。両方をonに戻したら、電池消費量は正常になり(約3.5%/h)、アプリを表示していなければ、地図表示モードを解除しなくても電池は減らなくなった。バックグラウンドデータを切ると、通信失敗とみなして何度もリトライして、電池を食うのかも知れない。(1/21 15:31)
  • 屋内などGPS電波が取れない状態で地図表示させた場合には正しい現在位置が表示できない。
    • バックグラウンドアクティビティを解除しているせいか、位置情報を「端末のみ」にしているせいか。
    • 他のアプリ(GPSロガー)が継続して位置を取っているので、それが使えるはずなのに。
    • → バックグラウンドアクティビティをonにしても駄目な感じ。画面を表に出しておかないとGPSが動かないようだ。まあ、その方が省電力なので好都合ではある。次回は位置情報の設定を「高精度」に変えて試してみたい。 (1/22 16:56)
    • → 「高精度」なら、屋内で少し(結構長い)待つと位置が出るようだ。もしかすると、「端末のみ」でも待てば出るのかも知れない。でも、GPSの電波が取れない状態では無理か。そういう状態では、「高精度」では位置が出てもおかしいことが多い(全く高精度ではない)。だから、特段「高精度」にする必要はなさそうだ。Googleに位置が通知されるのは嫌だし。 (1/26 8:39)
  • 施設名を押しても情報は出ない。
    • 長押しすると住所が出るが、それを押しても住所の情報が出るだけ。
    • ここ地図は出る施設が少しある(アイコンが出ているものは情報が出るようだ)。

Googleマップに慣れているので、施設情報が出ないのは結構不便だ。昨日のドライブ中に困った。いざという時はGoogleマップを使うしかなさそうだ。

※2番目の選択肢にしていたここ地図は、無料版でもナビ(案内)ができる以外はあまり存在価値がなさそうな感じだ。また、NAVITIMEやMapionやYahoo!なども再度試したが、施設情報に関してはいつもNAVIやここ地図と同様に今ひとつだった。

  •   0
  •   0

僕にしては珍しく、一週間くらい書かずにいた。ある方が入院されているので、(自分の禁を犯してw)twitterでやり取りしている。その流れで細かい投稿をそっちにしていたら、こっちに書かなくても満足できていたようだ。何もしていなかった訳ではなく、以下のようなことをやっていたので、詳しくは追って書きたい。

  • 画像管理アプリのdigiKam5からXnViewMPへの移行
    • digiKamに移った時と同様、コメントとカテゴリ(メタデータ)を引き継ぐ(普通に表示できるようにする)のがかなりの手間と苦労だった。 (→ 投稿)
    • ちょっとした(でも面倒な)残件と謎があるものの、概ね終わった。
    • XnViewMPは軽くていい。が、将来もまた何かに移りそうだw
    • それでも、データ仕様(EXIF)がオープンなので、(Linuxなら)ツールを使ったりスクリプトを作ったりすれば、いくらでも移行できるのがいい。
    • ついでに、過去にし忘れていた画像のカテゴリ分け(タグ付け)もした。そのために更新ファイルが増えて、オンラインバックアップのデータ量が半端ないw
    • ただ、オンラインバックアップの履歴保存のおかげで、XnViewMPで気づかずに上書きしてしまって失われたコメントを復活できたのは良かった。ちゃんと過去の版がリストアできることが分かった。
      • 履歴は頻繁に使うものではないが、いざという時には便利だ。今は3か月までにしているが、1年くらい残すといいかも知れない(お金次第ではある)。
      • ただ、復活させたコメントはどれも大したものではなく、「そこまで頑張る意味あった?」というオチではあったw
  • スマフォの地図アプリのデータ量と電池消費率の最適探し (→ 投稿)
    • 概ね結論が出た。「いつもNAVI」がいい感じだ。ただ、電池消費率はもう少し詰めたい。
  • 生活費の削減方法の検討 (→ 投稿)
    • とりあえず、10-12万円/年(約1万円/月)の削減が目標。手段は分かり、意外に簡単そうだが、実行は難しそう。
    • 更に、年間数十万円減らす策もあるのだが、結構な手間が掛かる。
  • 大掃除 (まだ残りありw)
    • TODOの作成日を見たら、随分長ーーく掃除してなかったのだが、本当なのか? 確かに、あの埃の量はそうだったかも・・・
  • (昔の写真を整理していて思い出した)白黒画像のカラー化手法がすごい。
    • 以前にも書いたが、画像によってはすごく自然にできる。
    • どうやっているのか興味はあるが、(論文を読んで)調べる気は起こらないw
  • 地図アプリの評価にヨドバシへ散歩して
    • 有機ELテレビが紙のように薄くて感動した。「買いますか?」→「まさか!」だけどねw
      • 技術バカの極地と言えよう。気持ちは分かるけど、ほとんど意味がない。
    • (naokiさんに教えて頂いた、)無制限Wi-Fi(ポケットルータ)は大体約5千円/月で手頃だが、3日で10GBの制限が惜しい。あと、電話が使えなさそうなのも惜しい。光回線をなくせるのはもう少し先だ。
    • (モバイルデータ量をケチるために試した、)ヨドバシの無料Wi-Fiが使えなかった。いくらやっても、認証だの証明書だのの文句を言われてwebが見られなかった。プロキシのせい? 全く惜しい。

並べてみると大したことではなく、先進性も生産性のかけらもないが、いろいろおもしろくやって、いい暇つぶしではあった。この調子で50年くらい一気に過ぎると、いいかも知れないw

  •   0
  •   0

僕のモバイル回線は500MB/月というケチケチ契約なので、可能な限り通信データ量を減らす必要がある。それで、昨年末から試行錯誤してある程度の目処が立ったので、書く。

基本的には、不要なモバイルデータ通信(以下、モバイル)をせず、必要な通信でもデータ量を減らせばいいので、アプリやOS(Android)でそのように設定すればいい。

ここで問題というか疑問なのは、僕のスマフォ(AQUOS sense lite)は長い(数時間)スリープ時にWi-Fiがoffになり、その時に通信が発生するとモバイルが使われてしまうのだ(その後、Wi-Fiに切り替わるのかも知れない)。AndroidはWi-Fiは「スリープにしない」にしているのだが、なぜかoffになってしまう。検索すると、Wi-Fiにもう一個設定(Wi-Fiの自動有効化)があるはずなのだが、なぜか僕のにはない。OSのバージョンが微妙に違うのだろうか。そして、Wi-Fiを自動でoffにするのはAndroidのディープスリープ(Doze)機能なのか、AQUOS固有の省電力機能なのかと思っている※。それでも、可能な限りモバイルを使わないようにしてみた。

※更に調べたら、Androidの既知の(ずっと無視され続けている)問題のようだ。(→ 参考1, 参考2) Android 8 Oreoでは設定の体系が変わってスリープ時のWi-Fi動作の設定がなくなった(→ 参考)ために問題が隠れてしまったが、僕のにはまだ設定があるので効かないことが発覚しているのか。一旦設定を解除して再設定すれば直るという情報もあったので、それを試してみたが駄目だった。。。 → Wi-Fiをonにし続けるアプリ(例: Best WiFi Keeper)を使うといいようだが、電池消費が増えるのは望ましくない(結構矛盾した要求だw)が、どうだろうか?

(1/12 7:51) Best WiFi Keeperなど、Wi-Fiをonにし続けるアプリをいくつか試したが、どれも効果はなかった(30分から1時間でWi-Fiがoffになる)。また、Automagicで同様の機能を作ってみたが、完全にonにし続けることはできなかった(タイマー(exact timer)が指定時間間隔で起床しないようで、処理自体ができない。「電池の最適化」をoffにすればいいのかも知れないが(→ 参考)、更に電池消費が増えそうだ)。AndroidはどうしてもDozeしたいようだ。それに、Wi-Fiをonにし続けていると若干電池消費が増えて(約1.5倍になる)好ましくないので我慢することにし、モバイルを使うアプリを更に減らすことにした。

ただ、いろいろ変える前にデータ通信量を調べるアプリを入れて、どのアプリが(いつ)どのくらいモバイルを使っているかを調べ、多いものから対処する必要がある。また、変更後に効果を見る必要もある。僕は通信量チェッカーとデータモニターを併用している。基本的には前者で充分だが、たまに変なことがあるので、その時には後者でも確認する。

通信量チェッカーで見ると、予想外のアプリが通信している(→ モバイルを使っている)ことが分かった。それぞれの量は少ないのだが、そういうのをカットしていれば残量が貯まって繰り越されて、どうしても必要な時に使える(チリも積もれば山となる(キロを笑うものはメガに泣く?))ので、小まめに切るのは重要だ。それから、知らずに素行の悪いアプリを入れていて、こちらの情報を流出させる場合もあるから、そういう点でも小まめに確認して切るのは良さそうだ(この用途には、後述の通信ブロックアプリの方がいい)。そうして余計な通信を減らすと電池消費量も減る可能性があるから、なお良い。

以下に、モバイル通信データ量を減らせる可能性があることを列挙する。

  • アプリの設定
    • 「自動同期」を止める、「Wi-Fiのみ使用」にするなど。 (例: Evernote)
    • 「データ節約モード」にする。(例: Spotify)
  • Androidの設定のアプリのモバイルデータなどの設定
    • 「バックグラウンドデータ」をoffにする。
    • 「バックグラウンドアクティビティ」をoffにする。: バックグラウンドでのアプリ実行が不要な場合に設定すると、更に通信をしなくなりそう。
    • (1/21 15:33追記) アプリによっては(例: いつもNAVI)、両方またはどちらかをoffにすると電池消費率が増える場合があるので、適宜調整する必要がある。
  • データ量の少ないアプリを選ぶ。 (例: 地図アプリ)
  • データ圧縮するアプリを選ぶ。 (例: ブラウザ)
  • 通信ブロックアプリで通信を制限する。 (例: NetGuard)

一番有用なのは、不要ならアプリの「バックグラウンドデータ」をoffにすることだ。丹念に各アプリをoffにすると、大分減る。Androidを「データセーバー」に設定するのでも良さそうだ。この場合は、モバイルが必要なアプリにデータセーバー時にもモバイルを使う設定をする必要がある。

アプリごとの話を書くと、Spotifyのデータ節約モードは効く。

地図アプリのいつでもNAVIは、大抵は少ない(1回数百KB程度)のだが、たまに多い(5MBくらい)場合があって謎だ。それでも、Googleマップよりはずっと少ない(ただし、使い勝手は少し劣る)。

Evernoteもたまに数MBの通信を行う。それで自動同期を止めると、他のデバイスとの同期がうまく行かない場合があるので、そうはせずに「バックグラウンドデータ」をoffにした(これでも駄目かも知れない)。

Operaブラウザの圧縮機能は悪くはないがすごく効く訳ではないので、僕は使っていない。圧縮時は通信が一旦Opera社を通るのも、ちょっと気に入らない。

NetGuardは最後の砦にいい。アプリごとにモバイルだけでなくWi-Fiも切断できるので、意図しない通信をカットできる。それで、元々通信しないアプリでは広告がほとんど出なくなって(広告は外部から取ってくることが多いが、それが取れないため)、うれしい(→ : 最下部は広告の領域)。ただ、何となく、スリープからの復帰が遅いことがある気がするのと、VPN機能を使っているので、通信時に電池を食う可能性を心配している(未確認)。なお、同様の機能はGoogleのDatallyにもあるが、Datallyはモバイルしか設定できない。

そのような設定をして、今は、余り外で使わなければ一日3MB以下に収まるようになった。

  •   0
  •   0

先日Googleマップの通信データ量が多いことに気付いて、軽い地図アプリを探した。ただ、データ量を少なくする方法などで検索すると、「Googleマップは余りデータ量が多くない」という情報もあって、不思議な気がしたので、少し調べてみた。

まず、僕が問題に気付いた時は低速モードで使っていたのだが、通信速度が遅いためにデータ量が増えてしまう可能性(データの取得が遅いために再取得が多発するなど)を疑ってWi-Fiで試したが、データ量は多いままだった。また、データ量を減らせる設定を調べたが、航空写真などをoffにする以外はなかった(Chromeを使うGoogle Maps Goというのはあったが、データ量は余り減らなかった)。

検索して出て来るページには、データ量が少ない派と多い派がある。以下に、それらのデータ量の例を示す。()内は用途である。

少ない派

多い派

2つに分かれていて、多い派は少ない派の約20倍にもなるのがどうにも不思議なのだが、少ない派はどれもGoogleマップを「カーナビ」として使っていたようだ。多い派は、1番目のページは「ナビしてもらい」とはあるものの、実際にどうしたのかは不明だが、「出先で」とあるので、街中での移動時に使って、ズームを繰り返したのではないだろうか(それでも1GBは多過ぎるので、別の要因のような気がする)。2番目のページはカーナビだが、大縮尺で表示していたのかも知れない。そして、3番目のページは僕と同様の方法でデータ量を測定しているので、僕の測定でデータ量が多くなったのは異常でないことが分かる。

以上から、推測ではあるが、カーナビ用途では、ルートを設定した後は比較的小さい一定の縮尺で地図を出し続け、曲がる地点で案内する(この時に交差点の拡大図は出るだろうが、それは簡単な図形なのでデータ量は小さそうだ)程度でズーム(特に拡大)することがほとんどないから、データ量が少ないのではないだろうか。

それで、実際に小縮尺のまま拡大せずにデータ量を測ってみた。以下の操作パターンで測定した。

  1. 「浅間山」で検索
  2. スクロールを5回
  3. 現在地を表示

この時の通信データ量は0.74MBと、前回(約5.3MB/回)に比べて随分小さかった。そして、この値は前回測定したデータ量の小さいアプリ(例: いつもNAVI)のオーダーだから、Googleマップでもうまくすればデータ量が減らせるのではないか。

という訳で、Googleマップではズーム(あるいは大縮尺)を多用するとデータ量が増えるのではないかという結論になった。また、市街地ではズームを多用し、拡大して使うことが多いうえに、施設が多くて情報が増えるため、データ量が更に増える可能性も考えられる。

中の作りを想像しながらデータ量が増える原因を想像してみると、ズーム途中の地図を律儀に何度も取得している(例: 仮に1ピンチ中に途中の地図を4回取得し、それらの取得を中断しないとデータ量は4倍になり、スクロールとピンチを繰り返せば簡単にデータ量が激増する。この説だと、ゆっくりピンチするほどデータ量は増える)、大縮尺地図はベクターになっていない(小縮尺でもベクターかは不明: ベクターという説もあるが、Operaで圧縮すると汚くなるので、違う気がする)、大縮尺時には異なる縮尺・タイプの地図も取得している、あるいは、大縮尺時の地図取得の最適化ができていない(例: 無駄に広く取っている(表示されていない部分に移動した時にもスムーズに表示するため? ナビの時以外で、アプリに自分が車か徒歩かなどは設定できないので、広く取る気持ちは分かる。ただ、Googleなんだから自動判定して欲しいw 移動速度で簡単に判別できそうだ): 仮に、表示されている部分の周囲4×4の分を取ると16倍になる)とかだろうか。

上の仮説が正しければ、ベクターでない以外は作りの甘さとか「バグ」ってことになるが、さて、いつか分かる日(「Googleマップの最適化により、通信データ量が激減!」とかいうニュース)は来るだろうか・・・

Googleマップでも通信データ量を増やさずに使える可能性はあるものの、僕の使い方には合わないので、やっぱり他の地図アプリが必要そうだ。

 

PS. この検討で分かったのは、webなどに書かれているキャッチフレーズ的な文句を鵜呑みにしてはいけないことだ。間違っていないことが多いが、条件が合わないと全く異なる結果になる。僕も、「Googleマップは余りデータ量が多くない」を盲信して失敗した。

  •   0
  •   0

今は「『ギガ』が減る」(「使用可能通信データ量の残りが減る」の意)などと言うらしいが、(まあ、「ギガって何だよ」※としたり顔で言(って、「マニアはうるさいんだよ!」などと思われてしま)う人は多いから、ここではその良し悪しには触れないとしてw)セコい契約をしている僕の場合は、「メガ」だ。1/1000だw

※そういう人が「40キロの道で」なんて言ったら、「キロってなんだよ?」って言うとおもしろそうだw

昨日、Googleマップが通信データ量を馬鹿食いするのに気付いて、いろいろ探してみた。結論としては、ゼンリンのいつもNAVI(以下、ゼンリン)が一番良さそうだ。次は、ドコモの迷わない地図(以下、ドコモ。中身はゼンリンと同じようだが、見た目や使い勝手を変えているようだ。例に漏れず、使い勝手は改悪されている)だ。この2つはデータ量が飛躍的に少ない(測定誤りかと思ったのだが、繰り返して測定しても少なかった)。そのため、低速モードでもレスポンスがいい。もしかしたら、ベクター地図を使っているのかも知れない。それぞれのアプリのページではこういう長所を特に目にしなかったが、もっと強調すればもっと売れるのにと思う。

ゼンリンとドコモの違いは、地図の色遣いなどが若干違うのと、表示される建物などのマークの数が違うことだ。前者は多くて煩雑だが、後者は少な目で、色遣いも合わせて見やすい。ドコモは高齢のユーザーも考慮したのだろうか? あるいは、アプリ名の「迷わない」点を重視したのかも知れない。以下に、ほぼ同じ縮尺でのそれぞれの表示例を示す。

ドコモは見た目はすっきりしていていいのだが、使い勝手がイマイチ(例: 設定画面で何か設定すると、地図画面に戻ってしまう)なのが残念だ。使い勝手はゼンリンがいい。あと、データ量はなぜかゼンリンが少なかった(ドコモでの測定誤りの可能性はある)。僕としては、ゼンリンの表示をドコモに近づけたい(細かくカスタマイズできるといいのだが、全くできないようだ)。

細かいことだが、ごちゃついては居るが、地図の使い勝手ではゼンリンの方が良さそうだ。というのは、まず、駅の地下街(と思われる)の色が付いている方が分かりやすい気がする。次に、東京芸術劇場が載っている。ドコモには載っておらず、代わり(かどうかは不明)にレディースクリニックが載っている。東京芸術劇場ほど大きなものでも検索しないと出て来なかったら、そこに行く途中で見失ってしまいそうだ。どういう観点で載せる/載せないを決めたのだろうか? 他に、ドコモは交番を警官の帽子のマークにしているが、余り頂けない。ゼンリンのように、普通に⊗がいいと思う。更に、ドコモにはコンビニが載ってないのもかなり不便そうだ。

ゼンリンが惜しいのは、文字が見やすくないことだ。太さとか大きさとか微妙なところなのだが、そこはドコモに軍配が上がる。

次点は、ここ地図(NAVITIME)とロケスマである。NAVITIMEのその名の地図アプリはデータ量が多いが、こちらは軽目である。ロケスマも軽目だが、現在地付近の検索しかできないのが長所であり短所でもある。

比較内容と結果を以下に示す。

通信データ量の測定・比較方法

モバイル回線(低速モード, 約200kbs)で、地図アプリに対して、決まったテスト操作パターン※を実施して、その間の通信データ量を通信量チェッカーで測る。

※操作パターンは以下とした。

  1. 「池袋」を検索、表示
  2. そこで「食事」を検索(または飲食のカテゴリを表示)
  3. 3回、スクロールと再検索を繰り返す。
  4. ズームイン、アウト
  5. 現在地を表示

測定結果(通信データ量)と感想と評価

  • × Google maps (「マップ」): 5.26MB
    • とにかく遅くて、使い物にならない。
    • データ量が多い。
  • × Google maps (Opera miniで圧縮最大で使用): 3.12MB
    • 結構遅いのでイライラ。
  • × Google maps (Operaで圧縮ONで使用): 3.45MB
    • 再検索結果が出ない(圧縮で誤動作?)。
    • やっぱり遅い。
  • △+ ロケスマ (Digital Advantage): 2.11MB
    • 地名での検索ができない(現在地周辺のみ)。→ 「周辺フード100」で試した。
    • 提携(登録)されている店などしか出ない?
  • × MAPS.ME: (使いにくいので測定せず)
    • 使う都度、(まだしていなかったら)地図をダウンロードする必要があるので不便。
  • × NAVITIME: 6.2MB
    • 「食事」での検索は無理なようだったので、地名で検索後、周辺情報のグルメ・カフェ・ファミレスで試した。
    • 検索が遅いことがある。
    • データ量が多い。
  • △ ここ地図 (「地図」, NAVITIME): 2.69MB
    • 結構速くていい。
    • 余計な通知が鬱陶しい(非表示にすればいい)。
  • ○ 迷わない地図 (ドコモ): 0.93MB
    • 速い。
    • 使い勝手は良くはない(特に設定)が、悪くもない。
    • 表示が鬱陶しいことがある。
    • dアカウントが要る機能がある。
    • 更に有料(300円/月)のものもある(例: VICS情報)。
    • データ量が少ないが本当??
    • 「地図アプリ by いつもNAVI」のクレジット
    • ドコモの契約がなくても使える。
  • ○ いつもNAVI (ゼンリン): 0.47MB
    • データ量が少ないが正しい?
    • 迷わない地図より使いやすい。
    • 地図上のマークがドコモより多くて煩雑。
    • 鬱陶しい表示がある。
    • 有料(300円/月)の機能がある(例: VICS情報)。
  • × マピオン: (すごく使いにくいので測定中止)
    • 検索・表示が遅い。
    • ちゃんと表示されない。
    • 検索してもそこが拡大表示されない。
    • 使いにくい。
    • データ量も多い。
  • × MapFan (Increment P): (すごく使いにくいので測定中止)
    • 評価がすごく低い。
    • 起動が遅い。
    • すごく使いにくい。
    • ユーザー登録を催促される(無効化は可能)。

マピオンやMapFanは地図で有名だから試したのだが、惨憺たる結果だった。更に、昭文社(MAPPLE)は無料アプリがないという体たらくだった。まあ、会社のスタンスなのだろうが、昭文社は大失敗したのではないだろうか? この3社にいいアプリを作れとは言わないから、データで商売すればいいのにと思う。その点、ゼンリンは先見の明があった。

 (20:47記) なお、Yahoo! MAPは、前の投稿のPS2に書いたように何もしなくても電池を食う腐ったアプリなので、比較対象外とした。ただ、仮に比較してもゼンリンには全く及ばなかっただろう。

それから、データ量以外に消費電力にも注意が要る。常に電気を食いまくる、「腐ったアプリ」のことがあるし、そうでなくても、少ないデータ量に対応するための処理が重くて電池を食う可能性もあるのだ。それは実際に使ってみないと分からないので、外出した時などにいつもNAVI(または迷わない地図)を試そうと思う。

(2019/1/3 14:36) 徒歩で街中のホームセンターに行った時に、いつもNAVIとロケスマとここ地図を試しに使ってみたので、感想などを書く。

主に前の二者を現在地付近の表示や店の検索に使ってみた。ただ、いつもNAVIは無料版ではナビ(道案内)ができないことに気付き、それだとGoogleマップの代替にならず、知らない街中では不便なので、ここ地図も追加で試してみた。そのため、ここ地図は余り使っていないのでデータ量が少な目になっていると思う。どのデータ量も同じ操作によるものではないので絶対的な比較はできないが、評価時の値とのオーダーの比較程度はできそうだ。

  • △- いつもNAVI: 意外にデータを食う(2.7MB)。
    • 以前少なかったのはなぜ?? : その時はWi-Fiだったから? ズームなどがデータを食う?
    • ナビが有料(300円 /月 or 3000円/年)なので不便。Googleマップの代替にはならない。
  • × ロケスマ: いつもNAVIと同じくらい(2.3MB)。 → 余り便利でないので削除した。
    • 提携の店(余り多くない)程度しか出ず、それ以外は検索しても出ないので駄目。
  • △+ ここ地図: 軽いかも(0.35MB)。
    • データ量が少ないのは、余り使ってないせいかも知れない。
    • 大縮尺の地図は結構簡素。
    • 無料でもナビができるので、次回使ってみる。

どういう訳か、前の二者はどちらもデータ量が多くて、2.5MB前後だった。特に、いつもNAVIは評価時の値に比べて随分多い印象だ。これだと、Googleマップと似たようなものかも知れない。測定誤りだったのだろうか。なお、どのアプリも電池は余り消費しないようで、GPSロガーが大きかった(各地図アプリの約3倍)。

なお、迷わない地図もいつもNAVI同様にナビは有料なので、削除した。残ったGoogleマップの代替となりうる候補は、ここ地図だけである。あとはYahoo! MAP(ナビができるとして)で電池を食わない方法が見つかれば、いいかも知れない。 ← Yahoo!はデータ量が多いので、駄目な感じ。

データ量の測定アプリの通信量チェッカーは、データ量が表示されるまで遅延があるし、少なく出ることがあるようなので、今後はデータモニターを使うことにする。

(1/3 15:34) ここ地図は、検索すると縮尺が小さくなってしまうので、不便だった。ただ、無料でナビできるのはこれしかない(データ量の多いYahoo!は除く)。また、いつもNAVIは家でWi-Fiで測定すると、やはりデータ量が少ないのが不思議だ。仕方ないので、以下のように、状況に応じて使い分けるのが良さそうだ。

  • 通常使い: いつもNAVI
  • ナビ(道案内)が要る時: ここ地図
  • 上のどちらも不充分な時・通信データ量に余裕がある時: Googleマップ

(1/3 16:21) Googleマップのliteモード(ブラウザでURLに"?force=lite"を追加する)も試したが、データ量は劇的には減らなかった(同じ操作をした場合、通常のアプリが5MBの時、4MBだった)。またモバイルの高速モードでは軽快に使えるが、低速モードでは遅くて使い勝手が悪かった。

 

PS. 多くの方は「こんな面倒なことやってられるか!」と思うだろうが、だから、「いつの間にかギガ/電池がなくなった。(このくそスマフォ!)」とか「通信料が高い」とか「電池重い」などという羽目になるのである。僕は、そういう実用以外に趣味でもあるので、飽きずに追求しているw

  •   1
  •   0

近頃は寒いが天気がいいので、ちょっとドライブに行きたくなった。いくつかの候補があったのだが、距離や気分で、以前行ったつくばのラーメン屋(さいらい亭)で、辛いラーメンか熱い焼きそばが食べたくなった。ただ、店の名前が分からず、地図で探しても出て来なかったので、前に書いたように、自分のブログを探したら分かった。ただ、店名で検索したら、もうやってないような感じだった。その代わり、支店なのか移転したのか、同じ名前の店(さいらい亭 筑穂店)があり、料理の内容も同様だったので、そこに行くことにした。

10時頃出発した。数日前に窓ガラスを拭いたのだが、それがイマイチで、まだらになってしまって、却って見辛くなっていた。仕方ないのでワイパーで拭った。外から分かるかは分からないが、日が当たるとなんかみっともない感じなので、あとで綺麗にしたい。

つくばに入ったら、一気に交通マナーが悪くなった気がする。殺伐とした感じがした。まあ、栃木も同様だろうが・・・

12時頃、つくば市北部の7-11で休んだ。いつもよりはましだが、やっぱり眠い。そして、休んだら、急に眠くなった。そこの手前に、学生の頃に通った教習所があり、とても懐かしかった。昔から方向音痴で、そこには送迎バスでしか行ったことがないので、あんなところにあったとは、全然知らなかった。

そこから筑波山が良く見えた(ただ、写真はイマイチ)。天気が良くて、帰路には山の上の建物まで見えた。何となく、手前の林檎(?)の木から、ここには以前来たような気もするが、駐車場との位置関係が違う気もする。

12:30頃、店の辺りに着いた。が、店が見つからなかった。すごく近くに行ったはずなのだが、店の影も形もない。辺りを歩いたり結構探したのだが、見つからなかった。番地でも調べようとしたが、ほとんどの建物に番地が表示されていないので駄目だった。天気は良かったが、風が冷たかったので諦めた。この店もなくなったのか(地図のマークの辺りに建物が描かれていないのは、そういうこと?)※と思ったが、今考えると、Googleマップがおかしかった可能性もある(以前、かにみそさんがひどい目に遭っていた)。コンビニの人に聞けば良かったんだろうけど、どうも苦手なので聞かなかった。

※別のアプリ(迷わない地図、いつもNAVI、ここ地図)で調べたら、このさいらい亭は出て来なかったので、なくなってしまったようだ。移り変わりが激しいな。そして、Googleといえども、ゼンリンやNAVITIMEには敵わないようだ。 (12/29 13:12)

で、他にもその店の本店や別の支店はあるのだが、結構遠いので諦めて、デニーズか別のラーメン屋にしようと思った。後者は珍来というチェーン店で、学生時代には良く行ったから懐かしい。が、そこのラーメンをとりたてて食べたい気分ではなかったので、好きなデニーズにした。

デニーズは、入り口が待ちの長い信号の近くで、前に信号待ちの車が並んでいたので、入りにくかった。が、あとで良く見たら、反対側に入りやすい広い駐車場があったw 結構混んでいたが、待たずに座れた。ここに来たことはなかったかも知れない。つくばはココスが多かったのと、学生にはデニーズは高目だったので、余り行こうとは思わなかった。店員のお嬢さんは不慣れな感じだが、のどかで良かった。

日射しが強くて暑かったので、ノンアルコールビールがおいしかった。カレーがおいしそうだったのだが、そもそもラーメンを食べに来たので、坦々麺にした。いつものように、1600円くらいになった。なかなかおいしかった。食べたら更に暑くなった。

意外に客層が地味だった。高齢化か、寂れたのか、元々こんなものだったのか。でも、のどかでいい。それでも、学生らしき女性で目をひく人も居た。

その後、大学の中の道を一周したり、辺りを車でぶらぶらした。何度も書くが、当時と違って、今はスピードを出さなくても全くイライラせず、気持ち良く走れるのがいい。ただ、辺りの大きな建物は見覚えあるものの、それ以外はすっかり様変わりしていて、更に、入っている店も変わっていたりするうえに方向音痴も相まって、全く地理感覚がなく、現在地もどこに何があるのかも分からなかった。当時住んでいたアパートにすらたどり着けなかった・・・ まあ、仕方ないので諦めた。

コンビニは随分増えて、至る所にある。ただ、当時アルバイトしていた7-11はなくなっていた。建物は残っていたが、良くあるように、別の用途に使われていた。

一通り周ってから帰路に就いた。帰りは、前の会社でつくばに出張する時に通っていた道にした。僕は乗せてもらっていただけだが、結構覚えていた。この道はなかなか「マニアック」(だけど、すごく細いという訳でもない)で、運転してくれた人は最短だと言っていたのだが、経路を見ると確かに直線的だ(地図では筑波山の「波」辺りを通る)。

16時頃に寄った筑西の7-11で、となりの軽トラにCB750Fourが載っていた。詳しくないが、「750ライダー」のやつではないだろうか。古いからそれなりに傷んではいるが、結構程度が良さそうだった。業者の人なのだろうか?

17:30頃無事に帰宅した。若干マナーの悪い車が居た以外は、気持よく運転できた。つくばはやっぱり交通マナーが悪い気がする。学園(数本の大通りに囲まれた、長方形の地区。大学などがある)の中はいいのだが、外の大通りに出ると全然違って殺伐とする。中は現代だが、外は戦国時代みたいな感じだ。まあ、栃木も似たようなものだが・・・

155km、約7.5時間。いつものように車は快調だった。バッテリーも大丈夫だった。
AQUOS sense liteで撮影。

題は、ちょっと「ティファニーで朝食を」みたい? (全然?w)

PS1. 今日のカス

上記の筑西の7-11だったか、タクシーがコンビニの駐車場を結構なスピードでショートカットして行った。普通は左折でやるが(もちろん、していいものではないが)、そいつは赤信号で右折をショートカットした。かなり危ないと思う。それに、コンビニから出る時に車が来たりしてうまく行かない確率が高く、逆に事故の起こる率がすごく高くなるから割に合わないと思うのだが、アフォは目先のことにしか興味がなく、そんな計算はしない・できないのだろう・・・

そのカスは随分手慣れた感じだったから、常習者なのだろう。まあ、いつかひどい目に遭うことだろう。被害者が出ないことを祈る。こういう手合は、事故を起こしたって特段構わないと思っていると推測するが、プロ意識はないのだろうか? そういう(泥棒みたいな良くない意味の)プロってことか。

こういうのが居るから、「それでもいいんだ」とか思って真似したり、「そうしないと煽られる」とか思ってひどい運転をする人が減らないのではないかと思う。僕も若い頃はそうだった。少しでも遅かったり間違えたりするとクラクションを鳴らされたりして、それが嫌だったので、多少経験を積んで自分が逆の立場になったら、やられたことはやり返せみたいな感じの、ひどい運転をしていた。そういう連鎖もあると思う。

PS2. スマフォの地図の通信データ量について

地図は、(スタンダードな)Googleマップを使っていたのだが、今日は随分と使い勝手が悪かった。速度制限モードで遅かったせいだろうが、表示がかなり遅かった。それで、もしやと思って通信データ量を見たら、すごく増えていた(Googleマップは今日だけで10MBくらいだった)ので、びっくりした。普通に(特段の最適化などをせずに)地図画像を送っているようだ(てっきり、ベクターでやっているのかと思い込んでいた)。ちょっと調べたいだけなのに、こんなに使われたら大変だ。音楽の分がなくなってしまう。

それで、帰ってから別のアプリを探して試してみたら、ロケスマというのが軽そうな感じだった。あとはYahoo!地図もGoogleよりは軽そうだった。ただ、何もしなくても電池を食ってるようなので、削除した(→ 削除したら、入れてから2倍程度に増えていた電池消費率が戻った: 12/29 5:25)。やっぱりYahoo!はイケてないなあ・・・

それから、知らなかったのだが、GoogleのDatallyという通信データ圧縮アプリがあったので、試すことにした。なお、OperaやOpera miniにもデータ圧縮機能があるのだが、随分画質を落としてもGoogleマップを20%程度しか圧縮できず、期待外れだったので、Opera miniは止めた。ただ、Datallyがこれより圧縮できなかったら復活させたい。Operaは標準ブラウザにしているのだが、一応圧縮をONにして使うことにした。 ← SSLのデータもOperaのサーバに行ったら嫌なので、圧縮は止める。(12/29 14:40)

(12/29 9:49追記) Datallyは実際にはデータ圧縮をする訳ではない。単にバックグラウンドでの通信をブロックするだけのものだった。一方、それは設定で可能なので、全く不要なアプリだ。

確かに、端末内の、アプリと独立したフィルタだけで通信データ圧縮は不可能だ。Operaだと思い込んでしまった。ただ、Googleなら自社の豊富なサーバでできると思うのだが、今後やるのだろうか? ただ、それはかなり怖い話ではある。

  •   0
  •   0