The main reason of low performance Android app is that it runs GC very frequently. Simple in one line : The time for which GC is running the actual app is not running. When the android app runs it allocates so many object on the basis of your code and when the objects that are no longer referred the system call GC when there is memory pressure to deallocate those objects , so if the object allocation and deallocation is occurring on regular basis , the GC is running on regular basis to release memory , So more time the GC is running , your app is not running for that time . So it seems the app is lagging. The app updates its UI every 16ms (considering 60FPS -> 1000ms/60 = 16.67ms~16ms ) for smooth UI rendering . So if the GC is running for that time the app is unable to update UI for that time , leads to skipping of few frames , so it seems that the app is lagging. So the actual reason is that the GC was running or may ...
Image heavy applications have to decode many images, so there will be continuous allocation and deallocation of memory in application. This results in frequent calling of the Garbage Collector (GC). And if you call the GC too many times, your application UI freezes. Glide , Fresco and Android Networking all use the Bitmap Pool Concept to load images efficient By using the Bitmap pool to avoid continuous allocation and deallocation of memory in your application, you reduce GC overhead, which results in a smooth-running application. One way to do this is to use inBitmap (which reuses bitmap memory). Suppose we have to load few bitmaps in an Android application. When we load bitmapOne, it will allocate the memory for bitmapOne. Then if when we no longer need bitmapOne, do not recycle the bitmap (as recycling involves calling GC). Instead, use this bitmapOne as an inBitmap for bitmapTwo. This way, the same memory can be reused for bitmapTwo. B...