新しいGingerbread APIはStrictModeです。 または、ANRダイアログと戦う

最近、Android Developers Blogの記事を読んでStrictModeを発見しました。 以下に彼女の翻訳を紹介します。

舞台裏

Googleのクールな点の1つは「時間の20％」です。作業時間の20％には、メインプロジェクトとは関係のないプロジェクトに参加する権利があります。 Googleに来たとき、私は常にプロジェクトからプロジェクトに切り替えましたが、これについてよく冗談を言いました。 私が常に戻ってきたプロジェクトの1つはAndroidでした。 プラットフォームの開放性が気に入ったので、バイクで家まで車を走らせたときにガレージのドアを開けるなど、やりたいことがすべてできるようになりました。 このプロジェクトが成功することを本当に望んでいましたが、私は1つのことについて心配していました。 常にデータ入力に即座に応答するとは限らないブレーキアニメーションとユーザーインターフェイス要素。 この理由は、間違ったスレッドで実行されているタスクであることは明らかでした。



私はアクティブなSMSユーザーであり、Cupcakeリリース（Android 1.5）の準備中に行った20％のプロジェクトの1つは、メッセージングアプリケーションの最適化でした。 私はそれを最適化してよりスムーズにした後、他の20％のプロジェクト間を駆け巡りました。 ドーナツ（Android 1.6）のリリース後、最適化の一部が誤って壊れていることがわかりました。 私は少しイライラしていましたが、Androidには常に不足していることがわかったので、Androidはすぐに使用できる組み込みの広範囲にわたるパフォーマンス監視ツールです。



私は1年ほど前に丸一日Android開発チームに参加し、Froyoでパフォーマンスの問題を調査するのに多くの時間を費やしました。 特に、ANRダイアログとの戦いに多くの時間を費やしました（アプリケーションがメインUIスレッド内で長時間の操作を実行すると、これらの面倒なダイアログが表示されます）。 既存のツールを使用してこれらのダイアログをデバッグすることは困難で退屈でした。 特に複数のプロセスが相互作用した場合（たとえば、バインダーまたはContentResolverから他のプロセスのサービスまたはContentProviderへの呼び出し）、理由を見つけるのに十分ではありませんでした。 インターフェイスのスローダウンまたはANR会話を追跡するには、より洗練されたツールが必要でした。

StrictMode

StrictModeはGingerbread以降で利用可能な新しいAPIです。これにより、スレッド上で実行が禁止されている操作のリストを規制するポリシーをスレッドに設定できます。 実装の詳細に特に深く入り込むことなく、これは単にトレッドローカル変数に格納されたビットマスクです。



デフォルトでは、すべての操作が許可されており、必要になるまで何も邪魔されません。 ポリシーを通じて管理できるフラグには次のものがあります。

• ディスク書き込み検出
• ディスク読み取り検出
• ネットワーク発見
• 検出時：ロギング
• 検出時：アプリケーション停止
• 検出時：Dropboxエントリー
• 検出時：ANRダイアログを表示

さらに、StrictModeには、ディスク（ java.io.*



、 android.database.sqlite.*



、など）およびネットワーク（ java.net.*



）にアクセスするほとんどの場所に、コンプライアンスをチェックするいくつかのフックがあります確立されたポリシーの現在のフロー、それに応じた対応。



StrictModeの強みは、Binderが他のサービスまたはContentProviderにIPC要求を行うたびに、すべてのスレッドでポリシーがトリガーされることです。一方、プロセス間の呼び出しの数にかかわらず、トレースのスタックは接着されます。

誰も遅くなりたくない

アプリケーションがディスクI / Oを実行するすべての場所を知ることができますが、システムサービスとプロバイダーがそれを行うすべての場所を知っていますか？ しません。 そのような場所を見つけようとしましたが、プラットフォームのソースコードの量が多すぎます。 私たちは常にSDKのドキュメントの改善に取り組んでおり、パフォーマンスのヒントを追加していますが、通常はコード内のコードへのランダムアクセスを見つけるためにStrictModeに依存しています。

モバイルデバイスでのディスクアクセス

ちょっと待って！ ディスクアクセスで何が問題になりますか？ 結局のところ、すべてのAndroidデバイスはフラッシュメモリを使用します。 可動部品のないほぼ超高速のSSDですか？ これを心配する必要はありませんか？ 残念ながら、ありません。



ほとんどのAndroidデバイスで使用されるすべてのフラッシュコンポーネントまたはファイルシステムが高速であるという事実に頼ることはできません。 YAFFS-多くのAndroidデバイスで使用されるファイルシステムは、すべての操作に対してグローバルロックを持っています。 デバイス全体では、一度に実行できる操作は1つだけです。 運が悪ければ、単純な「統計」操作でさえ時間がかかることがあります。 従来のファイルシステムを備えた他のデバイスにも、たとえば、ガベージコレクターがフラッシュメモリを解放するために遅い操作の実行を開始することを決定した場合など、多くの欠点があります。 （この問題については、こちらで詳しく説明しています ）



上記のすべてからの結論は次のとおりです。モバイルデバイスのファイルシステムは通常高速ですが、それでも90％のケースでは遅延が発生すると非常に大きくなります。 さらに、ほとんどのファイルシステムのパフォーマンスは、ディスクの空き容量が減少すると低下します。 （Google I / O Zippy Androidアプリのスライドをご覧ください）

