每個人都知道一個 App 的成功，與這個 App 的性能體驗有著很密切的關系。但是如何讓你的 App 擁有極致性能體驗呢？在 DroidCon NYC 2015 的這個分享里，Boris Farber 帶來了他關于 Android Api 以及如何避免一些常見坑的經驗。帶你了解如何縮短啟動時間，優化滑動效果，創建更加順滑的用戶體驗。

簡介

大家好，我是 Boris，現在是 Google 的一枚員工，目前專注于需要高性能的 App。這個分享是我長期以來從錯誤中，以及在給合作伙伴做咨詢的時候攢下的最佳實踐。如果你有一個小型的 App，讀過之后，會在你的 App 成長階段起到幫助。

我常常會見到那些啟動時間很長，滑動不流暢，甚至出現沒有反應的 App。我們通常要花很多時間去改善這些問題，畢竟我們都希望自己的 App 能夠成功。

Activity 泄漏

我們第一個需要修復的問題就是 Activity 泄漏，我們先來看看內存泄漏是怎么發生的。 Activity 泄漏通常是內存泄漏的一種。為什么會泄漏呢？如果你持有一個未使用的 Activity 的引用，其實也就持有了 Activity 的布局，自然也就包含了所有的 View。最棘手的是持有靜態引用。別忘了，Activity 和 Fragment 都有自己的生命周期。一旦我們持有了靜態引用，Activity 和 Fragment 就不會被垃圾回收器清理掉了。這就是為什么靜態引用很危險。

m_staticActivity = staticFragment.getActivity()

我看過太多次這樣的代碼了。

另外，泄漏 Listener 也是經常會發生的事情。比如說，我有下面的代碼。LeakActivity繼承自 Activity，我們有一個單例：NastyManager，當我們通過 addListener(this) 將 Activity 作為 Listener 和 NastyManager 綁定起來的時候，不好的事情就發生了。

public class LeakActivity extends Activity { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); NastyManager.getInstance().addListener(this); } }

想要修復這樣的 Bug，其實相當簡單，就是在你的 Acitivity 被銷毀的時候，將他和 NastyManager 取消掉綁定就好了。

@Override public void onDestroy() { super.onDestroy(); NastyManager.getInstance().removeListener(this); }

相對上面的解決方案，我們自然還有更好的。比如我們真的需要用到單例嗎？通常，并不需要。不過某些時候可能真的很需要。我們得權衡和設計。不過無論如何，記住，當 Activity 銷毀的時候，在單例中移除掉對 Activity 的引用。下面我們討論下： 如果是內部類，會發生什么？比如說，我們有一個在 Activity 里有一個很簡短的非靜態 Handler。

盡管它看起來很短，但是只要它還存活著，那么包含它的 Activity 就會存活著。如果你不信我，在 VM 里試試看。這就是另一個內存泄漏的案例：Activity 內部的 Handler。

public class MainActivity extends Activity { //... Handler handler; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); //... handler = new Handler() { @Override public void handleMessage(Message msg) {} } }

Handler 是個很常用也很有用的類，異步，線程安全等等。如果有下面這樣的代碼，會發生什么呢？handler.postDeslayed ，假設 delay 時間是幾個小時… 這意味著什么？意味著只要 handler 的消息還沒有被處理結束，它就一直存活著，包含它的 Activity 就跟著活著。我們來想辦法修復它，修復的方案是WeakReference，也就是所謂的弱引用。垃圾回收器在回收的時候，是會忽視掉弱引用的，所以包含它的 Activity 會被正常清理掉。大概代碼如下：

概括來說：我們有個內部類，就像 Handler，內部非靜態類是不能脫離所屬類而單獨存活的，Android 里通常是 Activity。所以，看看你的代碼里的內部類，確保他們沒有出現內存泄漏。

相比非靜態內部類，最好使用靜態內部類。區別就是靜態內部類不依賴所屬類，他們擁有不同的生命周期。我經常見到類似的原因引起的內存泄露。

如何避免 Activity 泄漏?

移除掉所有的靜態引用?？紤]用 EventBus 來解耦 Listener。記著在不需要的時候，解除 Listener 的綁定。盡量用靜態內部類。做 Code Review。個人經驗：Code Review 能很早的發現內存泄漏。了解你程序的結構。用類似 MAT，Eclipse Analyzer，LeakCanary 這樣的工具分析內存。在 Callback 里打印 Log?；瑒?

實現流暢滑動的技巧：UI 線程只用作 UI 渲染。這一條真諦能夠解決 99% 的滑動卡頓問題。不要在 UI 線程做下面的事情：

載入圖片網絡請求解析 JSON 讀取數據庫

做這些操作是很慢的，像圖片，網絡，JSON考慮用現成的庫，有很多社區提供的解決方案，數據庫考慮下用 Loader，支持批量更新和載入。

圖片

圖片相關的庫有很多，比如 Glide, Picasso, Fresco。你可以自己去了解下他們之間的區別，以幫助自己在特定場景下做出取舍。

