ブライテクノ株式会社 代表取締役 中西良明 

} 中西 良明 ◦ ブライテクノ株式会社 代表取締役 – 2010年10月起業 – メイン事業： Android/iOSアプリ開発およびコンサルティング ◦ 略歴 – 大阪大学にて情報工学を専攻、修士課程卒業後、松下電器産 業(株)に入社。インターネット、情報セキュリティ、携帯電話関連 の研究開発に従事 – 同社退社後、マカフィー(株)で携帯電話・スマートフォン向けのセ キュリティソフトの研究開発を担当 – その後、ソニー・エリクソン・モバイルコミュニケーションズ(株)で Android端末開発プロジェクトに参画 – 退職後起業し、現在に至る 

} 中西 良明 ◦ Twitter: @chun_ryo ◦ Android、iOS両刀使い 

} 書籍 ◦ 『Android開発者のためのSwift入門』 (リックテレコム) – http://www.amazon.co.jp/dp/4897979838 } 同人誌 ◦ 『Sweet Android』 (TechBooster) – Android 6.0のパーミッションについて 

} 電力使用量削減の歴史 ◦ 端末メーカによる独自対策 ◦ 通信キャリアによる指針 ◦ Googleが提供する機能 } Android 6.0の省電力対策 ◦ Doze Mode ◦ App Standby 

} Android 6.0の省電力についての理解 ◦ 背景 ◦ その機能 ◦ 対策（どうしても回避したい人向け） } Job Schedulerの良さ 

No content

} 概要 ◦ 通信キャリアや端末メーカが、独自の対策を実施 ◦ 通信キャリアからアプリ開発者にガイドラインを提供 ◦ GoogleによるAndroidの改善 – 断片化(フラグメンテーション)などにより利用が進まない ◦ Android 6.0での大変革 

} Google検索で2010年頃の記事を発掘してみる ◦ http://smhn.info/201203-sharp-eco-bcintent- deny – 『もちろん、iPhoneのバッテリーにも寿命はあるが、Androidは、 そのマルチタスク性ゆえ、バッテリー寿命が短いのが難。』 ◦ http://call-t.blog.so-net.ne.jp/2010-04-04 – 『で、、、結局、Google以外はすべてサービス停止。 それにとも ない、、、Xperiaの大きな特徴のひとつ、、、Timescapeは、お 蔵入り』 } 多くの記事で「不要なタスクを殺す」という対策を推奨 

} 各社が省エネ設定(アプリ)を提供 (2011年頃) ◦ Wi-Fi/BluetoothのON/OFF、画面明るさなどなどを電池残 量に応じて自動的に調整 – NTTドコモ – ecoモード(アプリでの提供、2015年3月31日終了) – au – ecoモード設定 – ソフトバンク – 省エネ設定（とにかく省エネ／おやすみ省エネ） ◦ ASCIIによる当時の比較記事 – http://ascii.jp/elem/000/000/629/629870/ 

} SHARP: エコ技 (2011年) ◦ 設定時にBroadcast Intentをアプリに送らないようにする – AlarmManagerによる指定時間の処理実行も止められる – 特定アプリを対象から外す設定は可能 ◦ 当時の開発者イベントにおける説明で物議をかもす – http://togetter.com/li/273604 – Broadband Intentを止めるなどにより、アプリのバックグランド動作 を抑制 似た機能、最近どこかで見たような気がする 

◦ Androidアプリ作成ガイドライン～効率的な通信制御に向け て～ (NTTドコモ) – 端末が効率的な電力消費などを行うようにするため、アプリ開発 者に対してガイドラインを提示 – https://www.nttdocomo.co.jp/service/developer/smar t_phone/etc/#p01 

} Fused Location Provider ◦ アプリごとの位置情報取得が大きな影響を与えていたので、 Google Play servicesが仲介して抑制 – Google Play servicesにロックインされるため、Kindleなどでは 使えない } Sensor Batching (4.4以降) ◦ できるだけCPUを動かさず、センサからの情報を取得 – ハードウェアも対応している必要あり – iPhoneにも同様の機構(M9プロセッサなど)あり – http://techbooster.org/android/device/16666/ 

} Job Scheduler (5.0以降) ◦ 細かく条件設定できるジョブの遅延実行 – 例：端末がアイドルモードなら実行しない、ネットワーク接続無し 時は実行しない、などなど – https://www.youtube.com/watch?v=QdINLG5QrJc } BatterySaver (5.0以降) ◦ OS標準の省電力モード – 初期設定では、電池残量が少なくなると自動的に発動 – CPUクロック低下、画面を暗く、同期停止などなど – 通信キャリアの独自取り組みから3年…… 

} アプリ開発時に電力使用を考慮しているか？ ◦ Fused Location Providerを利用しているか？ ◦ 電力消費に配慮するガイドラインに従っているか？ ◦ Sensor Batchingを利用しているか？ ◦ Job Schedulerを利用しているか？ 

} アプリ開発時に電力使用を考慮しているか？ ◦ Fused Location Providerを利用しているか？ – 多い ◦ 電力消費に配慮するガイドラインに従っているか？ – ほとんどいない ◦ Sensor Batchingを利用しているか？ – 少ない（そもそもセンサ利用なし含む） ◦ Job Schedulerを利用しているか？ – 少ない 

} 知らなかった } 旧OSバージョンも対応が必要(だから使えない) } 対応すると要求仕様を満たせない ◦ (お客様 and/or 上司) is GOD 

