Memory Management on Windows Mobile 6.x

When you start developing for Windows Mobile you will be amazed by the things we can build for a Mobile. If you have developed windows desktop applications, mobile development is similar. The Compact Framework is subset of the full .NET Framework functionality. Most of the API’s and libraries available for desktop are available for mobile but are of smaller version. To start with Windows Mobile development, developer should know the limitations of Mobile devices when compared to desktops, the main limitations in Windows Mobile 6 are the memory, battery life and program speed. Do not build desktop sized applications for mobile without considering the memory limitations.

Let’s understand the memory architecture of Windows Mobile 6.x. Windows Mobile 6.x inherits its memory architecture from the Microsoft Windows CE 5.0, which is a 32-bit operating system. Windows CE 5.0 was designed when a small footprint of memory was important. Windows Mobile has only 32MB virtual memory for each application to leverage in the process space. The latest devices are getting shipped with more memory as it is cheaper these days, but it does not matter how much memory is built into the device, Windows mobile will only use this in 32 bit slots. This memory limitation has been removed from in Windows Embedded 6.0, and might reflect in Windows Mobile 7.

I will try giving my observations for developing memory efficient mobile applications, which I have read from various other blogs related to memory management. When developing large applications with lot of UI, images, sounds and other resources, we need to keep in mind the 32 MB Virtual Memory limitation per application. All the resources added to the EXE will make the EXE heavy and this will take maximum memory from the allotted slot. To view the 32 memory slots usage, you can use the VirtualMemory application developed by William Blanke’s and view your applications memory usage in one of the 32 slots.

To avoid memory crunch when developing large mobile applications, we can keep the EXE empty and create a managed DLL which will hold the code, forms, resources and data. This will reduce the amount of Virtual Memory the app uses in the given slot and at will also take advantage of the memory outside the slot in 1 GB shared memory area.

I have developed two versions of a mobile application which has images bound with it. The below are the findings from the both versions of the application, the StandardApp.exe with the images bound to it and the OptimizedApp.exe with the EXE being empty and moving the form, code and images to managed DLL.

Standard EXE, which occupies more memory at the bottom of the 32 MB slot.	Optimized EXE, which occupies very less memory at the bottom of 32 MB slot.

The application code should have an exe with only a call to the managed DLL, and the managed DLL should have the forms, code and other resources. This makes the EXE smaller from 3 MB to 5KB.

Sample code:

• OptimizedApp Exe:
  

  

• Managed DLL:
  

  

Points to remember when developing WM 6 applications:

1. Write code smaller and lighter to save space in Virtual Memory. Use programming shortcuts as opposed to following pure programming practices that can inflate code size and memory consumption.
2. Try keeping your EXE empty by keeping all Forms, resources, code and data in managed DLL. This will reduce the memory required for EXE in the 32 MB slot for this application.
3. Merge small DLLs into larger ones (64 KB aligned), Windows Mobile 5.0 loads components on a 64 KB space, which means that even a small DLL will used minimum of 64KB. If there are many small DLLs it will be better to merge into one DLL resulting in 64KB.
4. Never rely on Garbage Collector although on managed environment. Avoid calling GC.Collect method.
5. Implement the IDisposable interface and finalizers effectively.
6. Do not cache unnecessary data (mostly volatile data) which you will use occasionally.
7. Use custom strongly typed or generic data transfer objects instead of DataSets to reduce memory overhead and improve application performance.
8. If your application requires logging, try to use compressed format to reduce the memory and storage usage.
9. Use the using keyword in C#, this declares and instantiates the object as late as possible, and disposes the object as soon as possible.
   
   
   This will implicitly call the Dispose method for the connection instance after the use.