android應用性能分析

A. 針對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性能優化的淺談

B. android 性能優化有哪些辦法

性能優化的常用方法

主要內容包括布局優化，繪制優化，內存泄露優化，相應速度優化，ListView優化，Bitmap優化，線程優化等，下面主要給你舉了其中的幾個例子：

(1)布局優化

布局優化的思想很簡單，就是盡量減少布局文件的層級。

如何進行優化呢？首先刪除布局中無用的控制項和層級，其次有選擇地使用性能較低的ViewGroup，比如LinearLayout。如果布局中有的布局既可以用LinearLayout也可以用RelativeLayout，那就用LinearLayout,這是因為RelativeLayout比較復雜，他的布局過程花費更多的CPU時間。FrameLayout和LinearLayout一樣都是一種簡單高效的ViewGroup，因此可以考慮使用他們，但是很多時候，單純的通過一個LinearLayout或者FrameLayout無法實現產品的效果，需要通過嵌套的方式來完成，這種情況建議採用RelativeLayout，因為ViewGroup的嵌套就相當於增加了布局的層級，同樣會降低程序的性能。

布局優化的另一種手段是採用<include>標槍,<merge>標簽和ViewStub。<include>標簽主要用於布局重用，<merge>標簽一般和<include>配合使用，它可以減少布局的層級。而ViewStub則提供了按需載入功能，當需要時才將ViewStub中的布局載入到內存，這提高了程序的初始化效率。

(2)繪制方法

繪制優化是指View的onDraw方法避免執行大量的操作，這主要有兩方面。

首先，onDraw中不要創建新的布局對象，這是因為onDraw方法可能會被頻繁調用，這樣就會在一瞬間產生大量的臨時對象，這不僅佔用了過多的內存而且還會導致系統更加頻繁的gc，降低了程序的執行效率。

另一方面，onDraw方法中不要做耗時的任務，也不能執行成千上萬次循環操作，盡管每次循環都很輕量級，但是大量的循環仍然十分搶佔CPU的時間片，這會造成View的繪制過程不流暢。

(3)內存泄露優化

內存泄露在開發過程中是一個需要重視的問題，但是由於內存泄露問題對開發人員的經驗和開發意識要求比較高，因此這是開發人員最容易犯的錯誤之一。內存泄露的優化分為兩個方面，一方面是在開發過程中避免寫出內存泄露的代碼，另一方面通過一些分析工具比如MAT來找出潛在的內存泄露繼而解決。

關於性能優化的建議

1.避免黃健過多對象；

2.不要過多使用枚舉，枚舉佔用的內存空間比整型大一些。

3.常量使用staticfinal來修飾。

4.使用一些Android特有的數據結構，比如SpareArray和Pair等，他們都具有更好的性能。

5.適當使用軟引用和弱引用。

6.採用內存緩存和磁碟緩存

7.盡量採用靜態內部類，這樣可以避免潛在的內部類而導致的內存泄漏。

C. android應用測試哪些要點，如何進行測試的

1、主要從應用的功能、應用兼容性進行測試，愛內測是專門測試app性能的工具；
2、接著就是從android的不同版本和終端的解析度出發，界面易用性測試；
3、最後就是應用安全性測試，不同網路狀態下的測試。

D. android studio有哪些性能分析工具

導言：
Android應用在CPU佔用，內存消耗方面的性能指標是影響產品質量的重要因素，由於QQ管家，360手機助手等應用都提供直觀的內存消耗，流量監控功能，致使用戶比以往更加關注軟體的性能，並以此進行軟體選用的決策。
目前，已經有很多可以監控android app 性能的工具可以供開發人員使用，如：基於Eclipse插件體系的MAT，其通過生成.hprof文件對內存泄露情況進行排查；內存檢測工具APT：提供CPU利用率實時曲線圖，方便對比測試內存泄露問題[圖0-1]

E. 怎麼樣進行Android應用的性能分析

