********************************************************************** セッションS2-c テーマ:Android携帯の省電力化技術 ~現状とこれから~ コーディネータ:久住憲嗣 氏 (九州大学) 日時:9/2 9:00-10:20 参加人数:約25人 ********************************************************************** ◯ 発言者の略称 H氏:九州大学 システムLSI研究センター 久住憲嗣 氏 K氏:NTTドコモ 先進技術研究所 神山剛 氏 O氏:富士通研究所 大石亮介 氏 その他:出席者 ※ H氏、K氏、O氏は登壇者(発表者)です。 ◯ 議事録本文 ☆ H氏の発表 導入  Android携帯端末は、高機能になって便利になっている。   大変普及しており、ユーザは高度なサービスを享受している。  しかしながら、消費電力が大きく、全然電池がもたない。   私の周りでは、本体よりも大きな電池のパックを持ち歩いて使っている人もいる。  本セッションでは、キャリアの立場として、NTTドコモのK氏、  メーカの立場として、富士通研究所のO氏、研究者の立場として、私から、  現在、こういう問題意識で、こういうことに取り組んでいる、ということを  まず述べる。その後、出席者の方々と議論をする。   Android端末の消費電力を減らすためにはいろんな観点がある。  アプリの観点から   ・ユーザの行動を変えてもらうために、不要なサービスを使わせないだとか、   サービスの品質を下げるといったアプローチ。  ・アプリケーション開発者において、不要なサービスを利用しないようにする。   例:使っていないのにGPSがONになっている、ということがないようにする。     より消費エネルギーの低い実装方法を利用する。     また、そのための支援の仕組みを作る。 システムの視点から  ・DalvikVMなどのサービスの類をチューニングして減らしていく。 ・アクセラレータなどのHWを換えてなんとかする。   サービスに近い観点からK氏に、システムに近い観点からO氏にお話いただく予定。 分科会なので、途中で止めてのツッコミもあり。 ☆ K氏の発表 サービス事業者寄りの観点から、ドコモの考え方や、それをどう研究に活かしているか、 具体的にどんな事例をやっているかを紹介する。 ドコモではお客様の満足度を重視している。  サービスそのものの進化だけでなく、品質向上も重要な課題。  電池のもちは、何年にも渡って不満要因の上位なので、満足度の上で重要課題。 お客様の声の一例  ・もっと電池容量を増やしてほしい。  ・xxxに換えてから電池がもたなくなった。  ・高機能化に向けてもっとやることあるだろう。 こういった要望はもともとFOMAの頃から多かったが、スマートフォン販売にあたり、 特に増え続けている。 お客様に実感してもらえる改善は必要だけれども難しい。 電池がもたない原因はいろいろある。  電池自体の劣化、充電器の故障。  お客様の使い方の頻度、使用環境。 お客様の言葉は抽象的で、そこから原因が分かるかというと、必ずしもそうではない。  まずやるべきことは、原因の特定。 ドコモがとるべきアプローチは何か。  システム寄りなところは、メーカさんとの共同で対処。  ドコモはサービス事業者なので、サービス開発から窓口対応などの様々な業務プロセス  から対策をとる。 省電力の研究について、ドコモでは、サービス事業者的なアプローチをとっている。  ユーザやサービスの開発者に分かりやすい原因特定技術(見える化技術)。  ユーザに原因と改善効果を実感して貰える対策。 スマートフォンの場合、ユーザの使い方が多様化している。  ユーザの使い方を考慮した消費電力の解析が必要。 アプリの違いによる消費電力の違い  高いものだと2Wを超える。  無線通信やカメラ、GPSを複合的に使うアプリだと消費電力が高くなる。 原因特定のための見える化技術  原因の特定を容易にする。  端末消費電力のモデルをどういうモデルにして、それをどう扱うかという話。  従来の解析手法では、ドコモのニーズを満たさない。   HW設計時における評価を目的にしたモデル    ・ハードウェア依存。 ・計算オーバヘッドが大きい。 消費電力の実測  ・使い方が多様化しているので、評価シナリオが多く試験工数が多い。 端末のモデル化における取り組み  端末の構成を抽象化して電力をモデル化する。  CPUだけでなく、消費電力の大きいデバイスを外さない。   ハードウェアの稼働率(CPU使用率など)といったものを使う。  ハードウェアを抽象化している。   簡単なパラメータで、デバイスの電力をそこそこの精度で見積もる。  アプリのプロセスごとの電力を考える。  → これらを組み合わせれば全体のモデルとなる、という考え方でやっている。 大事なパラメータはCPU使用率、データ送信量、ストレージへのアクセス、LCD。 端末を考えると、LCDは非常に重要。 モデル化における留意点 CPUだけでなく、端末全体を考える。 アプリ開発における解析に利用できる。 モデル化の工数を下げる。   パラメータにかかる係数を機種ごとに用意。  実機がなくても、パラメータさえあれば、電力を算出でき、評価できる。 モデルの生成について  モデルは機種ごとに作成。   モデル生成のためのトレーニングエンジンを実機で動かし、電力を図りつつ、   パラメータを得て、それらをモデル式に当てはめて係数を求める。 見える化技術の事例  アプリ開発者向け:Androidアプリ開発環境における消費電力解析 Androidはeclipse上のプラグインでアプリ開発をする。 リアルタイムに消費電力を計算で求めて、画面に表示させる。 待受時をベースとした電力の内訳を表示する。 CPUがこのくらい、無線がこのくらい、など。 モデルに必要なパラメータを、エミュレータからとってくる。   ツールの目的は、アプリ開発者に消費電力を意識させること。    低消費電力なアプリ開発につながる。   何が電力を食っているかという内訳を出しているので、どこを改善すればよいかを   把握してもらえるのではないかと考えている。  ユーザ向け:ecoモードアプリ   Android向けのアプリで、設定を一括変更して端末を省電力モードにする。   現時点であまり高度な機能は実装していないが、低リテラシな一般のお客様向けで、   簡単に操作できるもの。   ecoモード状態にしたときに、どれくらい電池のもちがよくなるかを見せる。    ある意味で見える化。    効果を実感してもらう。   類似アプリとの違い    ・ユーザの利用動向、つまり、ユーザごとにどのような設定で、どれくらい     使っているかを考慮(ユーザスタディ)して、設計している。    ・見える化することで、ユーザの理解向上による不満軽減を狙っている。 いいたいこと  「電池持ちに対する不満」を解消しなければならない。  そのための対策として、やれることはなんでもやる。   分かりやすいところで、HWやSWの低消費エネルギー化という解があるが、他にも   やりようはあると思っている。  改善の対象が、システムであれ、アプリであれ、ユーザであれ、ユーザスタディが  重要で、本当に効果があるのかどうかを常に意識して取り組んでいる。   まとめ  電池もちの改善に対するドコモの考え方について話した。  研究としては、見える化技術を紹介した。  ユーザの使い方も考慮した対策をしている。 ☆ O氏の発表 Androidにおけるアプリケーションベースの省電力化について話す。 アジェンダ  ・スマートフォンと消費電力問題  ・アプリベースの消費電力測定  ・ケーススタディ  ・消費電力とプロセス動作との関係  ・省電力化に対する提案 スマートフォンに要求される機能  クラウドベースの利用を前提とした常時接続。  高速な無線ネットワーク。  携帯電話のような小さいデバイスにしては大容量なストレージ。  様々な機能のデバイスを内蔵。   タッチパネルやセンサなど。  これら機能を、ユーザが使いこなすためのAPIを用意。 Android  基本的にオープンソースというのが大きい特徴である。  Javaベースのアプリプラットフォームである。   VMとして、今までにない独自のDalvikVMというものを使っている。  同時に複数のアプリプロセスを動作させることができる。   他のスマートフォンでは、ユーザプロセスは基本的に1つしか動かない。  アプリプロセスの分類   ・activity:画面を占有するプロセス    ブラウザやメールなど。   ・service:画面を占有しないプロセス    メールの待受など、バックグラウンド専用。     他のプロセスを動かしつつ、バックグラウンドで動いている。    他のスマートフォンにはない、Androidの特徴。   ・1つのアプリで両方の特徴を持つこともある。    twitterクライアントなど、SNSアプリ。  端末のHW資源をほぼ制限なく使える。   3rdパーティのベンダや個人がアプリ開発をするとき、OSによる   ハードウエアの制限を受けずにアプリ開発ができる。   従来の携帯では、ネットワークやGPSの使用などには制限があった。 Androidの進化  2008年くらいに1.0が出て、年を追うごとにどんどんバージョンが上がっている。  HWデバイスも最初はシンプルだった。   翌年、画面サイズが倍、カメラの解像度向上、CPUのクロック向上。   翌年、タブレット、カメラ2つ。   昨年の終わり〜今年、デュアルコアのCPU。  現在、AndroidOSの最新バージョンは3.2くらい。  今後、CPUの周波数が1.5GHzになったり、クアッドコアのプロセッサが出てくるかも。  非常に高機能、高性能なスペックが要求されるため、HWやOSがどんどん進化して、  消費電力に対する要求も厳しくなっており、これは大きな課題となっている。 なぜAndroidは電池を食うのか。  考えられる理由は2つくらいある。  1つ目は、アプリが高性能、高機能化していること。   HWの制限なくアプリを開発できてしまう。    ユーザにとっては嬉しいけれども、メーカにとっては頭を抱える問題。   Androidに限らず、他のスマートフォンでも状況は同じ。  2つ目は、バックグラウンドで動作するアプリがあること。   【O氏からの質問】    ・出席者の中で、アプリを開発したことがある人はいますか?     → 多少いた。    ・出席者の中で、サービスを開発したことある人いますか?     → いなかった。   サービスという仕組みを使うと、バックグラウンドで動作可能なアプリを作れる。    他のプロセスに画面が切り替わっても終了せず動き続ける。     例えば、音楽の再生や情報収集など。   これは、電池という点からだと、大変な事態。 実際にどこで電力がくわれているかが問題。  K氏の話でもあったように、その原因を特定して、対策を考えることが大事。 ケーススタディ  実際の消費電力を測ってみる。   画面を使うアプリと、バックグラウンドで動くアプリのそれぞれについて。  対象のアプリは、API Demos。   googleの提供している、開発者のためのサンプルアプリ。   ホーム画面を出しながら、メールアプリでメール着信したときの消費電力を測る。  環境としては、Nexus Oneという、googleがリファレンスモデルとして使っている  端末を使った。 実際に電力を測った結果     なにもしないでほっとく(ホーム画面でアイドル状態)。  → 約130mA  しばらくすると、自動的に画面の輝度が下がる。  → 約110mA  その後、画面が消えて待機状態になる。  → 約2.5mA  画面OFFするだけで、消費電力は1/50になる。  画面ONにすることは消費電力のインパクトが大きい。  サンプルアプリAPI demosの中の、アニメーション動作をするサンプルを実行。   フェードイン、ズームイン動作を実行する。   → 約130mA(待機画面よりも少し増えるくらい)。   バックボタンを押してホームに戻る。   → その瞬間は電力が増える。  → 単にプロセスを動かすだけだと、LCDの消費電力の方がずっと大きく、    CPUの処理自体に大きな電力がかかっているという訳ではないことが分かる。     バックキーを押した瞬間のように、複雑な処理を行うと瞬間的に電力が増加     することはある。     物理的なボタンでなく、タッチパネルを押すと消費電力は一気に増加する。      物理的なボタンよりもタッチパネルの方が消費電力は大きい。  画面の向きを変えると消費電力が変わることがある。     リスト操作(何個か候補が出てきて選ぶ)の消費電力を測った。    端末を縦向きにする。    → 約150mA    端末を横向きにする。    → 約210mA   なぜこういうことが起こるか。   → 画面の表示領域が変わるので、ディスプレイに描画する量が変わるため、     消費電力が変わる。  ダイアログ(操作中に小さいメニューが出てきて、OKとかキャンセルとかを選ぶ)  を表示させる消費電力を見てみる。   ダイアログに表示するメッセージの長さを変えて測った。    短いテキストを表示させる。    → 180mA    長いテキストを表示させる。    → 190mA   テキストを長くするだけで、消費電力が変わってしまうことがある。   テキストの長さを変えるという、ちょっとした工夫をするだけで、消費電力に   効果があるということは面白いと思った。  進捗バー(複雑な処理をするときに0%〜100%を棒グラフで示すなど)を表示させた  ときの電力を見てみる。   進捗バーを表示する間、それだけで結構大きな電力を消費する。   → 160mA   進捗バーを表示している間は、実際は裏で、通信や計算など、なにか処理を   していて、ユーザがいらいらしないようにその進捗を見せているのだが、   進捗を見せるだけの処理で、比較的大きな電力を消費している。   → ここも工夫次第で電力を落とせるかもしれないと思っている。  今まで紹介したものは、画面に何か表示させて、それを操作するものだったが、  今度は、ユーザは何も操作していないけれども、バックグラウンドで処理を  しているものの消費電力を見てみる。   メール着信待ちの際の消費電力を測った。    オープンソースのk-9mailというアプリを使った。    imapで、画面OFFでメール受信をした。   何もしていないとき。   → ほぼ0に近い、2、3mAくらい。   着信があったとき。   → 100mA〜200mAの大きな電流が流れる。   着信が終わったあと。   → 非常に低い、数mAの値まで戻る。   最大値を見ると、約200mAの電流が流れている。   → ネットワーク通信は、画面を表示させるよりも大きな電流が発生している     ことが分かった。    大きい電流が流れている間に、システムが何をやっているか、プロセスがいつ 動いているか、そして、メール着信にかかる電力を減らせるかどうかということ について考えてみた。  メール着信のプロセスは、勝手に動いてしまい、目で見て分からないので、  より詳しい解析を行った。   そのために、電流測定とトレース取得を同時に行う環境を構築した。    ・端末を電流計で測る。    ・測定用PCを用意し、電流計の値を記録する。    ・端末のトレースをリアルタイムで取得する。 環境構築は、簡単にできるかと思っていたが、やってみると、そうでもなかった。  トレースログを取得するため、PCと端末をUSBケーブルで接続するのだが、  PCのUSBポートから電力を供給するため、正しい電流を測定できなかった。  → トレースは端末内部のメモリに保存し、あとでPCに送ることとした。  電流測定時刻は、電流値をPCで記録するためにPCの時計、トレースログは、  ケーブルで接続していないために端末の時計で記録している。そのために、  PCと端末の間で時刻のズレが生じた。  → 電流測定開始時に、両方の時刻のズレを計算しておくこととした。    数十msecの誤差は簡単に修正する方法がないので、手で修正した。 トレースをどうやってとったか。  2つのアプローチが考えられた。  1つ目は、Android開発環境に入っているトレーサツールを利用する方法。   javaアプリのソースに、ログを出力するコードを明示的に埋め込む必要がある。  2つ目は、DalvikVMの中に実装されている、Traceviewというトレースをとる機能を  利用する方法。今回は、こちらの方法を採用した。   もとのTraceviewは、アプリの性能をプロファイルするためのツールなので、   実時間での計測はできなかった。   → java VMのトレーサを改造して、実時間のログをとれるようにした。     オープンソースだったので、改造は可能だった。  → javaアプリのソースを改変することなく、トレースを取得できる環境を    構築できた。 実際にメール着信処理のトレースを解析  メールのプロセスだけでなく、システムのプロセスも動いているので、それも解析  することで、メールの通信動作に関する部分を抽出できた。  今回はDalvikVM上のプロセスのみを解析対象とし、Cやアセンブリで書かれている  部分のトレースはとっていない。  電流波形とトレースログを重ねあわせて見てみた。   メール着信処理が終わった後も、何も処理していないのに、電流が高い状態   (約200mA)がしばらく続いていた。   → ここは無駄な電力ではないかと気づいた。そして、その部分にバグがあった     ことが分かった。 Androidシステムを省電力化するためにはどうすればよいか。  ・バックライト、タッチパネル操作時の動作などを改良する。   キーボードなどは最近使われなくなったが、消費電力的には有利。  ・カーネルによるクロック周波数制御、デバイス制御を工夫する。  ・プロセスの消費電力を減らす。     まとめ  スマートフォン、特にAndroidの消費電力の特徴について調べた。   実際に消費電力を測定した。   動作ログと電流を重ねあわせて詳しく解析することで、どういう省電力化が   できるかを、HW、OS、アプリ、それぞれのレイヤで考えることができる。 ☆ 質疑応答 出席者T氏:  全体的に電力を見える化、いろんな電力を見ましょうという話がメインであった。  見えた電力で、どう電力を最適化するかという技術について、現状やっていること  と、これから取り組みたいことは?  O氏:   まず目に見えるところから手をつけており、ディスプレイの輝度を下げること   をしている。    輝度をそれほど上げなくてもはっきり見える技術を開発している。    はじめは分かりやすくということが目的だったが、電力的にも効果があった。   取り組みは、CPUの周波数のコントロールをやろうとしている。  K氏:   ユーザの振る舞いに注目している。   何が最適かというのはアプリごとに違う。    必要な電力を使っている分には問題ない。    どれぐらい電力を使うべきか、どれくらいのサービスを提供すべきかといった、    トレードオフを考えないといけないと思っている。 出席者B氏:  キャリアさんとベンダさんの見える化の思惑が見えて面白かった。  携帯という大きい枠組みで、ドコモの見える化技術と富士通の見える化技術で、  フィードバックやコネクションはあるのか?  K氏:   研究レベルでは現状ない。今回話してみて、同じようなことやってるなと思った。     出席者B氏:  これから協力体制があると嬉しいのでは?  O氏:   キャリアさんと一緒にやっていることが全くないという訳ではない。   また、Googleさんとある種の取り組みを進めている。 H氏:  実時間ログを取得できるような改造を本家にコミットしている?  O氏:   具体的な話はないが、可能ならやりたい。   例えば、APIの問題で電力を消費することが明らかになれば、そこを改良して、   電力を抑えられるAPIを、Googleなどに提案することを積極的にやっていきたい。    そういう取り組みも進めてはいる。 H氏:  Androidだと何でもできる反面、その進化の速さから、コントロールできる  範囲が昔の携帯より狭いのでは?  O氏:   メーカとしても、そのことは問題と思っている。   本来、携帯やPCでは、OSとHWが併せて進化するのが理想。    もちろん、そういう流れでは進んでいる。   AndroidをHWにただ載せるだけだと、面白くないし、差別化も難しい。    それに対抗することが必要だと思っている。    会社で取り組みをしているわけではないが個人的な思いとして、我々は今まで    に優れた携帯電話を作ってきたという思いもあるので、そのときの資産を    うまく使っていきたい。   今まではキャリアさんと提携してクローズにやってきたが、もっとオープンな   ところで、海外メーカと戦っていかなければと思っている。    そのとき、主導権をとっていかなければならないが、一番やりやすいのは、    オープンソースでやることで、そういった方向で進めていきたいと考えている。  K氏:   アプリを作るとき、Androidの進化についていくにはどうすればいいかは   よく聞く話ではあり、それに対する取り組みも始めている。    最近は、個々のアプリ屋さんのものをどんどん出していこうという流れがある。    オープンソースのコミュニティと積極的に交流して、ノウハウを蓄積、共有    していこうという取り組みがある。 H氏:  人によって利用状況が違うので、アプリの最適なチューニング方法や、システム  全体の方向性も違うと思った。  そのことについて、何か意見をいただきたい。  K氏:   ユーザの振る舞いをどう活かしていくかが大事。   法的に難しいが、そういった情報をサービス改善に使っていきたいと思っている。    O氏:   HWやOSの改善は当然これからも進めていく。   それに加えて、いろいろと便利なアプリが出てきて、それらのアプリをユーザが   使い、それで電池を食ってしまうというトレードオフがあるが、アプリの使い勝手   はそのままにして、消費電力を抑えたい。   そのためには、アプリ開発者の協力が不可欠だと思っている。    アプリ開発者の人と一体になって、HWもいいものが作れる、アプリもいいものが    作れるという、Win-Winな関係を積極的に目指していきたいと考えている。 H氏:  結局のところ、人なんだなと思った。  協力関係を築くときに、その下地となる見える化技術は重要だと思った。 出席者R氏:  APIごとの消費電力を測る取り組みについて、APIごとに消費電力が分かっている  ならば、APIの利用に関して、省エネのレベルを見せてユーザ側に選択させる  取り組みをしてはどうか?  K氏:   アイデアとしては考えている。   例えば、「このアプリだと電池を食う」ということをユーザに見せることも   できる。   見せ方が大事だと思っている。  O氏:   かなり以前からそのことを検討しているが、問題がある。    エンドユーザは機能をまず求めてしまう。     便利さの優先度が、電池の優先度より高いユーザが多い。     電池を優先させてしまうと、不便だけど、電池はもつという印象を     与えてしまう。    見せ方に工夫が必要であり、まだ製品に生かせていない。 ◯ まとめ Android携帯端末における省電力技術について、キャリアとメーカの それぞれの立場における取り組みを紹介した。 消費電力の見える化技術が重要であり、ユーザやアプリ開発者に消費電力を うまく意識させることが重要である。 Android携帯端末における省電力を実現するためには、HWやOSの開発者 だけでなく、その上で動くアプリの開発者や、それを使うユーザも連携して いく必要がある。