背景#
APP 接入部網路貨運資訊交互平台，這裡記錄一下接入想法和過程。
實現#
iOS SDK 提供的方法，共有下面 6 個
- init
- start
- send
- pause
- restart
- stop
看起來很簡單，但是需要考慮 SDK 某個方法可能會失敗，而且可能會有同一個司機多個托運單、或者同一托運單分段多個司機運輸以及托運過程中換車、司機運輸中換手機等場景，想要持續記錄位置資訊，完成完整的一個單據鏈路就不那麼容易了。
而這些場景的處理，需要服務端的協助，但是服務端沒有和部網路貨運資訊平台直接交互的介面，無法直接從貨運資訊平台讀取狀態和資料，所以處理就顯得麻煩了。
我們的設想是，服務端兜底處理異常，所以，首先要讓服務端知道當前處理的單據和步驟，故而需要一個記錄介面，每次執行 SDK 的方法後，成功或失敗都同步給服務端。
為了避免出現其他手機或其他使用者或後臺手動關閉單子的情況，需要服務端提供另一個查詢是否有待結束運單的介面，同樣，這個介面在每次執行 SDK 的方法後，都要調用，用於獲取是否有待關閉的運單。
而還有一種情況，即使用者開始運單後，APP 被殺掉了再次打開時，這時候應該執行 SDK 的什麼方法？或者司機中途換了另一個手機登陸了帳號，這時候原手機上再次打開應該執行什麼方法？新手機上應該執行什麼方法？所以需要一個查詢介面，用於這種情況下查詢待執行的步驟。
但是問題來了，同一個司機，由於順路或者車型大的原因，可能同時有多個運單，而每個運單的間隔發送時間不一定相同？所以如何同時開啟多個 timer，不會混亂，且又能保證運單結束後，關閉對應的 timer？通過運單號和分單號作為 key，創建 timer 封裝到單獨的 Model 中，model 作為 value，存儲在字典中。每次要創建 timer 前，根據運單號和分單號查詢對應 timer 是否存在，存在則不重複創建；不存在則創建。當執行了 SDK 的 Stop 或 Pause 方法後，同樣的方法獲取到對應 timer，然後停止這個 timer。
但在實際中，遇到了 SDK 由於某種原因 Stop 失敗，實際上這個運單已經結束的情況；還遇到了 SDK 執行方法成功，但是保存狀態到服務端時失敗的情況。這些異常情況，單獨根據同步記錄表是沒有辦法處理的，只能從業務表中獲取對應狀態後，再返回對應要執行的方法。