While Silverlight for Windows Phone makes developing applications for WP7 “really easy”, this doesn’t change the fact that building a mobile app requires you to pay much more attention to the (un)availability of system resources like, memory.
There are three values you can monitor to ensure your app is using memory responsibly. They can be found in the Microsoft.Phone.Info.DeviceExtendedProperties class:
- DeviceTotalMemory is the least useful of these values, but might still be something you want to check out. It could be used to make decisions about whether or not to kick off a memory intensive process. You might use it similarly to the way you check the RenderTier in WPF – to show a better experience on devices that can handle it.
- ApplicationCurrentMemoryUsage can be used to ensure that in general you’re not trying to do too much with your app. One example of this from my experience is loading up too many pivot items in a pivot control. The recommended max is 7, but depending on what you’re doing in them, you might find that’s too many. If your current memory usage is bumping up against the max, you definitely need to do something to reclaim some memory.
- ApplicationPeakMemoryUsage can be used for your own pre-certification testing to ensure you never go over the 90MB max threshhold.
To ensure you don’t stray too far down the wrong path, it’s good to frequently check these numbers. If you have metrics like this right in front of you while running the app, even better. So I created a control to periodically check these values and optionally show them at runtime. You can use this control strictly for testing purposes, or you can use it to make decisions a runtime about what if anything you need to dump to get back into the safe zone for memory usage.
It's easy to use, on Application Launching and Application Activated, new it up:
MemoryMonitor memoryMonitor = new MemoryMonitor(isEnabled, showVisualization);
Then when run the app, you'll see this at the top of your screen:

You might want to change it's configuration based on compilation switches, only showing the visualization in debug mode. You might want to only new it up in debug mode. You might want to keep it running, tracking memory usage throughout the lifetime of your application, and when current memory usage exceeds a threshold, be notified so you can clean stuff up. It'll handle these scenarios.
So like any stuff you do when you’re down in it, you find it useful but others might not. Take it, change it, improve it, do what you want with it. I found it useful, maybe you will, too. If you do something good, share it back.
MemoryMonitor.cs (17.65 kb)