Thread class in Android is no different from the Thread class in regular Java programming. When the application starts, it will get an implementation of the Linux native thread. The thread class creates the execution environment for tasks, that are represented using Runnable interface. The Thread implements Runnable, so that the task will be executed in the environment. The task can be defined by the Thread or it can be injected during Thread execution. Occasionally the application wants to terminate the thread's execution before it has finished its task. For example, if the application is running through data synchronization which is taking longer time, that thread can be halted / stopped to cancel the process. The UI Thread will receive the input from the user and it instructs the background thread to stop the process. A thread cannot be directly terminated. Threads can be interrupted, which is a request to the Thread that it should terminate. Finally the Thread can take a decision whether to follow the instruction or not.
Mobile applications can crash when they are driven through memory leaks. Memory leaks can be detrimental to the application strategy and they will also effect the overall performance of the device. Thread and their communication plays a very important role to have a better UI experience. Memory leaks can occur in different occasions for each of the asynchronous techniques used on Android. A memory leak when we define very traditionally, is the memory allocated by the application that is not used any more but never identified by the GC ( Garbage Collector ) to claim it back. So the memory will be occupied until the application process is killed. The memory that is allocated for a long time is called Memory Hogging.
For every application running on the Android device a VM instance will be handling the process in which the application is running. The Dalvik Virtual Machine ( DVM ) , a totally optimized VM to run applications at extremely low memory conditions will also optimize memory usage. It reclaims the memory frequently with the help of GC from the shared memory called as Heap. But the condition is the objects, references which are used in the application should be unreachable. Once the memory becomes unreachable the GC will finalize the object and claims it back. If the object reachable, it is not eligible for Garbage Collection, so GC cannot do anything w.r.t to reachable objects.
The following are the different types of application threads.
- UI thread
- Binder thread
- Worker thread
2 important characteristics of memory leaks w.r.t threads :
Potential risk : The risk for a memory leak increases for long-lived threads. Thread that are short-lived will do their job and they will terminate making the job easy of GC to reclaim the memory. Long-lived threads will have continuous references to the object even though they are not required.
Leak size : Application that leaks a small amount of memory works fine and it will pass the test. But if the leak size is high like images, multimedia content etc, that application has to pay the
price. A few leaks may be enough to exhaust the entire memory.
Follow these to avoid memory leaks
- Use static inner classes
- Use weak references
- Clean up message queue
- Retain worker threads
- Stop worker thread execution