體驗共享單車後對於Locman技術實現的幾點思考

體驗共享單車後對於Locman技術實現的幾點思考

原創 2017-02-28

關鍵點：

• 共享單車體驗
• 摩拜單車技術實現的思考
• ofo單車技術實現的思考
• Locman現階段技術實現分析
• 對於Locman後期實現的一點小思考

   自2015年Uber、Airbnb火熱起來以後給O2O創業帶了一個新的名詞 共享經濟（所謂的共享經濟模式就是經過一個平臺化的互聯網工具，把社會上具備相同屬性的閒散資源整合到一塊兒，以更加高效的方式知足市場的供給），在國內就出現了一大批如滴滴、易到用車、神州專車等基於共享模式號稱解決人們打車難的平臺出現，統治了打車這個行業，但在人們「最後一千米」出行方面仍是面臨了難題。世界就是這麼奇妙，哪裏有需求哪裏就會有解決方案，在2016年中相繼出現了摩拜單車、ofo單車、小藍單車等方便出行的「原始交通工具」，在一開始出來以後，做爲屌絲的我爲了避免給 29九、99 元的押金，並無想過會使用它們，然而一次出行讓我不得不使用上它，後來居然喜歡上了。下面就來講說我使用到的共享單車以及體驗感覺：

摩拜單車

   第一次使用上宣稱 觸手可騎 的摩拜單車是在2017年2月6日，因爲出行須要開通並使用了摩拜單車。

• 找車：摩拜App感受是比較輕量級的實現，僅包含了我地圖找車、開鎖、投訴等幾個主要功能模塊，找車直觀簡潔，在此次騎行選擇上我用了mobike lite，經過地圖上顯示的車位置，很快找到了。
• 用車： 掃碼->開鎖->go 短短几秒鐘就完成了開鎖功能，這體驗感受比較方便快捷，知足了人們習慣上使用的掃碼功能，也增長了藍牙開鎖功能。
• 騎行：摩拜單車第一代騎行很笨重，這有可能與其使用了實心胎、單臂前軸、大功率電機有關。相較於傳統自行車體驗非常很差，在第二代上摩拜單車作出了改進，使用了與傳統自行車基本同樣的設計，在重量上來講已經減輕不少，可是相較於ofo單車仍是比較笨重。
• 結束行程：摩拜在還車計費上作到了也比較智能， 只須要將鎖開關關閉便可完成還車計費，比較方便，不須要用戶手動操做App結束計費。

ofo單車

   第一次使用ofo單車是在2017年2月10日，騎行了摩拜單車後感受坐墊不能調節，騎行比較費力，當時也沒有在周邊找到摩拜單車，就開通了宣稱 隨時隨地有車騎(ANYTIME ANYWHERE) 騎行體驗比較好的ofo單車。

• 找車：下載ofo單車App後，說實話在找車方面相較於摩拜作的實在太不智能，從App上只能瞭解到周邊有多少輛車，並無一個很直觀的標註告知車的位置，給找車上帶了了必定的困難，可是ofo單車的數量也還多，也可以比較快速的找到車。
• 用車：與摩拜相似，在App上有一個掃碼開鎖的功能，可是還提供了一個用戶直接輸入車牌號開鎖的入口（這對於騎行者手機攝像頭不行或者二維碼損壞是一個比較好的解決策略）。因爲ofo使用的是機械鎖，因此在開鎖方面並無給我帶來所謂科技感，開鎖也不是很方便，須要用戶手動調節密碼，按下彈簧開關纔可以開鎖。
• 騎行：騎行體驗上感受與傳統自行車相差無幾，可是感受更加輕便，更沒必要提與摩拜笨重的車體，加上可充氣輪胎與可調節高度的坐墊使騎行更加溫馨，這也是我一直比較喜歡使用小黃車的緣由。
• 結束行程：在還車體驗上也是並無互聯網帶來的便捷感，須要用戶手動關閉鎖以後，打亂密碼，在還車以後還需手動在App上點擊結束行程才能中止計費。這裏也存在一個比較大的漏洞就是用戶能夠先結束行程或者記住該輛車的密碼長期使用，這也是ofo單車在小區單元樓下、地下車庫常常見到的緣由。

   以上就是我在使用了共享單車的一些直觀感覺，可是做爲一個Coder我比較關注的是摩拜單車整個用車流程的體驗，如下就是我參考網絡大牛，以及本身的一些感覺揣測的摩拜單車開鎖、關鎖的技術實現（由於與如今的工做遇到的問題以及解決辦法類似），若是有不合理的地方歡迎指正，聯繫個人郵箱。

