如何通過技術優化讓 Android 程序變得流暢？

01-04

看到站上好多牛人在討論淘寶卡頓的問題，能不能從通用的角度說說如何讓 Android 應用程序用起來「流暢」。
相關問題：如何從程序優化的角度解釋淘寶支付寶的安卓版卡頓？ - Android

謝邀。

如何從程序優化的角度解釋淘寶支付寶的安卓版卡頓？ - Android 問題中， @M.A.G.I 和 @Trinea 兩位前輩已經從不同的角度（渲染丟幀、內存抖動、任務調度）說明了卡頓產生的原因。

至於性能優化，這是非常大一個範疇，包括 Android 的很多方面。具體還請移步：

Android性能優化典範

Android性能優化之渲染篇

Android性能優化之運算篇

Android性能優化之內存篇

Android性能優化之電量篇

Android性能優化典範

謝邀，以下回答來自本人的文集。如果轉發請務必注出處。同時希望能夠起到拋磚引玉的作用，引起大家更多的思考。

-------------------

調優之前

性能改善應該作為產品設計時就應該考慮的要素，也是品質控制的重要一環。還是那句老話，如果做，請趁早。在雛形階段，就應該對於性能的表現形式定下具體的KPI，比如，需要用多少時間來打開某個頁面，導入/導出多少條數據在多少秒之內，運行時的內存峰值控制在多少等等。

如果你面對的是一個多個團隊維護，開發維護歷史坎坷，用戶眾多的產品，那第一步要做的也是確定KPI，並經可能準確穩定的得到基線。

確定KPI

KPI不一定非要從最終用戶的交付出發, 也可以是像"loop函數的處理時間不超過0.05秒"這樣規定.
得到基線
根據KPI先得到基線, 如果已經有成型的產品, 則用當前的版本作為輸入得到, 如果沒有產品, 考察幾個市面上的竟品得到. 同時需要注意的是基線的測量不可避免的會遇到樣本不足和數據抖動的問題, 使得不穩定性, 所以測量方法也要儘可能的穩定和禁得住推敲.測量方法的設計也是一個涉及面比較廣的話題了, 不展開了. 多測試幾次,應用方差/平均值這樣的統計方法處理. 現在越來越多的應用使用線上收集的方式來收集性能數據, 就是為了增加樣本數.

識別問題得到基線後, 基本上對於產品的性能就有一個__客觀__的認識了。記下來就開始針對用戶/產品/開發者不滿意的地方進行工作了。不過，先不要急，首先要識別問題。這裡有一個我對於問題的分類，跟各位分享。

資源資源類問題指產品對於資源使用上存在著嚴重的浪費，比如頻繁的IO操作，過度的線程使用等等。

體驗大部分影響用戶體驗的問題，都可能是資源類問題引起的。但是還有相當一部分與資源無關，比如：數據從網路端到客戶端呈現比較慢，打開任務列表是等到菊花也謝了等

分析並解決問題就像性能問題是多種多樣的一樣，解決問題的手段也要視不同情況而定。但是，還是有一定的規律可循，同時，也有一些風險需要規避:

迷信新技術

盲目的認為新技術的引入可以解決性能問題，往往摁下葫蘆起了瓢。
頻繁改設計

每當有性能指標表現低下時，就改動設計，認為設計一定存在不合理的地方。

同時，有一些實踐經驗分享：

優化交互

對於體驗類問題，其實最好的切入點是優化交互設計。比如：讓頁面能馬上進入，可以讓用戶操作一些不需要網路數據的操作；多張圖片展示增加動畫效果，雖然總體展示時間不能提高，但是給用戶在整個過程中產品很努力不無聊。
先改bug

比較突出的性能問題往往伴隨著bug或者代碼瑕疵。比如，在Android上內存的泄漏引起頻繁gc導致程序卡頓；邏輯錯誤導致程序在後台持續請求數據，引起功耗增加等。所以，請先將bug控制住，我們再來談性能的改善。
適合移動設備的設計
- 伺服器端介面設計上儘可能的精簡，考慮到移動端的設計，分頁，消息結構精簡，鍵值短。
- 移動端對於資源類（webview， thread， IO類操作）有統一的管理，無論多少產品由多少個團隊維護，都要從統一的資源入口進行請求和處理。隊列在這方面一直很受歡迎^o^
- 根據機型和網路情況適配，避免產生過大，過多的資源對象（比如圖片， Html5的DOM等）
- 考慮數據資源的共用和緩存。圖片和H5的緩存不再話下，多團隊合作時要考慮之前這些數據是否已經有可以借用，圖片對象有時可以借用，部分數據可能也會有用。
- 視圖層深的優化，可能需要設計的介入
  但是很多時候對於視圖結構的麻木可能是罪魁禍首。沒有太好的建議，因為場景一般都比較複雜。這裡呼籲，請先積攢一些手寫UI的經驗再來開發工程產品吧。
- 其他。一些細節的把握，參考各種代碼實踐經驗，微小調整追求卓越。

修改之後

測量，收集數據，來印證修改效果，一切用數據說話。
記得將解決實踐記錄到checklist分享
制定相應的代碼靜態規則/單元用例等放入持續集成中。

總結

斷: 去掉不關注的方面, 專註影響性能的因素

舍: 放棄不切合實際的做法, 專註於問題的實質原因

離: 讓性能問題, 慢慢遠離你的產品吧^_^

沒有場景的優化都是耍流氓，淘寶的代碼百萬級別了，不要拿十萬行代碼來對比，有毛意思

沒那麼多幺蛾子，其實很簡單，把heavy task放在background thread里，精簡內存，確保沒有leak

這個需要在程序設計的時候就下足功夫，沒有那種神奇的工具可以一鍵就讓你的app如牛奶般絲滑。。。

做開發的話也多為用戶考慮，寫代碼時多考慮

別廢話。先跑個prof再撕逼。

最近Facebook開源了Redex

Redex是Andoird位元組碼(DEX)優化工具被Redex優化過後的APK體積更小運行速度更快

詳見博客地址：使用 Redex 壓縮和優化 Android APK

也可以關注個人公眾號：DevTipss

1.減少代碼冗餘.比如重複性的代碼可以寫在函數里,每次只需調用同一塊代碼.更不要為實現一個功能而圖方便引入一個龐大的庫(有很多功能可能用不上,卻降低執行代碼的效率)

2.內存管理控制.某些功能在用不上時絕對不要霸佔著寶貴的內存空間.給我通通釋放掉！！！！

3.多了解一下計算機工作原理的知識,理解實現同一功能的兩段代碼背後運行效率的區別.

其實就算做到了以上這些,也不保證程序能流暢,誰叫你們安塞猴系統讓各種程序輕而易舉地呆在後台,冊那！