每個(gè)人都知道一個(gè) App 的成功，與這個(gè) App 的性能體驗(yàn)有著很密切的關(guān)系。但是如何讓你的 App 擁有極致性能體驗(yàn)?zāi)兀吭?DroidCon NYC 2015 的這個(gè)分享里，Boris Farber 帶來了他關(guān)于 Android Api 以及如何避免一些常見坑的經(jīng)驗(yàn)。帶你了解如何縮短啟動(dòng)時(shí)間，優(yōu)化滑動(dòng)效果，創(chuàng)建更加順滑的用戶體驗(yàn)。

簡介

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

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

Activity 泄漏

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

m_staticActivity = staticFragment.getActivity()

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

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

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

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

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

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

盡管它看起來很短，但是只要它還存活著，那么包含它的 Activity 就會存活著。如果你不信我，在 VM 里試試看。這就是另一個(gè)內(nèi)存泄漏的案例：Activity 內(nèi)部的 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 是個(gè)很常用也很有用的類，異步，線程安全等等。如果有下面這樣的代碼，會發(fā)生什么呢？handler.postDeslayed ，假設(shè) delay 時(shí)間是幾個(gè)小時(shí)… 這意味著什么？意味著只要 handler 的消息還沒有被處理結(jié)束，它就一直存活著，包含它的 Activity 就跟著活著。我們來想辦法修復(fù)它，修復(fù)的方案是WeakReference，也就是所謂的弱引用。垃圾回收器在回收的時(shí)候，是會忽視掉弱引用的，所以包含它的 Activity 會被正常清理掉。大概代碼如下：

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

相比非靜態(tài)內(nèi)部類，最好使用靜態(tài)內(nèi)部類。區(qū)別就是靜態(tài)內(nèi)部類不依賴所屬類，他們擁有不同的生命周期。我經(jīng)常見到類似的原因引起的內(nèi)存泄露。

如何避免 Activity 泄漏?

移除掉所有的靜態(tài)引用。考慮用 EventBus 來解耦 Listener。記著在不需要的時(shí)候，解除 Listener 的綁定。盡量用靜態(tài)內(nèi)部類。做 Code Review。個(gè)人經(jīng)驗(yàn)：Code Review 能很早的發(fā)現(xiàn)內(nèi)存泄漏。了解你程序的結(jié)構(gòu)。用類似 MAT，Eclipse Analyzer，LeakCanary 這樣的工具分析內(nèi)存。在 Callback 里打印 Log。滑動(dòng)

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

載入圖片網(wǎng)絡(luò)請求解析 JSON 讀取數(shù)據(jù)庫

做這些操作是很慢的，像圖片，網(wǎng)絡(luò)，JSON考慮用現(xiàn)成的庫，有很多社區(qū)提供的解決方案，數(shù)據(jù)庫考慮下用 Loader，支持批量更新和載入。

圖片

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

內(nèi)存

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

網(wǎng)絡(luò)

首先，Java 的網(wǎng)絡(luò)請求確實(shí)是 Android 的一個(gè)阻礙。很多 Java.net 的 API 都是阻斷執(zhí)行的，切記不可在 UI 線程執(zhí)行網(wǎng)絡(luò)請求。在線程里執(zhí)行或者直接使用第三方庫吧。

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

大 JSON

在 UI 線程，也不做解析 Json 的事情，因?yàn)檫@是一個(gè)很耗時(shí)的事情。試著用 Google 的 GSON 來做反序列化的操作。

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

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

如何優(yōu)化滑動(dòng)速度?

UI 線程只做 UI 更新。理解并發(fā) API。開始使用優(yōu)秀的第三方庫。使用 Loader 加載數(shù)據(jù)庫數(shù)據(jù)

之所以要用第三方庫，是因?yàn)槟阕约喝ネ晟埔粋€(gè)復(fù)雜功能是需要花時(shí)間的。如果你打算專注在自己的功能性的 App 上，那么用庫吧。

并發(fā) APIs

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

我們來盤點(diǎn)下這些的區(qū)別：

IntentService

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

AsyncTask

如果你的任務(wù)需要更新 UI，那么考慮用 AsyncTask 吧，AsyncTask 雖然相對容易，但是有些坑得留意。當(dāng)你旋轉(zhuǎn)手機(jī)的時(shí)候，Activity 會被關(guān)閉，然后重啟。不然可能造成內(nèi)存泄露。

Executor Framework

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

如何適應(yīng)并發(fā)APIs?

學(xué)會和理解 API，懂得權(quán)衡確保找到了問題的正確解決方案了解問題真實(shí)所在重構(gòu)代碼Deprecation

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

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

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

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

如何避免廢棄 Api：

使用正確的 API。重構(gòu)依賴。不要濫用系統(tǒng)。更新依賴和工具。越新的通常越好。

用 Toolbar 而非 ActionBar，在需要?jiǎng)赢嫷臅r(shí)候用 RecyclerView，因?yàn)樗鼘ｉT為動(dòng)畫做過優(yōu)化。同時(shí) Android M 里移除了 Apache Http Connection。請使用 HttpURLConnection，它擁有更簡單的 API，更小的體積，默認(rèn)的壓縮功能，更好的 Response 緩存，等等其他很贊的功能。

架構(gòu)

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

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

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

總的來說，提及架構(gòu)和設(shè)計(jì)，最好的方法就是讓你的程序最快響應(yīng)。確保用戶能夠快速理解你的 App，并且擁有良好體驗(yàn)。