卡頓分析之內(nèi)存抖動和計算性能優(yōu)化

1、低性能函數(shù)開始，也就是函數(shù)執(zhí)行過慢讓首先從一個非常熟悉，這是性能概念方面的初級基礎計算機科學知識。有時候，當你寫完代碼之后，你發(fā)現(xiàn)它的運行速度，比你預想的要慢，這種情況經(jīng)常會無緣無故地出現(xiàn)，你專注于采用某種方法編寫代碼，來解決特定，但是很快你發(fā)現(xiàn)代碼的運行時間過長，遠遠超過你的預期。代碼運行時間過長，在很大程度上可以歸咎于編程語言，當然還有相關硬件執(zhí)行代碼的方式。例如，在一些老舊硬件上，執(zhí)行浮點比較算法分支語句所花的時間，幾乎是整數(shù)或數(shù)值的四倍。其原因在于架構，負責浮點計算的 CPU 部分在分支邏輯階段之后開始工作。這意味著任何浮點比較都需要等待，直到循環(huán)管道結(jié)束，從而拖延其他運算，直到分支邏

2、輯最終執(zhí)行完成，但是請不要感到害怕?，F(xiàn)代硬件通常不需要處理這種細微問題，但是這也說明了一個很重要的觀點，即，你編寫代碼的方式會影響性能，具體視硬件上執(zhí)行的編程語言而有所不同。這個問題甚至可以追溯到代碼，你需要理解系統(tǒng)如何運行代碼。架構。的是，為了優(yōu)化你的緩慢的函數(shù)執(zhí)行通常是由于兩方面造成的，第一種是執(zhí)行速度很慢的函數(shù)，這種函數(shù)很容易被發(fā)現(xiàn)。你的某些函數(shù)所花費的時間，超過你的預期 2 倍、10 倍，甚至 50 倍，這種問題容易解決。只要找到那些運行很慢的函數(shù)，查看代碼找到問題所在，然后想辦法解決就可以了。更難發(fā)現(xiàn)的是第二種類型，想法設法也難以發(fā)現(xiàn)，尤其是當你有數(shù)以千計的函數(shù)時，每個函數(shù)所用的時間

3、都額外增加一毫秒，從而導致整個程序執(zhí)行速度變慢數(shù)百毫秒，這種類型很難，而且更難以解決，因為通常你需要分析，每段執(zhí)行代碼才能發(fā)現(xiàn)這些小問題，這最終會影響你的產(chǎn)品發(fā)布，進而影響公司業(yè)績。要解決這些細小，主要的方法是剖析（profiling），通過時間線分析方法，找到執(zhí)行速度緩慢的代碼部分，或者時間明顯長于其它代碼的部分，然后進行一些細小變更。然后再次進行時間線分析，找到執(zhí)行很慢的函數(shù)之后，你需要對這些函數(shù)的代碼行進行時間線分析，以及調(diào)用這些函數(shù)的所有其他函數(shù)。這項工作確實相當繁瑣，除非你是這個領域的，但是不要害怕，Android SDK 有一些很不錯的工具，幫助你找到這些有問題的代碼部分，讓你能夠

4、立即解決它們，讓來了解它們。Traceview 工具你的應用程序中的一些計算相關的性能問題。在這個演示中，我將演示如何使用工具來Sunshine 應用程序，這個工具是 TraceView。載入它，打開 DDMS 視圖選擇要分析的應用，請你注意一下，上的一些圖標，尤其是這個圖標?？瓷先ハ袷侨婕^，上面有紅色的圓點，如果按這些按鈕，會出現(xiàn)一些提示，說將開始進行方法分析。這是 TraceView 的啟動方法，點擊它。將出現(xiàn)一個彈出窗口，提示有兩種方法來分析你的應用程序。你可以每個方法的輸入和輸出，他們對資源的要求很高，或者，你也利用示例進行一些分析。其含義是，默認情況下分析程序，將會每 1000

