.NET powers applications on Windows Phone and most of the advice presented in this book is equally applicable to mobile applications. With each release of .NET, the set of APIs common to all platforms gets larger.
That said, there are a few major and a handful of minor differences you should be aware of. All of the information in this short chapter is applicable to Windows Phone 8. As of this version, the CLR running on the devices is essentially similar to the one on the desktop or server, with some configuration differences.
- Tools
The Windows Phone SDK ships with a tool that allows you to measure your application’s performance along a number of metrics. The Windows Phone Application Analysis tool can run in a few different modes, depending on the type of information you need.
The most basic mode is called App Monitor and allows you to get simple feedback for user-facing issues like startup time, response time, battery usage, network usage, and high resource usage.
If you need detailed CPU or Memory profiling data, you can get that data as well.
Figure 9-1. The Application Analysis tool lets you measure either general quality characteristics of your application or do a more in-depth profile of either CPU or memory.
- Garbage Collection and Memory
The garbage collector is essentially the same, but the segment sizes will be smaller, reflecting the smaller memory size in general. Background GC is not supported. (Neither is server GC, but that should go without saying).
Applications are explicitly limited in the amount of memory they can use. .NET applications are limited to a maximum of 300 MB on a typical device. Background tasks are further limited to only about 20 MB of memory usage (or 11 MB for low-memory devices). Applications that exceed these limits may be immediately terminated by the operating system. These limits can vary depending on the type of application and hardware, and may change over time with future updates. See http://www.writinghighperf.net/go/31 for an up-to-date explanation.
Minimizing the static resources your program uses will go a long way to reducing the overall memory usage. Keep in mind that you can usually get away with relatively low resolution versions of most resources, such as images, sounds, documents, or other content. Use the lowest resolution you can get away with, keeping in mind that phone capabilities such as screen resolution do tend to improve over time.
The main principle to keep in mind is that you must be much more conscious of your memory usage on a mobile device. The desktop with its multiple gigabytes of RAM plus a huge page file is far more forgiving than a mobile device will be.
- JIT
On a mobile device, startup speed is particularly critical. An application that is not ready to run within a short amount of time can fail quickly in the crowded app marketplace.
Before Windows Phone 8, applications were JITted on the fly the first time the program ran, just like the desktop version of the CLR. This was slow and used an excessive amount of the battery. Thankfully, Windows Phone 8 introduced cloud compilation. With this, all applications are now pre-compiled in the Windows Phone Store before being sent to the device.
This pre-compilation is not the same as NGEN. NGEN is device-specific and depends on the exact hardware and framework versions present. It would be impractical to generate every possible combination of these native image files in the Store. They could have decided that NGEN would run on the device, but this would have meant that every time there was an OS or .NET update, every single application would have to be re-NGENed, which would drastically increase the update time and could easily wipe out the battery.
Instead, cloud compilation introduces another image format, called Machine Dependent Intermediate Language, or MDIL. This language is very similar to the final assembly code that will actually execute on the mobile processor, but instead of address offsets for things like fields, there are tokens representing which field the instruction is referring to.
Once this almost-complete image is on the device, the only thing that needs to be done is replace the tokens with the actual addresses, a process called binding. You can think of this as an analogous process to linking in the world of native code compilation.
Compare the following diagram to the normal JIT flow diagram from Chapter 3:
Figure 9-2. Windows Phone Application deployment process. An application passes through multiple stages of compilation before it actually executes on your device.
The benefits of this strategy are significant:
- Minimal time spent JITting
- No need to run NGEN on the phone
- No re-download of native images every time there is an OS update
- Lower battery usage
- Faster updating
- Asynchronous Programming and Memory Models
You can use all of the asynchronous APIs mentioned in Chapter 4 on Windows Phone devices, but there are a few significant differences between a desktop and a mobile device that may affect your application.
I still recommend the Task APIs for general purpose asynchronous programming, but Windows Phone also has the BackgroundWorker class, which wraps thread pool worker items and adds UI-related features. It is suitable for background tasks that need to regularly notify the UI of updates to its state.
The number of processors available to you will typically be less than on a desktop or server platform. At the time of this writing, most mid- and high-end mobile devices have two to four processors.
Perhaps the most important difference is that many mobile devices, such as Windows Phone or the Surface RT devices, use ARM processors, which have a different memory model than the x86 or x64 processors that you are used to.
As described in Chapter 4, this affects you mostly if you have a bug in your thread synchronization. If you share code between the desktop version of your software and the mobile app it is possible to never see the problem on the desktop, but as soon as you port it to a device that runs on ARM, the pre-existing race conditions in your code could become apparent in the form of data corruption or random crashes. Ensure that you are correctly using volatile, Interlocked methods, and thread synchronization objects, as described in Chapter 4, and you should avoid any problems.
- Other Considerations
Always keep in mind that more CPU usage translates directly into lower battery life. Use the tools mentioned in this chapter to monitor and fix any areas of high CPU usage.
Use system resources as quickly and sparingly as possible. For example, Windows Phone OS will often turn off the radio transmitter, so when you need to make network requests, batch them and send them in parallel to allow the transmitter to turn off sooner, saving battery life.
Finally, as with all UI applications, you want to avoid blocking the UI thread for any reason. Always perform long-running operations on a separate Task explicitly or by using the BackgroundWorker class. You will also need to understand the performance characteristics of XAML, which is out of scope for this book (see the bibliography at the end of the book for more resources).
- Summary
Most general .NET programming advice applies to Windows Phone programming as well, but you do have to be conscious of the smaller hardware capabilities and different architecture running the code. Many types of thread synchronization bugs are far more likely to manifest on ARM hardware.
Developing mobile software forces many more constraints upon you as a developer that are not present on the desktop. Following the best practices in this book will get you quite far in dealing with these. To see what all of the certification requirements are for Windows Phone applications, see http://www.writinghighperf.net/go/37/.