android性能優化

① android 性能優化有哪些

耗時任務非同步處理；
布局文件優化；
不可見視圖需要時載入；
應用內慎用多進程。
歡迎採納

② android系統性能優化怎麼學習

我們知道App運行過程中所有的操作都默認在主線程（UI線程）中進行的，這樣App的響應速度就會受到影響。會導致程序陷入卡頓、死掉甚至會發生系統錯誤。
為了加快響應速度，需要把費時的操作（比如網路請求、資料庫操作或者復雜的計算）從主線程移動到一個單獨的線程中。最高效的方式就是在類這一級完成這項操作，可以使用AsyncTask或者IntentService來創建後台操作。如果選擇使用IntentService，它會在需要的時候啟動起來，然後通過一個工作線程來處理請求（Intent）。

③ android 大量多線程怎麼優化

在程序開發的實踐當中，為了讓程序表現得更加流暢，我們肯定會需要使用到多線程來提升程序的並發執行性能。但是編寫多線程並發的代碼一直以來都是一個相對棘手的問題，所以想要獲得更佳的程序性能，我們非常有必要掌握多線程並發編程的基礎技能。
眾所周知，Android 程序的大多數代碼操作都必須執行在主線程，例如系統事件(例如設備屏幕發生旋轉)，輸入事件(例如用戶點擊滑動等)，程序回調服務，UI 繪制以及鬧鍾事件等等。那麼我們在上述事件或者方法中插入的代碼也將執行在主線程。

一旦我們在主線程裡面添加了操作復雜的代碼，這些代碼就很可能阻礙主線程去響應點擊/滑動事件，阻礙主線程的 UI 繪制等等。我們知道，為了讓屏幕的刷新幀率達到 60fps，我們需要確保 16ms 內完成單次刷新的操作。一旦我們在主線程裡面執行的任務過於繁重就可能導致接收到刷新信號的時候因為資源被佔用而無法完成這次刷新操作，這樣就會產生掉幀的現象，刷新幀率自然也就跟著下降了(一旦刷新幀率降到 20fps 左右，用戶就可以明顯感知到卡頓不流暢了)。

為了避免上面提到的掉幀問題，我們需要使用多線程的技術方案，把那些操作復雜的任務移動到其他線程當中執行，這樣就不容易阻塞主線程的操作，也就減小了出現掉幀的可能性。

那麼問題來了，為主線程減輕負的多線程方案有哪些呢？這些方案分別適合在什麼場景下使用？Android 系統為我們提供了若干組工具類來幫助解決這個問題。
AsyncTask: 為 UI 線程與工作線程之間進行快速的切換提供一種簡單便捷的機制。適用於當下立即需要啟動，但是非同步執行的生命周期短暫的使用場景。
HandlerThread: 為某些回調方法或者等待某些任務的執行設置一個專屬的線程，並提供線程任務的調度機制。
ThreadPool: 把任務分解成不同的單元，分發到各個不同的線程上，進行同時並發處理。
IntentService: 適合於執行由 UI 觸發的後台 Service 任務，並可以把後台任務執行的情況通過一定的機制反饋給 UI。
了解這些系統提供的多線程工具類分別適合在什麼場景下，可以幫助我們選擇合適的解決方案，避免出現不可預期的麻煩。雖然使用多線程可以提高程序的並發量，但是我們需要特別注意因為引入多線程而可能伴隨而來的內存問題。舉個例子，在 Activity 內部定義的一個 AsyncTask，它屬於一個內部類，該類本身和外面的 Activity 是有引用關系的，如果 Activity 要銷毀的時候，AsyncTask 還仍然在運行，這會導致 Activity 沒有辦法完全釋放，從而引發內存泄漏。所以說，多線程是提升程序性能的有效手段之一，但是使用多線程卻需要十分謹慎小心，如果不了解背後的執行機制以及使用的注意事項，很可能引起嚴重的問題。

④ android 性能優化用的什麼工具

推薦leb和獵豹清理大師

