Archive for the ‘Android’ Category

モバイル通信のデータ量の節約には余念がないのだが、通信データ量を調べていたら、思わぬことが分かった。前にも書いたが、家に居るのに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

モバイルの会社を移る件。12/23にOCNからMNP番号が届き、イオンモバイルに申し込んだら、昨日の昼にイオンが開通したようで、不通となった。そして今朝、SIMが届いたので交換して、回線が復活した。不通期間は1日未満だった。今は不通期間なしのプロバイダもあるようだが、これくらいなら問題ない。

基本的な動作確認はOKだった。スピードは、最初にブラウザで実施したFASTやGoogleのテストでは問題なかった(Google: ダウンロード: 6.3Mbps, アップロード: 0.21 Mbps)のだが、アップロードが遅いのが気になり、何かの間違いがあったかと思い、アプリ(RBB, FAST, ドコモ)でも試したら、200-400kbps程度に遅くなってしまった。再度Googleで試すと遅くなっているので、なぜか、速度制限が掛かった(とは言っても、瞬時に500MBも転送できないはずだが・・・)か低速モードになってしまったのだろうか。

Googleでのスピード測定結果 (イオンモバイル タイプ1 (ドコモ回線))

まだIDが届いていないため、速度設定の確認や変更ができないので、待つことにする。

(13:19) 原因が分かった。全く思わぬことだった。

電話(例によってなかなか繋がらず・・・)でIDを聞いてwebで状態を調べたら、速度設定は高速だったのだが、残量が0だった。それで、再度電話で理由を聞いたら、契約月の料金・容量は日割り計算のため、使用可能量が130MBしかなくて、それを使い果たしたとのこと。

なるほど。確かにAndroidでもデータ使用量が約150MBとなっていたので、全く正しい。知らないうちにFASTやGoogleのスピードテストでデータを使い過ぎたようだ(もしかして、Googleのアップロードが遅かったのは、ダウンロードで使い果たしてしまったせいか?)。ブロードバンド用だったのかも知れない。全く恐ろしいサービスだw あと、うっかりモバイル回線で測定アプリをダウンロードしたのもまずかった。容量が小さい契約だと、今まで忘れていた注意をする必要があるようだ。スピード測定アプリは、ドコモの「ライトモード」が良さそうだ。

まあ、年末まで我慢すればいいし、400円で1GB追加できるし、この状態でSpotifyがどうなるかを確かめられるから、良しとしよう。

(13:43) Spotifyは大丈夫そうだ。「自動品質」で、「データ節約モード」をOFFにしていても、問題なく再生できた(再生開始まで少し時間が掛かるが、バッファリングをしているのだろう)。ここは目論見どおりで良かった。そして、速度測定だけのためにお金を払うのも馬鹿らしいので、低速での実用性を確かめるため、このまま使ってみよう。

低速モードでもSpotifyがちゃんと再生できた。

ちなみに、イオンモバイルでは低速モードでも3日で360MB使うと更なる速度制限が掛かることがあるそうだ。Spotifyの速度を150kbpsとすれば、1日10時間再生したとすると、

150/8*10*60*60/1000= 675MB

と、1日で軽くオーバーしてしまう。それでは1日(360/3= 120MB)に何時間まで再生できるかを求めると、

(360*1000/3)/(150/8*60*60)= 1.8時間

と、予想外に短い。なかなかうまくは行かないようだ。。。 とりあえず、データ節約モードをONにしよう。仮に70kbpsなら3.8時間、25kbps(Spotifyのページでは最低は24kbps)なら10.7時間はOKだ。

何となく失敗した気がしないでもないが、実際には前月からの繰り越し(約250MB見込み)があるから、1回の帰省や旅行で使えるデータ量は、低速モードも合わせると(250+500+360=)約1110MBとなる。これなら、25kbpsで約98時間は再生できるから、1日12時間再生したとしても8日以上持つ。

低速モードでもSpotifyが再生できるところで安心してしまい、その先(360MB/3日の制限)の確認をしなかったのは、(いかにも僕らしく)詰めが甘かった。それにしても、これは何ともセコい話だw

(18:26追記) 転送データ量がシビアなので、通信量モニタアプリを入れて調べたら、Spotifyをデータ節約モードにしても低品質にしても、ダウンロードの転送速度が下がらなかった(200kbps前後になる)。おかしいと思って更に調べたら、転送速度は下げないが(おそらくフルスピードで転送している)、低品質の場合は曲のデータ量が少ないので、曲の前半で転送が終わり、平均転送速度が下がるようだ。

