I downloaded the application and played with it, watching memory through dumpsys.
Everything looks normal, the memory is restored every time. I cannot reproduce the situation, but I see one surge that is probably related. Whenever you move around the map or scale (mainly updating tiles) on the satellite, there will be a brief burst of memory. If you do it fast enough, you will not give him the opportunity to return it, and it will grow.
Now my phone is Android 3.3.4 and has a pretty good configuration, so perhaps the GC is much more efficient. It is interesting, though, if my old test phones will recover memory more slowly, and therefore, when I get to the map (say, after adding fish), I will still have memory from a previous activity that was not restored by GC. Then what would I do, I would go to my location and check the situation by zooming in / out. This, combined with previous memory from previous actions, can cause phones to reach the limit.
This is just a theory, although I am on the road and do not have access to all my test phones. Do you know which version of failed phones? I will be back in 3-4 days, and I can try the application on my old phones.
UPDATED: I conducted more experiments on this application. I am pretty sure that adding fish continuously will add more memories. I continued to add and remove fish and verify that memory continues to grow through dumpsys meminfo. Real users of the Pro Edition or even Lite, who continue to add and remove fish, may ultimately get close to the limit, and after that the transition to the card will cause an error in the memory, as there will be a memory jump on the card. Here is a snapshot after adding and removing fish several times.
** MEMINFO in pid 11572 [com.hookedroid.fishingcompanion.lite] **
native dalvik other total limit bitmap nativeBmp
size: 19728 18251 N / A 37979 32768 N / AN / A
allocated: 17174 14674 N / A 31848 N / A 3144 0
free: 405 3577 N / A 3982 N / AN / AN / A
(Pss): 12750 1771 25944 40465 N / AN / AN / A
(shared dirty): 908 1544 5800 8252 N / AN / AN / A
(priv dirty): 12732 1008 24208 37948 N / AN / AN / A
Your personal memory will move to 37,948, and I'm sure that if I continue to add and remove fish, it will eventually throw an OutOfMemoryException.
MORE UPDATES (a few minutes later): I manage to collapse the application using the above theory. I had to add and remove fish several times before this happened. It can be more than 50 fish before the application crashed.
I assume that for some reason SQL is not being cleaned properly. Looking at dumpsys after each set of adding and removing 10 fish (which is the limit of the lite version), I see that
SQL
heap: 6581 MEMORY_USED: 6581
PAGECACHE_OVERFLOW: 173 MALLOC_SIZE: 50
DATABASES
pgsz dbsz Lookaside (b) dbname
1 16 62 FishingCompanion
1 16 62 FishingCompanion
1 16 62 FishingCompanion
1 16 62 FishingCompanion
1 16 62 FishingCompanion
1 16 62 FishingCompanion
1 16 62 FishingCompanion
1 16 62 FishingCompanion
1 16 62 FishingCompanion
1 16 62 FishingCompanion
1 16 33 FishingCompanion
1 16 62 FishingCompanion
1 16 62 FishingCompanion
1 16 62 FishingCompanion
1 16 62 FishingCompanion
1 16 62 FishingCompanion
1 16 62 FishingCompanion
SQL memory continues to grow, although I have already deleted the fish. If I continue to do this for some time, in the end it will fall into the upper limit of the phone and go to the card (which will cause a jump in memory) will cause an exception in memory, which would seem to indicate that the map page is the reason, whereas I think that the add / remove fish page is part of the real reason (I say “part of the real reason” because I don’t know if such an action will happen if I add a new location).
I got an OutMemoryException correctly when the total memory is about 58 MB (this is probably different from phone to phone). For reference, here is a similar OutOfMemoryException exception that I received:
D / dalvikvm (11572): GC_FOR_MALLOC freed 125K, 11% free 25734K / 28743K, external 4047K / 4695K, paused 188ms
D / AndroidRuntime (11572): Shutting down VM
W / dalvikvm (11572): threadid = 1: thread exiting with uncaught exception (group = 0x4001d648)
E / AndroidRuntime (11572): FATAL EXCEPTION: main
E / AndroidRuntime (11572): java.lang.OutOfMemoryError: bitmap size exceeds VM budget (Heap Size = 28743KB, Allocated = 25734KB, Bitmap Size = 4047KB)
E / AndroidRuntime (11572): at android.graphics.Bitmap.nativeCreate (Native Method)
E / AndroidRuntime (11572): at android.graphics.Bitmap.createBitmap (Bitmap.java:695)
E / AndroidRuntime (11572): at com.google.android.maps.ZoomHelper.createSnapshot (ZoomHelper.java:444)
E / AndroidRuntime (11572): at com.google.android.maps.ZoomHelper.beginZoom (ZoomHelper.java:194)
E / AndroidRuntime (11572): at com.google.android.maps.MapView $ 2.onScaleBegin (MapView.javahaps80)
E / AndroidRuntime (11572): at android.view.ScaleGestureDetector.onTouchEvent (ScaleGestureDetector.java:216)
E / AndroidRuntime (11572): at com.google.android.maps.MapView.onTouchEvent (MapView.java:682)
E / AndroidRuntime (11572): at android.view.View.dispatchTouchEvent (View.java:3932)
E / AndroidRuntime (11572): at android.view.ViewGroup.dispatchTouchEvent (ViewGroup.java:955)
E / AndroidRuntime (11572): at android.view.ViewGroup.dispatchTouchEvent (ViewGroup.java:1015)
E / AndroidRuntime (11572): at android.view.ViewGroup.dispatchTouchEvent (ViewGroup.java:1015)
E / AndroidRuntime (11572): at android.view.ViewGroup.dispatchTouchEvent (ViewGroup.java:1015)
Hope this helps