希望有人能夠幫助我，或者至少能夠啓發我一點。在發佈Mango Beta工具之後，我對新的WP7 Profiler發揮了很大作用，並且有一件事讓我困擾。WP7 ListBoxItem ContentPresenter測量時間
每一個只有一些更復雜的項目的列表框將永遠繪製。舉個例子 - 一個列表框的項目由Border-> Grid-> 6xTextBoxes（每個顯示單個符號）組成，每個列表框項目需要303ms。其中288毫秒用於ListBoxItem的ContentPresenter測量時間（不包括）。
我知道Measure是一種昂貴的操作，但這仍然超出了瘋狂。任何想法將不勝感激。
確保您的數據被完全裝入一個異步操作，只添加項目到你的列表框是在UI線程上運行
確保你在你的模板中使用電網的，而不是StackPanel的
下面的文章也非常有用：
我只能確認MeasureOverride是最耗時的操作。 （你不需要一個分析器來找出它。）我只能猜測它爲什麼需要這麼長時間。
首先，MeasureOverride通過ListBoxItem的可視化樹遞歸地傳遞。在這個調用鏈的末尾，可能會調用返回實際大小的本機代碼。
因此，保持簡單的項目結構是至關重要的。
您的結構似乎過於複雜。如果你看看TextBox模板，你會發現它的結構是Grid> Border> ContentPresenter。我無法判斷ContentPresenter的背後，因爲我不知道你的代碼，我只是想知道爲什麼你不使用TextBlock（在可能的情況下） - 它更有效率。
作爲一個實驗，我會嘗試實現MyListBoxItem.MeasureOverride並返回固定大小而不調用基礎實現。我不知道它是否有效，但它可能會帶來令人驚訝的結果。
當您實現自己的列表項時，您可能會調查的第二件事是調用MeasureOverride的頻率。 （或者只是查看分析器輸出。）如果調用數量太高，則佈局可能會佔用更多的循環。也許有一些衝突的尺寸要求需要幾個步驟來解決。
您提到40項。那不應該扮演任何角色。 ListBox構造大約3個ListBoxItem的屏幕，剩餘的項目根據需要構建（最經常重用）。如果通過增加項目編號來增加測量時間，則在數據實施中查找問題。
感謝您的回覆。這40個項目實際上在一個屏幕上（有一個包裝面板）。順便說一句，我正在使用TextBlocks，對於混淆抱歉。尺寸很好，並沒有被稱爲很多次，所以一定有其他的東西。我已嘗試手動設置所有可能的大小而不起作用。將玩更多的攫取，並可能嘗試實施MeasureOverride，看看我能否改善它。再次感謝您的建議。 – Miro
謝謝，但數據是本地計算的，並且不是問題，因爲它只需幾毫秒即可生成。我真的很想聽到關於度量問題的一些想法 – Miro
您是否遵循了我包含的鏈接中的建議？我通常遵循這些，並且在我提交的兩個應用程序中還沒有遇到重大問題。 –
在過去的幾個月中，我遇到了大多數的建議，並嘗試過但沒有成功。尺寸是固定的，沒有數據被下載，我有幾個項目（大約40個列表框項目）。仍然測量phaze需要的時間比它有意義。 – Miro