原創 2017-02-28

關鍵點：

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

自2015年Uber、Airbnb火熱起來之后給O2O創業帶了一個新的名詞 共享經濟（所謂的共享經濟模式就是通過一個平臺化的互聯網工具，把社會上具有相同屬性的閑散資源整合到一起，以更加高效的方式滿足市場的供給），在國內就出現了一大批如滴滴、易到用車、神州專車等基于共享模式號稱解決人們打車難的平臺出現，統治了打車這個行業，但在人們“最后一公里”出行方面還是面臨了難題。世界就是這么奇妙，哪里有需求哪里就會有解決方案，在2016年中相繼出現了摩拜單車、ofo單車、小藍單車等方便出行的“原始交通工具”，在一開始出來之后，作為屌絲的我為了不給 299、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發送開鎖指令），得到單車鎖已開回執后開始計費；行程結束后，服務器收到了單車的關鎖信息，結束計費并向手機下發結束計費指令。

摩拜整個通信流程

• 二維碼方式開鎖猜想

  二維碼開鎖方式

• 藍牙開鎖方式猜想
  ???關于摩拜單車藍牙開鎖，在這里個人覺得有兩種方式：一種是與二維碼相同直接向服務器請求開鎖指令后，通過服務器發送指令到單車開鎖；另一種是請求成功后指令直接發送到用戶手機端，此時在通過手機與單車的藍牙發送指令開鎖，個人比較傾向于第二種（不然摩拜在后階段也不會大力推行藍牙開鎖方式，有可能還存在更多好處，暫時未分析出來），此種方式可以減少服務器與單車鏈接的不確定性，增加開鎖成功幾率，同時通過藍牙開啟成功后，單車的鎖已開狀態信息可以又通過手機直接上傳至服務器并同時開啟計費。
  

  藍牙開鎖-方式1
  藍牙開鎖-方式2

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

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

ofo單車通信模型

• 手機終端與服務器之間的通信
  ???ofo在與服務通信過程中，其實主要也只有三個比較重要的請求：一個是向服務器請求開鎖密碼，請求成功后一段時間開始計費，與摩拜單車請求成功后單車回執鎖已開命令存在實質性差別；一個是請求關鎖然后結束行程；另一個就是向服務器上傳已經記錄的GPS定位軌跡數據（這里也是ofo在開始騎行前為什么需要開啟GPS定位功能）。這與其他所有手機終端與服務器Request-Response并無差異，在技術上也很簡單。

現階段Locman技術實現分析

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

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

Locman通信模型

從上圖可以看出，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與設備可以同時上傳。
    
    Locman流程優化

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