本次案例分析選用的是 摩拜單車ios５.７.５版本
使用過程中發現了如下兩個問題：
1.2.1 3dtouch快捷操作選擇掃一掃偶然出現閃退現象，直接上**。
bug現象：
bug現象：
使用者背景：非計算機專業本科在校生。
使用機型：ios10，（沒有3dtouch功能）。
使用者改進建議：能夠記錄每一次的行蹤，但是卻不能手動刪除，這可真是乙個麻煩的問題。emmmm,這可能會對某些不想讓手機記錄下行動軌跡的使用者放棄選擇mobike。
關於ui設計還是比較符合大眾審美的，說不上非常炫酷華麗的ui設計，但是起碼讓人用起來不彆扭
結論：一般，對比同類沒有什麼很突出的表現。
①：【地圖尋車->】【預約車輛->】掃碼開鎖->結束付款
②：檢視歷史行蹤
③：應用內的**服務
④：自行車報修
注：【】為可選項
品牌mobike
ofohallo bike
介面ui
三款軟體中個人人為最優介面 ９分
中規中矩 ８分
中規中矩 ８分
掃碼速度
對於***圖形的識別速度，同類軟體中速度最慢的乙個 ７分
不支援快捷開鎖，還要手動輸入密碼是比較麻煩的 ５分
識別速度快，是三個軟體中開鎖最方便的乙個 ９分
其他附加功能
附加功能繁多，總是會有點繞，但好在選單層次分明，容易使用 ７分
無法取消你所不關心的通知訊息，總是有個小紅點很煩人 ５分
基本無太多附加功能，是個人最喜歡的乙個 ７分
①優化開鎖速度，從***的內容識別開始。
②簡化**內容，內容越多新客戶使用的機率就更小了，因為入手難度高，學習成本高
③採用獎懲制度，鼓勵使用者報修，對問題分等級處理，簡單的報修問題可以先不對自行車進行鎖定處理（設定成無法開鎖），對於會影響騎行的問題要將自行車鎖定起來。以免影響了使用者的體驗感。
n：a：
從新開發乙個導航系統對於這種創業公司是遠不可能的，我們只能夠通過與高德地圖攜手。通過各種商業手段去獲取到高德的地圖導航介面，並嵌入到系統中。另外應用本身就有記錄行蹤，可以通過記錄下的行蹤資料對常用的路線進行優化反饋，讓騎行路線從使用者中來到使用者中去，還可以填補高德地圖不存在的路線。
b：解決使用者取到車以後的可能存在的不知道往哪走的問題。另外採用商業合作去獲取別人現成的導航功能是可行性比較高的方案。
c: d：
誰用誰知道，用過一次以後需要導航的使用者自然會選擇該類產品
4.如果讓我來領導技術團隊：這個可是乙個憑空意淫的大難題。首先，美工和後端的開發是可以分離的，而且要考慮多端支援到底支援多少，比如我們要同時相容ios和安卓兩大陣營，還要同時相容小程式和手機端大小的web頁面。
後端的話應該是通用的。但是後端的難點是建立在我要用誰的地圖引擎，我的後端要搭建乙個支援多大規模的伺服器，這個也是很難拍腦袋就想出來了。
五個人的團隊應該是不足以支援這麼多方向的開發的，但是如果勉強要這麼做，我會選擇兩個人做服務端提供服務，（後端後期可能工作就比較少了，那他不妨最後以乙個小白的身份去做測試）。
時間軸方面
②：２－４周。服務端開始搭建伺服器平台。前端開始做ui的實現，期間要對方向進行微調，比如某方面的功能受制於某項法律規定，或者其他的資源無法開發等。
③：５－９周 主要**的編寫
④：９－１２對原型進行內測修改。服務端可以考慮優化，而美工由於功能的疊加可能需要對介面進行簡單的重構。
⑤：１３－１４ 兩周時間做第一次的測試，此時的主要內容在測試方面。
⑥：１４－１５ 對測試的問題進行修改
⑦：１６－１７ 進行回歸測試
注：測試應該是貫穿整個開發過程的，故在這裡就不一一例舉出來了
摩拜單車開鎖原理
摩拜的開鎖原理，需要通過整體架構來梳理，分為幾個部分 業務層 使用者掃碼，讀取乙個匹配裝置序列號，使用者資料在後台訂單系統做一次裝置使用授權校驗 比如押金餘額 沒有問題的話，下一步 裝置層 通知伺服器下發乙個開鎖訊號到車鎖控制系統。簡單的說就是業務層解決完了，處理開關問題。在以上最難的部分在於處理通...
摩拜單車 說走就走的旅程
聽 azure 背後的故事 不知從何時起，我們每天生活的城市裡，開始被霧霾籠罩，沒有一點點防備，就會開始漫長的限行時光。漸漸地，我們開始懷念單車出行的日子，那時候的天很藍，空氣良好，日子也簡單而自由。有這樣乙個女孩兒，她說 我希望我像乙個機器貓一樣，當我想要一輛自行車的時候，我就能從口袋裡掏出一輛自...
APP的案例分析
通過各種案例分析，評測，辯論，總結，我們就能看到軟體工程的原則在實踐中的種種體現，也幫助我們在實踐中做得更好。產品微軟小娜 智慧型助手，ios pc 安卓都有 第一部分調研，評測 在ios應用商店搜尋微軟小娜，出來cortana，是軟體的真實的名字，介面很簡潔清晰，註冊登入之後開始愉快的調戲小娜。按...