本文翻譯自：Busting Android performance myths，作者：Calin Juravle，譯文「Meandni」。

近年來，社區充斥著關于 Android 性能優化的各種誤區，本文本著誤區終結者的精神，使用具體的性能檢測工具，結合真實案例仔細分析這些情況，并對比它們的測試結果，也會聚焦 Android 開發者平時在編碼過程的實際場景，用實際數據告訴你在實際編碼之前請，一定要進行必要的性能檢測。

誤區 1：Kotlin 比 Java 更消耗性能

Google 云端硬盤團隊目前已將其應用程序從 Java 全面替換為 Kotlin，重構范圍涉及 170 多個文件，超過 16,000 行代碼，包含 40 多個編譯產物，在團隊監控的指標中，第一要素是啟動時間，測試結果如下：

如圖所示，使用 kotlin 并沒有對性能造成實質的影響，而且在整個基準測試過程中，Google 團隊也都沒有觀察到明顯的性能差異，即使編譯時間和編譯后的代碼大小略有增加，但都保持在 2％ 之內，完全可以忽略不計。而得益于 kotlin 簡潔的語法，團隊的代碼行卻減少了大約 25％，也變得更易讀和易維護。

還比較值得一提的是，使用 kotlin 時，我們也可以使用像 R8 這樣的代碼縮減工具，對代碼進行進一步的優化。

誤區二：Getters 和 setters 方法更耗時

因為擔心性能下降，有些開發者會選擇在類中直接使用 public 修飾字段，而不去寫 getter 和 setter 方法，如下面這段代碼，這里的 getFoo () 方法就是變量 foo 的 getter 函數：

public class ToyClass {public int foo;public int getFoo() { return foo; } }ToyClass tc = new ToyClass();

直接使用 tc.foo 獲取變量顯然已經破壞了面向對象的封裝性，而在性能方面，我們在配備 Android 10 的 Pixel 3 上使用 Jetpack Benchmark 對 tc.getFoo () 與 tc.foo 兩個方法進行了基準測試，該庫提供了預熱代碼的功能，最終的穩定測試結果如下：

getter 方法的性能與直接 access 變量的性能也并沒有多大差別，結果并不奇怪，因為 Android RunTime (ART) 內聯了代碼中所有的 getter 方法，因此，在 JIT 或 AOT 編譯后執行的代碼是相同的，正因如此，在 kotlin 中即使我們默認需要使用 getter 或 setter 獲得變量，性能也并不會有所下降，如果使用 Java，除非特殊需要，否則就不應該使用這種方式破壞代碼的封裝性。

誤區三：Lambda 比內部類慢

Lambda（尤其是在引入 Stream API 的情況下）是一種非常方便的語法，可實現非常簡潔的代碼。如下這段代碼，對對象數組的內部字段值求和，這里，使用了 Stream API 搭配 map-reduce 操作：

ArrayList<ToyClass> array = build();int sum = array.stream().map(tc -> tc.foo).reduce(0, (a, b) -> a + b);

第一個 lambda 會將對象轉換為整數，第二個 lambda 會將產生的兩個值相加。

下面代碼中，我們再將 lambda 表達式換成內部類：

ToyClassToInteger toyClassToInteger = new ToyClassToInteger();SumOp sumOp = new SumOp();int sum = array.stream().map(toyClassToInteger).reduce(0, sumOp);

這里，有兩個內部類：一個是 toyClassToInteger，它可以將對象轉換為整數，第二個 SumOp 用來做求和運算。

從語法上看，第一個帶有 lambda 的示例顯然更優雅，也更易讀。那么，性能差異又如何呢？我們再次在 Pixel 3 上使用了 Jetpack Benchmark，也沒有發現性能差異：

從圖中可以看到，我們還定義了單獨的外部 (top-level) 類一起來做比較，發現性能都沒有什么差異，原因就是 lambda 表達式最終也會被轉換為匿名內部類。因此，為了代碼的簡潔易讀，在這種場景下 lambda 表達式就是第一選擇。

