【问题标题】:Writing clean, performant code for the iPhone为 iPhone 编写干净、高性能的代码
【发布时间】:2010-10-28 21:57:21
【问题描述】:

我已经用 Objective-C 在 iPhone 上开发几个月了,我一直在应用在用 Java 开发应用程序时学到和改进的最佳实践。其中包括:设计具有单一职责的类,在适当的情况下应用设计模式,以及编写只做一件事的short methods。对我来说,这些做法从 clean-code 的角度来看都是有益的,而且很大程度上与领域无关。

我对结果非常满意。然而,一些 iPhone 开发人员独立地建议我不要这样做,因为他们说我编写了太多的类和太多的方法。我曾多次收到警告:

  • 堆栈会爆炸
  • 太多的类会减慢 iPhone 的速度(即被用户察觉)
  • 嵌套方法调用会损害性能(即用户可察觉)

在实践中,我没有遇到过这些问题。从表面上看iPhone performance metrics,在我看来,实现通用模式和短方法所需的额外方法调用和对象生命周期开销不太可能造成任何用户可察觉的延迟。但是,其他 iPhone 开发者的建议让我有点害怕。

我想继续学习和完善过去对我很有帮助的与领域无关的编程实践,但是在 iPhone 上进行开发时,我不希望走上一条以痛苦告终的路线!

所以关于这个平台——我是否应该放弃一些常见的最佳实践并更加注意优化方法调用和对象生命周期开销?还是我应该继续关注Knuth's 的建议:

过早的优化是 所有邪恶(或至少大部分)在 编程

【问题讨论】:

  • 我想知道您是否可以展示一些代码示例。我想看看您如何在 Cocoa Touch 世界中使用您的 Java 经验。您在 github 上是否有任何公共存储库或与您的 ObjC 源类似的东西?

标签: iphone performance optimization coding-style


【解决方案1】:

对我来说,这确实归结为可维护性。使用高质量的代码,您可以更轻松地维护系统。

我有与我一起工作的开发人员,当我建议他们采取捷径使系统正常工作时,他们鄙视我并延迟交付项目。从长远来看,它每次都付出了代价!!!

如果它是一个密集型应用程序,使用 opebGL 和其他什么不是,那么性能可能会成为一个问题。如果它只是一个简单的实用程序或数据应用程序。我建议继续使用您知道的最佳代码实践,然后继续学习它们,因为它们非常宝贵。大多数模式与领域无关,并且对所有基础编程语言都有益。

如果你确实破坏了堆栈,那么将其中一些方法/类重新分解为单个调用(至少你知道它可能会发生并且会在它发生时立即注意到它)如果它没有那么你有很棒的代码以保持任何半生不熟的代码猴子都可以轻松阅读它。

【讨论】:

  • 当您说“我建议他们采取捷径使系统正常工作”时,您的意思是您建议他们这样做吗?这似乎与您的其余答案不一致。您的意思是您向他们指出他们正在走捷径,但您实际上会建议他们不要这样做?
  • 不,我实际上建议他们走捷径,但从那时起,我看到了良好的代码、可读性和模式的好处,尤其是在团队环境中。你可以说我改变了我的调子 :) 作为经理,我为我的开发人员辩护,如果他们说在他们以特定的模式/架构实现它之前他们不能交付。然后我告诉客户会有延迟。因为我知道当客户在几周内更改 tac 时,我们将准备好使用非 hacky 代码。
【解决方案2】:

OO 应用程序变慢的整个问题仅仅是对象比结构化编程风格更容易失控。曾几何时,在改进方法调用优化之前,这可能会产生影响,尤其是在进行间接(即虚拟)调用时。

如果您的对象被大量使用,并且您有一些您经常调用的较低级别的对象,那么您可能会因使用它们而受到性能影响 - 但我说的是数百万次调用(我见过一些我那个时代的代码很糟糕,包括非结构化的、结构化的和面向对象的!)。如果您不断地分配和删除大量 (LOTS) 对象,也会对性能造成更大的影响。

真正的唯一答案是看一看。如果您有一个对象被分配、快速连续删除,然后优化它(即使它看起来不那么优雅),如果您有一个对象调用它的方法数千次,那么也优化它。 (但是一旦你完成了这个测量,你就会测量它的性能并且你会改进慢的位!)

在“优雅”的代码和运行简单快速的代码之间需要权衡取舍,不要走极端,你应该没问题。

【讨论】:

    【解决方案3】:

    在开发一个相当复杂的黑莓应用程序时,我也有类似的经历。我也被告知要避免频繁的对象分配、内部类等。我们原来的应用程序是一团无法维护的混乱。我最近重写了应用程序,重点关注良好的 OO 设计(需要的模式、大量单一用途且通常不可变的对象等)。在很多地方,我违反了避免某些“昂贵”构造和对象分配的建议。由此产生的应用程序不仅更易于维护,而且更小。如果额外的对象分配产生了任何开销,我当然没有注意到。我认为这里的教训正是 Knuth 所说的。首先关注良好的设计,然后在需要时进行优化。此外,如今这些移动设备拥有足够的内存,因此该建议可能会失宠……

    【讨论】:

      【解决方案4】:

      一般来说:不用担心。使用对象和消息可能成为潜在性能问题的唯一情况是您一次执行数百或数千个分配,或者每隔几毫秒发送数千个消息。您不会希望在物理模拟中使用 Obj-C 对象来表示数千个 3D 矢量。

      即使在循环中发送大量消息的情况下,也可以通过在循环之前存储指向适当方法的函数指针来获得更好的性能。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2018-08-26
        • 2011-02-15
        • 1970-01-01
        • 1970-01-01
        • 2013-04-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多