手機版LEB安全大師安卓版主要功能：
1.一鍵體檢：掃描惡意軟體.垃圾文件，一鍵修復
2.主動防禦：獨有主動防禦功能，控制軟體敏感許可權，解決吸費/竊取隱私/偷跑流量問題
3.系統優化：一鍵結束進程，清除垃圾文件，手機加速
4.自啟管家：獨創後台自啟控制，解決流氓軟體自動啟動,省電省內存
5.省電優化：多種省電模式，關閉耗電硬體，提供充電保護
6.上網監控：上網流量實時監控，流量超支自動斷網
7.聯網防火牆：獨創聯網防火牆，控制軟體聯網許可權
8.病毒查殺：強力查殺病毒/木馬/流氓軟體
9.軟體管理：批量卸載/批量移動/系統精簡等功能
10.通信防火牆：智能攔截垃圾簡訊和騷擾電話，具備黑名單/白名單/關鍵字等攔截模式
11.防盜服務：換卡通知/防盜拍照/鎖定手機/手機定位/銷毀數據/數據備份/響鈴報警/虛擬警告等多種功能, ROM安裝模式
12.自動IP撥號，來去電歸屬地顯示。

⑤ 安卓應用性能優化最佳實踐好不好

安個360就夠了吧，360可以優化也可以連接電腦

⑥ 如何對Android客戶端性能優化

為什麼我們的App需要優化，最顯而易見的時刻：用戶say，什麼狗屎，刷這么久都沒反應，取關卸載算了。
這跟什麼有關，我們先蒼白的反駁下，尼瑪用戶設備老舊網又爛，關我屁事，根本不用優化。可是，老闆拍板了，施壓給CTO，然後CTO又來找你：Y的今天必須給我想辦法優化了，不然不準回家。
好吧，為什麼從UI的表象上看，App又卡又慢而且還錯亂。我們試著來剖析下吧。
題外話：把minSDK改到4.0＋，去特么的low用戶，連手機都不願意換，還能指望它能給你帶來多少營收么，直接pass掉吧。4.0前的系統bug不少，不能為了彌補這些bug而降低了整體的高性能。
好了，讓我們先從UI說起：
首先要明白的是UI的繪制流程：measure-layout-draw，measure與layout都需要for loop所有的子控制項，匯集起來才能完成繪制，布局。所以子控制項越多，所消耗的時間越長(inflate，layout_weight，relative，多層嵌套等)，減少不必要的子控制項或層級，是相當有必要的。你可以通過merge,viewstub這些標簽來減少層級嵌套。如果你的空間觀念沒那麼好，可以用HierarchyViewer工具來檢查。
對於Listview或者GridView這種多item的組件來說，復用item可以減少inflate次數，通過setTag，getTag的ViewHolder方式實現復用，這里要注意的是，holder中的控制項最好reset後再賦值，避免圖片，文字錯亂。
對於ViewPager第一次顯示時卡頓以及左右滑動卡頓，有以下幾種優化方式：

ViewPager同時緩存page數最好為最小值3，如果過多，那麼第一次顯示時，ViewPager所初始化的pager就會很多，這樣pager累積渲染耗時就會增多，看起來就卡。
每個pager應該只在顯示時才載入網路或資料庫(UserVisibleHint=true)，最好不要預載入數據，以免造成浪費
圖片顯示不出來或者載入時間太長，怎麼辦？分兩部分，下載速度，載入速度。

對於下載，要控制好同時下載的最大任務數(平均速度慢)，同時給InputStream再包一層緩沖流會更快(如BufferedInputStream)。
對於載入速度，我們要知道一點，雖然下載的圖片可能只有幾百K，但是decode成bitmap所佔用的內存可是成倍的，盡可能的減小圖片size是根本因素，讓服務端提供不同解析度的圖片才是最好的解決方案，內存總有耗盡的時刻，別老想著大解析度會更清晰，實際就只有150*150的空間，非給弄張1000*1000的圖片是不恰當的。另外論載入速度：內存>硬碟>網路，合理的使用內存緩存也是關鍵。假如自己寫不好，沒關系，有那麼多開源的圖片緩存框架，不用自己操心。
再說緩存
有很多種緩存方式，也不用Stay列舉了，我們要說的是搭配使用。

