针对该问题Windows Phone团队详细列出了应用优化指南，帮助开发者高效的实现针对不同版本Windows Phone的应用优化，具体应用优化方案包括以下几个方面：
优化启动时间
确保应用的启动时间能够大幅度缩减，开发者在应用渲染完成之前尽可能的延缓其他用户动作发生的可能性。这就意味着开发者需要最小化App/Page框架下的代码并且保持Launching/OnNavigatedTo 用户动作最小化。
例如应用初始化将会花费一定的时间或者依赖网络相应以及文件的输入或输出，那么开发者可以利用进度条的形式来传达动作信息，同时在不影响页面布局的情况下调整系统托盘不透明度为0以利用系统托盘ProgressIndicator 来保证最佳性能。
当原始框架渲染完成，在异步操作未完成的情况下开发者可以利用独立的存储操作来阻塞UI线程的调用，确保调用异步来保证启动时用户界面的快速响应。
由于Frame是由操作系统本身绘制并作为启动序列的一部分，因而可以适度增加闪屏来延长启动时间。此外还可以通过从页面中简化和去除不必要的XAML以减少受XAML分析的影响，也可以显著延长启动。
减少内存使用
在资质认证页面5.2.5中明确提到在低端设备中应用的内存使用量不得超过90MB，随着像Lumia 610这样的设备上市，这些优化工作将会显得至关重要。
开发者可以利用内存分析器和相关API来分析应用程序的内存使用情况。其首要基本原则为保证在用户需要的时候进行内存处理，以替代在启动界面预先加载应用数据。例如，根据需求加载页面的数据，在内容改变时再进行刷新数据而不是一味的进行全局数据的加载。
注意内存泄漏，例如用户在使用Win键切换至主屏幕时应用并未瑞出，这样就会出现一个循环的导航切换功能，驻留在内存当中，当用户利用多任务进行切换时很可能会导致应用由于内存不足而崩溃的现象。为了避免这种循环导航的出现，开发者可以替换掉Win键的功能或者利用Windows Phone 7.5提供的会展操作API来解决该问题。
此外，还要确保图像使用效率，因为当应用程序加载高分辨率图像到UI界面然后通过缩放来适应较小的Container容器，也将会消耗更多的内存。
处理性能下调
为了保证前台256MB内存的释放，通用的后台代理(PeriodicTasks/ResourceIntensiveTasks)将不可用。
当前Windows Phone终端用户可以再设置选项里面手动关闭后台功能，当后台代理超过限额时，操纵系统将自动终结后台应用，这些功能都是通过InvalidOperationException来实现的，因而开发者有必要针对Tango设备对该功能进行调整。
按照上面给出的思路来禁用掉上述功能以确保应用的用户体验最大限度的不受影响，从而在低端设备正常发挥其性能和特征，开发者可以给予最新版的SDK7.1.1进行debug。
此外，开发者如果希望通过减少/修改功能，以便于在低端设备上的内存需求，可以使用WebBrowserTask和BingMapsTask来替代内存密集型的WebBrowser和Map控件。例如，可以卸载应用程序中占用本地内存的进程，避免在人机交互过程中内存不足而导致应用崩溃的现象。的
用户输入响应
用户总是希望应用程序界面能够反应灵敏，因而保持UI线程的的动作在不需要的情况下尽可能的处于冻结状态则显得非常必要。
为了保证页面加载时间，在应用被完全渲染之前延缓加载时间同样至关重要，此外，利用TiltEffect的确认用户输入也将使应用程序的外观和感觉具备原生应用程序的用户体验。
许多开发者在应用程序通过添加页面过渡动画，来延缓加载时间，这是一个非常值得推荐的做法，但是如果过度画面会影响到应用程序的稳定性时，开发者则需要将其禁用，尤其是针对低端设备，这样可以显著的提高应用程序的性能。
总结
通过上述优化指南，开发者可以轻易地保证用户能够获得良好的用户体验，而这些简单的优化并不仅仅针对低端设备，同样对于当前的Windows Phone设备一样可以获得良好的用户体验。同时，合理的利用256MB的SDK工具也将会使得开发者的优化工作更为高效。
【编辑推荐】
