[Перевод] Руководство по фоновой работе в Android. Часть 2: Loaders27.02.2018 15:33

Это вторая из серии статей об инструментах и методах фоновой работы в Android. Ранее уже были рассмотрены AsyncTask, в следующих выпусках — ThreadPools с EventBus, RxJava 2 и корутины в Kotlin.

В предыдущем тексте мы упомянули, что у AsyncTasks есть несколько проблем. Давайте вспомним две из них:

• AsyncTasks ничего не знают о жизненном цикле Activity. При неправильном обращении вы в лучшем случае получите утечку памяти, а в худшем — сбой.
• AsyncTask не поддерживает сохранение состояния прогресса и повторное использование результатов загрузки.

Смысл первой проблемы вот в чем: чтобы обновить UI в методе onPostExecute, нам нужна ссылка на конкретный view или на всю Activity, к которой он относится. Наивный подход в том, чтобы хранить эту ссылку внутри самого AsyncTask:

public static LoadWeatherForecastTask extends AsyncTask {

    private Activity activity;

    LoadWeatherForecastTask(Activity activity) {
        this.activity = activity;
    }
}

Проблема в том, что как только пользователь поворачивает устройство, Activity уничтожается, и ссылка устаревает. Это приводит к утечке памяти. Почему? Вспомним, что наш метод doInBackground вызывается внутри Future, исполняемого на executor — статическом члене класса AsyncTask. Это делает наш объект AsyncTask, а также Activity, строго достижимыми (потому что статика является одним из корней GC), а следовательно, неподходящими для сборки мусора. Это в свою очередь означает, что несколько поворотов экрана могут вызвать OutOfMemoryError, потому что Activity занимает приличный объем памяти.

Исправить эту ошибку можно с помощью WeakReference:

public static LoadWeatherForecastTask extends AsyncTask {

  private WeakReference activityRef;
  
  LoadWeatherForecastTask(Activity activity) {
    this.activityRef = new WeakReference<>(activity);
  }
}

Хорошо, от OOM мы избавились, но результат выполнения AsyncTask в любом случае потерян, и мы обречены вновь его запускать, разряжая телефон и расходуя трафик.

Для того, чтобы исправить это, команда Android несколько лет назад предложила Loaders API («Загрузчики»). Посмотрим, как использовать это API. Нам нужно реализовать интерфейс Loader.Callbacks:

inner class WeatherForecastLoaderCallbacks : LoaderManager.LoaderCallbacks {

   override fun onLoaderReset(loader: Loader?) {

   }

   override fun onCreateLoader(id: Int, args: Bundle?): Loader {
      return WeatherForecastLoader(applicationContext)
   }

   override fun onLoadFinished(loader: Loader?, data: WeatherForecast?) {
      temperatureTextView.text = data!!.temp.toString();
   }
}

Как можно заметить, метод onLoadFinished очень похож на onPostExecute, который мы реализовывали в AsyncTask.

Нам нужно создать сам Loader:

class WeatherForecastLoader(context: Context) : AsyncTaskLoader(context) {

   override fun loadInBackground(): WeatherForecast {
      try {
         Thread.sleep(5000)
      } catch (e: InterruptedException) {
         return WeatherForecast("", 0F, "")
      }

      return WeatherForecast("Saint-Petersburg", 20F, "Sunny")
   }
}

И вызвать initLoader () с id нашего Loader:

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    ...
    val weatherForecastLoader = WeatherForecastLoaderCallbacks()
    loaderManager
      .initLoader(forecastLoaderId, Bundle(), weatherForecastLoader)
}

Пожалуйста, обратите внимание: WeatherForecastLoaderCallbacks — вложенный класс нашей Activity; LoaderManager хранит ссылку на этот объект Callbacks —, а значит, и на саму Activity тоже

Немало кода, да? Но мы тут получаем важное преимущество. Во-первых, Loader оказывается переиспользован при повороте экрана (или других изменениях конфигурации). Если экран повернули, onLoadFinished будет вызван с передачей результата, загруженного нами ранее.

Другое преимущество в том, что у нас не происходит утечка памяти, хотя доступ к Activity у нас остается, позволяя обновлять интерфейс.

Круто, у AsyncTask обоих этих преимуществ не было! Давайте теперь разберёмся, как всё это работает.

Тут-то и начинается главное веселье. Я думал, что LoaderManager хранится где-то внутри Application, но настоящая реализация оказалась куда более интересной.

LoaderManager создается при создании экземпляра Activity:

public class Activity {
    
    final FragmentController mFragments =       
           FragmentController.createController(new HostCallbacks());
    
    public LoaderManager getLoaderManager() {
        return mFragments.getLoaderManager();
    }
}

FragmentController.createController — это просто именованный конструктор для класса FragmentController. FragmentController делегирует создание LoaderManager в HostCallbacks (вложенному классу нашей Activity), реализация выглядит так:

LoaderManagerImpl getLoaderManagerImpl() {
    if (mLoaderManager != null) {
        return mLoaderManager;
    }
    mCheckedForLoaderManager = true;
    mLoaderManager = getLoaderManager("(root)", mLoadersStarted, true /*create*/);
    return mLoaderManager;

Как видите, LoaderManager для самой Activity инициализируется лениво; экземпляр LoaderManager не создается до тех пор, пока впервые не понадобится. Доступ к LoaderManager нашей Activity происходит по ключу »(root)» в Map LoadersManagers. Доступ к этой Map реализован так:

LoaderManagerImpl getLoaderManager(String who, boolean started, boolean create) {
    if (mAllLoaderManagers == null) {
        mAllLoaderManagers = new ArrayMap();
    }
    LoaderManagerImpl lm = (LoaderManagerImpl)              mAllLoaderManagers.get(who);
    if (lm == null && create) {
        lm = new LoaderManagerImpl(who, this, started);
        mAllLoaderManagers.put(who, lm);
    } else if (started && lm != null && !lm.mStarted){
        lm.doStart();
    }
    return lm;
}

Однако это не последняя запись поля LoaderManager. Посмотрим на метод Activity#onCreate:

@MainThread
@CallSuper
protected void onCreate(@Nullable Bundle savedInstanceState) {
    ...
    if (mLastNonConfigurationInstances != null) {
        mFragments.restoreLoaderNonConfig(
              mLastNonConfigurationInstances.loaders);
    }
    ...
}

Метод restoreLoaderNonConfig в итоге просто обновляет host controller, который теперь является членом класса нового экземпляра Activity, созданной после изменения конфигурации.

При вызове метода initLoader () у LoaderManager уже есть вся информация о Loaders, которые были созданы в уничтоженной Activity. Так что он может опубликовать загруженный результат немедленно:

public abstract class LoaderManager {
    public  Loader initLoader(int id, Bundle args,       
                        LoaderManager.LoaderCallbacks callback) {
       ...

       LoaderInfo info = mLoaders.get(id);

       ...

        if (info == null) {
            info = createAndInstallLoader(id, args, 
                  (LoaderManager.LoaderCallbacks