Google that let people "hehe" image technology

In fact, Google in the image technology do not understand, but not just libjpeg optimize_mode parameters so simple.

With the Android system in the image memory management of "confused", picture quality is really not a thing, the quality almost everyone can endure, improper memory management will lead to the application of the crash (Oom:out of memory) can really no one can endure.
How much memory does the bitmap account for? It is simple to calculate, if you need to display a square picture with a width of 612 pixels, the corresponding bitmap object needs to 612*612*4=1498176 bytes of memory, which is about less than 1.5MB of memory. This level of memory consumption, in the development of desktop applications, the problem is not big, anyway, so many years, we have been accustomed to regardless of 3,721, all the memory is my use. In the era of mobile internet, that is not the case, smart phone operating systems (such as iOS and Android) strictly limit the amount of memory that each application can use, the super you will crash out, do not affect the normal operation of other applications.

About the oom problem in image memory management, basically every Android developer has encountered, online search, can find a variety of "magic" solutions, such as:
1, reduce the display size of the picture, do not use argb_8888 (32-bit), but choose to use argb_4444 (16-bit) or even rgb_565 (8-bit). Well, the problem is not to think about how to solve, but choose to use smaller, worse display quality to replace, this idea, praise! According to this logic, no diagram application of the most memory, we all go to develop no diagram application.
2, the explicit collection of image memory, that is, the manual recycle a bitmap object. It sounds like a straight path, requires memory allocation, and does not need to be recycled, is this always OK? In fact, this solution assumes that the Android system's garbage collection efficiency is low or possibly unreliable, this writing, encountered in the ListView constantly scrolling display picture of the demand (this is also a very basic demand it? , always encounter such a strange problem, not "outof memory", that is, "trying to use a recycled bitmap", anyway, a word "collapse"!
3, set Bitmap object as soft reference (Soft Reference), frequent manual call garbage collection (garbagecollection). Before you need to request a larger memory space, take a GC and release some memory to make the crash less likely. This is really the last trick, but it is only a temporary cure, let the probability of collapse slightly lower on so little.

As a team with a lot of efforts in the picture, the above "solution" we have tried, tangled, but can not completely solve the problem, oom that can really be our development in the Android has encountered the biggest stumbling block.
Not only do we use DDMS to monitor the memory situation, but we also use the mat (memory Analyzertool) to analyze the possible causes of memory problems. During the analysis, we have even found some memory leaks in the MIUI historical version, but it is still not possible to completely resolve oom.
In order to avoid the effects of code logic as much as possible, we ran a clean Google used to train developers of the project Bitmapfun, but still useless, the ListView rolling, memory surge, roll faster, the application will be collapsed.
Remember at that time several of us also had internal exchange, Google itself don't know Bitmapfun will oom?

Ultimately, a complete solution to the problem, a thorough understanding of the memory management mechanism of the Android image, a thorough understanding of the principles of garbage collection and memory leaks, is still a small option: inpurgeable (and its associated ininputshareable option).
For a detailed description of the BitmapFactory.options.inPurgeable option, refer to the official Google documentation (http://developer.android.com/reference/android/graphics/ bitmapfactory.options.html#inpurgeable).
If the Set inpurgeable option is true, the memory occupied by the bitmap object is cleaned up when the system needs to reclaim memory. This way, if you need to access the bitmap object again, you need to re-decode. Because Re-decode need to maintain a reference to the source (InputStream or ByteArray), inpurgeable cannot be used for Decoderesource and DecodeFile.
This is actually the ultimate solution for oom, because the images needed to display in the app are usually from JPG or PNG files, and JPG or PNG is much smaller (such as 50KB) than the memory required for the bitmap object (such as 1.5MB). Keeping a reference to the bitmap source (InputStream or ByteArray) requires only a few one-tenth of the memory, and the system performance required by Re-decode is minimal for today's hardware computing power when the bitmap object needs to be displayed again. Need Re-decode, but no oom troubled, this is how important parameters Ah!
OK, now in your application to be assured that the bold set inpurgeable to True, and then set the corresponding inputshareable to true, with DDMS to monitor memory usage. Have you found that the memory footprint is low and very stable, whether it's a quick-scrolling listview or a constant Click to view a larger image? No more worrying about the oom caused by bitmap?

Such an important option, Google gave the proposal is "not recommended to use", in this, small too can only say a "hehe". (Have the ability to let your family's bitmapfun not oom Ah!) ）

About the memory usage of the bitmap object, for the moment. Little too say the general principles of solving memory problems in Android development:
1, Oom is the most annoying kind of crash, usually does not collapse in the problematic, memory-leaking code, which can only be resolved by careful analysis of memory leaks.
2, Android garbage collection mechanism can be trusted, do not need manual recycle, do not need to call GC frequently (bitmap oom because of the need for too much memory, and not necessarily a memory leak). After the object is exhausted, it is sufficient to remove the reference.
3, always only with argb_8888, the early Android even suggested developers with rgb_565, that is Google did not want to understand.
4, the memory leakage problem must be the reference did not release, most of the problems do not need the mat such advanced tools for deep tracking, usually ddms+review code is enough.
5, nearly a year Android application of oom problem is not so obvious, there are two reasons, the first is the general improvement of the level of Android developers, the better the code, the more memory leaks, the second is the development of smart phone hardware (the flagship machine is 3GB of memory it? ), it's not because Google has figured it out.

Finally add a sentence, whether it is Optimize_code, or inpurgeable, Apple is really understand, from the beginning to understand, iOS developers really happy!

Google that let people "hehe" image technology