內存

Bitmap 操作是很需要技巧的，圖片一般比較大，而且系統對最大內存又有限制和要求。在我面對 4.0 之前的系統的時候，我簡直要崩潰了。內存管理也很需要技巧。有的時候需要放到文件里，有的時候需要放到內存里，別忘了，我們還有一個很有用的工具：LRUCache。

網絡

首先，Java 的網絡請求確實是 Android 的一個阻礙。很多 Java.net 的 API 都是阻斷執行的，切記不可在 UI 線程執行網絡請求。在線程里執行或者直接使用第三方庫吧。

異步 HTTP 其實也挺麻煩的，4.4 起 OkHttp 就成了 Android 代碼的一部分了，然而… 如果你需要最新版本的 OkHttp ，可以考慮自己引入。另外有個不錯的庫叫： Volley，也可以試試 Square 的 Retrofit。這些都能讓你的網絡請求變得更友好。

大 JSON

在 UI 線程，也不做解析 Json 的事情，因為這是一個很耗時的事情。試著用 Google 的 GSON 來做反序列化的操作。

對于巨大的 JSON 解析，建議用更快的 Jackson 以及 ig-json-parser，這兩個工具在 JSON 的解析上做的非常漂亮。從公司的反饋結果來看 ig-json-parser 的效率是最高的。

Looper.myLooper() == Looper.getMainLooper() 是可以幫助你確定你是否在主線程的代碼。

如何優化滑動速度?

UI 線程只做 UI 更新。理解并發 API。開始使用優秀的第三方庫。使用 Loader 加載數據庫數據

之所以要用第三方庫，是因為你自己去完善一個復雜功能是需要花時間的。如果你打算專注在自己的功能性的 App 上，那么用庫吧。

并發 APIs

如何讓 App 快速響應請求是個很重要。開發者們，甚至包括我，經常忘記 Service 的方法是在 UI 線程執行的。請考慮使用 IntentService，AsyncTask，Executors，Handler 和 Loopers。

我們來盤點下這些的區別：

IntentService

我在之前的公司，我用 IntentService 來執行上傳功能。IntentService 是一個單線程，一次一個任務的工作流。我們沒有很復雜的任務系統。如果你有大型復雜的任務，而且這個任務不需要跟 UI 打交道，那么考慮用 IntentService 吧。

AsyncTask

如果你的任務需要更新 UI，那么考慮用 AsyncTask 吧，AsyncTask 雖然相對容易，但是有些坑得留意。當你旋轉手機的時候，Activity 會被關閉，然后重啟。不然可能造成內存泄露。

Executor Framework

這是 Java 6 自帶的并發方案。默認是存在一個由系統管理的線程池，你可以通過 callback，future 來控制和管理。這根 MapRedues 發難有點像，面對復雜的任務，你希望能夠把他們拆分交給多個線程來處理。Executor 的框架就很能勝任這種場景。

如何適應并發APIs?

學會和理解 API，懂得權衡確保找到了問題的正確解決方案了解問題真實所在重構代碼Deprecation

我們肯定都知道，最好能夠避免使用廢棄的 API。比如以下的例子：

不要通過反射來調用私有 API。不要再 NDK 和 C 語言層調用私有 Native 方法。不要輕易調用 Runtime.exec 指令完成進程通訊功能。adb shell am 做進程通訊并不好。

廢棄的意思是這些 API 將會被移除，通常在正式版發布 1，2天左右，你的 App 就不會工作了。更糟糕的情況是，如果你的 App 依賴了一些庫，而這些庫喲改了廢棄的 Api 或者工具。那可就慘了，如果一旦作者沒有更新…你懂得。

不要用廢棄 Api 的另一個原因是性能問題和安全問題。

如何避免廢棄 Api：

使用正確的 API。重構依賴。不要濫用系統。更新依賴和工具。越新的通常越好。

用 Toolbar 而非 ActionBar，在需要動畫的時候用 RecyclerView，因為它專門為動畫做過優化。同時 Android M 里移除了 Apache Http Connection。請使用 HttpURLConnection，它擁有更簡單的 API，更小的體積，默認的壓縮功能，更好的 Response 緩存，等等其他很贊的功能。

架構

架構中的 Bug 總是最為煩人。想要避免這種問題，學習下 App 組件的生命周期。比如什么是 Activity 的 Flag？什么是 Fragment？什么事 stated fragment？什么是 task？讀讀文檔，嘗試下用回調的 log 搞清楚這些概念。

時常有人問我：“Picasso 和 Glide 哪個更好？我改用 Volley 還是 OkHttp？”，這種問題根本沒有 100% 正確的答案。不過，當我在選擇一個庫的時候，我會用下面的 Checklist 來決策：

確保它能夠解決你的問題。確保它和當前所有的依賴能正常工作。檢查依賴留意一下依賴的版本沖突了解維護情況和成本

總的來說，提及架構和設計，最好的方法就是讓你的程序最快響應。確保用戶能夠快速理解你的 App，并且擁有良好體驗。