2013-01-14 57 views
5

我想知道有關Timer成分,什麼,如果有的話,因爲它的使用或其使用的多個實例的發生負面影響。在實踐中,一次應該在項目中使用多少個定時器應該有限制?使用計時器是否對應用程序有負面影響?

+0

downvotes。爲什麼?好問題,+1 –

+0

「這個問題基本上沒有顯示任何研究成果」。 – asawyer

+0

@asawyer你如何研究這個?嘗試它是不可靠的,不能一概而論。試試Google的主題。你會發現這個問題,而不是別的。 –

回答

11

好吧,一切都是相對的,但System.Windows.Forms.Timer是一個相當昂貴的對象。它的工作原理是創建一個隱藏的窗口,使底層winapi SetTimer()函數可以工作。該窗口不共享,每個計時器對象都有自己的窗口。窗口通常是更昂貴的操作系統對象之一。

所以一個非常困難的上限是你永遠不能有超過10,000個啓用的定時器。 Windows拒絕允許應用程序創建多個窗口。考慮到在一個桌面會話中運行的所有進程的所有窗口都需要共享一個共享堆,您應該停留在該限制以南。換句話說,創建大量窗口但保持低於10,000配額可能會對其他進程產生負面影響,但當堆耗盡時,可能會使其失敗。

我會說一個合理的上限徘徊在100這是一個大量的運動部件一般保持跟蹤的,假設所有這些計時器有不同的Tick事件處理程序。如果他們不那麼你應該以不同的方式解決這個問題,你只需要一個定時器來測量一個任意數量的間隔。您通過將到期時間存儲在SortedList中並僅爲第一個到期的計時器啓動計時器。當它打勾時,處理列表中有過期時間並重復的條目。當您添加或刪除到期時間時,停止定時器並在新的第一次到期時間內重新啓動它。

+0

+1我不知道10,000窗口的限制。 –

0

我假設你指的是的WinForms計時器對象,因此,

從文檔:

使用定時器,以提高在用戶定義的時間間隔的事件。這個 Windows計時器專爲線程用於執行處理的單線程環境而設計。它要求用戶代碼 有一個UI消息泵可用,並始終從相同的 線程運行,或將呼叫編組到另一個線程。

當您使用此 計時器時,使用Tick事件執行輪詢操作或在指定的時間段內顯示 啓動屏幕。每當啓用 屬性設置爲true,並且Interval屬性大於零 ,Tick事件在基於區間 屬性設置間隔提高。

所以讀通過行線,如果你開始收拾與計時器您的應用程序,你很快將要爲比賽渲染UI的時間間隔事件。

例如:你有一個使用定時器運行時鐘的時鐘應用。在每隔1秒的時間間隔內,您的應用程序將呈現手部。

在這個程序,你也讓用戶定義儘可能多的「報警」,因爲他們想要的。每一個創建一個新的計時器,將在設定的時間觸發。這些警報也可以是週期性的。也就是說,您允許用戶設置每隔x秒熄滅一次的「警報」。

現在假設用戶有一個長期運行的任務(Access數據庫,網絡資源,計算圓周率到1500個字符等)上週期性發生報警。現在假設用戶有10個長時間運行的任務需要按順序發生,並且需要以3 4和5秒的間隔發生。

這些計時器的行爲不會爲這種應用是足夠的,因爲下面會發生:

  • 時鐘將停止「警報」
  • 報警的執行過程中渲染可以在一個運行另一個,因此他們會排隊,但不應該發生,因爲UI線程正在同步處理所有消息。
  • 你最終會遇到一個沒有響應的用戶界面,它不會做你想做的事。

所以作爲最好的回答我可以在你的實際問題;對於定時器的數量不一定有限制,只需要考慮處理事件處理程序所需的時間與它們何時會觸發的時間之間的時間間隔。

如果您正在使用定時器來觸發將最終返回到UI線程並進行更改的單獨處理線程,那麼在您運行到該線程的上端之前沒有可行的限制目標機器的性能。也就是說,在某些時候,定時器的數量可能非常大,以至於您調用更多定時器事件並堵塞消息隊列,以致表單渲染受到影響。

因此,在短期:

負面影響:

  • 計時器在UI線程運行,因此它們都是阻塞
  • 他們可以有意外的行爲,如果你的間隔比的時間量較短它需要處理你的事件處理程序。

在實踐中,您應該需要限制定時器使用的唯一時間,就像用戶無法控制的任何組件一樣,如果它們開始影響用戶體驗。

我希望閱讀的時間比寫作時的感覺少得多。

+1

55毫秒的準確性鈔票嚴重過時。這可以追溯到Windows 98,在所有現代版本的Windows上,它是1/64秒或更好。 –

+0

爲什麼它們似乎只更新MSDN上的最小值?感謝您的澄清。 –

相關問題