誤區四：對象分配開銷過大，應該使用對象池

Android 內置了最先進的內存分配和垃圾回收機制，如下圖所示，幾乎每個版本的更新都在對象分配方面做各式各樣的更新。

各個版本之間的垃圾收集性能都有顯著的改善，如今，垃圾收集對應用程序的流暢已經幾乎沒有影響了。下圖展示了 Google 官方在 Android 10 中對具有分代并發收集的對象收集所做的改進，新版本的 Android 11 中也有明顯的改進。

在 GC 基準測試（例如 H2）中，吞吐量大幅提高了 170％ 以上，而在實際應用（如 Google Sheets）中，吞吐量也提高了 68％。

如果認為垃圾收集效率低下并且內存分配負擔很重，那么就相當于認為創建的垃圾越少，垃圾收集工作就越少，因此，代替每次使用時都創建新對象，我們可以維護一個經常使用的類型的對象池，然后從池中獲取已創建的對象，如下：

Pool<A> pool[] = new Pool<>[50];void foo() {A a = pool.acquire();…pool.release(a); }

這里省略了代碼細節，大體就是就是定義了一個 pool，從 pool 中獲取對象，然后最終釋放。

要測試這種場景，我們使用微基準測試 (microbenchmark)：從池中測試分配對象的開銷，以及 CPU 的開銷，來確定垃圾回收是否會影響應用程序的性能。

在這種情況下，我們依然可以在裝有 Android 10 的 Pixel 2 XL 上循環運行了數千次分配對象的代碼，因為對于小型或大型對象，性能可能會有所不同，我們還通過添加不同的字段來模擬不同的對象大小，最終的開銷結果如下：

用于垃圾回收的 CPU 開銷的結果如下：

從圖中可以看出，標準分配和池化對象之間的差異也很小，但是，當涉及到較大對象的垃圾回收時，池解決方案略微高一點。

這個結果并不意外，因為池化對象會增加應用的內存占用量，此時，應用突然占用了太多的內存，即使由于池化對象減少了垃圾回收調用的數量，每個垃圾回收調用的成本也更高，因為垃圾收集器必須遍歷更多的內存才能確定哪些對象需要被收集，哪些對象需要保留。

那么，對象是否應該被池化，這還是主要取決于應用的需求。如果不考慮到代碼復雜性，池化對象有如下缺點：

• 提高內存占用量
• 使對象存活變長
• 需要非常完善的對象池機制

但是，池的方法對于大并且耗時的對象分配可能確實是有效的，關鍵是要記住在選擇方案之前進行充分的測試。

誤區五：debug 模式下進行性能分析

在 debug 的同時對應用進行性能分析非常方便，畢竟，我們通常也是在 debug 模式下進行編碼的，并且，即使 debug 應用中的性能分析不準確，也可以更快地進行迭代修改提高效率，然后事實是并沒有。

為了驗證這一誤解，我們分析了 Activity 相關的常見操作過程過的測試結果，如下圖：

在某些測試（例如反序列化）中，debug 與否對性能沒有影響，但是，有些結果卻有 50％ 甚至以上的差別，我們甚至發現結果速度可能會慢 100％ 的例子，這是因為 runtime 在 debug 模式下時對代碼幾乎沒有優化，因此與用戶在生產設備上運行的代碼有很大不同。

在 debug 模式下進行性能分析的結果是可能會誤導優化方向，導致浪費時間來優化不需要優化的內容。

疑點

現在，我們需要有意識的逃避上述提到的五大誤區，下面我們再來看一下一些日常開發中不太明顯，但我們經常會有的疑惑的問題，事實結果可能也與我們想的大相徑庭。

疑點 1：Multidex：是否影響應用性能？

如今的 APK 文件越來越大，因為大型應用通常會超出 Android 限定的方法數量，從而使用 Multidex 方案打破傳統的 dex 規范。

問題是，多少方法可以稱之為多？而且如果應用包含大量 dex 是否對性能產生影響？很多時候我們也并不是因為應用太大，而是為了根據功能拆分 dex 文件來方便團隊開發而使用 Multidex。

