hdk_embeddedの日記

【AN-1】高性能なAndroidアプリを作るには - ティム ブレイ

Android | 02:51

高性能とは処理が早くて応答性の高いアプリのこと。

• ANRやイベントループの停止を防ぐ技術
• ボトルネックとなるI/Oアクセスについて
• アプリケーションのパフォーマンス最適化手法

について解説。Androidの今後の予定についてもQ&Aで答えます。

関連ページ

AsyncTask

• http://developer.android.com/intl/ja/reference/android/os/AsyncTask.html

(追記)TechBoosterに解説記事を載せました(via @kacchi0516)

TechBooster Asynctaskを使って非同期処理を行う

• http://techbooster.jpn.org/application/1339/

IntentService

• http://developer.android.com/intl/ja/reference/android/app/IntentService.html

TraceView

• http://developer.android.com/intl/ja/reference/android/os/Debug.html

EclipseのMemory Analyzer、MAT(http://www.eclipse.org/mat/)の使い方

Android アプリケーションのヒープメモリを観察する

• http://subtech.g.hatena.ne.jp/cho45/20100206/1265431649

(追記) TwitterID:pakuqi さんのブログです

Memory Analyzerの使い方

• 電脳羊（Android Dream）http://xiangcai.at.webry.info/201009/article_7.html

ユーザの満足度

高性能なAndroidアプリについて技術的なプレゼンテーションを行いたい。

総じてスピードの速いアプリケーションのほうがユーザエクスペリエンスが良い。

ただし、ウェブページの取得、データベースのアップデートは早いとはいえないだろう。

その時にユーザの不満をそらすには？何かヒントがある？

満足度を向上させる方法を伝えたい。

"推定はしないこと、なぜ遅いのかを測定する","ユーザへの敬意を"

Janky

ChromeチームによるJankという単語が作られた。

ユーザがスムーズさを感じないときを指し示す。

"A janky app"(おっそいアプリ、ストレスを感じる動作を意味する)

UIスレッドが大事

Androidのスレッド処理はマルチスレッド化されている。その中でも特別なのがUIスレッド。

描画、ユーザレスポンスに直結するUIスレッドではアプリケーションのロジック作業を行わないことが原則。

原則を守ることが満足度を高める第一義

ANRは世界最悪だ。もっともよくない。

アプリは追放(アンインストール)されてしまう。

5秒応答がない、インテントレシーバの処理に10秒かかる、

これらANRを引き起こす症状は起きてはいけないこと。

(ANR:Application Not Responding、アプリケーションが無応答状態になること)

マルチメディア処理、たとえばビデオを60FPSで再生している場合などは16msしか余裕がない。

一般に100〜200ms以上の遅延はJankyとなる。

ストレージ読込(1バイト)読み込み	25ms
ストレージ書込(1バイト)書き込み	200ms
サーバーへのPing(※)	100ms

(その他もろもろ…)

※信号強度、ホップの回数など様々な要素がかかる。

特にネットワーク経由でデータを取得する際は最低でも１秒かかってユーザエクスペリエンスが低下する

フラッシュへの書き込みについて(Yaffs2)

Flashは磁気ディスクとは違なった特徴を持つ。経過年数、書かれているデータ、デバイス種類などが影響してアクセス速度が変わってしまう。

ストレージへの操作(読み書き、権限付与など)はUIスレッドで行わないこと。

SQLiteはほかのデータベースと比べると小さいが、複雑な処理をおこなっていることに変わりはない。

リレーショナルデータベースを扱うときは注意して、慎重に考えること。やはりUIスレッドを使わないこと

たくさんのログはSQLiteをつかわず、プレーンのテキストを使うことを推奨する。

データ特性に合わせて記録形態を変えるのが大切だ。

I/Oは非常に遅い

ネットワークは遅いし、ストレージも遅い。

このようなレスポンスに時間がかかる遅い処理はUIスレッドで行わないように。

asyncTask

asyncTaskを使うことでI/Oの処理をUIスレッドより切り離せる。

進捗をプログレスバーを出すなどUIスレッドで描画は行うが、実際の書込処理などはバックグラウンドのスレッドで処理する。

(非同期タスクサンプルコード：http://developer.android.com/intl/ja/reference/android/os/AsyncTask.html)

Fire And Forget Modeと呼んでいる。

ファイア・アンド・フォーゲットとは撃ちっぱなしを指す軍事用語。処理が始まれば、(バックグラウンドで行うので)気にしなくて良い、ということ。

asyncTaskの詳細

いくつか注意点

• UIスレッドから呼び出すこと
• 再帰呼び出しはできない
• Activityがbackgroundになってしまったときに処理中であってもasyncTaskを殺される可能性がある

解決策

→ android.app.IntentServiceを利用すること

呼び出されたら、Androidはアプリを生き残らせようとがんばる。

UIスレッドで遅い処理を行わないようにする便利なルーチーンがある。

ユーザの満足度向上のために

• 全ボタンをDisableにかえてユーザ操作を禁止する
• スピナーをつかい処理中を見せる(Androidではいろんな見せ方があるが、一つの提案として)
• 200nを超えるようならプログレスバーを使う
• AsyncTaskを利用する

アプリでの実装例

Android Marketに LifeSaver というアプリがある

Androidでは、電話の履歴、テキストメッセージの履歴が端末間を移動できない。

→これらデータをSD Cardに移動するアプリ

ユーザが何が行われているか、目で確認できるようにしている。

SDカードへのデータ移動は速くすることができないので、丁寧にユーザーに説明する。

パフォーマンスアドバイス

どうやって高速化するか。ボトルネットを見極めることは非常に難しい。開発者は事前の最適化は出来ないと肝に銘じるべき。

事前にやっておけば、もしかしたら早くなるかもしれない。が(全く変わらない可能性もあるので)あまりよい手法ではない。

重要なことは

• 出来るだけシンプルな処理にする
• テストして性能を確認 →問題なければおしまいだ。飲みに行こう。
• 推定はしないこと、なぜ遅いのかを測定すること
• 運が良ければ少しの修正で治るかもしれない

→通常、これらを何度か繰り返す必要がある。

プロファイリングツール

最適化を支援するツールの紹介

• TraceViewを使う
• Log.dでタイムスタンプを入れる
• エクスストリームプロファイル(※)

※とてもパフォーマンスが気になる場合、ユーザーにAndroidAppを使ってもらい、フィードバックを得る。

TraceViewの使い方

android.os.Debug.startMethodTracing(String traceName)

android.os.Debug.stopMethodTracing()

http://developer.android.com/intl/ja/reference/android/os/Debug.html

3つ、遅くなるかもしれないところがある。

• データ読込
• データ保存
• StringをJSONへ変換するなどCPUパワーに由来する箇所

TraceViewをつかって突き止めよう。Traceコードが入ると、スピードはおそくなる。

(デモの後、解析結果を図示してみせる)

TraceViewで実行すると、ほとんどprintに時間がかかっているのが分かる。

これはSDカードへの書き込みが考えられる。さらに細かくみていくとprintlnの読み出し、

そのうちの半分ぐらいがnewlineにかかる部分だ。

一方、このプログラムの30パーセントがJSONオブジェクトをStringに変換する作業で時間を消費しているようだ。

つまりプログラムを動かしている時間の3分の1はJSONオブジェクトをストリングへのコンバートしているだけだ。

→ 今回の場合は、頻繁に使うアプリではないのであまり気にしない。

見つけたボトルネックに対して最適化が必要であれば行うべきだ。

まとめ

• 1つ目：ユーザへ敬意を払うこと。そのためにはユーザに最も近いUIスレッドは特に注意する。決して大きな作業をUIスレッドでやらないこと。

AsyncTask、IntentServiceを使う

• 2つ目：推測をせずに測定を行うこと。測定ツールを使わない理由はない(＝必ずやること)。クリス プルエットもTraceViewと何週間も共に過ごしたと言っていた。それほどに重要。

別のメモリアナライザ(MATがOOM調査するのに便利)も使える

Memory Analyzer http://www.eclipse.org/mat/

http://subtech.g.hatena.ne.jp/cho45/20100206/1265431649

最後に

ユーザーに敬意を、UIスレッドを大切に、何かを変える前に測定を。

Q&A

Q:Android 3.0でセキュリティは強化される？

A:次のバージョンを3.0と呼ぶかも決まってはいないが、セキュリティグループがAndroid開発チームの中には存在している。

Anroidでのセキュリティには非常に多くの労力が払われていると回答

Q:様々なAndroid端末が出てくるが開発者が対応する上で注意すべき点は？

A:Googleでは"互換性の問題"と呼んでいる。Android Developers blogで互換性の問題に関して一連の記事が書かれている

http://android-developers.blogspot.com/ 是非ともみていただきたい。

きちんとアプリケーションを書いて適切に対応すれば、Galaxy Tabのように1024*600といった解像度であっても

問題なく動作する(1000本以上のアプリケーションがきちんと動いた、とのこと)

(追記)

Q:C2DMはスケールするのか?

A:"We're Google!"