對於手機應用性能可以從兩方面關注:
1.app產品做好之後必須從每個控制項在國內不同的手機品牌和不同系統版本進行兼容性測試，業內也叫遍歷測試，所謂的遍歷測試是可以移動識別應用的控制項從而進行多層次的運行測試，當中包含了安裝測試，啟動測試，控制項遍歷測試，最後是卸載測試！
2.兼容性測試，也就是適配測試完成之後需要開始對網路性能進行測試，這里大概有幾個方面需要進行的:網路性能測試，元素載入性能測試，網路可用性測試等等！
國內現有的測試周期和測試手段都是通過人工化測試，真正實現自動化又節省時間與人力的只有藉助第三方應用性能管理提供商才可以實現！

F. 如何從技術上全面分析一款android app

一、用戶體驗是王道

1.這是一個看臉的時代，不論是人還是app。

2.Android出現也已經是很長的一段時間了，各種技術相對比較成熟，開源社區里那些圖片庫、網路庫、UI界面、數據框架一抓一大把，在同一個類別的應用中，如果沒點干貨真的很難脫穎而出。誰來判斷干貨，不是研發，不是pm，是用戶。

3.我現在的Leader之前跟我說過一句話，我深以為然--做一款app，其實最核心的是怎麼獲取到用戶，怎麼願意讓用戶去使用你，而不是你應用內的技術怎麼怎麼牛B。不喜勿噴，其實我剛開始的時候也不能理解，但是後來逐漸領悟到他說的竟然是對的。對於移動互聯網來說，app的生生死死真是太常見了，各個公司每年新開的項目一大片，真正能夠活下來的又有幾個。所以在應用的前期還是努力迭代功能，讓自己的app活下去之後，再考慮技術的問題吧

二、應用架構是否合理

1.簡單就一句話，不要重復造輪子，不要重復造輪子，尤其是不要在一個應用里反復造多個輪子。現在的軟體開發早就過了單槍匹馬闖天下的時代了，很多個研發同時工作，難免會造成各自代碼不熟悉，這時候就需要有人能夠將整個應用的架構能夠捋清楚，千萬不要出現項目中我用我的庫方法，你用你的庫方法，大家一起造輪子玩這種情況。

2.能夠使用開源庫就從了他吧。還是那句話，別人造好的輪子，為嘛不用，非得自己造一個，真以為自己是全能嗎？你不累我看著都累啊。

三、內存、網路、界面性能響應優化

其實大家都說過了軟體性能的重要性，我在這里也就不再進行復述了，反正LeakCanary,TraceView等等性能工具，誰用誰知道。

四、單元測試

感覺國內好像很少有研發自己寫單元測試的情況啊，其實我覺得很多時候，研發才是對功能最熟悉的人，很多邊界條件只有在代碼中才能夠恰好遇到，所以寫好單元測試做一隻不麻煩QA的猿才是好猿。

五、安全

Sorry，我對應用安全不是很懂，就是簡單用用Proguard混淆就Over了，加殼什麼的感覺貌似沒有太大必要，畢竟對於很多Android應用而言，其實看一眼大概知道他的界面邏輯了，ui層自己重寫絕對比逆向快，而api介面之類的東西，或許是我不太敏感吧。

G. Android開發中，有哪些好方法可以檢測內存泄露和性能

下面是回答的內容

內存泄露，是Android開發者最頭疼的事。可能一處小小的內存泄露，都可能是毀於千里之堤的蟻穴。怎麼才能檢測內存泄露呢？網上教程非常多，不過很多都是使用Eclipse檢測的, 其實1.3版本以後的Android Studio 檢測內存非常方便, 如果結合上MAT工具,LeakCanary插件,一切就變得so easy了。

熟悉Android Studio界面工欲善其事,必先利其器。

我們接下來先來熟悉下Android Studio的界面

結果

非獨占時間:某函數佔用的CPU時間,包含內部調用其它函數的CPU時間。
獨占時間:某函數佔用CPU時間,但不含內部調用其它函數所佔用的CPU時間。

我們如何判斷可能有問題的方法？

通過方法的調用次數和獨占時間來查看，通常判斷方法是：

