軌跡系列13——多軌跡展現在實際項目中的落地和優化

文章版權由做者李曉暉和博客園共有，若轉載請於明顯處標明出處：http://www.cnblogs.com/naaoveGIS/

1.背景

         在以前的」多車輛實時跡展現方案」(http://www.javashuo.com/article/p-hzmmgifx-kd.html)文章中，我講解了咱們對多軌跡實時監測展現方案在前段的一些實踐和對於後端架構的設計，可是在真實項目的落地過程當中，咱們基於此作了不少的優化，這裏作一個簡單的總結。

       這裏我將該項目大體作一個描述：公司某個項目中有一萬兩千輛車須要作實時監控，並且這些車24小時均會不間斷進行GPS上報。因此其中涉及到GPS的對接、海量數據存儲的設計方案、消息推送、前端展現、系列報警設計等。這其中的GPS對接、數據存儲涉及等問題我在軌跡系列文章中均有描述，感興趣的朋友能夠看看，本篇着重描述信息推送和前端展現的優化。

2.GPS推送機制的設計

       這裏的消息推送並非很複雜，因此咱們並無採用卡夫卡等成熟的消息機制架構，依然採用的是前篇中我進行了介紹的WebSocket方案。可是，有幾點咱們須要考慮：

       a.前端爲了播放效果，每次傳入的GPS中一個車輛必須擁有2個以上的GPS數據（若是隻有一個則是停留的）

       b.咱們有1萬輛以上的車輛，每次推送給前端的數據不該該是全部的，即作成廣播協議是不合理的。

       針對這兩個問題，咱們分別作了解決：

       a.採用redis進行GPS數據的實時存放，可是進行了存放規則設定，即redis中存放的軌跡只包含目前時間向前推移指定時間的軌跡量。好比，redis中永遠存放的是此前三分鐘的軌跡數據（時間長可設置）。這樣能夠累積必定量的軌跡後推送，以便實現播放效果，而且方便高效讀取。

       b.在消息推送中，咱們根據humanID來進行數據推送的選擇。不一樣人員要看到的車輛是不同的，因humanID不一樣而不一樣。

       在推送方案中咱們還進行了其餘優化：

       a.經過心跳檢查來進行socket鏈接保活。

       b.前端播放時效與後臺軌跡推送的同步。

3.多軌跡前端展現優化點總結

       a.根據車輛數目切換展現方式，車輛少時用車輛圖標，車輛多時用點。

       b.從新設計車輛圖標，以俯視圖進行車輛圖標設計，並經過後視鏡等細節來更好的表現車頭和車尾。

       c.每次GPS從新獲取後，地圖不進行縮放，保持觀察的連續性。而且經過車輛ID的關聯，保證前端播放軌跡的連續不閃爍。

       d.車輛車牌的顯示，而且只有在地圖縮放到必定級別後才顯示，以免圖標雜亂。

       e.經過計算播放點與最近GPS點的距離來展現該播放點的車速。

       f.提供車輛詳細信息展現的入口。

       g.根據車輛不一樣的狀態，好比超速、停留等用不一樣的車輛圖標來進行表示。

 4.項目真實效果展現

 　　多軌跡展現效果：

　　

　　單車輛歷史軌跡展現效果：

　　

 

　　　　　　　　　　　　　　　　　　　　　　　　-----歡迎轉載，但保留版權，請於明顯處標明出處：http://www.cnblogs.com/naaoveGIS/

                                                                      　　　　    若是您以爲本文確實幫助了您，能夠微信掃一掃，進行小額的打賞和鼓勵，謝謝 ^_^