Android – job scheduler vs runnable: downlink?

For regular background tasks, I see that jobscheduler is often used. Or, there are jobservice and AlarmManager for slightly different use cases. But why not start a new runnable? What are the disadvantages of using runnable for background tasks? Will runnable use more resources when idle?

resolvent:

Runnable is an interface that does not perform any operation except providing a single method named run. Maybe you want to know how to use handlerthread, thread, asynctask, executorservice, jobscheduler, intentservice and AlarmManager?

This is an Android thread memo:

>Runnable: an interface that does nothing by itself, but uses it when interacting with classes related to many other threads > thread: the most basic way to run code from the main thread of the process. > asynctask: the basic Android centric way to run code from the main thread. There is a thread dedicated to all asynctask instances, Therefore, you can only run one in your process at a time > handlerthread: a convenient way to send messages (with possible delays) between the main thread and another thread > executorservice: a powerful thread pool that allows you to take advantage of multiple CPU cores > services (Android) : an Android component with no user interface but its method still runs on the main thread > intentservice: an Android service subclass that you can extend. It contains a background thread on which you can complete work without related activities > AlarmManager: a mechanism provided by the Android system to start Android components at a specific time, But you will forget everything when you restart > jobscheduler: lollipop and the above mechanism provided by the Android system, start the Android service according to the description of the work to be completed, and you can choose to keep the configuration when you restart (now prefer workmanager) > workmanager: Android architecture component (the library provided by Google can run on many Android versions), It works like the jobscheduler, but it can also coordinate multiple jobs

How Android OS manages processes and threads:

When selecting threading mechanism, it is very important to understand how Android OS manages applications. Android OS can see applications and components (activity, service, broadcastreceiver and ContentProvider) in applications. Advanced Android operating system does not know threads in applications

Unlike applications on desktop computers, the application process installed in Android OS has a more fuzzy life cycle. For example, if you start the calculator app, Android will create a Linux Process for it. If you leave the calculator, it usually won't kill the calculator process immediately. If you start using many other applications and don't return to the calculator for a long time, It may eventually decide to reclaim the memory used by the calculator process and end the process. Even if the process exists, the user may put the phone into sleep, and the CPU will stop executing all threads in all processes until the CPU wakes up again. The wake-up lock can prevent the CPU from sleeping. Mechanisms such as workmanager can handle the wake-up lock for you

In practice, this means that you can split threads from activities that have their own lives. As long as the process is active, the thread will not be suspended or stopped by the Android operating system, even if the activity may receive these life cycle callbacks. However, when Android decides to end your process, All threads will also die. As an application developer, the only way to tell Android that it shouldn't kill your process is to create a service, or even make it a foreground service, so that Android knows what's happening in your application, or use workmanager since Android to realize this (it may be a service under the hood...). When using a service, you still need to separate some threads to perform your work, because the service function is executed on the main thread of your process, unless you receive messages through IPC binder calls, and these messages run threads on 16 bound pools. If you call the ContentProvider method through IPC instead of locally, it is the same

Here are some questions to help you determine how to use:

>Are you performing a task that is directly associated with an activity that the user is interacting visually on the screen?

Consider handlerthread, asynctask, or executorservice

>Do you play music in the background or what other users want to control through notifications?

Consider pairing service with handlerthread or something similar

>Are you performing tasks that need to happen sooner or later, but are not directly related to what is happening on the screen now?

Consider using workmanager or AlarmManager for intentservice

>If a user turns off their device immediately when your task is about to start, do you want to try again when you restart the device?

Consider workmanager

As always, it is best to obtain such information directly from the source. For example https://developer.android.com/topic/libraries/architecture/workmanager Google said:

For more tips on this, please read https://developer.android.com/ JavaDocs and guides on