在移动设备上定期从 XML 文档中获取数据，性能好吗？
我正在开发的游戏有几个用于管理精灵动画的 XML 文件。目前，当我创建精灵实例时，我会将其加载到 XDocument 中一次并将其保存在缓存中，以便在需要再次加载时使用我可以
在游戏中经常这样做，因为我创建动画精灵等，并像这样浏览它的定义：
var definitions = doc.Document.Descendants(name);
foreach (var animationDefinition in definitions)
所以我的问题是，这在手机上可以接受吗？ iPhone 4/Windows Phone 7/Android？我在 Android 和 iPhone 中使用 MonoTouch，而 WP7 有自己的 .Net 运行。
我问的原因是目前我没有加载那么多动画精灵，但随着我加载的越来越多，我已经加载了。担心它会开始损害性能。我认为最好现在改变我的设计想法，而不是等到以后再受苦。
感谢您的帮助！
A game I"m working on has several XML files it uses to manage sprite animations. Currently when I create an instance of a sprite I load it up into an XDocument once and keep it in a cache so that if I need to load it again I can just grab what is arlready in memory.
I do this very often in-game as I create animated sprites and such, going through its definitions like so:
var definitions = doc.Document.Descendants(name);
foreach (var animationDefinition in definitions)
So my question is, is this acceptable on a mobile phone? Say iPhone 3GS/iPhone 4/Windows Phone 7/Android? I use MonoTouch in ANdroid and iPhone while WP7 has its own .Net running.
The reason I ask is currently I don't load that many animated sprites up but as I do more and more I'm worried it will start hurting performance. I figure it might be best to change my design ideas now than wait to suffer at a later date.
Thanks for any help!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我会简单地测试哪个更快（使用 SAXParser 再次读取它或使用 DOM 将其存储在内存中）。
也许将 XML 文件中读取的数据保存在数组/向量/类之类的内容中也是有意义的，这样您就不需要一遍又一遍地解析 XML 文件。
I would simply test what's faster (reading it again an again using a SAXParser or storing it in Memory using DOM).
Maybe it also makes sense to save the read data from your XML-File in something like an Array/Vector/Class so you don't need to parse the XML File over and over again.
本质上你想问的是有多少是“太多”。我建议考虑性能找到一个“实用”限制，您只需要递归地增加精灵的数量并注意应用程序何时变慢。保持安全系数为 1.5 到 3。您知道的。同样，您首先需要考虑总共有多少个精灵。如果所有内容都可以保留在内存中并尊重所有其他规范，那么就去做吧。客户不会介意游戏加载时间稍微长一些，只要内部流畅即可。否则就测试一下。
Well in essentially what you are trying to ask is how many is "too many". I would suggest to find a "practical" limit considering performance, you just need to recursively increase the number of sprites and notice when the application slows down. Keep a safety factor of say 1.5 to 3. And there you know. Again you need to consider how many sprites do you have in all to begin with. If all can possibly be kept in memory respect all other specifications, then go for it. Customer's won't mind a slightly longer loading time for games, as long as it is smooth inside. Else just test stuff out.