摩拜單車的開鎖、關鎖技術實現思考

   做爲一個Coder，在現階段項目中遇到不少問題，發現與摩拜單車實現技術相似，可是未作到與摩拜單車同樣的體驗。在體驗了摩拜單車以及參考了各位網絡大神對於摩拜單車通訊的講解，也有一點本身的體會，現只對摩拜通訊記錄以下（關於硬件方面如何設計及工做此處省略1000......字）：

摩拜整個通訊中，有三個比較關鍵節點：

• [x] 自行車：最重要的設備
• [x] 手機終端：也能夠叫作咱們的一個用戶
• [x] 服務器：處理相關信息

   上述圖示，能夠看出，這三者之間存在兩兩相互通訊：單車與手機終端、手機終端與服務器、單車與服務器，再這三者之間相互通訊，技術最爲難實現也最重要的一環是單車與服務器之間的通訊。

• 單車與服務器通訊
     從網絡各位大神分享的技術博客綜合（由於硬件方面不是太懂，網上有大神對摩拜的車鎖進行了一個拆解），單車與服務器之間的通訊方式存在兩種方式：一種是使用SIM卡經過短信方式向單車發送開鎖/關鎖命令，這種是不須要TCP/IP創建一個長鏈接的，這種方式存在一個弊端就是發送短信的尋址須要一個比較長的時間，因此在摩拜單車的第一代部分單車開鎖就存在一個延遲較大、不穩定的一個狀況；第二種就是經過TCP/IP建立長鏈接，在這裏猜測使用長鏈接的方式主要是用在單車像服務器發送定位信息使用，畢竟摩拜是在其單車中提供了發電裝置，並且在我使用單車的過程當中關閉了手機終端的網絡，一樣是在結束行程以後查看個人行程軌跡。

• 單車與手機終端通訊
     在第一階段，摩拜採用的是手機掃描二維碼的方式讀取單車信息，這是一個手機主動讀取數據的過程，在此過程當中應該是不存在手機與單車的通訊機制的；摩拜後期新增了藍牙開鎖（也是摩拜比較推崇的一個開鎖方式），畢竟低功耗藍牙4.0在技術上已經很成熟，價格低廉，特別是耗電量低等諸多有點。本人猜想可能出於省電考慮，使用藍牙以後單車無需實時在線（全部命令能夠經過手機端連接服務器，接收並取得命令激活單車 這裏只是一種猜想,可是具備可行性），在藍牙開啓的狀況下摩拜App會主動嘗試鏈接單車藍牙，連接成功後經過藍牙指令讀取單車信息，而後經過App的網絡傳輸指定單車信息至服務器請求開鎖。在此過程後，摩拜能夠經過兩種方式向單車發送開鎖指令：第一種是與掃描二維碼方式同樣，經過服務器端直接發送開鎖指令到單車；另外一種是將開鎖指令下發給手機端，而後手機端經過藍牙發送指令開鎖並將單車從睡眠狀態激活（我以爲應該是採用的此種方式，否則摩拜也沒有必要再作一個藍牙開鎖）。

• 手機終端與服務器端通訊
     在這裏就比較簡單了，與咱們常見App服務器交換數據相似。在行程開始前App獲取單車信息直接上傳服務器請求開鎖，服務器下發開鎖指令（無論是二維碼方式下發到單車，仍是藍牙方式下發至App而後經過App發送開鎖指令），獲得單車鎖已開回執後開始計費；行程結束後，服務器收到了單車的關鎖信息，結束計費並向手機下發結束計費指令。

摩拜整個通訊流程

• 二維碼方式開鎖猜測

• 藍牙開鎖方式猜測
     關於摩拜單車藍牙開鎖，在這裏我的以爲有兩種方式：一種是與二維碼相同直接向服務器請求開鎖指令後，經過服務器發送指令到單車開鎖；另外一種是請求成功後指令直接發送到用戶手機端，此時在經過手機與單車的藍牙發送指令開鎖，我的比較傾向於第二種（否則摩拜在後階段也不會大力推行藍牙開鎖方式，有可能還存在更多好處，暫時未分析出來），此種方式能夠減小服務器與單車連接的不肯定性，增長開鎖成功概率，同時經過藍牙開啓成功後，單車的鎖已開狀態信息能夠又經過手機直接上傳至服務器並同時開啓計費。

