我一直在處理這個問題數週,並且不確定它是我的代碼的錯,僞造的appPaused事件觸發不夠快,或者Trigger.io的文檔沒有幾乎可以清楚地知道iOS給我們執行清理代碼的時間。appPaused事件適合我嗎?我使用iOS上的清理代碼獲得了一些奇怪的行爲
根據有關appPaused事件的文檔:
- 的iOS:時間短量給出了執行,通常最好的假設,回調和定時器可以不火,直到應用程序被恢復。
我的應用程序處理websockets,理想情況下,我可以在用戶最小化我的應用程序或手機被鎖定時向我的服務器發送關閉事件。目前,我的所有清理代碼都能在Android上完美運行,但在iOS上,我的清理代碼在應用程序恢復之前不會運行。奇怪的部分是有時(可能是20次中的1次)在appPaused事件觸發後,iOS清理正確運行。
爲了驗證這一點,我已經做了兩兩件事:
我做運行後appPaused觸發事件是一個消息對我的WebSocket服務器說:「應用程序已暫停」的第一件事。 95%的時間,這個消息實際上並沒有發送,直到應用程序恢復,但其他5%的時間我的websocket服務器在我暫停應用程序後立即收到它。
然後我說得那麼首先要運行後appPaused觸發事件是存儲Date.now線()的一個全局變量。然後,當應用程序恢復時,然後將Date.now()存儲在另一個全局變量中,並找出它們之間的差異。它很有趣,因爲在調用appPaused事件之後,正確地觸發了Date.now()行的時間大約有50%,但Date.now()調用的另一半時間僅爲毫秒,證明了這一點清理代碼在應用程序恢復之前不會運行。
所以,我真的能只希望有時有appPaused進行燒製,即使存儲Date.now()在一個變量後有足夠的時間?這是其他人在iOS上運行Trigger.io應用程序時遇到的情況嗎?讓我知道是否有人可以使用更多信息。