為了測試多個 dex 文件對性能的影響，我們使用了計算器應用，默認情況下，它只包含單個 dex 文件，我們可以根據其程序包邊界將其拆分為五個 dex 文件，來根據功能部件模擬拆分。

首先，測試啟動應用的性能，結果如下：

因此，拆分 dex 文件對此處并沒有影響，對于其他應用，可能會因為某些因素而產生輕微的開銷：應用程序的大小以及拆分方式。但是，只要合理地分割 dex 文件并且不添加成百個 dex 文件，對啟動時間的影響應該不大。

接下來是 APK 的大小和內存消耗：

如圖所示，APK 大小和應用的運行時內存占用量都略有增加，這是因為將應用程序拆分為多個 dex 文件時，每個 dex 文件都會有一些符號表和緩存表中的重復數據。

但是，我們可以通過減少 dex 文件之間的依賴關系來最大限度地避免這種情況，在這個案例中，并沒有將 dex 包量化，我們可以使用 R8 和 D8 之類的工具合理分析項目結構并使用最小化的依賴關系，這些工具可以自動拆分 dex 文件，并幫助我們避免常見的錯誤，最大程度地減少依賴關系，如創建的 dex 文件數量不會超過指定的數量，并且不會將所有啟動類都放置在主文件中。但是，如果我們對 dex 文件進行自定義拆分，請確保合理分析。

疑點 2：無用代碼

使用 ART 這樣的即時編譯器的好處之一就是可以在運行時分析代碼，并對其進行優化。有一種說法是，如果解釋器 / JIT 系統沒有對代碼進行概要分析，就可能不會執行該代碼。為了驗證這一理論，我們檢查了 Google 應用生成的 ART 配置文件，發現許多代碼并沒有被 JIT 做概要分析，這就表明許多代碼實際上從未在設備上執行過。

有幾種類型的代碼可能無法剖析：

• 錯誤處理代碼，希望它不會執行太多。
• 兼容性代碼，并非在所有設備上都執行的代碼，尤其是 Android 5 以上版本的設備。
• 不常用功能的代碼。

但是，從結果分布來看，應用程序中還是會存在很多不必要的代碼。R8 可以幫助我們快速，簡便，免費地刪除不必要的代碼，來縮小這部分的開銷。如果不這么做，我們也可以將應用打包成 Android App Bundle，這種格式只會使用特定設備所需的代碼和資源來運行應用。

總結

本文，我們分析了 Android 性能優化的五大誤區，但某些情況下數據的結果還并不清晰，我們需要做的就是在優化和修改代碼之前盡量做好性能測試。

目前，已經有很多工具可以幫助我們分析評估如何優化應用了，如 Android Studio 中的 profilers，它也提供了電池和網絡的監測功能。也可以用一些工具做更深入的探究，如 Perfetto 和 Systrace，這些工具會提供更加詳細的功能，例如在應用啟動或執行過程中發生的具體情況。

Jetpack Benchmark 摒棄了監測和基準測試的所有復雜操作，官方強烈建議我們在持續集成系統中使用它來跟蹤性能，并查看應用在添加功能的行為，最后需要注意的一點是，不要在 debug 模式下分析應用性能。

【360°全方位性能調優】
性能優化相關所有知識點已經為你們整理成了PDF，從理論著手，利用大量實戰案例帶你全方位掌握APP性能優化的各個知識點和思路，需要的小伙伴點贊+關注后在我的GitHub即可直接免費下載獲取~

感謝大家關注我，分享Android干貨，交流Android技術。
對文章有何見解，或者有何技術問題，都可以在評論區一起留言討論，我會虔誠為你解答。
也歡迎大家來我的B站找我玩，有各類Android架構師進階技術難點的視頻講解，助你早日升職加薪。
B站直通車：https://space.bilibili.com/544650554

總結

以上是生活随笔為你收集整理的解锁！95%的Android程序员做性能优化时，存在的五大误区和两大疑点！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。