1。在pc上调试比模拟器愉快的多，也可以更容易的发布小样给别人看。
需同时保持pc和wp7的两份代码，随时保持相容性，可以用copy project来简单完成。
我就是有相当一段时间没有保持代码相容性，结果前些天移植wp7的时候要重构一些代码。
PC端用的是dotnet framework 4 client profile，当然也可以不带 client profile
wp7端用的是 dotnet framework compact 3.5
曾几何时WM端的应用在pc上可以直接执行调试，现在已经行不通了，wp7项目编译时只是链接了一堆空架子dll，里面没有执行代码。
我以前没有注意到compact的限制，这会让你头疼致死的，早点关注起来。
2。完全告别content
content在不同平台要分别编译，最关键是是把资源也混合在编译过程中，在项目扩大时完全不可接受。
目前我已经建立的声音、贴图、模型、字体的非content方案
由于compact不支持二进制序列化，切记直接操作stream
3。资源和执行文件的分别发布
目前打包成一个xap文件的形式，而且没有发现支持分多个包，势必造成软件更新的代价庞大。让资源部分通过微软商城去更新下载
资源部分采用独立的更新策略，随用随下，变化部分再下载。
也可以提供更好的用户体验，不用长时间的加载，提供一个后台下载、加载线程去处理
4。一些节约内存的策略
贴图加载时压缩，Reach也支持DXT1 3 5 三种压缩格式，XNA本身的spritefont就用DX3压缩的，需要手写压缩算法。
模型实例管理，防止重复建立模型副本
字体要用动态词频调整策略，这个有点儿麻烦，动态词频就会消耗更多cpu，静态缓存就会消耗更多内存，这是个需要取舍的问题。但是显然内存是更大的瓶颈，让我们寄希望于cpu更省电吧。