如果方法調用次數不多，但每次調用卻需要花費很長的時間的函數，可能會有問題。

如果自身佔用時間不長，但調用卻非常頻繁的函數也可能會有問題。

綜述

上面給大家介紹了若干使用Android Studio檢查程序性能的工具,工具永遠是輔助,不要因為工具耽誤太長時間。如果有問題，歡迎大家糾正。

H. android性能測試需要哪些技術

Monkey 就是SDK中附帶的一個工具，該工具用於進行壓力測試。 然後開發人員結合monkey 列印的日誌 和系統列印的日誌，結局測試中出現的問題。
Monkey 測試,所有的事件都是隨機產生的，不帶任何人的主觀性。
1.標準的monkey 命令
[adb shell] monkey [options] <eventcount> , 例如：
adb shell monkey -v 500 產生500次隨機事件，作用在系統中所有activity（其實也不是所有的activity，而是包含 Intent.CATEGORY_LAUNCHER 或Intent.CATEGORY_MONKEY 的activity）。
上面只是一個簡單的例子，實際情況中通常會有很多的options 選項。

2：常用選項
--help：列印幫助信息
-v：指定列印信息的詳細級別，一個 -v增加一個級別 ， 默認級別為 0 。

3.事件選項
-s：指定產生隨機事件種子值，相同的種子值產生相同的事件序列。如： -s 200
--throttle：每個事件結束後的間隔時間——降低系統的壓力（如不指定，系統會盡快的發送事件序列）。如：--throttle 100
--pct-touch：指定觸摸事件的百分比，如：--pct-touch 5% ， 相關的還有以下option：
--pct-motion <percent> （滑動事件）、 --pct-trackball <percent> （軌跡球事件） 、 --pct-nav <percent> （導航事件 up/down/left/right）、 --pct-majornav <percent> (主要導航事件 back key 、 menu key)、 --pct-syskeys <percent> (系統按鍵事件 Home 、Back 、startCall 、 endCall 、 volumeControl)、 --pct-appswitch <percent> （activity之間的切換）、 --pct-anyevent <percent>（任意事件）。

4.約束選項
-p：指定有效的package（如不指定，則對系統中所有package有效），一個-p 對應一個有效package， 如：-p com.ckt -p com.ckt.asura；
-c：activity必須至少包含一個指定的category，才能被啟動，否則啟動不了。

5.調試選項
--dbg-no-events：初始化啟動的activity，但是不產生任何事件。
--hprof：指定該項後在事件序列發送前後會立即生成分析報告 —— 一般建議指定該項。
--ignore-crashes：忽略崩潰
--ignore-timeouts：忽略超時
--ignore-security-exceptions：忽略安全異常
--kill-process-after-error：發生錯誤後直接殺掉進程
--monitor-native-crashes：跟蹤本地方法的崩潰問題
--wait-dbg：知道連接了調試器才執行monkey測試。

6.一個簡單的monkey命令：
adb shell monkey -p com.xy.android.junit -s 500 -v 10000
表示產生時間序列的種子值：500， 產生 10000個事件 。

I. 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總結

J. 如何對Android手機 進行 多媒體性能測試 呢

所謂的多媒體就是指圖片,聲音和視頻對么?
買手機前准備幾張顏色比較鮮艷,分辯率比較高的圖片,放在手機上看效果,注意看手機屏幕顯示的色塊多不多,色塊太多的話證明屏幕的可顯示顏色較低.再就是分辯率,現在的手機都會給出很具體的參數,其實直接看參數就可以了,不用這么糾結的.如果還是不放心的話,檢查手機時就把仔細地檢查屏幕,看顯示的顆粒感強不強,一般400*800以上的分辯率肉眼已經很難看出顆粒感了.
檢查聲音的道理跟上面差不多,准備一兩首音質比較高的mp3或者其他格式的音頻,在手機上播放,包括耳機和外放.
視頻也如上,不再碼字.
如果信不過自己的眼睛的話還可以用Aurora Softworks和Quadrant這兩個軟體進行直觀的測試.跑完後直接看分數就OK了