ThinkGeo.com    |     Documentation    |     Premium Support

Memory usage in iOS v12 + a few other issues

After upgrading to v12 from v10 we are seeing a significant amount number of jetsam events that are closing our application. We are running our test on an IPAD 6th gen with basically nothing else installed or running but our application. After relatively few view operations the jetsam logs get generated. I have duplicated a similar issue with the SQLite layer in the howDoI sample code – although it takes much more view operations before the app is closed. Our particular test case employs about 32 SQLite feature layers.

I added some simple memory tracking code into the application – managed memory appears very consistent between the v10 and v12, however the native memory is significantly different.

Taking a snapshot of mem usage prior to initial update the native memory usage in v10 is
258.25 MB
After initial map update it is
298.16 MB
Free Memory 78.66

For v12 mem usage prior to first update is
290.03 MB
after initial map update it is
467.88 MB
Free 18.27 MB

These numbers do represent the worse case scenario where all featues are visible. They are also numbers from when the app is built in debug. Only significant difference between the two versions is that one is using BingmapsLayers and the v12 version is using the overlay.
Numbers are relatively consistent over multiple runs. As mentioned the increased memory usage has proven to be significant problem which may forces us back to using v10 again.

v13.0-168 has introduced some redrawing issues over v13.0-167. When zooming in the map the display zooms immediately on the existing image that is displayed – the underlying features are redrawn and the old image is supposed to go away – that is no longer occurring the older enlarged feature display remains. Linear layers show this issue readily.

one piece of functionality that we have is the ability to zoom into a selected features bounding box. When we do this the base map goes away. Scale at bottom of the map indicates 50 feet for a frame of reference – v10 with bing layers does not have this issue.

When requesting a feature layer to be redrawn all features in the layer are getting refreshed instead of just the one. In this case all of the layers involved are in the same overlay.

Also I added a refresh button to the mix to see if there is likely a memory leak – expectation would be the memory stays pretty much the same since the extents/scale aren’t changing. This is a little bit less clear cut as the memory does fluctuate a bit when iOS reclaims some – but the used memory is increasing when hitting the refresh button.

Again all of these memory issues I am referring to are native memory as opposed to the managed memory.

Thanks Richard,
Could you send you modified how do I sample. We could look into more detail.

Thanks

Frank

Attached is a v12 test case – it only has the bing maps overlay loaded. v10 vs v12 for this test case only has about a 15MB difference on initial map load – not feature layers are included. By simply using the view control and pinch/zoom operations I can get the application within 5 minutes – this particular crash is not the jetsam event but is still problematic.

What this test case is meant to show is what appears to be a memory leak in native code – managed code does not appear to be an issue. Now on a panning operation I would expect the memory usage to remain relatively stable – instead it continually climbs. It does seem to plateau at a certain point and occasionally drop depending on what the view operation is and how much of the bing map is displayed.

Keep in mind this is a simple test case --without any feature layers. If you add SQLite data sets to this you will likely see a significant increase of memory usage after initial display. quite a few of the feature layers we use in our product are linear layers with text associated with them. So we are in a situation of high memory usage – where each view operation as expected causes a memory usages spike while drawing, but does not fully return to the same levels after drawing. Eventually when of the drawing spikes causes iOS to terminate our application with a Jetsam log.
ThinkgeoTestCaseBack.zip (468.2 KB)
Following is a native library that we created to get memory usage info for the application.
libMemTracker.zip (3.2 KB)

Hi Richard,

Thanks for your sample! We are on it right now.

Ben

Hi Richard,

Please get the latest beta version (ThinkGeo.UI.iOS Beta141) and have another try. The memory usage is improved a lot. I tested with 40 mutlitile layer overlays with one SQLite layer in each of them, and it works fine without crashing. Of course it’s not a good practice to have so many overlays in a real application.

Also Rick said you guys also have issues in Android. Could you please make sure everything goes well on iOS on your side first and we can then move over to Android.

Thanks,
Ben

Somewhat a miscommunication on overlays – we have maybe 4 different overlays with all of the SQLite layers residing in a single overlay. My initial impression is that it does seem a lot more stable though I have only done brief testing at this point. I will continue looking at this tomorrow as I got sidetracked by another issue.

The bing maps are now way off - an area that should show in atlanta is ending up in the arctic. Not sure when this was introduced, but it was not an issue with core 13.0.0 beta-167 and ios version 13.0.0 beta-125