5、毫秒偵測一次你的應用程序，以發(fā)現(xiàn)和實際上在運行的功能，現(xiàn)在，讓來使用這些默認設置。我點擊一下 OK，既然分析程序已經(jīng)在繼續(xù)，就與你的應用程序進行交互，看能否一些動作。因此跳轉(zhuǎn)到這里與 Sunshine 應用程序進行交互，好極了，山景地區(qū)的天氣。不幸的是，周末的天氣卻不太好，將會下雨?？纯春０秴^(qū)域，在南加州的朋友還好嗎？奇怪，他們已經(jīng)進入冬季，這在亞哥是很少見的。回到 Android Device Monitor，想要停止分析。還是應該點擊這個圖標，啟動時也是點擊它。在最上方有一個黑標或者黑色方塊，點擊它可以停止分析?，F(xiàn)在，可能需要一點時間來載入，將會顯示在窗口上方，選項卡的這個位置。請記住，實

6、際所用的時間可能更長一點，具體取決于實際的內(nèi)容。來看視圖，視圖有兩個主要組成部分。上方窗格的名稱是 timeline 面板，下方窗格內(nèi)有很多的信息，稱為 profile 面板。這個時間線能夠很好的顯示代碼的執(zhí)行情況，這里顯示的每一行，實際上對應于一個線程。顯示的每一個顏色，對應于一個正在運行的特定方法。例如，可以看到，主線程的所有活動，可以看到方法啟動和停止時間點，更有用的是放大這里，找到特定的方法，了解他們是如何執(zhí)行的。它們會以這種 U 型模式顯示出來。這里的條形表示，方法的啟動時間。右側(cè)的條形表示，方法的停止時間。條形的寬度表示方法執(zhí)行所用的時間。現(xiàn)在，選擇一個特定的方法，跳轉(zhuǎn)到視圖窗口的

