MQL5 OnTick 與 OnTimer｜EA設計的選用方式

結論：判斷看「新K線」，時間類處理交給 OnTimer

先說結論。如果是以 H1、H4 這類較長週期進行交易判斷的 EA，只要在「新K線形成後的第一個報價」做判斷就足夠了。每來一個報價就重複同樣的計算，只是白白消耗 CPU，判斷結果並不會改變。另一方面，即使沒有報價進來也想執行的處理，就要用 OnTimer，例如週末輸出狀態、在固定時間整理委託單等。

不過，哪一種才正確，還是取決於策略本身。本文整理這兩種機制的差異，以及選購 EA 時可以自行確認的重點。

機制：報價驅動與時間驅動

OnTick（報價驅動）

每當執行 EA 的商品收到新價格（報價）時，就會呼叫 OnTick。行情劇烈的時段，一秒內可能被呼叫好幾次；行情停止的週末則一次都不會被呼叫。

這裡有一項必須知道的規格：上一次 OnTick 的處理尚未結束時，新到的報價不會被排入佇列，而是直接被略過。換句話說，單次處理很吃重的 EA，在行情急遽波動時會漏掉報價。

OnTimer（時間驅動）

OnTimer 會依照 EventSetTimer() 設定的間隔被呼叫。它與價格變動無關，因此市場休市期間也會被呼叫。一個 EA 只能有一個計時器，處理卡住時同樣會被略過。此外，也不保證會剛好在指定的間隔時間被呼叫。

低頻策略不浪費 CPU 的寫法

如果是以 H4 判斷的策略，一根K線持續的 4 小時內，不論 OnTick 被呼叫幾千次，用來判斷的已收盤K線數值都不會改變。因此我們基本上採用「只在K線切換時才執行重處理」的寫法：

datetime g_lastBar = 0;

void OnTick()
{
   datetime cur = iTime(_Symbol, PERIOD_H4, 0);
   if(cur == g_lastBar) return;   // 同一根K線期間什麼都不做
   g_lastBar = cur;
   // 在這裡使用已收盤K線（shift 1）進行判斷
}

指標的 handle 只在 OnInit 建立一次，不要在 OnTick 中每次重新建立，這點也很重要。若使用 OnTimer，請在 OnDeinit 中呼叫 EventKillTimer() 停止計時器。

在 VPS 上的多個圖表掛載 EA 時，這類差異會以 CPU 負載的形式表現出來。關於 VPS 的選擇思路，請參考 VPS資訊。

選購 EA 時可以自行確認的事項

即使看不到內部程式碼，下列幾點仍可在一定程度上確認：

• 說明文件與參數：是否有「僅在新K線時判斷」之類的設定
• VPS 的 CPU 使用率：移除某個 EA 後負載明顯下降的話，可能該 EA 每個報價都在執行重處理
• EA 日誌：是否每個報價都輸出相同內容
• 回測結果：以K線開盤價判斷的 EA，使用「僅開盤價」與「每個報價」的結果應該不會差太多。若差異很大，代表它也會對K線進行中的價格波動做出反應

EA 的安裝與設定基本方法，請參考 EA設定方法。

限制與注意事項

不利的一面也要先說清楚。

• 看不到K線進行中的風險：把判斷限定在新K線，就不會對K線進行中的急遽變動做出反應。停損必須設計成以附在委託單上的停損單來保護，否則可能承受意料之外的虧損。
• 新K線的延遲：新K線形成後，要等該K線的第一個報價抵達，處理才會啟動。在波動較小的商品或時段，判斷可能比K線開始的時間晚一些。
• OnTimer 在回測與實際運作之間容易有落差：回測中計時器是以虛擬時間被呼叫的，不一定與實際帳戶的間隔相同。
• 處理變輕，績效也不會因此改變：降低 CPU 負載並不會讓策略更容易獲利。策略本身的好壞是另一個問題。

像 ETHEREUM EA 這類 H4 週期、交易次數較少的策略，這種設計上的差異更不容易看出來。不過，從外部能確認的範圍終究有限。我們能夠負責任斷言的，只有我們自己寫的程式碼。

總結

• OnTick 在收到價格時被呼叫，OnTimer 則每隔一段固定時間被呼叫
• 處理期間到達的事件不會排入佇列而是被略過，重處理會導致漏掉事件
• 低頻策略採用「只在新K線時判斷」的寫法，就不會浪費 CPU
• 想在沒有報價的時間也執行的處理，請使用 OnTimer
• K線進行中的風險要靠停損單防範，處理變輕並不會提升績效
• 其他實用技巧整理於 EA・MT5知識庫