比方說，以前我們一直在用強引用，HashMap，後來我們發現占內存，我們就用軟引用，弱引用來及時回收，再後來因為回收機制不可控，所以又有了lrucache，disklrucache通過演算法來平衡內存與硬碟緩存。隨著android版本的推進與演化，我們也應該擁抱變化。如果你的App里還有軟引用，弱引用的地方，不妨再check下。
比方說網路＋資料庫。網路我們一般都是去主動獲取，而非被動接受。那如果說數據是重復的或者未更改的呢？那我們去取一次網路數據有什麼意義呢？我的解決方案是給每個activity或fragment或每個組件設置一個最大請求間隔，比如一個listview，第一次請求數據時，保存一份到資料庫，並記下時間戳，當下次重新初始化時，判斷是否超過最大時間間隔(如5分鍾)，如果沒有，只載入資料庫數據，不需要再做網路請求。當然，還有一些隱式的http請求框架會緩存伺服器數據，在一定時間內不再請求網路，或者當伺服器返回304時將之前緩存的數據直接返回。
反正也說到網路了，那我們也來說說

現在有很多現成HTTP框架供我們使用，我們幾乎只用寫配置就可以搞定一個url請求，但是這里有很多需要服務端配合的，比如：json數據格式，WebP代替jpg，支持斷點續傳，多個請求合並成一個，盡量不做重定向，伺服器緩存以及負載均衡等。
對客戶端本身，除了上述的實現，我們還需要合理的緩存，控制最大請求並發量，及時取消已失效的請求，過濾重復請求，timeout時間設置，請求優先順序設置等。
優化可不是一個人的事，實現一個功能簡單，但是想優化重構，那是很不容易的事。需要多方面的預判與聯調。合理的假設與實踐是優化最重要的手段。
說完這些具體的點，我們再來說說一些常識，或者稱之為代碼規范。

你要知道for loop中不要聲明臨時變數，不到萬不得已不要在裡面寫try catch。
明白垃圾回收機制，避免頻繁GC，內存泄漏，OOM(有機會專門說)
合理使用數據類型，比如StringBuilder代替String，(筆試題最常見的是str+="str"中有幾個對象) ，少用枚舉enum，少用父類聲明(List,Map)
如果你有頻繁的new線程，那最好通過線程池去execute它們，減少線程創建開銷。
你要知道單例的好處，並正確的使用它。
多用常量，少用顯式的"action_key"，並維護一個常量類，別重復聲明這些常量。
如果可以，至少要弄懂設計模式中的策略模式，組合模式，裝飾模式，工廠模式，觀察者模式，這些能幫助你合理的解耦，即使需求頻繁變更，你也不用害怕牽一發而動全身。需求變更不可怕，可怕的是沒有在寫代碼之前做合理的設計。
當然還有很多很多，Stay所說的也只是一個大的輪廓，還是需要自己不斷的嘗試。會開發寫代碼跟會做產品的區別還是蠻大的，僅僅是態度就能刷死80%的碼農了。當你碰到一些需要優化的地方，耐心的去分析，時間的累積會讓你成為真正的工程師。
另外優化也沒有絕對的完美，每一次優化都是基於當前的環境來做的，要明白溝通是最好的優化，不盲從，不隨便，三思而後行。
Android上如何做性能優化的？大概寫三年代碼就能差不多知道了。

⑦ 針對Android的性能優化集中哪些方面

一、概要：

本文主要以Android的渲染機制、UI優化、多線程的處理、緩存處理、電量優化以及代碼規范等幾方面來簡述Android的性能優化

二、渲染機制的優化：

大多數用戶感知到的卡頓等性能問題的最主要根源都是因為渲染性能。

Android系統每隔16ms發出VSYNC信號，觸發對UI進行渲染， 如果每次渲染都成功，這樣就能夠達到流暢的畫面所需要的60fps，為了能夠實現60fps，這意味著程序的大多數操作都必須在16ms內完成。

*關於JobScheler的更多知識可以參考http://hukai.me/android-training-course-in-chinese/background-jobs/scheling/index.html

七、代碼規范

1）for loop中不要聲明臨時變數，不到萬不得已不要在裡面寫try catch。

2）明白垃圾回收機制，避免頻繁GC，內存泄漏，OOM(有機會專門說)

3）合理使用數據類型，StringBuilder代替String，少用枚舉enum，少用父類聲明(List,Map)

4）如果你有頻繁的new線程，那最好通過線程池去execute它們，減少線程創建開銷。

5）你要知道單例的好處，並正確的使用它。

6）多用常量，少用顯式的"action_key"，並維護一個常量類，別重復聲明這些常量。

7）如果可以，至少要弄懂設計模式中的策略模式，組合模式，裝飾模式，工廠模式，觀察者模式，這些能幫助你合理的解耦，即使需求頻繁變更，你也不用害怕牽一發而動全身。需求變更不可怕，可怕的是沒有在寫代碼之前做合理的設計。

