我是一个完整的 android 新手，但我已经编写 c# 很长时间了。我正在编写一个 android 应用程序，并且我的 C# 程序员想要开始创建松散耦合的设计并将代码移动到不同的层，使用接口等。
但后来我偶然发现了 Designing for performance 指导方针，它告诉我要避免创建对象，然后它还说要司法优化。
我是否只是基于良好的设计进行构建，然后在出现性能问题时处理它们？
我想做的最后一件事是完成构建应用程序的工作并让它表现不佳。 谁能指出一些设计良好且性能良好的应用程序示例，或者只是提出一些建议？
谢谢
【问题讨论】：
标签： android performance oop architecture
我发现AndEngine 设计得相当好，它必须关注性能，因为它是一个游戏开发库——所以你可以下载它的副本并阅读源代码。
在“为性能而设计”文档中，我会指出以下声明：
请注意，尽管本文档 主要涵盖微优化， 这些几乎永远不会成败 你的软件。 选择正确的 算法和数据结构应该 永远是您的首要任务，但 超出了本文档的范围。
创建粒子系统就是一个例子。对其建模的一个好方法是拥有一个包含 Particle 对象集合的 ParticleSystem 对象……也许这些 Particle 实现了 Particle 接口……这不是避免创建对象的地方。但是，出于性能原因，您需要优化 ParticleSystem 以回收 Particle 对象，而不是每次生成 Particle 对象时都从头开始创建它们。
就我个人而言，我并没有发现性能是一个很大的限制因素，但我认为这实际上取决于您正在构建的应用类型。
我的意见是先构建一个合适的设计，测试性能，然后从那里优化。
【讨论】：
作为一般规则，要做的事情是使数据结构尽可能简单和规范化。就像不要仅仅因为它们易于获取就扔进哈希表数据结构。知道如何进行分析 (here's my method)，如果您遇到真正的性能问题，请修复它。否则，越简单越好，即使这意味着简单的数组、列表和 O(N) 循环。
保持数据结构规范化的原因是，如果不是，那么它可能会有不一致的状态，并且你会很想编写通知样式的代码来保持它的一致性。这些可能是真正的性能杀手。如果你这样做，分析会告诉你这就是正在发生的事情。 如果您必须有冗余数据，我认为最好能够容忍一些暂时的不一致，您可以通过传递数据来定期修复。这比试图通过通知始终强烈地保证一致性要好。
非规范化数据结构的另一个问题是它可以创建和销毁大量对象。这也可能是一个真正的性能杀手，尽管您可以使用池技术来改善它。
【讨论】：
更多地关注出现在同一篇文章中的 Donald Knuth 的话：
“我们应该忘记小 效率，说大约 97% 时间：过早优化是 万恶之根。万恶之根。”
那么如果你在处理另外 3% 的人，你会看到......
【讨论】：