TBox與APP如何分工

設想以下場景，汽車時速在80公裡以下，你可以打開車窗吹風。而如果車速在120公裡以上時，你還會打開車窗吹風嗎？反正我不會，因為我在高速上試過，噪音特别大，而且也不安全。

是以，可以定義一個場景，當車速在120公裡以上時（這個可以再考慮，甚至80公裡以下也可以包括進去），如果車窗還是打開的，需要提醒使用者關閉車窗。

目前的實作步驟是這樣的，如果車窗打開，TBox會向APP發送車窗打開的信号，APP會向TBox請求車輛速度資料，如果速度大于等于120公裡，就會彈出“車速高速120公裡，請勿打開車窗”的提醒。否則沒有提醒。

仔細斟酌上面的流程，我們會發現這個流程的設計有缺陷。因為這個流程隻會在車速大于120公裡打開車窗時有效。而如果在車速80公裡以下時打開車窗，當車速提高到120公裡時，雖然車窗還是打開的，但沒有提醒。

是問題嗎？是問題，也可以解決。最簡單明了的辦法就是當車窗打開時，APP定時的向TBox請求車輛速度資料進行判斷。這個方法技術上可行，但是，實際上不可行。因為我們要考慮一個很重要的情況，那就是APP是跑在手機上的，而手機電池總是那麼不給力。如果使用者隻是在80公裡以下開車，那麼APP的這些請求就是做了無用功，而且因為要不斷的動用與TBox連接配接的無線子產品進行通信，會造成手機電池耗電過快。

是以，是以，技術上可行，實際上不可行。因為你不能讓使用者的手機耗電過快。那怎麼辦？要徹底的解決問題，就要重新定義TBox與APP的功能。

原來的定義是：TBox負責從Can總線上取資料，然後傳給手機APP，手機APP對各個業務場景進行邏輯判斷，并給使用者提醒。

TBox就是個資料通路，它不負責邏輯判斷。它不負責邏輯判斷，那麼這個判斷就會交給APP，而根據上面場景的描述，我們發現如果APP中進行邏輯判斷，就會造成許多場景實作困難。

那麼重新定義後的功能是什麼樣的？

TBox取得資料，并進行邏輯判斷，判斷結果通知APP。這樣APP變成一個顯示終端，盡量減少邏輯處理，這樣可以減少電量消耗。當然，TBox耗電多一點是沒有問題的，因為他連接配接的是汽車電源。

再分析下上面的場景，如果車窗打開，TBox會記錄這個狀态，并且在狀态清單中根據Can資料上傳的車輛速度（Can資料上傳的頻率是100ms），來決定是否産生提醒資訊，如果有提醒資訊就通知APP彈出提醒框。

這下，場景看起來就合理了，因為TBox與Can之間的資料交換是自動的，頻繁的，是以不需要像APP那樣要加個定時器進行定期查詢了。

最後，再對TBox進行下功能定義，TBox不僅僅是從Can取資料，并轉發資料的通路，它應該還有運算功能，根據設定的場景條件進行邏輯判斷，并得出正确結果，通知其它子產品。

我這裡多說一句，每個博文下來，有人圍觀，沒有人出聲。

麻煩大家告訴下，你們在哪裡看到，然後來圍觀的？