android，面向對象程序設計vs性能設計

Question

我是一個android的完整noob，但我一直在編程c＃很長一段時間。我正在編寫一個android應用程序，並且已經到了一個地步，我的c＃程序員想要開始創建一個鬆散耦合的設計，並使用接口將代碼移入不同的層，等等。

但是後來我偶然發現了Designing for performance它告訴我的指導原則避免創建對象然後它也會說優化司法。

我是否只是基於良好的設計進行構建，然後在出現性能問題時進行處理？

我想要做的最後一件事是通過構建應用程序的工作並使其性能很差。 有人可以指點我設計的一些應用程序的例子，具有良好的性能或只是提出一些建議？

感謝

Answer 1

我發現AndEngine是相當精心設計的，它必須與性能關注，因爲它是一個遊戲開發庫 - 所以你可能會拉低它的拷貝和讀取源。

在「性能設計」的文件，我想指出這種說法：

注意，雖然該文件 主要涵蓋微型優化， 這些幾乎從來不會做或打破 軟件。 選擇合適的 算法和數據結構應該是 總是你的優先級，但是 超出了本文的範圍。

一個例子就是創建一個粒子系統。建模它的一個好方法是擁有一個包含粒子對象集合的粒子系統對象......也許這些粒子實現粒子接口......這不是避免創建對象的地方。但是，出於性能方面的原因，您將希望優化粒子系統以回收粒子對象，而不是每次從粒子系統產生時從頭開始創建它們。

就個人而言，我還沒有發現性能是一個限制因素，但我認爲這將取決於您正在構建的應用程序類型。

我的意見是先建立一個合適的設計，測試性能，並從那裏進行優化。

Answer 2

作爲一般規則，要做的事情是保持數據結構儘可能簡單和標準化。就像不要僅僅因爲它們很容易被抓到就拋出哈希表數據結構。知道如何進行性能分析（here's my method），如果你有一個真正的性能問題，然後修復它。否則，越簡單越好，即使這意味着簡單的數組，列表和O（N）循環。

保持數據結構規範化的原因是，如果不是，那麼它可能具有不一致的狀態，並且您會很強烈地寫出通知樣式的代碼來試圖保持它的一致性。那些可能是真正的表演殺手。如果你這樣做，分析將告訴你這是發生了什麼。 如果您必須擁有冗餘數據，我認爲最好能夠容忍一些暫時的不一致性，並通過傳遞數據定期修復。這比通過通知強烈保證始終如一的一致性要好。

非標準化數據結構的另一個問題是它可能有很多對象的創建和銷燬。這也可能是一個真正的性能殺手，雖然你可以通過泳池技術來改善它。

Answer 3

更加註重高德納的報價出現在同一篇文章中：

「我們應該忘記小 效率，講的 時間約97％：過早的優化是所有的 根邪惡的根源。「

然後，如果你是在處理與其他3％你會看到...