Spotifyのデータ転送パターン (データ節約モードでは、再生中でもデータ転送が停まる)

なお、今は速度制限されているため、データ節約モードをonにしないと音切れすることがある(再生に追いつかないのだろう)。また、データ転送量も増える(上に書いたように実際の転送速度を測っている訳ではなさそうだから、「自動」とは書いてあっても実速度で音質を調整している訳でもなさそうだ。あるいは、電波状態が悪いなどでもっと低速な時に調整するのかも知れない)。一方、スピーカーでの音質はデータ節約モード(低品質)でもそうでなくても悪いのでw、常にデータ節約モードにしていても問題なさそうだ。

(2019/1/1 7:42) 月が変わって通信データ残量が回復したので、速度を再測定した。ドコモスピードテスト(ライトモード)とRBB SPEED TESTで測定したところ、ダウンロード: 約26Mbps、アップロード: 約7.5Mbpsと問題なかった。室内のせいか電波強度が弱いが、アンテナのマークはフルなので、大きな問題はなさそうだ。

RBB SPEED TESTの結果 (イオンモバイル)

なお、どちらも通信データ量が結構大きかった。ドコモはライトモードでも約9MB、RBBは約30MBだった。あまり何度もやるものではなさそうだ。

 

PS. Spotifyの話になるが、自作のミニプレーヤー(Linuxで動く)は期せずしてNW(クラウドというのかな?)対応になっており、スマフォで再生していても現在の曲情報(アルバム画像や再生位置までも)が表示・更新されるし、リモコンでも制御できる。そんな機能を作ったつもりはなかったので、狐につままれた気分だ。小人さんの仕業だろうか?w

  •   0
  •   0

ブラウザはVivaldiを使っているのだが、どうにもメモリを馬鹿食いするので辟易して来た。ベースにしているChromeの作りのせいではあるのだが、普通に使っていても、気付くと全体(32GB)の半分以上のメモリを消費していることがあって(Vivaldiがほとんどを消費しているようだ)、さすがにそれは許せないと思ってきた。更に、近頃は起動後に段々重くなって、サスペンドしたタブを開く処理が遅くてイライラする。

そこで、起死回生というのか、そろそろ「古き良きFirefox」はいかがなものかと試してみた。今までに何度も試して来たのだが、そのたびにケチが付いて見送って来た。バージョンはもう60を超えており(64)、前回(2017年夏)の55から10近く上がっているので、ものすごく改良されたのではないかと期待したw

今までの主な問題は以下であった。

  • アプリの構造が変わって、必要なアドオンがほぼ全滅した。
    • そのため、縦のタブバーができない。
  • アイドル時のCPU負荷が高い。

試してみると、必要なアドオンは復活(別のものになったものもある)しており、縦のタブバーのアドオンもあって(Tree Tabsにした)、使えそうだった。CPU負荷については直っていないようで、アイドル時でも15%前後と高目ではある。ただ、良く考えてみたら、今まで見ていたCPU使用率(ps uxコマンドでの"%CPU")は、1コア(Hyper threading(以下HT)の1スレッド)当たりの値のようだ。一方、CPUはHTによって仮想8コアなので、psコマンドで出るプログラムのCPU使用率はPC全体では1/8になる。すると、例えばアイドル時に16%だったとしても、全体への寄与(増加分)は(16/8=)2%程度(HTなので、実際の負荷はもう少し大きくなりそうだ)の負荷なので、大きな問題はなさそうだ。実際、topコマンドの"%Cpu(s)"の表示にも合っている。

負荷について少し考えてみた。: 僕のPCは古いので、CPU(Sandy Bridge)の能力は高くない。一方、今のアプリは近頃のCPUを想定して作っているので、僕のPCのような古いCPUで動かすと、重くなってしまうのではないか。そして、HTで見掛け上は8個ものコアがあるように見えるが、1個の仮想コアで処理するには軽くないのだろう。とは言え、1仮想コアの負荷は100%にはなっていない(通常使用時は30%前後)ので、実行に無理がある訳ではなさそうだ。

ただ、Vivaldiでは重くならないのが何とも不思議ではある。メモリを使う代わりにCPU負荷を軽くしようという方針なのだろうか。あるいは、Firefoxにはいろいろな(古い?)CPUに最適化できていない箇所があるのかも知れない。VivaldiのコアはChromeなので、それを作ったGoogleなら、いろいろ知っているだろうしリソースもあるから、さまざまなことができている可能性はある。

