Deep parsing of Grow heap (Frag case) heap memory _android

For Android developers, while using a Java language that automates memory management, it is possible that your application will continue to resemble Info/dalvikvm-heap (10798) in the case of memory mismanagement: Grow Heap (Frag case) to 6.437MB for 1114126-byte allocation, which appears
The value behind the Grow heap is increasing, and then the Android system begins to end the background task to add to the growing heap memory problem, which may eventually occur directly oom, and sometimes gc freed 0 objects/0 bytes in 75ms such a problem, for Java memory management We have recently said, on the above issues Android123 for you to do a simple analysis.

1. here Grow heap (Frag case) to the 6.437MB for 1114126-byte allocation indicates that you have been allocating a larger object that occupies up to 6.4MB of heap memory.

2. the question arises as to why a single object such as this is so large that the Android development network reminds us that this is a very dangerous operation because of the allocation of a byte[] array and the need to write the SQLite database in a BLOB format. Devices with different firmware and low RAM configurations are at any time oom dangerous, if you really need to go to the SQLite storage binary, here you can take a segmented way to split an object into 1MB or smaller, more fields to store, the middle plus a layer of split data cache layer to solve better.

3. each time a single large object is constructed, the GC can be notified of the preparation of the collection, such as the execution of System.GC () prior to the execution of the consuming operation; To prevent the occurrence of OutOfMemoryError, for Java memory overflow problem, we will use a variety of cases to explain.