暴食是什么？
所谓暴食，是指人类表现出的超出自身所需的强烈欲望。
产生原因：据说襁褓中的婴儿如果断奶不当，就会产生对食物的极端依赖。
暴食如何影响Windows Phone的开发工作？
——纵容无度、虚耗资源
这个世界永远不缺乏技术类产品，它们随着时间的推移不断涌现，并变得更新、更快且功能更强，越来越聪明的同时也越来越吻合个人需求。如今的平板设备及台式机在计算性能与存储能力方面，已经不输于几年之前的超级计算机。而在我看来，这一切利好因素非但没有令整个IT行业有所提升，反而导致软件开发商愈发好逸恶劳。时至今日，我们不必再为性能表现担忧，反正硬件已经足够强大，再繁重的任务也带得起来。
移动开发工作在这方面则堪称软件行业的表率。由于智能手机的尺寸规格受限，它们在性能上不可能做到游刃有余，因此在编写代码时就要充分考虑到这些局限以保障成品的运行效率。我们需要在性能优化工作上多花心思，因为一旦卡顿或拖慢情况出现，糟糕的使用体验会令我们很快失去用户。在本文中，我将跟大家一起聊聊Windows Phone开发人员应该如何在生态系统的开发工作中避免暴食带来的不利影响。
资源：毫无节制地占有手机资源是应用程序开发的大忌。Windows Phone系统团队的工作者们在如何令核心操作系统更加精简高效方面投入了大量时间和精力，但一切努力在对资源索求无度的应用程序面前都显得软弱无力。首先，请大家务必确保自己的产品在运行过程中不会占用太多内存，只有这样“芒果”系统才会在进行多任务/快速应用切换操作时始终让我们的程序驻留在设备内存当中。托管代码是解决问题的好办法，但注意避免任何不必要的占用状态或者库引用。最好别使用太多第三方工具包，尤其是杜绝类似功能重复载入的弊病。除此之外，虽然动画能提升使用体验并充分发挥Metro的固有优势，但使用过多引发的资源占用也会令用户反感。我就遇上过由于个性化动画太多，相关第三方工具令默认手机应用框架（用于处理XAML页面）在切换时对资源需求过高，最终引发严重的系统拖慢现象——当然，这可能是个别情况，但重点在于大家需要清楚了解哪些元素值得保留、而哪些应该放弃。根据优先级别列出一张清单，能够有效帮助我们调整设备的性能表现。
线程：作为开发人员，相信我不必再提醒大家为自己的平板/智能手机应用程序锁定用户界面（UI）线程了。虽然有时候我们只是在用手机计算人数或者清点账目，但应用程序UI需要始终处于响应状态。为了实现这一点，大多数Silverlight类编程建议我们以异步方式应对这类繁重的处理任务。也就是说在实际处理、动画及UI线程自动合并等工作中，合理使用后台线程配置功能。在必要的时候，我们完全可以建立一项单独的后台任务作为辅助。现实是残酷的，但大家不要灰心，毕竟Async CTP已经能够起到作用。等到将来它完全就绪后，我们将可以彻底告别烦人的Dispatcher，BeginInvoke（）或者DownloadCompleted（）APM/EAP模块。到那个时候，只需启用async-await（异步唤醒）功能，即可轻松帮助设备避免同时执行多个任务的窘境。
缓存：只要有可能，把一切东西都塞进缓存就对了，这能有效防止相同的网络HTTP被调用两次。这一点对于图像/平面类数据尤其适用。目前已经有许多产品，能够以隔离存储的形式为手机节省资源，大家感兴趣的话可以多加关注。
运行模型：现在大家已经知道Windows Phone “芒果”支持通过内存中的应用程序后台堆栈实现快速切换功能，但这并不代表微软原先采用的这套墓碑机制就完全不用担心了。显然，我们不能随便写出一款资源需求量巨大的应用程序，然后指望着它能够长期驻留在内存当中。要完全从墓碑机制的“伪多任务”阴影中走出来，我们还需要下一番苦功。在这里向大家推荐另一篇文章，希望能给各位带来些启示。
警告/提示：现在我们可以利用新的API创建警告/提示信息，这当然不错；不过也别过分依赖这套新机制。要知道提示信息的上限为50条，如果用户未能及时清理或查看这些消息，接近容量上限的情况很可能引发大麻烦。
使用API：新的日程表及联系人API非常贴心，对吧？不过再次提醒大家，拥有权利同时意味着承担责任。最好不要在用户无法选择的情况下滥用这些机制，这种忽略使用者感受的做法很可能让我们的应用程序面临卸载或者口碑极差的危机。
好了，这就是本文要谈的内容。总结起来就是一句话：不要因为我们能这么做，就不假思索地选择这么做。请大家随时关注《Windows Phone开发人员七宗罪》系列文章的第七篇。
原文标题：7 Deadly Sins for Windows Phone Developers: Gluttony 核子可乐译
原文链接：http://mobile.dzone.com/articles/7-deadly-sins-windows-phone-4
【编辑推荐】