他には、前にも書いたかも知れないが、Firefoxは(プロセス数を減らすためなのか、)各タブのイベントを処理をするためにCPUを動かし続けるような作りになっていて、(そのため、特にタブが多くなると、)負荷が高くなる可能性も考えられる。ただ、個人的には、必ずしもそうなってしまうとは思わず、ちゃんと作れば(あるいは、最適化を行えば、)負荷を低くできると思う(コードを見ていないので、あくまでも想像である)。

負荷が小さいに越したことはないが、10GB以上もメモリを馬鹿食いされるのに比べたらずっといいので、しばらく試して問題なければ移ることにする。なお、負荷が大きくなり過ぎるのが防げることを期待して、設定の"Content process limit"を2に減らした。また、メモリ使用量を更に減らすため、Auto Tab Discardというアドオンで、一定時間アイドルのタブをサスペンドするようにした(ただ、元々使用量が少ないので、効果は余り感じられない)。

なお、Firefoxの使用メモリ使用量は、前回同様、Vivaldiの1/3程度だった。以下に測定結果の例を示す。

VivaldiとFirefoxの使用メモリ量の比較

  • 測定条件
    • それぞれのブラウザで、概ね同じページ(3ウインドウ、約46タブ)を開いた。
    • ps uxコマンドを用いて各ブラウザのプロセスのRSSを合計した。
    • どちらも最新版
  • 測定コマンドの例: ps ux | grep firefox | awk '{sum+= $6;} END {print sum/1024;}'
  • 結果
    • Vivaldi: 約10GB
    • Firefox: 約3.2GB

現時点で分かっている問題(不満な点)は以下である。致命的なものはなく、アドオンや設定によって、基本的な使い勝手をVivaldiとほぼ同等にできた。

  • [済] 縦のタブバーにしても、ウインドウ上部のタブバーは消せない。 → CSS(userChrome.css)を修正して消せた。 (→ 参考1, 参考2)
  • [保留] Authy(2要素認証用トークン生成アプリ)が対応していない。 → Chromeアプリを使う。
    • Authyの起動直後はシステムがすごく重くなって、なぜかFirefoxも動かなくなる。
      • 数十秒待てば直る。
      • Firefoxの設定を初期化しても直らず。 → 諦める。
  • [済] ズームに"105%"がなく、ズームのデフォルト値が変えられない。 → アドオン(Fixed Zoom)でできた。
  • [保留] デザインが今一つごちゃついている。 → 我慢する。
  • [保留] ページの表示がおかしいことがある(例: じゃがさんのブログで上が妙に空いたり、下に白い部分が出ることがある)。 → 我慢する。
  • [TODO] スタイル(CSSの反映のされ方)が微妙にVivaldiと違う(例: 「いいね!」ボタンが大きい)。ブログのCSSが良くない? → 暫定的にボタンの文字を少し小さくした。

他に、僕のデスクトップ設定との絡みなのだが、Firefoxには右上にメニューボタンがあるので、ウインドウの位置によってはボタンが時計と干渉することがあるという、思わぬ落とし穴があった。メニューボタンは動かせないようなので、なかなか悩ましい。まあ、クラシックなメニューバーもあるので、大きな問題ではない。それに、アドオンで何とかなるかも知れない(上のタブ一覧を消したのと同様に、CSSの改造で動かせそうな気がする)。

CSSを変更してメニューボタンを左に移せた(→ 参考: "Show CSS Code"の内容をuserChrome.cssに追加する)。

今の懸念(心配)は、MSもChrome系に移ったため、Firefoxがとても少数派になり、将来、開発元のMozillaもろともなくなってしまう可能性があることだ。ただ、メモリ量の少ない小型機器でChromeを使うのは現実的ではないから、Firefoxも残る期待はある。嫌なのは、Red Hatのように変なところに買収されてしまうことだ。例えば、OracleやIBMやMSなんてところは避けたい。もちろん、Googleだってマズい。ここは是非、UbuntuのCanonicalと一緒になって歯を食いしばって頑張って欲しい。

特にその気はなかったのだが、いろいろと「移行」の多い年末だ。IT大掃除のようなものか。他に、OSのバージョンアップもしたいのだが、さすがに、スマフォの回線移行が重なって電話が使えない可能性がある状態で行うと、メールすら使えなくなってドツボに嵌まる可能性があるので、来年にしようと思っている。

 

PS. 少し前にスマフォでもFirefoxを試したが、まだ遅いままだったので止めた。以前と同様、最初はそうでもなかったのだが、何回か動かすと遅くなってしまう感じだ。何かのアドオンが悪いのだろうか。

  •   0
  •   0