Java依存性注入：Dagger 1とDagger 2のどちらが良いですか？
Dagger 2 の Dagger 1 に対する利点は何ですか？
これまでのところ私は（ちょうど）2を見つけました：
- Dagger 2を使用すると、Proguardでコードの難読化を使用できます
- Dagger 2の方が高速です（Androidアプリケーションに使用する場合、それほど利点はありませんが、ある種のサーバーに使用する場合は重要です）
同時に、大きな欠点が1つ見つかりました。Dagger2ではモジュールオーバーライド（@Module(overrides = true)）を使用できないため、少なくとも私にとっては非常に煩わしいものです。これは、単体テストに非常に役立ちました。
他に長所/短所はありますか？
https://blog.gouline.net/2015/05/04/dagger-2-even-sharper-less-square/ と http：//から得られるいくつかの利点と欠点google.github.io/dagger/dagger-1-migration.html ：
ダガー2の利点：
- これ以上の反映はありません-すべてが具体的な呼び出しとして行われます（ProGuardは構成なしで動作します）
- ランタイムグラフの構成が不要-リクエストごとのケースを含め、パフォーマンスが向上します
- 追跡可能-生成されたコードが改善され、リフレクションがないため、コードが読みやすく、わかりやすくなります
- Dagger 1でサポートされる唯一の2つのタイプであったフィールドとコンストラクターの注入に加えて、メソッドの注入をサポートします。
- モジュールはDagger 1よりも少ない構成で済みます
- ユーザーが整形式のスコープ注釈を使用できるようにします。 Dagger 1は、_
@Singleton_という1つのスコープのみをサポートしていました。
そして不利な点：
inject()メソッドには、インジェクションターゲットとの強い型の関連付けがあります。これはデバッグには適していますが、基本クラス（基本アクティビティ、フラグメントなど）から注入する一般的な方法が複雑になります。- コンポーネントの実装では、プロジェクトを再構築して表示する必要があり、インジェクション関連のコンパイルエラーがあると、クラスが表示されなくなります（つまり、生成されません）。
overridesをサポートしていません。単純なテスト偽物をオーバーライドするモジュールは、その動作をエミュレートするモジュールのサブクラスを作成できます。オーバーライドを使用し、依存性注入に依存するモジュールは、オーバーライドされたモジュールが2つのモジュール間の選択肢として表されるように分解する必要があります。
EDIT 2016/11/16：これは技術的な利点ではありませんが、Dagger 1は非推奨になり（2016年9月15日現在）、廃止されます。積極的に開発される。彼らはDagger2への移行を推奨しています。
toothpick をご覧になることはお勧めしません。
共著者として、私は明らかに偏見がありますが、ええ、これははるかに使いやすく、少なくともほとんどの場合、短剣よりも高速です。そして実際、スコープツリーは、複数のアクティビティにまたがるスコープでインスタンスをリサイクルするなど、より高度な機能を開発するための非常に強力な方法です。