Select to view content in your preferred language

Dispose map related objects after use

08-26-2021 07:30 AM
New Contributor II


We have a vtpk file on our device which we use to generate the map in offline mode.
Following is the code that we are using currently to do this. We found out that once the map is loaded the memory in the background keeps increasing and is never released.
In our Xamarin Forms UWP application, we use this map on the HomePage and few other following pages. As we navigate in the app, the memory in the background keeps growing and is never released.

We investigated this further and think that the lines 6 and 8 where we load the tiled layer from file on device, the "tilecache" and "vectorTiledLayer" are never disposed from memory. We also looked up if we can use IDisposable interface to dispose objects but seems like these two objects don't implement this interface.

What is the best and efficient way to load the offline vtpk file without affecting the memory much?
What we are doing below, is this the standard way of loading offline files?


var mapPackageFolder = Constants.TpkFolderLocation;
var mapPackageFile = @"Tas_WebM_BaseMap_no_contour.vtpk";

var mapPackagePath = System.IO.Path.Combine(mapPackageFolder, mapPackageFile);

var tileCache = new VectorTileCache(mapPackagePath);

ArcGISVectorTiledLayer vectorTiledLayer = new ArcGISVectorTiledLayer(tileCache);

map = new Map(new Basemap(vectorTiledLayer));

// Create starting viewpoint
Viewpoint startingViewpoint = new Viewpoint(
-42.882317, 147.327125,

map.InitialViewpoint = startingViewpoint;

return map;




3 Replies
New Contributor III

I am also facing this issue while loading ECWs in a scene.

0 Kudos
New Contributor II

Hi @dotMorten_esri ,

Any thoughts on this.

0 Kudos
Esri Notable Contributor

When you say "the memory in the background keeps growing and is never released" did you run the memory analysis tool to determine which objects are holding on to it? It is possible something in your navigation backstack is still alive.

Also note that the .NET Garbage Collector is pretty indeterministic wrt when it runs, so it might not actually be leaking, but GC just hasn't gotten around to collecting things. You could try running this code 3 times to be absolutely sure that everything that can be collected has been collected:


Just don't do that too often, as it is a blocking/expensive call, but it is useful to determine if something is actually still holding on or not.