Почему работающие обратные вызовы автоматически уничтожают активность?

Есть ли способ определить, был ли в приложении создан какой-либо метод postDelayed относительно библиотеки?

Вы можете использовать API MessageQueue.IdleHandler. См. LooperIdlingResource как эспрессо определяет, подходит ли время для активации в утверждении.

    @Override
    public boolean queueIdle() {

      QueueState queueState = myInterrogator.determineQueueState();
      if (queueState == QueueState.EMPTY || queueState == QueueState.TASK_DUE_LONG) {
        ...
      } else if (queueState == QueueState.BARRIER) {
        ...
      }

      return true;
    }

Это поможет вам понять, есть ли сообщение в MessageQueue, но не скажет вам, какое именно сообщение.

Решение, которое я бы выбрал, состоит в том, чтобы отменить планирование Runnable, которое у вас есть postDelayed в пределах onStop действия, потому что, если Activity (тот, что из библиотеки) был запущен, то вызывается onStop из SplashScreen:

public class SplashActivity extends AppCompatActivity {

  private final Runnable myRunnable = () -> {
    // launch `NextActivity`
  };
  private final Handler handler = new Handler();

  @Override protected void onCreate(@Nullable Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_splash);

    handler.postDelayed(myRunnable, 3000);
  }

  @Override
  protected void onStop() {
    super.onStop();
    handler.removeCallbacks(myRunnable);
  }

}

Вам нужно лучше объяснить проблему. Я запутался между отношением экрана-заставки и другими действиями, и если проблема связана с postDelayed() или с жизненным циклом действий. Я бы предложил крошечную графическую диаграмму, объясняющую, какие действия запускают другие.

Что касается postDelayed(), в общем, если вы делаете

 mHandler.postDelayed(new Runnable() { ... });

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

Runnable mLaunchSplashRunnable = new Runnable() { ... };
Runnable mLaunchContactsRunnable = new Runnable() { ... };

.
.

mHandler.postDelayed (mLaunchSplashRunnable, DELAY);
mHandler.postDelayed (mLaunchContactsRunnable, DELAY);

.
.

Поскольку исполняемые объекты теперь не являются анонимными, вы можете удалить их из очереди в любое время:

void removeLibraryDelayedRunnables() {
   mHandler.removeCallbacks(mLaunchSplashRunnable);
   mHandler.removeCallbacks(mLaunchContactsRunnable);
}

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

Метода запроса Handler, если конкретный Runnable поставлен в очередь, на самом деле, не существует, но вы можете использовать флаг boolean, установить его, когда исполняемый файл поставлен в очередь, и сбросить его, когда запускается Runnable, чтобы указать, что исполняемый файл находится в очереди. в ожидании.

Если я лучше пойму вашу проблему, я смогу помочь больше.

Почему бы вам не использовать статическую логическую переменную, чтобы определить, работает ли ваш экран-заставка или нет, когда вы собираетесь его вызвать.

Проблема в том, что как только вы начинаете запускать действия одно за другим, через некоторое время, когда ваше приложение потребляет много памяти, поэтому Android предполагает, что предыдущие действия могут быть уничтожены, чтобы оптимизировать систему и избежать замедления работы устройства, так работают мобильные устройства. , поэтому ваша основная активность, использующая API, уничтожается системой: пожалуйста, поймите жизненный цикл активности:

https://developer.android.com/guide/components/activities/activity-lifecycle.html

см. после onStop()... это относится к вашему приложению.

Надеюсь, что это поможет вам...

Я думаю, вам следует инвертировать логику в программе. Активность должна начинаться с вашей деятельности, а не со службы.

Для этого вы можете зарегистрировать BroadcastReceiver при создании каждого действия https://developer.android.com/reference/android/content/BroadcastReceiver.html и используйте sendBroadcast из службы https://developer.android.com/guide/components/broadcasts.html, когда необходимо запустить действие, чтобы дать команду широковещательному приемнику начать необходимое действие.

Использование обратного вызова с действием, связанным во времени, может оказаться не очень удачным решением для вашего SDK. Рассмотрите возможность использования наблюдаемых для передачи данных с сетевого уровня в действие, которому нужны данные.

Добавляя наблюдателя к активности, которой нужны данные, которая следит за выполнением сетевого вызова, вы предоставляете данные только активному наблюдателю. Таким образом, если действие закрывается до завершения вызова, данные не передаются в закрытое действие.

Это также позволяет вам создавать слабые ссылки на вашу библиотеку таким образом, что вам не нужно беспокоиться о утечке окон.

Так как мы еще не видели ваш код. Мой ответ будет слишком общим, извините за это.

Я думаю, вам следует сначала проверить logcat, чтобы увидеть, есть ли какие-либо исключения, связанные с закрытием этих действий. Если об этом ничего нет. Просто проверьте все блоки try catch, чтобы убедиться в этом. Итак, после того, как вы убедитесь, что речь не идет о каких-либо исключениях, проверьте файл AndroidManifest, чтобы увидеть «Режимы запуска» действий. Это также может привести к автоматическому закрытию.

Если все ваши действия находятся в стандартном режиме, попробуйте изменить хотя бы один режим запуска действий, чтобы запретить его закрытие, и повторите попытку. Если это также не имеет никакого смысла, проверьте код на наличие вызовов finish().

Все еще не повезло? Тогда я предполагаю, что это может быть случай ANR, который вы должны проверить на наличие утечек памяти, которые замораживают ваше приложение и, возможно, закрывают действия. Вероятно, эти runnables каким-то образом разрушают ваше приложение.

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

Действия могут быть уничтожены в любое время, поэтому, когда это произойдет, вам нужно позаботиться и об удаляемых диалогах. В жизненном цикле действия вам также нужно будет уничтожить «Диалоги», иначе вы получите «Протекшее окно».

Кроме того, диалоги, которые ссылаются на действия, выиграют от использования слабой ссылки на действия, вы затем будете использовать слабую ссылку, чтобы сообщать о действиях пользователей по отношению к действию.

@Override
public void onAttach(Activity activity) {
    super.onAttach(activity);
    listener = new WeakReference<>((MyActionListener) activity);
    activityWeakReference = new WeakReference<>(activity);
}

Прежде чем показывать диалоговое окно, я также хотел бы убедиться, что действие не находится в процессе завершения:

if (myActivityWeakReference.get() != null && !myActivityWeakReference.get().isFinishing()) {
  // show dialog
}

Затем, когда вы хотите управлять вращением устройства, где действия воссоздаются, вы можете использовать следующее вместе со своими диалогами:

    @Override
public void onCreate(@Nullable Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setRetainInstance(true);
}

/**
 * Prevent the dialog being dismissed when rotated, when using setRetainInstance
 */
@Override
public void onDestroyView() {
    if (getDialog() != null && getRetainInstance()) {
        getDialog().setDismissMessage(null);
    }
    super.onDestroyView();
}