When an application is launched in Android, it creates the primary thread of execution, referred to as the “main” thread. The 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 etcetera 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
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
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:
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.
Type #2. Threading Components that Don’t Attach to an Activity/Fragment
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.
A Typical Design Mistake
Look at the code snippet below:
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 being used in new code, however.
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 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.
A detailed discussion about “Service Binding and Threads” could be found here for referring.
Attention reader! Don’t stop learning now. Get hold of all the important Java Foundation and Collections concepts with the Fundamentals of Java and Java Collections Course at a student-friendly price and become industry ready. To complete your preparation from learning a language to DS Algo and many more, please refer Complete Interview Preparation Course.