Почему мы ограничиваем взгляды и докладчиков в MVP?

Question

Я размышляю над кодом, который я прочитал в этой статье https://github.com/frogermcs/GithubClient/tree/1bf53a2a36c8a85435e877847b987395e482ab4a

BaseActivity.java:

public abstract class BaseActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setupActivityComponent();
    }

    protected abstract void setupActivityComponent();
}

SplashActivityModule.java:

@Module
public class SplashActivityModule {
    private SplashActivity splashActivity;

    public SplashActivityModule(SplashActivity splashActivity) {
        this.splashActivity = splashActivity;
    }

    @Provides
    @ActivityScope
    SplashActivity provideSplashActivity() {
        return splashActivity;
    }

    @Provides
    @ActivityScope
    SplashActivityPresenter
    provideSplashActivityPresenter(Validator validator, UserManager 
    userManager, HeavyLibraryWrapper heavyLibraryWrapper) {
        return new SplashActivityPresenter(splashActivity, validator, 
                                           userManager, heavyLibraryWrapper);
    }
}

SplashActivityPresenter внедряется внутри SplashActivity.java:

public class SplashActivity extends BaseActivity {
    ...

    @Inject
    SplashActivityPresenter presenter;

    @Override
    protected void setupActivityComponent() {
        GithubClientApplication.get(this)
                .getAppComponent()
                .plus(new SplashActivityModule(this))
                .inject(this);
    }

SplashActivityPresenter.java:

public class SplashActivityPresenter {
    public String username;

    private SplashActivity splashActivity;
    private Validator validator;
    private UserManager userManager;
    private HeavyLibraryWrapper heavyLibraryWrapper;

    public SplashActivityPresenter(SplashActivity splashActivity, 
        Validator validator, UserManager userManager, 
        HeavyLibraryWrapper heavyLibraryWrapper) {
        this.splashActivity = splashActivity;
        this.validator = validator;
        this.userManager = userManager;
            this.heavyLibraryWrapper = heavyLibraryWrapper;

        //This calls should be delivered to ExternalLibrary right after it will be initialized
        this.heavyLibraryWrapper.callMethod();
        this.heavyLibraryWrapper.callMethod();
        this.heavyLibraryWrapper.callMethod();
        this.heavyLibraryWrapper.callMethod();
    }

    public void onShowRepositoriesClick() {
        if (validator.validUsername(username)) {
            splashActivity.showLoading(true);
            userManager.getUser(username).subscribe(new 
SimpleObserver<User>() {
                @Override
                public void onNext(User user) {
                    splashActivity.showLoading(false);
                    splashActivity.showRepositoriesListForUser(user);
                }

                @Override
                public void onError(Throwable e) {
                    splashActivity.showLoading(false);
                    splashActivity.showValidationError();
                }
            });
        } else {
            splashActivity.showValidationError();
        }
    }
}

1. Почему область видимости для действия?Предположим, мы не охватили это.Представление удерживается ведущим.По завершении действия доступ к докладчику прекращается, поэтому он подходит для сбора мусора.Транзитивно, ссылка на представление также будет иметь право на сборку мусора, верно?

2. Зачем привязывать докладчика к действию?Предположим, мы не охватили это.Действие создает нового докладчика для каждого экземпляра действия (каждый раз, когда вы впервые вводите действие или поворачиваете экран).По окончании упражнения доступ к докладчику прекращается, поэтому он может участвовать в сборке мусора.

Какой вред оставляет представление и докладчик без области?Есть ли способ для меня, чтобы проверить преимущества scoping против unscoping?

Answer 1

Этот ответ может быть не идеальным. но это может помочь вам понять больше.
- здесь - это когда объект имеет право на сборку мусора.
-если мы не сфера деятельности и ведущий. мы могли бы закончить мертвым замком для сборки мусора. где активность содержит ссылку на докладчика, а докладчик - ссылку на действия.
-два основных вопроса, которые я вижу там

1. Утечка контекста
2. Недостаточно памяти (Редкий случай.)
1) Когда происходит утечка контекста, действие завершено, и вы хотите что-то обновить для этого действия (когда вы не выпускаете докладчика).
Предположим, что SimpleObserver onNext вызывается после завершения действия. это приведет к ошибкам. так что как вам нужно освободить ссылку на активность. (просто присвойте null в методе onDestroy.)
2) активность и ведущий, держащие друг друга в ссылках, никогда не будут собирать мусор, пока приложение не будет уничтожено. так что вам может не хватить памяти.