摘要
效能追蹤建議
沒有遠見和規劃，這樣解決效能問題是痛苦的。產生問題的原因一次又一次從指尖溜走，不僅浪費時間並且讓你備感受挫。但是，如果按照正確的步驟，就可以把令人沮喪的效能追蹤轉變為有趣的偵探故事。每一條資訊都讓你更接近問題的根源。人不可能總是可信的，證據將是你唯一的朋友。當你開始研究問題的時候，會遇到不尋常的波折，追蹤之初發現的資訊最後可能會幫你解決問題。最棒的部分就是，當你最終逮住「壞小子」並修復問題時，會感覺到腎上腺素的刺激和成就感。
如果你從來沒有調查過效能問題，那麼第一步會是決定性的。不過，聽從下面幾個明顯或隱晦的建議，可以節約時間，並按照自己的方式來找出效能問題的原因。本章目標是提供一系列建議和指導來幫助讀者追蹤效能問題。在研究系統或應用程式出現的問題時，這些建議告訴你怎樣避開一些常見的陷阱。這些建議，大多數都是從浪費的時間和令人沮喪的死胡同中辛苦得到的教訓，它們有助於快速並有效地解決你的效能問題。
避免重複他人的工作。
避免重複自己的工作。
避免因收集的誤導資訊而導致的虛假線索。
為你的研究建立有用的參考文件。
儘管所有的效能調查都是有瑕疵的（「如果一開始就能想到」是你的口頭禪），但這些建議將會幫助你避免效能研究中的一些常見錯誤。
1.1 常用建議
1.1.1 記大量的筆記（記錄所有的事情）
在調查效能問題時，你可以做的最重要的事情大概就是記錄下看到的每乙個輸出、執行的每一條命令，以及研究的每乙個資訊。結構清晰的記錄能讓你只檢視記錄就可以檢驗關於效能問題原因的猜想，而不是重新執行測試。這能節約大量時間。寫下來並且建立效能記錄。
在效能調查之初，我通常會為其建立乙個目錄，在gnu emacs中開啟乙個新的「notes」檔案，開始記錄系統的資訊。之後，將效能結果儲存到這個目錄，並將有意思的和相關的資訊儲存到notes檔案。建議將下面的內容新增到你的效能調查檔案和目錄中：
記錄硬/軟體的配置情況—記錄下的資訊包括硬體配置（主存容量、cpu型別、網路和磁碟子系統）和軟體環境（os和軟體的版本、相關配置檔案）。這些資訊看上去很容易在之後重現，但是在追蹤問題時，你可能會大幅度地修改系統配置。認真細緻的筆記有助於在特定的測試過程中弄清楚系統配置。
示例：每次測試時，儲存cat /proc/pci、dmesg和uname -a的輸出。
儲存並組織效能結果—執行很長時間後還能評估效能結果是很有價值的。記錄系統配置的同時，也記錄測試結果。這使你得以比較不同的配置是如何影響效能結果的。如果需要，可以重新執行測試，但是測試一種配置是耗費時間的過程。只需讓筆記保持條理清晰，避免重複工作則效率更高。
寫下命令列呼叫—在執行效能工具時，常常需要用困難複雜的命令列來準確定位到你感興趣的系統區域進行測量。如果想重新測試，或在不同的應用程式上執行相同的測試，那麼，複製這些命令列不僅令人厭煩，並且在初次嘗試時，不容易做對。更好的辦法是準確記錄下你鍵入的資訊。這樣在之後的測試中就能夠完全重現命令列，而在回顧之前測試結果時，也可以看到你測量的內容。linux命令script（詳見第8章）或者從終端「剪下貼上」都是完成這項工作的好方法。
記錄研究資訊和url—調查效能問題時，將在網際網路上發現的相關資訊記錄下來是很重要的，不論發現的途徑是電子郵件，還是人際交往。如果你找到乙個看上去相關的**，就把它剪下貼上到你的筆記中。（**是會消失的。）當然，還要記錄下url，因為你可能在之後還要檢視這個網頁，或者網頁所指資訊對後面的調查會變得重要起來。
在收集和記錄所有這些資訊時，你可能會疑惑：這樣做值得嗎？有些資訊眼下顯得毫無作用或有誤導性，但它在將來可能是有用的。（好的效能調查就像一部優秀的偵探劇：儘管開始的時候所有的線索都令人迷惑，但最終都會真相大白。）在調查問題時，請牢記以下幾點：
結果的含義可能是不明確的—效能工具給你的資訊並不總是清晰明了的。有的時候，你需要更多的資訊才能理解某個結果的含義。之後，你可以回過頭以新的視角重新審視那些看似無用的測試結果。實際上，舊資訊可能會駁斥或者證明關於效能問題本質的某個特定理論。
所有的資訊都是有用的（這也就是你要記錄的原因）—記錄已執行的測試資訊以及系統配置資訊的原因不見得會立即明晰。這一點在你試圖向開發人員或管理人員解釋系統效能不佳的原因時是非常有用的。通過記錄和整理調查過程中你所見的一切，你就有證據支援特定理論，同時也具備大量的測試結果來證明或駁斥其他理論。
定期回顧你的筆記可以得到新的想法—當你為效能問題積攢了大量的資訊時，那就定期回顧它們。重新審視會讓你關注結果，而不是測試。當許多測試結果放在一起被同時檢視時，問題的原因也許就會自動浮現。回顧你收集的資料，就可以在不實際執行任何測試的情況下進行理論檢驗。
在調查問題時，重做一些工作雖然是不可避免的，但是，在重做工作上花費的時間越少，你的效率就越高。如果你寫了大量的筆記，並有辦法在發現資訊時記錄它們，那麼你就可以依賴已經做過的工作，而避免重複執行測試以及重複研究。保持筆記的可靠性和一致性，從而節省時間減少挫折。
例如，在調查效能問題後，最終確定為硬體原因（主存慢、cpu慢等），你可能會想通過公升級慢速硬體，並重新執行測試來檢驗這個想法。通常要花一點時間才能獲得新硬體，而在你可以重新執行測試之前可能已經過了很久。當最終可以開始的時候，你想要在新老硬體上執行同樣的測試。如果你已經儲存了之前的測試呼叫和測試結果，那麼，你馬上就知道要怎樣為新硬體進行測試設定，同時也可以比較新的結果與儲存的舊結果。
1.1.2 自動執行重複任務
當開始調整系統改進效能時，鍵入複雜命令列很容易出現錯誤，而無意中使用的不正確引數和配置則會產生誤導性的效能資訊。因此，自動執行效能工具呼叫和應用程式測試是乙個好辦法：
效能工具呼叫—有些linux效能工具的命令列相當複雜，給自己省點力，把它們儲存到乙個shell指令碼中，或是將所有命令都放到可以進行剪下貼上的參考檔案中。這可以讓你少受些挫折，並且讓你多少有些信心：用來呼叫工具的命令列是正確的。
應用程式測試—大部分應用程式有著複雜的配置，要麼通過命令列，要麼通過配置檔案。你會經常重新執行要多次測試的應用程式，若將呼叫儲存為指令碼，就能少走彎路。雖然剛開始的時候，鍵入30個字元的命令看上去很容易，但這樣的操作重複10次後，你就會嚮往自動執行了。
盡可能多地自動執行，就能減少錯誤。使用指令碼自動執行，可以節省時間，並有助於避免因不當工具和測試呼叫造成的誤導性資訊。
舉個例子，你想在特定工作負載下或某段時間內監控系統，但是在測試結束時，你可能不在現場。這種情況下，指令碼就很好用了，在測試完成時，可以自動收集、命名、儲存全部生成的效能資料，並將它們自動放到「results」目錄中。有了這些基礎之後，你就能按照不同的優化和調整重新執行測試，並且不用擔心資料是否已經儲存好。你反而可以集中精力找出問題的原因，而不是去管理測試結果。
1.1.3 盡可能選擇低開銷工具
一般情況下，觀察系統會修改系統的行為。（對物理愛好者來說，這就是海森堡（heisenberg）不確定性原理。）
具體而言，在使用效能工具時，它們會改變系統的行為方式。調查問題的時候，你想要看看應用程式是如何執行的，同時還必須處理效能工具引發的錯誤。這是不可避免的弊端，但是你要知道它的存在，並努力將其最小化。有些效能工具能夠給出高度精確的系統資訊，但其檢索資訊的開銷也很高。高開銷工具對系統行為帶來的變化大於低開銷工具。如果你只需要了解系統的粗略資訊，那麼使用低開銷的工具是更好的選擇，即使它們不夠準確。
例如，對於正在使用的應用程式，工具ps能給出其主存數量和型別的相當不錯但粗糙的概況。那些準確性更高，但是影響較大的工具，如memprof或valgrind，雖然也能提供這些資訊，但是它們消耗的主存和cpu資源比只使用原始應用程式要大，因此會改變系統行為。
1.1.4 使用多個工具來搞清楚問題
雖然在找出效能問題原因的時候，如果只需要用乙個工具那將是非常方便的，但這種情況相當少見。實際上，你使用的每一種工具都會為問題的原因提供線索，因此，你必須同時使用多個工具來真正搞清楚發生了什麼。比如，一種效能工具會告訴你系統存在大量的磁碟i/o，而另一種工具則告訴你系統使用了大量的交換。如果只以第乙個工具的結論制定解決方案，你可能會簡單地選擇更快的磁碟驅動器（然後發現效能問題僅僅改善了一點點）。而將兩種工具的結果放在一起，你就會判斷出：大量的磁碟i/o是由大量使用的交換造成的。在這種情況下，你可能會買更多的主存以減少交換（這樣就不會再有大量的磁碟i/o）。
比起單一地使用任何一種工具，同時使用多個效能工具通常能讓你對效能問題有更清晰的了解。
寓言：盲人摸象
三個盲人在一頭大象旁邊，想要搞清楚它長什麼樣子。第乙個人拉住了尾巴，說道：「大象就像一根繩子。」第二個人摸到了象腿，說道：「大象像一棵樹。」第三個人摸到了大象一側的身體，說道：「大象像一堵厚實的牆。」
顯然，沒有乙個人得出了正確的答案。如果他們將各自的印象進行共享和組合，那麼，他們就可能發現大象真正的模樣。別做摸象的盲人。同時使用多種效能工具找出問題的原因。
1.1.5 相信你的工具
效能追蹤的過程中，最令人興奮又令人沮喪的時刻之一，就是工具顯示了乙個「不可能」的結果。某些「不會」發生的事情卻明明白白地發生了。第一反應會認為工具壞了。不要被直覺愚弄了，工具是公正的。雖然它們可能會不正確，但這更有可能是因為應用程式做了不該做的事情。要使用工具來調查問題。
舉個例子，gnome計算器使用超過2000個系統呼叫只為了實現載入和退出。如果沒有效能工具來證明這個事實，那麼，僅僅為了啟動和停止應用程式就需要如此之多的系統呼叫看上去是沒有必要的。但是效能工具能夠顯示其發生的位置和原因。
1.1.6 利用其他人的經驗（慎重）
在調查任何乙個效能問題時，你可能會發現問題令人不知所措。不要獨自面對它。問問開發者是否見過同樣的問題。試著找到其他解決過你所遇問題的人。在網際網路上搜尋類似的問題，並希望找到解決方案。給使用者和開發人員發電子郵件。
比如，你通常可以按照在google上搜尋類似問題得到的指導來解決效能問題。很多時候，在調查乙個linux問題時，你會發現之前已經有人遇到過了（即使是幾年前），而且還在公共郵件列表中報告了解決方法。使用google是很容易的，它可以為你節省幾天的工作量。
優化建議 儲存效能優化。
在 應用中，海量的資料讀寫對磁碟訪問造成巨大壓力，雖然可以通過cache解決一部分資料讀壓力，但是很多時候，磁碟仍然是系統最嚴重的瓶頸。而且磁碟中儲存的資料是 最重要的資產，磁碟的可用性和容錯性也至關重要。機械硬碟是目前最常用的一種硬碟，通過馬達驅動磁頭臂，帶動磁頭到指定的磁碟位置訪問資料，由於每次...
React Native 效能優化建議
react native 雖然一直標榜媲美native的體驗，但實際使用下來，其渲染性還是非常低效，基於scrollview和listview兩大容器，在渲染上，相當於web端的table布局，需要等整個大table渲染完成才顯示頁面，也就是說，當容器內有大量的子元素，其白屏時間會非常長。如何讓re...
Android效能優化建議
android效能優化主要從卡頓 記憶體洩漏和崩潰 質量和邏輯 安裝包過大四方面入手。在使用時避免出現卡頓，響應速度快，減少使用者等待的時間，滿足使用者期望 同時減低 crash 率和 anr 率，不要在使用者使用過程中崩潰和無響應 節省流量和耗電，減少使用者使用成本，避免使用時導致手機發燙 安裝包...