書寫整潔，高性能的代碼爲iPhone

Question

我一直在與Objective-C的iPhone的現在開發了數個月，我一直在運用最佳實踐經驗和精緻的同時使用Java開發應用程序。這些包括：設計具有單一責任的類，適當時應用設計模式，以及編寫只能做一件事的short methods。對我而言，這些做法從clean-code的角度來看都是有益的，並且主要是域不可知的。

我對結果很滿意。然而，一些iPhone開發人員獨立地建議我不要這樣做，因爲他們說我寫了太多的類和太多的方法。在不同的時間，我一直告誡：

• 堆棧將打擊
• 太多的班會減慢iPhone下來（即感知用戶）
• 嵌套方法調用會損害性能（即由感知用戶）

在實踐中我沒有經歷過這些問題。在表面上看一些iPhone performance metrics在我看來，實現常用模式和簡短方法所需的額外方法調用和對象生命週期開銷不可能產生任何用戶感知的延遲。然而，其他iPhone開發人員的建議讓我感到一絲驚訝。

我想繼續學習和完善過去爲我服務的領域不可知的編程實踐，但是在iPhone上開發時，我不希望走向一條痛苦的終點！

所以對於這個平臺 - 我應該放棄一些常見的最佳做法和更自覺的優化方法調用和對象的生命週期管理費用？或者我應該繼續遵循Knuth's建議：

過早的優化是 根所有邪惡（或至少大部分）在 編程

Answer 1

對我來說，它確實歸結爲可維護性。通過高質量的代碼，您可以更輕鬆地維護系統。

我有誰與我工作，當我建議他們走捷徑做一個系統的工作，他們嘲笑我和後期交付項目的開發者。並且每次都長期支付！

，如果它是一個密集的應用程序，使用opebGL並沒有什麼然後性能可能會成爲一個問題。如果它只是一個簡單的實用程序或數據應用程序。我會建議與你認識的最佳代碼實踐相連，然後繼續學習它們，因爲它們是非常寶貴的。大多數模式都是域不可知的，並且在所有有用的編程語言中都是有益的。

如果你確實打擊了堆棧，那麼將這些方法/類中的一些重新分爲單個調用（至少你知道它可能發生並且一旦它發生就會注意到它）並且如果它沒有，那麼你有很棒代碼保持這一點很容易被任何一個半熟的代碼猴子閱讀，後者必須查看它。

Answer 2

與OO應用減慢整個問題很簡單，對象可以失控更容易比結構化編程風格。曾幾何時，在方法調用優化改進之前，這可能會有所作爲，尤其是在進行間接（即虛擬）調用時。

如果你的對象是使用了很多，你有你打電話經常會出現一些較低級別的對象，那麼你可能會也許是從使用它們獲得的性能損失 - 但我說的是數以百萬計的呼叫（我見過一些可怕的代碼，無論是非結構化的，結構化的還是面向對象的！）。如果您不斷分配和刪除批量（LOTS）對象，則還會獲得更多性能。

唯一的答案真的不過是來看看。如果你有一個被分配的對象，快速連續刪除，然後優化它（即使它看起來不那麼優雅），如果你有一個對象，你調用它的方法數千次，然後優化。 （但是一旦你這樣做了測量，你必須衡量其性能，你會提煉慢位！）

有過「優雅」的代碼和代碼，工程簡單，迅速，唐之間的貿易不要走向極端，你應該沒問題。

Answer 3

我在開發一個相當複雜的黑莓應用程序時有類似的經歷。我也被告知要避免頻繁的對象分配，內部類等。我們原來的應用程序是一個難以維護的混亂。我最近重寫了應用程序，重點關注了良好的面向對象設計（需要的模式，大量單一目的以及通常不可變的對象等）。在很多地方，我違反了避免某些「昂貴」構造和對象分配的建議。由此產生的應用程序不僅更容易維護，而且更小。如果額外的對象分配創造了任何開銷，我當然沒有注意到。我認爲這裏的教訓正是Knuth所說的。首先關注優秀的設計，然後根據需要進行優化。此外，這些移動設備現在有足夠的內存來在那裏這一建議將有望失寵......

Answer 4

一般來說：不要擔心。使用對象和消息可能是一個潛在的性能問題的唯一情況是，您一次執行數百或數千個分配，或者每隔幾毫秒就發送數千個消息。您不希望在物理模擬中使用Obj-C對象來表示數以千計的3D矢量。

即使在情況下，你正在做的很多消息在一個循環發送，您可以通過循環之前存儲函數指針，以適當的方法獲得更好的性能。