这是一个普遍的目标-c / iPhone问题：
如果我有一个大方法，创建一个类并从其他类调用该方法或者在每个新类中需要时重新编写该方法是否更好？我不是从代码阅读角度问，而是从iPhone性能角度来看。编译器在乎吗？有没有人有单身子类化的证据明显更快？
答案 0 :(得分：8)
推测优化总是过早优化。如果您遇到性能问题，请查看正在发生的事情。
在每个新课程中重写方法都是一种可怕的代码味道，告诉你几乎肯定做错了。就此而言，如果您担心适当的面向对象编程技术对性能的影响，您应该使用较低级别的东西。
（并且猜测你的问题的实际答案：无论方法在哪里，Objective-C方法调度仍然会发生。它是非常优化的，你可能没有注意到任何差异。）< / p>
答案 1 :(得分：1)
没有令人满意的广义答案，单身是否比多个实例更快。
我将讨论共享实例（而非单例）。
您可以使用共享实例进行更高级别的概括。
如果您的对象没有可变或线程严重状态，那么您可以通过共享该实例来减少您创建的对象数量。在这种情况下，您将减少您创建的对象的数量（在您的特定情况下，这是否应该是一个问题未知）。
同样，如果您发现问题，您通常可以重新考虑类设计，以便重复使用并根据您观察到的问题进行适当分享。这通常包括将一个大类的可变状态与其不可变状态分开，并在事务之间共享不可变的部分。这种技术通常用于更高级的问题，并且可能在中等复杂的iPhone应用程序中发生几次，但通常不会出现人们认为值得在小型应用程序中纠正的问题，因为开发人员认为这不是值得花时间的问题。
如果您的对象具有状态或必须以线程安全的方式运行，那么您可能需要适当地重新考虑需要共享的内容以及不需要共享的内容。这也因程序的执行方式而异。
所以，假设我们有一个：
共享实例会有帮助吗？
与每次创建新实例相比？是的。您可以创建更少的瞬态对象。这可能比计算本身花费更多。
在一个多线程的上下文中，有多个日期要转换，相比之下，每个线程有一个实例？否。你需要锁定，所有线程的客户端都在竞争相同的资源。如果它不是多线程的，你的程序会更快。在这种情况下，良好的（通用）解决方案是为每个线程创建一个格式化程序实例来处理所有这些日期，从而无需在处理每个日期时锁定格式化程序。
如果没有上下文，OP中的高级问题没有正确答案。您还需要很好地了解您的程序和问题，并选择正确的方法来解决问题。问题（或缺乏特定问题）不应成为创建单身人士的借口。
一般来说，我会说你应该首先关注好的设计，但也要注意你的程序的执行问题，并从中学习。许多等到明显性能问题的开发人员都不会认识到（并因此从中学习）他们过去的错误。因此，即使没有“明显的性能问题”，每隔一段时间进行一次配置并分析您的应用并了解如何改善出现的问题也是有帮助的。构造不良的设计也存在许多性能问题，样本/配置文件的信噪比不会非常有用 - 会有许多不太明显的问题，而且很多可能很难在事后纠正。通过分析和学习如何编写优化程序，您将提前了解性能注意事项，并在下次编写程序时避免和识别它们。识别将来出现的问题也需要更少的时间。