Theory: There are two kinds of memory allocation mechanism :

 

(1)    Some large application ,like oracle client ,world of warcraft game :

( We can think about it like Buffet( 自助餐) ，if you paid, you can control what you eat and do not need to pay anymore )

 

 

This kind of application will have a minimum configuration of memory ( for example ,the WOW game will have at least 1gigabyte memory) ,this minimum memory is the largest estimation of the memory that it may use ,it will never ask the Operation System for extra memory when running it .(For example ,the wow.exe only need 400m memory ,the left memory are reserved for temp files ,swap files ,object files and so on ,so even it only needs 400M,the rest 600M are unavailable for other application .)

So this kind of application has only two status:  (Can run / cannot run) ，Once it runs ,it will always run and do not need to worry about the memory .

 

(2)    Small application:

Most of the normal application are acted like this way ,it applies for a small memory ,and when it runs and needs more memory ,it asked the Operation system for more memory.

(we can think it as “Choose dishes from menu”(点菜) ,if we needs more ,we order more ,pay more)

 

So this kind of application will have three status:

(cannot run /Can run/ can run but future the memory used out)

 

During running ,it needs more memory and applied from OS ,so maybe onetime ,the OS cannot supply enough memory, this application will shutdown.

 

 

 

 

Our issue:

 

Based on the above theory ,we can take a look at the problem ,why sometimes ,the application will shut down if we scroll the screen very frequently in search result page. Because android mobile application is using Mechanism 2

 

Problem: when we go to the search result page ,if we scroll down the screen very frequently ,the application thread will shut down because of the memory used out.

 

Phenomenon:

 scroll down very frequently  

->Dalvik VM used out exception

 

Reason:

The Heap memory can be divided into parts ,one is reserved for java objects ,the other is reserved for native C objects.(They cannot mix together)

If we scroll up /down the screen very frequently ,the new native objects are created and ONLY the native heap memory are recycled. And the recycling speed is much slower than the allocating memory speed ,that’s why the heap memory will used out.

From the log ,we can see ,that only native heap memory are recycled (GC_EXTERNAL_ALLOC stands for the native heap memory recycle)

And most the memory recycled are small( less than 150KB) ,that’s because android based on “slab” mechanism to allocate memory ,and the slab has a limit size.

 

But what the size of the native heap memory it allocated when a new native c object created? The answer is 320KB in our test

So , allocate more and recycle less ,at last ,the memory will used out and the application process will die.

 

 

Solution;

When configure the emulator ,please set the RAM(SD card) to be a large number ,and restart the emulator.

Go to <ANDROID_ROOT>\.android\avd\<Your avd>\config.ini ,change the sdcard.size

本文转自 charles_wang888 51CTO博客，原文链接：http://blog.51cto.com/supercharles888/835923，如需转载请自行联系原作者