Share via


Best Practices for Developing Windows Mobile-based Applications

Send Feedback

Pocket PC vs. Smartphone

There are low-level differences between the Pocket PC and Smartphone platforms that affect the behavior, performance, and power consumption of your application. The following table qualitatively compares these low-level differences. These low-level differences can affect how you optimize applications and other software.

Component Pocket PC Smartphone
Microprocessor More cycles-per-second than Smartphone. Fewer cycles-per-second than Pocket PC.
RAM More RAM than Smartphone, if RAM-based file system chosen. Same RAM as Smartphone if flash-based system chosen.
  • In a RAM-based system, the Pocket PC must use RAM to preserve data for at least 72 hours after reaching the critical battery level. The 72-hour time frame allows the user to recharge the device to preserve their data.
Less RAM than Pocket PC.
  • Flash-based persistent storage file systems require less RAM.
  • Persistent storage file systems do not require a reserved amount of RAM to preserve user data.
  • RAM is limited on Smartphones due to market demand for low cost Smartphones.
File system RAM-based battery-backed file system or flash-bashed persistent storage system.
  • Unless operating mainly over a network, RAM-based file systems are faster than persistent storage file systems.
Flash-based persistent storage file system.
  • Persistent storage file systems can store data for extended periods of time.
Power states Standby when not in use. Idle when not in use.
Always-on No. Yes.

Performance Overview

Evaluating performance on a Pocket PC or a Smartphone consists of code profiling, battery life and power consumption, and reading and writing to storage. To maximize the performance of your Windows Mobile-based device, formulate user scenarios, and based on those user scenarios, create performance objectives. A common user scenario is booting the device. An example performance objective based on booting the device could be to minimize the time in seconds from cold booting to being able to make a phone call. If at all possible, make any performance objectives measureable. You should also set up user scenarios to expose any performance bottlenecks in your application. This may involve combining manual profiling with the Remote Call Profiler or the Remote Kernel Tracker. You can often use manual profiling to find bottlenecks, and then use the Remote Call Profiler to isolate specific issues. For the most accurate performance measurements, integrate your application into hardware that most closely resembles the retail device.

In This Section

Send Feedback on this topic to the authors

Feedback FAQs

© 2006 Microsoft Corporation. All rights reserved.