我試圖加快我的應用程序啓動時間（目前約5秒由於慢速Guice綁定），並且當我運行traceview時，我看到相當大的變化（高達30％）從執行相同的代碼。爲什麼traceview會給出不一致的測量結果？
我會認爲這是垃圾收集的差異，但根據traceview在startGC中花費的時間是完全不重要的。
這是特別加重的，因爲當測量變得如此變化時，很難確定我的優化的效果。
爲什麼會發生這種情況？有什麼方法可以使測量更加一致嗎？
我想你是從代碼開始分析而不是手動開啓它？但無論如何，即使您從代碼的特定位置使用Debug.startMethodTracing和Debug.stopMethodTracing，您也會收到不同的測量結果。
您可以看到here Traceview禁用JIT，我相信其他一些優化，因此在分析代碼時執行比沒有執行時要慢。您的代碼性能也取決於整體系統負載。如果其他應用程序在後臺執行任何繁重的操作，您的代碼將執行更長時間。所以你肯定會得到一個稍微不同的結果，所以啓動時間不可能是一個常數。
通常，您的方法執行時間並不重要，但與其他方法相比，它消耗的CPU時間有多少。
聽起來像測量不是你的最終目標。你的最終目標是加快速度。
要做到這一點的方法是找出哪些活動佔了很大一部分時間，因此您可以找到一個更好的方法來做到這一點。 我說「發現」，而不是「測量」，我說「活動」，而不是「慣例」。
要做到這一點，只需要對程序的狀態進行採樣。 許多配置文件收集了大量的程序狀態樣本，但是它們都屬於同樣的邏輯 - 他們總結說，理論上所有你想要的只是測量，而你並不真正關心什麼。實際上，如果不是總結摘要，你可以詳細檢查一些樣本，它會告訴你更多關於該程序如何花費時間的信息。更重要的是，如果只有兩（2）個樣本，你可以看到程序追求某個目標，而且你可以顯着提高，你會看到顯着的加速。 這個過程可以重複多次，這就是你可以如何真的優化它。
有趣的，但除非我失去了一些東西，它並沒有幫助回答這個問題。 Traceview已經提供了一個完全確定性的方法調用計數和層次結構。 – 2012-07-16 16:23:04
@Jeff：1）不要指望時間測量的一致性。無法控制的因素太多，反正也沒有關係。 2）關於調用計數和層次結構，請檢查問題[* here *]（http://stackoverflow.com/a/1779343/23771）。它似乎在告訴你你需要知道的一切，但事實並非如此。 – 2012-07-16 16:39:29
如果您在啓動時正在執行任何與網絡相關的活動，那麼此工具可以幫助您瞭解正在發生的情況以及您可能如何優化連接和緩存。 http://developer.att.com/developer/legalAgreementPage.jsp?passedItemId=9700312
我在說測量CPU時間，這當然是traceview提供的唯一指標。我一定把我提到的五秒鐘啓動時間（用沒有啓動分析功能的秒錶來衡量）作爲介紹首先分析動機的介紹，一定讓你感到困惑。那麼，如何以合理的一致性衡量啓動消耗的CPU時間？是的，我正在使用'Debug.start/stopMethodTracing' – 2012-07-15 19:14:45
我認爲不可能實現比以前更多的一致性。如果你的初始化過程使用一些IO函數來讀取數據，它已經不會一致。另外我想你的代碼是在單獨的線程中運行的，所以如果它在單處理器系統上運行，分析結果將取決於系統線程調度器，因爲實際上你的代碼不會一直執行。我非常確定不可能從不同的發射獲得完全相同的曲線。 – 2012-07-15 19:55:16