6

私は Android のベスト プラクティスに従おうとしているので、デバッグ モードでは次のすべてをオンにします。

StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder().detectAll().penaltyLog().build()); //detect and log all thread violations
StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder().detectAll().penaltyLog().build()); //detect and log all virtual machine violations

メイン (UI) スレッドで何らかの種類のファイル アクセスまたは SQL を使用しようとすると、Android が怒鳴るようになりました。しかし、メイン スレッドでファイル アクセスや SQL を使用することをお勧めします。たとえば、メイン アクティビティは、onCreate()まだ設定されていない場合に備えて、既定の設定値を内部に読み込む必要があります。

PreferenceManager.setDefaultValues(context, resId, readAgain);

おっと --- がonCreate()UI スレッドで呼び出されるため、アプリケーションの最初の実行時にファイル アクセスが発生します。これを回避する唯一の方法は、別のスレッドを開始することです。これにより、設定を読み取ってデフォルト値が既に設定されていることを期待する可能性のある他の UI コードとの競合状態が発生します。

DownloadManager などのサービスも考えてください。ダウンロードをキューに入れると、(メイン スレッドで) ダウンロードが完了したことを知らせるイベントが発生します。そのダウンロードに関する情報を実際に取得するには (ダウンロード ID のみが表示されます)、DownloadManager にクエリを実行する必要があります。これにはカーソルが含まれており、厳密なポリシーがオンになっている場合はエラーが発生します。

では、メイン スレッドでカーソルにアクセスしても問題ないのでしょうか。それとも悪いことで、Android 開発チームと Android 書籍の著者の半数がそのことを忘れていたのでしょうか?

4

1 に答える 1

8

これを回避する唯一の方法は、別のスレッドを開始することです。これにより、設定を読み取ってデフォルト値が既に設定されていることを期待する可能性のある他の UI コードとの競合状態が発生します。

次に、を使用して、呼び出しをAsyncTask入れ、「設定を読み取る可能性のある他の UI コード」を に入れます。setDefaultValues()doInBackground()onPostExecute()

そのダウンロードに関する情報を実際に取得するには (ダウンロード ID のみを提供します)、DownloadManager にクエリを実行する必要があります。これにはカーソルが含まれており、厳密なポリシーがオンになっている場合はエラーが発生します。

DownloadManagerそのため、バックグラウンド スレッドでクエリを実行します。

では、メイン スレッドでカーソルにアクセスしても問題ないのでしょうか。

それはあなたの「良い」の定義に依存します。

Android 1.x およびほとんどの 2.x デバイスでは、使用されるファイル システムは YAFFS2 であり、これは基本的にすべてのプロセスですべてのディスク アクセスをシリアル化します。最終的な影響として、コードは単独では十分にパフォーマンスが高いように見えますが、バックグラウンドで他の処理が行われているため (新しい電子メールのダウンロードなど)、本番環境では動作が遅くなることがあります。

これは Android 3.x 以降 (ext4 に切り替えた) ではそれほど問題ではありませんが、フラッシュ I/O がまだ比較的遅いことは間違いありません。

StrictMode動きが遅くなる可能性がある場所を指摘するように設計されています。良性のものとそうでないものを判断するのはあなた次第です。理想的な世界では、それらすべてをクリーンアップします。理想的な世界では、私は髪を持っているでしょう.

それとも悪いことで、Android 開発チームと Android 書籍の著者の半数がそのことを忘れていたのでしょうか?

それは常に「悪いこと」でした。

「Android 開発チームの半分」とは言えません。早い段階で、彼らは開発者が既存の開発の専門知識を適用して動作の鈍さを検出することを期待していたと思います。これは、他のプラットフォームのパフォーマンスの問題と大きな違いはありません。Loader時間の経過とともに、この問題を軽減するためのシステム レベルの変更 (例: YAFFS2->ext4) に加えて、開発者をポジティブ パス (例: フレームワーク) に導くためのより多くのパターンを提供してきました。部分的には、シングルスレッド UI など、Android がパフォーマンスに関連する明確な課題をもたらす場所に対処しようとしています。

同様に、すべての Android 書籍の著者を代表することはできません。Android の特徴と機能に焦点を当てていたので、本の初期版ではパフォーマンスの問題に焦点を当てていませんでした。時間が経つにつれて、これらの分野でより多くのアドバイスを追加してきました。また、これらのトピックに関連するオープン ソース コードも提供しています。2012 年には、これらの問題に取り組み続けるために、書籍を大幅に改訂し、さらに多くのオープン ソース プロジェクトを作成する予定です。あなたの口調を考えると、私 (そしておそらく他の人たち) は、この点に関してあなたの目には完全に失敗していると思います。あなたの意見を歓迎します.

于 2011-11-30T00:39:26.377 に答える