8）View中設置緩存屬性.setDrawingCache為true.

9）cursor的使用。不過要注意管理好cursor,不要每次打開關閉cursor.因為打開關閉Cursor非常耗時。Cursor.require用於刷cursor.

10）採用SurfaceView在子線程刷新UI,避免手勢的處理和繪制在同一UI線程（普通View都這樣做）

11）採用JNI，將耗時間的處理放到c/c++層來處理

12）有些能用文件操作的，盡量採用文件操作，文件操作的速度比資料庫的操作要快10倍左右

13）懶載入和緩存機制。訪問網路的耗時操作啟動一個新線程來做，而不要再UI線程來做

14）如果方法用不到成員變數，可以把方法申明為static，性能會提高到15%到20%

15）避免使用getter/setter存取field，可以把field申明為public，直接訪問

16）私有內部類要訪問外部類的field或方法時,其成員變數不要用private，因為在編譯時會生成setter/getter,影響性能。可以把外部類的field或方法聲明為包訪問許可權

17）合理利用浮點數，浮點數比整型慢兩倍

18）針對ListView的性能優化，ListView的背景色與cacheColorHint設置相同顏色，可以提高滑動時的渲染性能。ListView中getView是性能是關鍵，這里要盡可能的優化。

getView方法中要重用view；getView方法中不能做復雜的邏輯計算，特別是資料庫操作，否則會嚴重影響滑動時的性能

19）不用new關鍵詞創建類的實例，用new關鍵詞創建類的實例時，構造函數鏈中的所有構造函數都會被自動調用。但如果一個對象實現了Cloneable介面，我們可以調用它的clone()方法。

clone()方法不會調用任何類構造函數。在使用設計模式（Design Pattern）的場合，如果用Factory模式創建對象，則改用clone()方法創建新的對象實例非常簡單。例如，下面是Factory模式的一個典型實現：

20）public static Credit getNewCredit() {
return new Credit();
}
改進後的代碼使用clone()方法，如下所示：
private static Credit BaseCredit = new Credit();
public static Credit getNewCredit() {
return (Credit) BaseCredit.clone();
}
上面的思路對於數組處理同樣很有用。

21）乘法和除法

考慮下面的代碼：

22）ViewPager同時緩存page數最好為最小值3，如果過多，那麼第一次顯示時，ViewPager所初始化的pager就會很多，這樣pager累積渲染耗時就會增多，看起來就卡。

23）每個pager應該只在顯示時才載入網路或資料庫(UserVisibleHint=true)，最好不要預載入數據，以免造成浪費

24）提高下載速度：要控制好同時下載的最大任務數，同時給InputStream再包一層緩沖流會更快(如BufferedInputStream)

25）提供載入速度：讓服務端提供不同解析度的圖片才是最好的解決方案。還有合理使用內存緩存，使用開源的框架

引用：Android性能優化的淺談

⑧ android應用性能優化 這本書怎麼樣

《Android應用性能優化》是人民郵電出版社2012-10出版的圖書。
就目前來說，已經跟不上潮流了。建議看新一點的書。

⑨ 如何對Android進行性能優化

不知道你是說對系統優化還是什麼app優化，

系統優化就只能找底層人員的了，我也不是很了解。

app優化的話，大體有以下幾個方面

1. ui優化，去除累贅的布局，優化初始化的速度，提高apk流暢性。

2. 網路交互優化，好的網路和數據處理方式決定了app的體驗性能。

3. 檢查內存是否有泄漏，人們常說的anr詳細。

如何你問的是android手機優化。

平常人只能下載手機管家這種軟體進行清除內存，垃圾，卸載無用的apk，保持android系統的流暢性。

⑩ Android應用性能優化的內容簡介