ofo單車開鎖、關鎖技術實現

   相較於摩拜單車，ofo在實現開鎖、關鎖功能上，並無用到任何複雜的技術，雖然也存在單車、手機終端、服務器這三個關鍵節點。從下圖圖示能夠看出，ofo單車也存在單車與手機終端、手機終端與服務器之間通訊，只比摩拜少了一個單車與服務器端的通訊。在ofo中單車與手機終端通訊也能夠弱化，雖然存在掃碼開鎖，其實單車與手機終端是沒有任何實質通訊。

• 手機終端與服務器之間的通訊
     ofo在與服務通訊過程當中，其實主要也只有三個比較重要的請求：一個是向服務器請求開鎖密碼，請求成功後一段時間開始計費，與摩拜單車請求成功後單車回執鎖已開命令存在實質性差異；一個是請求關鎖而後結束行程；另外一個就是向服務器上傳已經記錄的GPS定位軌跡數據（這裏也是ofo在開始騎行前爲何須要開啓GPS定位功能）。這與其餘全部手機終端與服務器Request-Response並沒有差別，在技術上也很簡單。

現階段Locman技術實現分析

   先後已經開發過兩個版本的Locman軟件(存在N多個定製版本，應該在後續考慮引入模塊化組件化開發）：一個是Locman2.0，另外一個是現階段的啞資源管理平臺；對於這兩個版本不做軟件硬件實現以及工做流程不作任何評價，這裏我只是談一談我在作了這兩個版本以後的整個開鎖關鎖流程 （僅表明我的理解）。
   現階段Locman與摩拜單車實現流程很是相似也是存在三個很是重要的節點+人工操做：

• [x] 硬件設備：人井，光交等（自研硬件）
• [x] 手機終端：移動管理軟件
• [x] 服務器：C/S、平臺系統

   從上圖能夠看出，Locman平臺開鎖、關鎖通訊方式與摩拜基本是一致的，也是存在：硬件設備與服務器、硬件設備與手機終端、手機終端與服務器之間的兩兩通訊，可是在實現上存在許多不一樣（與業務場景相關），比較重要的一點是咱們的硬件設備必須手動激活，加入了應急開鎖功能。

• 硬件設備與服務器通訊
     當硬件設備手動激活後，在手機終端發送遠程開啓請求指令，服務器會經過兩種方式：一種是SIM卡發送短信遠程開鎖指令；另外一種是經過GPRS發送。同理設備上報狀態信息也採用以上兩種方式。

• 硬件設備與手機終端通訊
     這種通訊現階段僅存在於光交設備。當設備人工激活後，經過手機App鏈接設備，鏈接成功以後讀取設備信息並請求開鎖指令，經過藍牙向設備發送開鎖指令開鎖。

• 手機終端與服務器通訊
     手機終端與服務器通訊方式比較簡單：一個是服務器經過推送方式提示手機用戶告警信息；另外一個是當設備手動激活後，須要經過工單中已知的設備信息（這裏手機終端並未與設備通訊）向服務器請求遠程開啓指令。服務器並無向手機終端返回確實已開啓設備的信息（由於是現場做業，並且無需其餘附加操做：例如摩拜單車的計費功能，能夠經過設備鎖人工斷定）。

Locman開鎖流程

爲何現階段咱們開鎖存在人工操做

• 省電
• 省電
• 省電

   這裏與摩拜存在很大的區別，因爲咱們的設備是須要長時間保持電量（無充電來源），因此咱們的設備並無經過TCP/IP與服務器端保持長鏈接，而且設備在使用後會自動進入關機狀態，若是在無人工參與時設備只會固定一個週期上報狀態信息。

對體驗共享單車後Locman後期的一點思考

   如下問題只是我的的一些思考，如存在不合理或者不全面歡迎指正，請聯繫個人公司郵箱，謝謝！

• Locman能夠不使用激活鑰匙激活設備嗎？
     如今藍牙4.0技術發展已經很成熟，相較於之前老的藍牙2.0在功耗上大大下降，從如今使用的藍牙鼠標來看，兩節5號電池雷柏藍牙鼠標可使用大約3個半個月（親身體驗），若是是4節1號電池應該使用週期會更長（這個有待技術後期驗證）。以上的說法在技術上來講至關不嚴謹，這裏我從網上找到了關於藍牙4.0相關功耗文章：
  藍牙4.0低功耗技術及其認證要求，提到可使一枚鈕釦電池工做長達數年；
  nRF8001鈕釦電池續航的超低功耗藍牙4.0技術，訊通科技電子技術公司；
  更多關於藍牙4.0功耗問題，請進入百度文庫 搜索 藍牙4.0功耗

     經過上述瞭解後，若是咱們設備使用藍牙能夠直接保持藍牙在線，而且能夠被搜索到（至於如何與咱們本身的App安全配對問題，須要硬件與軟件共同解決），當施工人員靠近設備便可直接鏈接上藍牙，此時有兩種方式開鎖以及上報設備狀態信息：

  • App經過藍牙近距發送激活命令，設備接收到激活命令以後按照之前手動插入激活鑰匙相同，激活設備；等待設備激活後，發送遠程控制開鎖命令開鎖，並上報狀態信息。相較於以前只是去除了人工手動激活，也並無解決掉開鎖延時、開鎖成功率不高的問題；
  • App經過藍牙近距離發送激活命令獲取到設備信息，經過App網絡請求服務器遠程控制權限命令後經過藍牙直接開鎖，而且能夠同App直接上報設備狀態。快速方便、開鎖成功率高。

• Locman可使用二維碼掃描開鎖嗎？

   在現階段設備開鎖狀況只須要讀取到咱們的設備信息而且具備開鎖權限的用戶均可以開鎖。權限已由服務器自動判斷，如今主要的就是設備信息問題，咱們能夠經過在設備上加入具備設備信息的二維碼標籤便可。後續的開鎖流程：一種是就可直接參照現階段遠程開鎖流程操做；另外一種是結合上一個問題已討論的藍牙進行開鎖。

• Locman能夠增長離線開鎖功能嗎？

   關於Locman離線開鎖功能，在完成2.0版本以後就有了這個想法。在外施工的工做人員會遇到網絡信號很差，這種狀況應該是比較常見的，這不只僅是隻包含咱們手機終端設備信號，也包括咱們硬件設備在不少時候請求了遠程開鎖並不可以成功的開啓。
   在現階段實現流程中加入離線開鎖功能是不現實的，首先咱們設備是須要手動激活，而後經過服務器發送開鎖命令纔可以完成開鎖流程。可是若是結合上述 Locman能夠不使用激活鑰匙激活設備嗎？ 可以新增藍牙開鎖。大體流程以下：
   施工人員在處於有網絡狀態下，下載離線設備數據，而且根據用戶權限獲取開鎖命令（命令能夠是：根據用戶權限生成的一次性命令、永久命令），在用戶處於網絡很差的狀況，經過藍牙鏈接發送獲取設備信息而且獲得信息與離線存儲口令進行匹配，匹配成功後再經過藍牙直接發送開鎖命令直接開啓設備。

• Locman能夠增長預定功能嗎？

   我以爲答案是確定的，參照 Locman能夠增長離線開鎖功能嗎？ 用戶能夠直接選擇預先下載對應設備的開鎖命令（這裏的命令與離線命令須要區分開來）進行預定，在用戶預定以後凍結該設備（凍結時長或者其餘參考因素）爲其餘人操做。後續操做方式與上述 Locman能夠增長離線開鎖功能嗎？ 相同。

• 關於以上問題思考後Locman開/關設備實現流程圖
     整個流程主要是結合上述提出的幾個問題進行一個簡單得梳理，在現階段正在使用的流程中加入/新增了：
  • 手動激活改成藍牙自動激活；
  • 預定流程；
  • 讀取設備信息從離線數據、藍牙讀取、二維碼掃描；
  • 設備上傳信息修改成手機App與設備能夠同時上傳。
    

   最後這些想法是否合理還有待驗證，在這裏感謝個人同事鄧xx（就不寫全名了）對我在Locman整個開鎖流程上的梳理與幫助。