When an application is launched in Android, it creates the primary thread of execution, referred to as the “main” thread. Most thread is liable for dispatching events to the acceptable interface widgets also as communicating with components from the Android UI toolkit. To keep your application responsive, it’s essential to avoid using the most thread to perform any operation which will find yourself keeping it blocked.
Network operations and database calls, also as loading of certain components, are common samples of operations that one should avoid within the main thread. Once they are called within the main thread, they’re called synchronously, which suggests that the UI will remain completely unresponsive until the operation completes. Due to this, tasks requiring calls are usually performed in different threads, which in turn avoids blocking the UI and keeps it responsive while the tasks are being performed. (i.e., they’ve performed asynchronously from the UI).
Android provides some ways of making and managing threads, and lots of third-party libraries exist that make thread management tons more pleasant. However, with numerous approaches at hand, choosing the proper one are often quite confusing. In this article, you’ll study some common scenarios in Android development where threading becomes essential and a few simple solutions which will be applied to those scenarios and more.
Threading in Android
In Android, you’ll categorize all threading components into two basic categories:
- Threads that are attached to an activity/fragment: These threads are tied to the lifecycle of the activity/fragment and are terminated as soon because the activity/fragment is destroyed.
- Threads that aren’t attached to any activity/fragment: These threads can still run beyond the lifetime of the activity/fragment (if any) from which they were spawned.
Type #1: Threading Components that Attach to an Activity/Fragment
1. ASYNCTASK
AsyncTask is the most elementary Android component for threading. It’s super easy and simple to use it’s also good for some basic scenarios
Java
public class GeeksActivity extends Activity { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); // Adding Task to the List (Async) new MyTask().execute(url); } private class MyTask extends AsyncTask<String, Void, String> { @Override protected String doInBackground(String... params) { String url = params[0]; return doSomeWork(url); } @Override protected void onPostExecute(String result) { super.onPostExecute(result); // do something with the result } }} |
AsyncTask, however, falls short if you would like your deferred task to run beyond the lifetime of the activity/fragment. The fact that even the slightest of screen rotation can cause the activity to be destroyed is simply awful! So We Come to:
2. LOADERS
Loaders are the answer to the awful nightmare mentioned above. Loaders are great at performing in that context and they automatically stop when the activity is destroyed, even more, the sweet fact is that they also restart themselves after the activity is recreated.
Java
public class GeeksActivity extends Activity{ @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); // Getting instance of loader manager getLoaderManager().initLoader(1, null, new MyLoaderCallbacks()); } private class MyGeekyLoaderCallbacks implements LoaderManager.LoaderCallbacks { // Overriding the method @Override public Loader onCreateLoader(int id, Bundle args) { return new MyLoader(Lazyroar.this); } @Override public void onLoadFinished(Loader loader, Object data) { } @Override public void onLoaderReset(Loader loader) { } } private class MyLoader extends AsyncTaskLoader { public MyLoader(Context context) { super(context); } @Override public Object loadInBackground() { return someWorkToDo(); } }} |
Type #2. Threading Components that Don’t Attach to an Activity/Fragment
1. SERVICE
Service could be thought of as a component that’s useful for performing long (or potentially long) operations with no UI. Yes, you heard that right! Service’s don’t have any UI of theirs! Service runs within the main thread of its hosting process; the service doesn’t create its own thread and doesn’t run during a separate process unless you specify otherwise.
Java
public class ExampleServiceGeeks extends Service { @Override public int onStartCommand(Intent intent, int flags, int startId) { doSomeLongProccesingWork(); stopSelf(); // Self stopping the service // by calling stopSelf(); return START_NOT_STICKY; } @Nullable @Override // Binding the service to the Method calls public IBinder onBind(Intent intent) { return null; }} |
A Typical Design Mistake
Look at the code snippet below:
Java
public class Lazyroar extends Activity { // ... public class MyAsyncTask extends AsyncTask<Void, Void, String> { @Override protected void onPostExecute(String result) {...} @Override protected String doInBackground(Void... params) {...} }} |
Kotlin
class Lazyroar : Activity() { // ... inner class MyAsyncTask : AsyncTask<Unit, Unit, String>() { override fun onPostExecute(result: String) {...} override fun doInBackground(vararg params: Unit): String {...} }} |
What seems wrong?
The mistake which happened during this snippet is that the code declares the threading object MyAsyncTask as a non-static inner class of some activity (or an inner class in Kotlin). This declaration creates implicit regard to the enclosing Activity instance. As a result, the thing contains regard to the activity until the threaded work completes, causing a delay within the destruction of the referenced activity. Hence, we get a delay, which in turn harms the system and puts a heavy burden on the memory. A direct solution to the present problem would be to define your overloaded class instances either as static classes or in their own files, thus removing the implicit reference.
Another solution would be to always cancel and pack up background tasks within the appropriate Activity lifecycle callback, like onDestroy. This approach is often tedious and error-prone, however. As a general rule, you ought to not put complex, non-UI logic directly in activities. Additionally, AsyncTask is now deprecated, and it’s not recommended to be used in new code, however.
Thread Priority
As described in Processes and therefore the Application Lifecycle, the priority that your app’s threads receive depends partly on where the app is within the app lifecycle. As you create and manage threads in your application, it’s important to line their priority in order that the proper threads get the proper priorities at the proper times.
If the priority is set too high, then that thread might disrupt the UI Thread and even block it in some adverse cases and even the Render Thread, causing the app performance issues like dropped frames, lag, sluggish app UI, etc.
Every time you create a thread, you ought to call setThreadPriority(). The system’s thread scheduler gives preference to threads with high priorities, balancing those priorities with the necessity to eventually get all the work done. Generally, threads within the foreground group get around 95% of the entire execution time from the device, while the background group gets roughly 5%.
So, if you’re getting to rage on by doing long-running work on the pixels, this might be a far better solution for you. When your app creates a thread using HandlerThread don’t forget to line the thread’s priority supported by the sort of labor it’s doing. Remember, CPUs can only handle a little number of threads in parallel. Setting the priority helps the system know the proper ways to schedule this work when all other threads are fighting for attention.
Message Queue Explaining the Thread Process
A detailed discussion about “Service Binding and Threads” could be found here for reference.