今天的Android應用開發者經常要想盡辦法來提升程序性能。由於應用越來越復雜，這個問題也變得越來越棘手。本書主要介紹如何快速高效地優化應用，讓應用變得穩定高效。你將學會利用Android SDK和NDK來混合或單獨使用Java、C/C++來開發應用。書中還特別講解了如下內容：
· 一些OpenGL的優化技術以及RenderScript（Android的新特性）的基礎知識；
· 利用SDK來優化應用的Java代碼的技巧；
· 通過高效使用內存來提升性能的技巧；
· 延長電池使用時間的技巧；
· 使用多線程的時機及技巧；
· 評測剖析代碼的技巧。
把本書的內容學以致用，你的編程技術就會得到關鍵性的提升，寫出的應用就會更為健壯高效，從而廣受用戶好評，並最終獲得成功。
目錄
第1章Java代碼優化1.1Android如何執行代碼1.2優化斐波納契數列1.2.1從遞歸到迭代1.2.2BigInteger1.3緩存結果1.4API等級1.5數據結構1.6響應能力1.6.1推遲初始化1.6.2StrictMode1.7SQLite1.7.1SQLite語句1.7.2事務1.7.3查詢
第1章Java代碼優化1.1Android如何執行代碼1.2優化斐波納契數列1.2.1從遞歸到迭代1.2.2BigInteger1.3緩存結果1.4API等級1.5數據結構1.6響應能力1.6.1推遲初始化1.6.2StrictMode1.7SQLite1.7.1SQLite語句1.7.2事務1.7.3查詢1.8總結
第2章NDK入門2.1NDK里有什麼2.2混合使用Java和C/C++代碼2.2.1聲明本地方法2.2.2實現JNI粘合層2.2.3創建Makefile2.2.4實現本地函數2.2.5編譯本地庫2.2.6載入本地庫2.3Application.mk2.3.1為(幾乎)所有設備優化2.3.2支持所有設備2.4Android.mk2.5使用C/C++改進性能2.6本地Acitivity2.6.1構建缺失的庫2.6.2替代方案2.7總結
第3章NDK進階3.1匯編3.1.1最大公約數3.1.2色彩轉換3.1.3並行計算平均值3.1.4ARM指令3.1.5ARM NEON3.1.6CPU特性3.2C擴展3.2.1內置函數3.2.2向量指令3.3技巧3.3.1內聯函數3.3.2循環展開3.3.3內存預讀取3.3.4用LDM/STM替換LDR/STD3.4總結
第4章高效使用內存4.1說說內存4.2數據類型4.2.1值的比較4.2.2其他演算法4.2.3數組排序4.2.4定義自己的類4.3訪問內存4.4排布數據4.5垃圾收集4.5.1內存泄漏4.5.2引用4.6API4.7內存少的時候4.8總結
第5章多線程和同步5.1線程5.2AsyncTask5.3Handler和Looper5.3.1Handler5.3.2Looper5.4數據類型5.5並發5.6多核5.6.1為多核修改演算法5.6.2使用並發緩存5.7Activity生命周期5.7.1傳遞信息5.7.2記住狀態5.8總結
第6章性能評測和剖析6.1時間測量6.1.1System.nanoTime()6.1.2Debug.threadCpuTimeNanos()6.2方法調用跟蹤6.2.1Debug.startMethodTracing()6.2.2使用Traceview工具6.2.3DDMS中的Traceview6.2.4本地方法跟蹤6.3日誌6.4總結
第7章延長電池續航時間7.1電池7.2禁用廣播接收器7.3網路7.3.1後台數據7.3.2數據傳輸7.4位置7.4.1注銷監聽器7.4.2更新頻率7.4.3多種位置服務7.4.4篩選定位服務7.4.5最後已知位置7.5感測器7.6圖形7.7提醒7.8WakeLock7.9總結
第8章圖形8.1布局優化8.1.1相對布局8.1.2合並布局8.1.3重用布局8.1.4ViewStub8.2布局工具8.2.1層級視圖8.2.2layoutopt8.3OpenGL ES8.3.1擴展8.3.2紋理壓縮8.3.3Mipmap8.3.4多APK8.3.5著色8.3.6場景復雜性8.3.7消隱8.3.8渲染模式8.3.9功耗管理8.4總結
第9章RenderScript9.1概覽9.2Hello World9.3Hello Rendering9.3.1創建渲染腳本9.3.2創建RenderScriptGL Context9.3.3展開RSSurfaceView9.3.4設置內容視圖9.4在腳本中添加變數9.5HelloCompute9.5.1Allocation9.5.2rsForEach9.5.3性能9.6自帶的RenderScript API9.6.1rs_types.rsh9.6.2rs_core.rsh9.6.3rs_cl.rsh9.6.4rs_math.rsh9.6.5rs_graphics.rsh9.6.6rs_time.rsh9.6.7rs_atomic.rsh9.7RenderScript與NDK對比9.8總結