7、底部，這里，看到一些分析數(shù)據(jù)顯示出來?？梢钥吹侥男┓椒ㄕ{(diào)用了選定的方法。在這里，用他們的父級方法顯示為藍色，還可以看到一些信息，顯示在這個方法內(nèi)調(diào)用了哪些方法。也就是說，調(diào)用了一個發(fā)送輸入事件方法。在選擇之后，會顯示一個本地條柱。對于占 CPU 時間，選擇的所有這些方法，都有大量的附加統(tǒng)計信息。例如，可以看到獨可以使用這些信息，找到具體方法的特定問題。非獨占 CPU 時間是特定方法在其調(diào)用的所有方法所用的時間。這可以幫你在信息樹內(nèi)找到，選定方法的特定問題。另一個十分有用的信息是，方法被調(diào)用了多少次，或者遞歸調(diào)用本身多少次。如果滾動到右側(cè)，可以找到這些信息，這里有一個列名為“calls and

8、recur”，此列顯示方法被調(diào)用多少次，或者它被遞歸調(diào)用多少次。在這個分析面板中，有大量的附加信息。另外，記這個搜索框，它可以幫助查找你所關心的功能。每個方法前面都有一個數(shù)字，按照 Incl CPU Time 時間的排序序號展開一個方法后可以看到有兩部分Parent 表示調(diào)用這個方法的方法，可以叫做父方法Children 表示這個方法中調(diào)用的其他方法，可以叫做子方法Profile 面板中各列作用說明備注：CPU time 就是CPU 實際花了多少時間在運行函數(shù)，CPU 在多進程環(huán)境下不會把所有時間用在一個進的批處理與緩存技術介紹我最喜歡的兩個性能技術，批處理（batching）和緩存（cach

9、ing）。前一些函數(shù)和運算，需要非常大的資源開銷，這也會影響計算性能。例如，在向已經(jīng)面執(zhí)行之前把數(shù)據(jù)載入特定的內(nèi)存區(qū)域，或者，在搜索之前對數(shù)值集進行排序，在執(zhí)行多次之后，而且次數(shù)確實是個很大的數(shù)字，資源開銷將會嚴重影響應用程序的性能。批處理是可以幫助解決這種性能問題，它消除每個運算的獨立執(zhí)行開銷，好像是所有人都開一輛車，而不是每個都開一輛，從而節(jié)省。這種情況最常見于在執(zhí)行運算之前，你需要準備數(shù)據(jù)。例如，在查找集合中的值時，最有效的方法是進行排序，然后進行二分法搜索等等。有一點必須弄清楚，這并不是最有效的方法。這只是舉一個例子而已，最簡單的方法是寫一個函數(shù)，提供一個集合和一個值，對集合進行排序，

10、然后查看值是否存在于集合之中。對于某些性能要求來說，這樣做是可以的。但是，如果有 10000 個值，而且總共需要數(shù)百萬租數(shù)據(jù)，排序所花費的時間，將會增加很多倍，很明確。對這組數(shù)據(jù)完成排序，然后查找所有找到重復的運算，找到之后，10000 個值，并不是明智的方法。這時就需要用到批處理，進行批處理。緩存是與批處理相似的概念，這也是目前為止，你能理解的最重要的性能技術。這項技術全面地推動現(xiàn)代計算機科學的發(fā)展，以計算機為例，內(nèi)存的作用是用來信息，讓 CPU能夠更快的數(shù)據(jù)，其速度遠快于硬盤數(shù)據(jù)。列名作用Name該進程運行過所調(diào)用的函數(shù)名Incl Cpu Time函數(shù)占用的CPU 時間，包含調(diào)用其它函數(shù)的

11、CPU 時間Excl Cpu Time函數(shù)占用的CPU 時間，但不包含調(diào)用其它函數(shù)所占用的CPU 時間Incl Real Time函數(shù)運行的真實時間（以毫秒為），內(nèi)含調(diào)用其它函數(shù)所占用的真實時間Excl Real Time函數(shù)運行的真實時間（以毫秒為），不包含調(diào)用其它函數(shù)所占用的真實時間Calls+Recur Calls/Total函數(shù)被調(diào)用次數(shù)以及遞歸調(diào)用占總調(diào)用次數(shù)的百分比Cpu Time/Call函數(shù)調(diào)用CPU 時間與調(diào)用次數(shù)的比（該函數(shù)平均執(zhí)行時間）Real Time/Call同 CPU Time/Call 類似，只不過統(tǒng)計換成了真實時間或者以網(wǎng)絡為例，世界各地存在大型服務器倉庫，它們

12、被稱為數(shù)據(jù)中心，它們的作用是火緩沖被頻繁的內(nèi)容。這樣，你的計算機就不必每次都遠在 12000 英里之外的服務器。你在埃及的朋友可能在這個服務器上發(fā)布了一張，當然，如果你在埃及，這樣的緩沖服務器可能就沒意義，但是你已經(jīng)明白其中的道理。以代碼為例，最常見的緩存優(yōu)化通常涉及多次計算，但是如果始終相同的數(shù)據(jù)，例如，在循環(huán)計算中，你計算一個4x4 數(shù)列的導數(shù)，結(jié)算始終是相同的，每次重新計算循環(huán)迭代，實際是在浪費計算機資源。相反，在循環(huán)流程的外部導數(shù)的結(jié)果，并讓你的循環(huán)語句緩存結(jié)果，可以極大地效率。我之所以喜愛緩存和批處理，是因為他們能夠改善所有你能夠想到的性能問題，包括在本課提到，這是兩個非常有效的技術

13、。如果你想成為一名性能，你最好能夠熟練掌握這兩項強大的技術。使用批處理與緩存解決問題目標：在這個例子中，您將使用 Traceview 工具來查找并確定哪些是阻礙應用程序性能問題的代碼。然后，您將應用批處理或緩存來優(yōu)化性能不佳的代碼。1）觀察：首先，讓看看能夠用怎樣一個給定的應用功能來觀察一個問題。在設備上啟動compute 應用，然后啟動 Batching/CachingActivity。你會看到一個正在舞蹈的海盜動畫。上面有一個寫著“計算一些 Fibonacci 數(shù)”的按鈕，點擊它。你觀察到了什么，為什么會這樣？不難看出，的海盜朋友停止了搖擺?？隙ㄊ前聪掳粹o之后才導致了這個現(xiàn)象，現(xiàn)在，你已經(jīng)

14、觀察到了一個問題，來分析下。2）Profile：您剛剛了解了 Traceview，讓跡。把它運用起來。點擊按鈕，觀察程序的運行軌3）分析：根據(jù)運行軌跡分析，找出導致問題的方法是誰？在這里，要找的，實際上是 computeFibonacci 方法。讓看看，我是怎么樣找到它的。在下面的活動上運行 TraceView，當我按下這個 computeFibonacci 函數(shù)，將會剖析這個函數(shù)。這是 Traceview 的輸出，這是運行 Traceview 時看到的輸出，你應該看到一些類似的內(nèi)容，請注意這個大的粉域，這很糟，基本上，這表示有些函數(shù)在的主線程域。上占用大量的 CPU 時間。如果你按照獨占CP

15、U 時間排序或者將鼠標懸停在這個粉你會發(fā)現(xiàn)computeFibonacci 方法，它來自于需要解決這個問題。的緩存活動，是占用 CPU 資源最多的函數(shù)，解決有哪些好方法可以解決這個問題呢？請選擇所有正確不應該為主線程增加任何不必要的額外的工作，應該讓線程僅處理用戶輸入和屏幕繪制.看看是否能夠優(yōu)化函數(shù)，使用共享技術提高運行速度和減少資源開銷，讓緩存這些中間值。讓來看看代碼，看看發(fā)生了什么。在主線程收到一個 onClick（）事件計算斐波?？纯捶椒ǎ喝绻闶煜に惴ɡ碚?，你可以看到，數(shù)遞歸執(zhí)行，從代碼運行的角度來看，它是非常耗時的。解決這個問題的方法之一是通過計算和緩存中間結(jié)果。主線程阻塞為了確保應

16、用程序的高性能，每項功能都應該盡可能高效地運行。但是這些功能的執(zhí)行時間以及它們在代碼中所處的位置也很重要，當你首次啟動一個 Android 應用程序時，行線程就已經(jīng)創(chuàng)建了，主線程非常重要，因為它負責運行你的代碼，并在合適的視圖位置發(fā)送事件和執(zhí)行繪圖功能。這些前面已經(jīng)講過，基本上來說，主線程是應用程序所在的線程，有時候，主線程也稱為 UI 線程。例如，如果你觸摸屏幕上的按鈕，UI 線程將會發(fā)送一個觸摸事件給視圖，視圖將按鈕狀態(tài)設定為已按下設定，然后向事件隊列發(fā)送一個有效請求，然后 UI 線程處理此請求，并通知按鈕將其本身繪制為已按下狀態(tài)。如果你有任何觸摸事件的處理代碼塊，將會執(zhí)行，這些觸摸處理所

17、用的時間越長，線程的執(zhí)行時間就會越長，在繪圖功能執(zhí)行完之前，視圖將會更新顯示狀態(tài)，讓用戶能夠看到其狀態(tài)，這里需要記住的是，輸入處理代碼與渲染和更新代碼，共享這個線程的處理周期時間。這意味著，在觸摸事件處理，網(wǎng)絡或數(shù)據(jù)庫查詢等計算周期時間，UI 不會更新繪圖，在簡單的情況下，渲染周期可能會延誤 16 毫秒左右，而讓用戶感到延遲。但是，如果你暫停 UI 線程渲染超過 5 秒，用戶將會看到“應用程序未響應”框，并詢問用戶是否會想要關閉你的應用程序，這樣可能導致用戶停止使用。那你如何解決這個問題，你要找出不需要在主線執(zhí)行的功能，也就是說，不需要等它們完成之后，才能執(zhí)行繪圖。你應該將這個功能轉(zhuǎn)移到一個單

18、獨的獨立線程，這個線程不會UI 線程。例如，如果你按一下提交按鈕，以完成一個訂單，然后編寫和發(fā)送確認郵件，這可以在單獨的線有系列很好用的 API，能夠簡化這些工作。完成。Android使用 Traceview 工具明確問題所在我將要演示如何操作traceview，這個程序，可以識別所有安裝程序的幀速率，操作方法如下，安裝后，點擊 show on click handler 按鍵，各位會看到很眼跳舞海盜，然后點選 display an image 按鈕，現(xiàn)在大家會看到海盜不動了，但如果再這樣做，海盜又繼續(xù)跳舞 了，同時 Android 圖示也會出現(xiàn)在海盜下方。跟之前一樣，只要點擊這個按鈕，海盜就

19、不動 了，下面要怎樣操作，想必大家都知道了，就是要利用這些工具，現(xiàn)在演示怎樣操作 traceview。在這里，查看下剛才追蹤的數(shù)據(jù)，結(jié)果出現(xiàn)冗長的數(shù)據(jù)，這是什么意思呢？檢查數(shù)據(jù)，找出 哪兩個方法調(diào)用得最頻繁。辨別哪些程序，占用了大量的 CPU 資源？來看一下 Traceview 輸出，請注意這個大的活動區(qū)域，來探討一些觀察到的信息，你會發(fā)現(xiàn)，最上方的這個函數(shù)，在排序時占用的資源最多。還有其他一些函數(shù)，例如這個 nativePullOnce,但是它們是系統(tǒng)調(diào)用，無法控制它們。如果更進一步，就會注意到這個 nativeSetPixel 和這個 nativeGetPixel。讓看看它們來自于哪里，展

20、開它，看到了！在繁忙的 UI 線程活動的某個位置，setPixel 被調(diào)用，它來自于的應用代碼，getPixel也是如此，似乎來自忙的 UI 線程活動，讓忙的 UI 線程活動。現(xiàn)在，來更深入地探討。發(fā)現(xiàn) setPixel 和 getPixel，來自因此 getPixel 和 setPixel 并不是編寫的代碼，在這個代碼中哪個父級方法調(diào)用getPixel 和 setPixel？父級方法實際上是 saAndDisplayImage，讓來看 Traceview，來了解其含義?；氐揭晥D，如果展開可收縮菜單，可以找到父級調(diào)用堆棧，看到 setPixel 實際上被 s看看如何優(yōu)化。aAndDislayI

21、mage 方法調(diào)用。它在繁忙的 UI 線程活動之內(nèi)，讓異步任務對圖像進行編碼處理是一個相當大的任務，這也是不能輕易地優(yōu)化掉的任務。特別是那些涉及網(wǎng)絡接入，冗長的數(shù)據(jù)庫調(diào)用和圖像處理，那么一般規(guī)則是將它們從主線程移除。讓來使用異步任務：容器性能講過，一些類型的硬件可能會造成程序執(zhí)行速度較慢，還記得那個浮點分支問前面題嗎？對于今天的硬件來說，這已經(jīng)不是問題。但是有一些問題還是需要引起注意，比如說，你所使用的編程語言的基本元素的效率，以排序等基本算法為例，現(xiàn)在，有很多的排序算法，對于不同的情況，它們各有優(yōu)劣，例如，當元素數(shù)量少于一千或在大型已排序列表中尋找一個對象時，快速排序法通常比起冒泡排序法更快

22、。一般情況下，最好的方法是二分查找算法，但是，當在未排數(shù)組中尋找對象時情況變得完全不同，不同于比較每一個對象以查找你想要的值。你可以使用一個哈希函數(shù)來立即找到它，這是現(xiàn)代計算機科學和數(shù)據(jù)結(jié)構方面的基本知識。幸運的是，現(xiàn)代編程語言像 Java 等，為你提供了這些容器和算法，因此你不再需要自己反復地編寫 Murmur3 哈希函數(shù)和快速排序算法。但是你需要知道另外一些事情，在我多年的編程生涯中，一個經(jīng)常會影響項目性能，是由于這些語言提供的容器對象的性能所引起的。這聽起來不可思議！Java 提供一個矢量類的實現(xiàn)，你可以任意 push、pop，添加和取消對象，為了獲得這種靈活性，它在鏈式列表結(jié)構，這種結(jié)

23、構具有一系列獨特的性能特性，在你操作這種列表時，它的速度超級快，但是，當你在其他位置進行或刪除時，它會消耗大量的時間。我將會如何實際使用它們，Jame的是，底層系統(tǒng)提供的這些容器并不會考慮，你的程序therland了一系列的基準測試，他認為，需要注意性能與功能之間的一些差異。例如，他發(fā)現(xiàn) Hashtable 比 HashMap 大約快 22%，具體視你如何使用這些容器而有所不同，需要思考的是，你是否曾經(jīng)分析過你在代碼中使用的容器類。你是否堅信，你在代碼中使用的容器的實際運行速度絕對是最快的。一個好消息是，你可以使用 Android 中的 MPI 來剖析這些容器的性能。數(shù)據(jù)結(jié)構在這個例子中，你將會看到，創(chuàng)建應用時，容器中不恰當?shù)臄?shù)據(jù)結(jié)構所造成的性能問題，為此可以使用 Android SDK 中的工具，來識別不恰當數(shù)據(jù)結(jié)構帶來的性能問題。與修改應