アプリケーションのメインスレッド

通常、さまざまなAndroidコールバックとライフサイクルイベントは、アプリケーションのメインスレッド（別名UIスレッド）で処理されます。 ほとんどの場合、これにより作業が楽になりますが、すべてのアニメーション、スクロールなどもこのスレッドで実行されるため、注意する必要があります。



アニメーションを60 fpsで開始し、イベントが（メインスレッドでも）突然発生する場合、このイベントに応答するコードを実行するのに16ミリ秒かかります。 たとえば、ディスクへの書き込み操作のために16ミリ秒を超える時間を費やすと、ハングします。 通常、ディスクアクセスにかかる時間は16ミリ秒よりも大幅に短くなりますが、そうでない場合もあります。 たとえば、YAFFSファイルシステムの場合、現在書き込みプロセスの途中にある別のプロセスによってファイルシステムリソースが解放されている間待機するとします。



ネットワーク操作は特に低速で予測不能であるため、メインアプリケーションフローからネットワークリソースにアクセスしないでください。 同じ理由で、Honeycombの今後のリリースでは、メインスレッドのネットワークリクエストが致命的なエラーにつながるように作成しました（アプリケーションにHoneycomb以前のtargetSdkVersion



APIバージョンがある場合）。 そのため、Honeycombのリリースに向けてアプリケーションを準備する場合は、UIストリームでネットワーク要求を行わないようにしてください。 （以下の「滑らかさの増加」を参照）。

StrictModeをオンにする

StrictModeの推奨される使用方法は、開発プロセス中に有効にし、出力を分析し、アプリケーションをリリースする前に無効にすることです。



たとえばonCreate()



アプリケーションまたはコンポーネントのonCreate()



含めることができます。

  public void onCreate() { if (DEVELOPER_MODE) { StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder() .detectDiskReads() .detectDiskWrites() .detectNetwork() .penaltyLog() .build()); } super.onCreate(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

または単に：

  public void onCreate() { if (DEVELOPER_MODE) { StrictMode.enableDefaults(); } super.onCreate(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

後者のメソッドは、Gingerbread以前のAPIを引き続き使用できると同時に、リフレクションまたはその他の手法を使用してStrictModeを簡単に有効にできるようにするために追加されました。 たとえば、Donut（Android 1.6）をtargetApi



として指定できますが、Gingerbreadデバイスまたはエミュレーターでアプリケーションをテストする場合は、引き続きStrictModeを使用できます。

StrictMode分析

penaltyLog()



を使用する場合、デフォルトでは、 adb logcat



を実行し、端末出力を読み取ります。 ポリシー違反はすべてコンソールに入ります。



コード内の疑わしい場所を見つけたい場合は、 penaltyDropbox ()



有効にすると、StrictModeはその出力をDropBoxManager



書き込みます。そこから、後でadb shell dumpsys dropbox data_app_strictmode --print



を使用して抽出できます

滑らかさを増す

ストリームとj ava.util.concurrent.*



に加えて、 Handler



、 AsyncTask



、 AsyncQueryHandler



、 AsyncTask



などのAndroid APIを使用するオプションがあります。

私たちの経験

プラットフォーム自体のコードに取り組んでいる間に、私たちは毎日「ドッグフード」ビルドを受け取り、それがチーム全体で使用されました。 Gingerbreadの開発プロセスでは、StrictModeを有効にしてビルドを毎日収集し、見つかったすべての違反を記録して、さらなる分析を行いました。 1時間ごとにMapReduceプロセスが起動され、すべての違反、スタックトレース（プロセス間呼び出しを含む）、期間、発生したプロセスおよびパッケージなどを含むインタラクティブレポートが収集されました。



StrictModeのデータを使用して、数百のエラーを修正し、システム全体でアニメーションの滑らかさと応答性を向上させました。 Androidカーネル（システムサービスやプロバイダーなど）を最適化して、システム内のすべてのプログラムに役立つようにし、アプリケーション（AOSPとGoogleアプリケーションの両方）で多数のエラーを直接修正しました。 まだFroyoを使用している場合でも、GMail、Googleマップ、YouTubeの最新の更新には、StrictModeを使用して収集されたデータを分析することで得られるパフォーマンスを改善する修正が含まれています。



システムを自動的に高速化できなかった場合、特定のパターンのアプリケーションをより簡単かつ効率的にするための新しいAPIを追加しました。 たとえば、 commit()



'ohmによって返される値が必要ない場合は、 commit()



代わりに使用する必要がある新しいSharedPreferences.Editor.apply()



メソッドがあります（ほとんど誰も使用しないことが判明しています）。 リフレクションを使用して、プラットフォームのバージョンに応じてapply()



またはcommit()



を使用apply()



ことをランタイムで直接決定することもできます。



FroyoからGingerbreadに切り替えたユーザーは、システムの高速化にショックを受けました。 Chromeチームの友人も最近、同様の機能を追加しました。 もちろん、StrictModeはシステムの高速化に関連するすべての栄光を奪うことはできません。新しいガベージコレクターもこれに大きな役割を果たしました。

次は？

StrictMode APIとその機能は進化し続けます。 HoneycombのStrictModeに関連するものにいくつかのクールなものを追加しましたが、他に何が見たいか教えてください！ stackoverflow.comの「strictmode」タグで質問に答えます。 よろしくお願いします！