我已經(jīng)通過緩慢的UI更新解決了一些問題，并且我想聽聽解釋為什么我的代碼修改實際上可以提高性能。我開發(fā)了WPF應(yīng)用程序MVVM體系結(jié)構(gòu)。我在視圖模型中有一個屬性：public DateTime MyDate { get { return _myDate; } set { _myDate= value; OnPropertyChanged() OnPropertyChanged(() => MyDateFormatted); } }MyDateFormatted看起來如下：public string MyDateFormatted { get { return _myDate.ToString("MMMM dd, yyyy"); } }MyDate的設(shè)置程序不會在UI線程上發(fā)生。MyDateFormatted的獲取方法發(fā)生在UI線程上，因為，正如我所讀到的那樣，WPF自動將對UI線程的屬性更改編組。確保在MVVM WPF應(yīng)用程序的UI線程上調(diào)用OnPropertyChanged（）確實，UI已更新，但是非常緩慢。一次，我手動附加了OnPropertyChanged（（）=> MyDateFormatted）; 到UI Dispacher，通過將其與調(diào)用：Application.Current.Dispatcher包圍在一起，UI可以立即按我想要的速度進行更新，并且性能得到了極大的改善。你能解釋為什么嗎？謝謝！
1 回答
喵喵時光機
TA貢獻1846條經(jīng)驗 獲得超7個贊
一個可能的原因是Dispatcher.Invoke限制（放慢了）update的算法MyDate，并允許UI線程跟上這些更新。假設(shè)您有以下代碼：
new Thread(() => {
while (true) {
this.MyDate = DateTime.UtcNow;
}
})
{
IsBackground = true
}.Start();
在極端情況下，值會不斷更新而沒有任何延遲。發(fā)生的是調(diào)用OnPropertyChangedon時MyDate，WPF將通過Dispatcher.BeginInvoke（注釋Begin）在UI線程上對綁定更新進行排隊。
在那種極端情況下，它將很快淹沒UI線程隊列，并且UI線程將無法跟上要處理的未決操作的數(shù)量。那是因為它是異步的，因此Dispatcher.BeginInvoke不會減慢該while (true)線程的速度。
現(xiàn)在，假設(shè)您包裹this.MyDate = DateTime.UtcNow在里面Dispatcher.Invoke。Invoke是同步的，直到UI線程實際執(zhí)行此操作后才返回。現(xiàn)在，循環(huán)受到了限制，并且運行速度要慢得多，因為更新UI現(xiàn)在已成為循環(huán)的一部分，并且UI操作隊列不會無限增長。
在現(xiàn)實生活中，值得限制UI更新自己。因此，如果您有一個緊密的循環(huán)-不要在每次迭代中更新UI綁定的屬性，而是在每個X（100，1000）迭代中更新，這樣就不會給UI線程造成太大負擔(dān)（反正太快了，更新就沒用了，因為人眼無論如何都無法捕獲您的1ms更新）。如果您認為“修復(fù)”沒問題（因為它無需太多理由就減慢了算法的執(zhí)行速度）（執(zhí)行UI更新），那么“修復(fù)”可能就可以了。
- 1 回答
- 0 關(guān)注
- 388 瀏覽
添加回答
舉報
0/150
提交
取消