“注入一切”在Android中是一种不好的做法吗？

Question

在研究依赖注入时，我发现了一些建议 inject everything 的方法和其他建议 it's not necessary to do so 的方法。

在我当前的项目中，我关于依赖注入的经验法则是“如果该类是由我创建的，我将其设为可注入”。换句话说，只有像SimpleDateFormat、ArrayList、HashMap 这样的类在我的项目中是新的。我这样做的意图是，一旦在Activity 中调用Injector.getApplicationComponent().inject(this)，我就可以在任何地方@Inject 任何类。基本上我所有的类都有一个带有@Inject的非参数构造函数。

我主要使用 DI，因为我认为一旦 new 运算符被 Dagger 生成的类独占使用，它会提高性能和内存使用率。但是我从 Dagger 1 的开发者那里读到了post 说 DI 对性能没有影响，使用基本上是为了减少样板。

第一个问题是：

• Dagger 2 在 Android 应用程序中没有任何性能优势？

我的项目运行没有问题，我认为“注入一切”的方法有助于更好地组织，尽管有一些缺点。

使用这种方法的一个例子是下面的类：

public class TimelineEntryAdapter {

@Inject
Provider<TwitterEntry> mTwitterProvider;

@Inject
Provider<InstagramEntry> mInstagramProvider;

@Inject
Provider<FacebookEntry> mFacebookProvider;

@Inject
TimelineEntryComparator mComparator;

@Inject
public TimelineEntryAdapter() {
}

第二个问题是：

• 在 Android 中注入所有内容是一种不好的做法吗？

如果第二个问题的答案是“否”，那么有没有更好的方法来处理非参数构造函数来创建类？因为当我创建一个带有@Inject 注解的非args 构造函数并且一个类需要一些参数才能使用时，我必须使用setters：

public class SavelArtist {

private MusicBrainzArtist mMusicBrainzArtist;

private DiscogsArtist mDiscogsArtist;

private List<SavelTweet> mTweetList;

private SpotifyArtist mSpotifyArtist;

private List<SavelInstagram> mInstaTimeline;

private List<SavelFacebook> mFacebookTimeline;

private List<SavelRelease> mReleases;

@Inject
Provider<SavelRelease> mReleaseProvider;

@Inject
public SavelArtist() {
}

public void setMusicBrainzArtist(MusicBrainzArtist mbArtist) {
    mMusicBrainzArtist = mbArtist;
}

public void setDiscogsArtist(DiscogsArtist discogsArtist) {
    mDiscogsArtist = discogsArtist;
}

public void setTweetList(List<SavelTweet> tweetList) {
    mTweetList = tweetList;
}

public void setSpotifyArtist(SpotifyArtist spotifyArtist) {
    mSpotifyArtist = spotifyArtist;
}

public void setInstaTimeline(List<SavelInstagram> instaTimeline) {
    mInstaTimeline = instaTimeline;
}

public void setFacebookTimeline(List<SavelFacebook> fbTimeline) {
    mFacebookTimeline = fbTimeline;
}

所有参数都可以在构造函数上设置，一旦在流程中同时获取。

Answer 1

在研究依赖注入时，我发现了一些建议注入所有内容的方法，而另一些方法则表示没有必要这样做。

您引用的froger_mcs blog entry 并不主张注入所有内容。它非常清楚地指出：

这篇文章的目的是展示我们可以做什么，而不是我们应该做什么。

它继续说明注入所有东西的缺点：

如果您想将 Dagger 2 用于项目中的几乎所有内容，您将很快看到生成的代码使用了 64k 方法计数限制的一大块进行注入。

现在，关于你的问题：

Dagger 2 在 Android 应用中没有任何性能优势？

虽然 Dagger 2 提供了优于其他基于反射的 DI 框架（例如 Guice）的性能优势，但它并没有声称比通过调用构造函数手动构造对象图提供任何性能优势。您可以自己检查生成的类，看看它们确实最终仍会调用构造函数。

在 Android 中注入所有内容是一种不好的做法吗？

好吧，让我们来看看以下非常常见的 Android 代码：

Intent nextActivity = new Intent(this, NextActivity.class);
startActivity(nextActivity);

我们是否应该提取一个IntentFactory 并使用Dagger 2 注入它只是为了避免这里的new 关键字？在这一点上，很容易接近迂腐。 other answer you quoted 中关于注射剂和新剂之间区别的建议更加灵活和优雅。

继续你的下一个问题：

如果第二个问题的答案是“否”，那么有没有更好的方法来处理非参数构造函数来创建类？因为当我使用 @Inject 注释创建一个非参数构造函数并且一个类需要一些参数才能使用时，我必须使用 setter：

使用 setter 是错误的参数方法。你应该区分依赖和参数。依赖项通常与对象本身具有相同的生命周期。在对象的生命周期中，可以使用不同的参数调用为该对象公开的方法。

Answer 2

我不是依赖管理方面的专业人士，但我在公司中使用它，所以这是我的看法。

注入一切都基本好了。我将在其他地方使用的所有东西（其他模块、类、包）都制作成可注入的，并且只有静态的东西（带有隐藏构造函数的静态类），只在内部使用的东西是不可注入的。

它有什么好处？ 那么依赖系统将负责获取实例并丢弃它。它会自动清理。此外，在类上使用作用域将使您能够创建一个在整个应用程序中始终只有一个实例的类（多个线程访问它）或使其可重用（每个需要它的线程都是一个自己的实例）。

我也认为你可以像这样清理你的类：

@Reusable (Maybe a good Idea?)
public class SavelArtist {

private MusicBrainzArtist mMusicBrainzArtist;

private DiscogsArtist mDiscogsArtist;

private List<SavelTweet> mTweetList;

private SpotifyArtist mSpotifyArtist;

private List<SavelInstagram> mInstaTimeline;

private List<SavelFacebook> mFacebookTimeline;

private List<SavelRelease> mReleases;

private Provider<SavelRelease> mReleaseProvider;

public SavelArtist() {
}

@Inject
public void init(Provider<SavelRelease> mReleaseProvider) {
  this.mReleaseProvider = mReleaseProvider;
}

考虑总是声明类的范围。是单例吗？会重复使用吗？一旦应用程序变得复杂和庞大，这个小细节可以为您节省时间。

使用方法 init 来声明所有注入变量的优点是代码看起来很干净，易于维护，因为注入的所有内容都在这个位置。但这实际上是偏好:)