No content

} 省電力のために機能を提供 ◦ 機能を用意してもあまり使われない } 6.0からは強制的に電力消費を抑えよう ◦ Doze ◦ App Standby 

} 画面OFF、静止状態、バッテリ動作が一定時間続い た時に、端末はDoze(居眠り)のモードに入る ◦ Doze中はアプリの動作に制限がかかる(後述) ◦ Doze中、“maintenance window”という制限が解除され るタイミングがあり、その時には制限が解除される http://developer.android.com/intl/ja/training/monitoring- device-state/doze-standby.html 

} ネットワークアクセス停止 } Wake Lockを無視 } AlarmManagerの処理を遅延 ◦ 次回のmaintenance window、もしくはDoze解除時に処 理される ◦ Doze中にも実行させるAPIあり(後述) } Wi-Fiスキャンなし } 同期(sync adapter)の停止 } Job Schedulerの停止 

} API Level 23の以下のAPIを利用することで、Doze 中にもアラームを発火できる ◦ setAndAllowWhileIdle() ◦ setExactAndAllowWhileIdle() } これらのAPI使用時、約10秒間処理実行が許される ◦ その間にWake Lockすることで延長可能 } ただし、アプリは短くても15分に1度の間隔しかアラー ムを設定できない 

} あまり推奨されることではないが、前述の制限を回避 するアラーム設定方法も残されている } API Level 21で導入された setAlarmClock() でセッ トされたアラームは通常通りに発火する ◦ そのアラーム発火の少し前(shortly before)に、システムは Dozeを抜ける 

} Doze中通常のGCMはアプリには届かない } Doze中でも処理されるよう、優先度を上げるフラグが GCMに追加されている { "to" : "...", "priority" : ”high", "notification" : { ... }, "data" : { ... } } https://developers.google.com/cloud-messaging/concept-options 

} 高優先度GCMはリアルタイム処理が要求される場合 にのみ利用しなければならない ◦ Google Playの審査への影響や、GCMの利用制限が行わ れることがあるのかは現時点では不明 ◦ https://developers.google.com/cloud- messaging/concept-options 

対象のアプリ その他のアプリ AlarmManager setAndAllowWhileIdle() Dozeの一時的解除 Dozeのまま setExactAndAllowWhil eIdle() Dozeの一時的解除 Dozeのまま setAlarmClock() Dozeの解除 Dozeの解除 高優先度GCM Dozeの一時的解除 Dozeのまま AlarmManager#setAlarmClock()は影響が大きいので、極力 使用しないことが望ましい 

} アプリが一定期間明示的に利用されていない場合、 そのアプリを“スタンバイ状態”に置く ◦ 以下がないと明示的にアプリが利用されていないと判定 – ユーザが明示的にアプリを起動する – アプリがフォアグランド状態になる – アプリが生成した通知をユーザが見る(開く) } “スタンバイ状態”に置かれたアプリは、一日に一度し かネットワーク通信を実行できない 

} ユーザに対して、ホワイトリスト登録を要求するシステ ムダイアログを出すことができる ◦ REQUEST_IGNORE_BATTERY_OPTIMIZATIONS のパー ミッションを宣言 ◦ コード内で以下の処理を呼び出す Intent intent = new Intent(); String packageName = context.getPackageName(); PowerManager pm = (PowerManager) context.getSystemService(Context.POWER_SERVICE); if (!pm.isIgnoringBatteryOptimizations(packageName)) { intent.setAction( Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS); intent.setData(Uri.parse("package:" + packageName)); } startActivity(intent); 

} ホワイトリストへの登録を要求するアプリで、Google Playでの公開を停止された事例の報告あり ◦ StackOverflowで確認 種別 ユースケース GCM使用可 か？ 許可？ 備考 インスタントメッ セージ、チャット、 呼び出し リアルタイムメッ セージが Doze/App Standby中も必 須 ○ × 高優先度GCM を使用せよ 上記+法人 VoIP 同上 × ○ タスク自動化ア プリ アプリのコア機 能がスケジュー ルされた自動ア クション どちらでもよい (if applicable) ○ 

} AlarmManager#setAlarmClock() ◦ 省電力強化のために、Google PlayでsetAlarmClock() 利用のチェックを行うようになる可能性は考えられる ◦ 電力的に行儀のよいアプリ仕様を考える – API Level 23で追加されたAlarmManagerのAPIを利用する – 必要に応じて高優先度GCMを利用する 

} Android 5.0以上限定なら基本的にはJob Scheduler ◦ バックグランド処理にリアルタイム性が必須のアプリはほとん どない ◦ 通信状態によるジョブの実行制御、端末再起動時にも設定し たジョブを残すなどの豊富な設定が可能 ◦ PendingIntentを扱うよりも楽 } Android 5.0より前も対応しないといけない場合 ◦ AlarmManagerを利用する OR ◦ OSバージョン判定し、5.0以上ではJobSchedulerを使用して いく 

} Context#getSystemService()でJobSchedulerを 取得する } JobInfo.BuilderでJobInfoインスタンスを生成する } 取得したJobServiceにJobInfoインスタンスを登録す る Context appContext = getApplicationContext(); JobScheduler scheduler = (JobScheduler)appContext.getSystemService(JOB_SCHEDULER_SERVICE); ComponentName componentName = new ComponentName(appContext, MyJobService.class); JobInfo jobInfo = JobInfo.Builder(jobId, componentName) .setPeriod(5000).setNetworkType(JobInfo.NETWORK_TYPE_ANY).build(); scheduler.schedule(jobInfo); 

} 実行するジョブは、JobServiceクラスを派生したクラ スで定義する public class MyService extends JobService { @Override public boolean onStartJob(JobParameters params) { // TODO: AsyncTaskなどで実際の処理を別スレッドで実行させる return true; // true: 別スレッドで処理中, false: 処理完了 } @Override public boolean onStopJob(JobParameters params) { // TODO: システムからの停止要求があれば別スレッドのタスクをキャンセルする // たとえば、onStartJobで生成したAsyncTaskにcancel()を呼ぶ return false; // true: ジョブを再スケジュールする, false: ジョブを捨てる } } 

} Androidは省電力のための改善を続けてきた ◦ 省電力のためのAPI提供 ◦ ハードウェアの改善 } 6.0で強制的な省電力を断行した ◦ アプリ開発者が省電力に非協力的だったので、Googleの 堪忍袋の緒も切れた } アプリ開発者は今後省電力を強く意識したアプリ開発 を求められる ◦ Googleをこれ以上キレさせないためにも…… 

