web-dev-qa-db-ja.com

Androidメモリガイドの「依存性注入フレームワークを回避する」は、Daggerにも適用されますか？

そこで、メモリパフォーマンスに関するAndroidの記事でこのベストプラクティスに出会いました。

http://developer.Android.com/training/articles/memory.html

彼らは言った

依存性注入フレームワークを避ける

GuiceやRoboGuiceなどの依存性注入フレームワークを使用すると、作成するコードを簡素化し、テストやその他の構成変更に役立つ適応環境を提供できるため、魅力的な場合があります。ただし、これらのフレームワークは、注釈を探すためにコードをスキャンすることで多くのプロセス初期化を実行する傾向があります。これにより、必要ない場合でもかなりの量のコードをRAMにマッピングする必要があります。これらのマッピングされたページはクリーンメモリに割り当てられるため、Androidはそれらをドロップできますが、ページが長期間メモリに残されるまでは発生しません。

しかし、 Dagger は高速であると主張しています。どちらに行けばいいのかわかりませんか？

androidperformancedependency-injectiondagger
60
toy

この推奨事項は、notをすべての依存性注入フレームワークに等しく適用します。

..frameworks [Guiceのように機能する]は、/を使用してコードをスキャンすることにより、多くのプロセスの初期化を実行する傾向があります、これはrequire大量のコードをRAMにマップする必要がありますが、必要ありません。

したがって、does n'tというDI/IoCフレームワークを使用して、上記の[実行時]アノテーションをスキャンし、[過剰な]リフレクションの使用を暗示している場合、この理由はありません。適用しません。 Dagger は注釈を使用しますが、これらは seddifferently Guiceよりも1 記載されている問題を回避します。

Daggerは「Afast依存性インジェクターfor AndroidおよびJava」と記述されているため、著者はこの目的とそれはそのようなターゲットに適していると信じています-どうぞ、試してみてください。

1 Daggerは、実行時の注釈とリフレクションに依存する代わりに、コンパイル時の注釈（まあ、 mostly ）を使用します。メモリガイドが警告していた問題の原因は、実行時の注釈のスキャンと反映です。

37
user2864740

Androidチームは最近、推奨事項を 開発者がDagger 2を使用することを推奨 に更新しました。

以前の推奨事項は、反省の高いコストに基づいていました。 Dagger 2はリフレクションを使用しなくなったため、Dagger 1は使用したため、"不要なランタイムコストやメモリ使用なしでAndroidアプリで使用できます"。

（免責事項：私はDagger 2チームマネージャーです。）

13
JeremyManson

Daggerの作成者である@JakeWhartonは、 Butterknife と呼ばれるより単純なビュー「インジェクション」フレームワークも作成しました。

RoboGuiceのすべての変換者がDaggerでの「ビューインジェクション」の欠如について不満を言っていたため 。

次のように使用します。

class ExampleActivity extends Activity {
  @InjectView(R.id.title) TextView title;
  @InjectView(R.id.subtitle) TextView subtitle;
  @InjectView(R.id.footer) TextView footer;

  @Override public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.simple_activity);
    ButterKnife.inject(this);
    // TODO Use "injected" views...
  }
}
0
serv-inc