ご清聴、ありがとうございます 

補足資料 

} 電池容量の増加 ◦ Xperia初代 (1500mAh) → Z2(3200mAh) → Z5(2900mAh) ◦ 最近若干の減少傾向はあるが、初期の2倍程度 } プロセッサの低消費電力化 ◦ Qualcomm Snapdragonの低消費電力の取り組み – http://www.itmedia.co.jp/mobile/articles/1211/30/ne ws032.html } 液晶の省電力化 ◦ IGZO (SHARP) 

◦ Androidアプリ作成ガイドライン～効率的な通信制御に向け て～ (NTTドコモ) – https://www.nttdocomo.co.jp/service/developer/smar t_phone/etc/#p01 – 2016年現在、残念ながら資料からリンクされているARO解説ブログ はなくなっている ◦ AT&T Application Resource Optimizer (ARO) – https://developer.att.com/application-resource- optimizer ◦ TS.20 SMARTER APPS FOR SMARTER PHONES V4.0 (GSMA) – HTTP://WWW.GSMA.COM/NEWSROOM/ALL- DOCUMENTS/TS-20-SMARTER-APPS-FOR-SMARTER- PHONES/ 

} Daydreamの一つとしてDozeServiceが実装されて いる ◦ Daydream = API Level 17で導入されたスクリーンセー バー実装のための仕組み ◦ スクリーンセーバーが働くタイミングにDozeServiceが開始、 残りの条件が満たされればDozeに入る – バッテリ動作 – 一定時間静止 } ただしCar ModeであればDozeモードには入らない 

} 画面がオンになる } パルス(*)が発生する ◦ ただし端末が近接状態である場合、かばんやポケットに端末 が入っていると判断し、Dozeを維持する ◦ 端末が動いていても、それが通知のバイブによるものなら無 視してDozeを維持する (*) 加速度センサー、ピックアップセンサーなどで検出し た動作のこと 

} SystemUI内のDozeParameters.javaが参照する config.xml でのパラメータ設定で調整が可能 ◦ AOSPからの一部抜粋を以下に示す true 2000 

} adbを用いて端末を強制的にDozeモードにすること が可能 ◦ デバッグ時はUSBケーブルを接続しているので、そのままで はDoze状態にはならない ◦ 強制的に内部状態をバッテリーに切り替えるなどの手順が必 要 

} 手順 ◦ バッテリーモードをシミュレート ◦ 画面をオフにし、deviceidleをIDLEに移行 – 何度かIDLEが表示されるまで呼び出す – 以降、stepするごとにIDLE/IDLE_MAINTENANCEに変化させ られるので、maintenance windowの動作確認も可能 ◦ または、強制的にdeviceidleに移行 (画面オンのまま) $ adb shell dumpsys battery unplug $ adb shell dumpsys deviceidle step $ adb shell dumpsys deviceidle force-idle 

} 元に戻す手順 ◦ 電源接続状態を元に戻す $ adb shell dumpsys battery reset 

} 同様にApp Standbyもシミュレート可能 } 手順 ◦ バッテリーモードをシミュレート ◦ 指定したパッケージのアプリをスタンバイ状態に変更 $ adb shell dumpsys battery unplug $ adb shell am set-inactive true 

} 元に戻す手順 ◦ スタンバイ状態を解除する ◦ 電源接続状態を元に戻す $ adb shell am set-inactive false $ adb shell dumpsys battery reset