移動端開發規範
引言：最近得空，整理一些平時工作中要求的開發規範，淺薄之處還請大家多指教。
目錄
代碼規範
基本原則
-
代碼清晰
又清晰又簡潔的代碼當然是最好的了，但簡潔不如清晰重要。總的講不要使用單詞的簡寫，除了非常常用的簡寫以外，儘量使用單詞全稱。API的名稱不要有歧義，一看你的API就知道是以什麼方式做了什麼事情，不要讓人有疑問！
-
一致性
代碼保持一致，例如：創建UI相關的方法,可以使用統一的方法命名，所見即所得，見表知其意，這樣，既保證了代碼的一致性，也可以方便我們後續維護和管理，也利於團隊代碼風格的一致，協調！
編程中比較常見的有下面三種命名方式
- 駝峯(Camel)命名法:又稱小駝峯命名法，除首單詞外，其餘所有單詞的第一個字母大寫。
- 帕斯卡(pascal)命名法:又稱大駝峯命名法，所有單詞的第一個字母大寫下劃線命名法:單詞與單詞間用下劃線做間隔
一般建議拿來做命名的單詞要比較精悍短小，這樣即使兩三個單詞一起拼裝成一個命名，也不至於顯得很冗長。當然有些單詞我們也可以直接寫成一些約定俗成的縮寫。諸如：msg(message)、init(initial)、img(image)等….
通用規範
-
類命名
名詞，採用大駝峯命名法，儘量避免縮寫，除非該縮寫是衆所周知的。如HTML,URL,JSON，XML等.當然也可以根據開發中的一些命名習慣進行進行縮寫，比如Activity會縮寫爲AC，UIViewController會縮寫爲VC。
接口命名
和類名基本一致。也可以在接口名前面再加一個大寫的I，表明這是一個接口Interface。如：可以表明一個信息是否可以分享的接口，可以命名爲Shareable，也可以是IShareable。
-
方法命名
動詞或動名詞，採用小駝峯命名法。
-
變量命名
採用小駝峯命名法。同樣比較簡單，但爲了更好表明含義，建議做一下的的區分。成員變量命名前面加m（member，表示成員變量之意），如，控件的寬高 mWidth，mHeight。
-
常量命名
同樣較爲簡單，全部大寫,採用下劃線命名法.如：MIN_WIDTH,MAX_SIZE
-
枚舉類型命名
首字母大寫，之後每個單詞首字母都大寫，最後加“s” 枚舉變量使用枚舉類型去掉“s”作爲前綴，每個單詞首字母大寫，中間不允許加下劃線 舉例：
typedef enum UIControlEvents
{
UIControlEventTouchDown,
UIControlEventTouchUpInside
}
UIControlEvents;
-
圖片命名
這個圖片資源命名方式，以功能爲組織形式，是一個很好的習慣，有利於查看資源文件。
原則
採用單詞全拼，或者大家公認無岐義的縮寫(比如：nav，bg，btn等)
採用“模塊+功能”命名法，模塊分爲公共模塊、私有模塊。
公共模塊主要包括統一的背景，導航條，標籤，公共的按鈕背景，公共的默認圖等等；
私有模塊主要根據app的業務功能模塊劃分，比如用戶中心，消息中心等。
例如 :用戶中心 用戶頭像圖片的命名可以爲：uc_user_icon.png
-
通用規範
- 第三方的庫統一放在library目錄下
- 代碼量控制。單頁代碼最好控制在800行以內，每個方法最好不要超過80行，過多建議對代碼進行重構
- 整體代碼風格需要統一。邏輯運算符與代碼之前空一格。注意大括號的位置(“{}”)，一種是起首的大括號另起一行，另一種是起首的大括號跟在關鍵字的後面；一般來說這兩種都能夠接受，請儘可能保證在一份代碼中使用一種風格。
- 添加必要的註釋。在類的屬性，方法，比較大的代碼塊等位置可以添加必要的註釋。
- 刪除未被使用的資源文件
- 刪除多餘的方法。如果方法沒有使用到，請刪除它。如果方法沒有執行任何業務邏輯，請刪除它或者給出一定註釋。
- 刪除多餘的註釋，刪除註釋掉的代碼，刪除沒有意義的註釋。
- 刪除多餘的空行。所有方法與方法之間空1行 所有代碼塊之間空1行
通用設計規範
-
開屏頁版本號
目的：方便用戶及運營教學人員瞭解當前APP版本。
實現步驟：
- 開屏頁添加Label顯示，樣式由不同APP設計決定。
重要性：中
-
版本檢查
目的：線上最新版本檢查及更新。
實現步驟：
- 後端給出調用接口及參數。
- 前端在啓動頁中調用，彈出對話框提醒用戶更新，具體樣式由不同APP設計決定。
重要性：高
-
開屏頁廣告
目的：線上活動及推廣。
實現步驟：
- 後端給出調用接口及參數。
- 前端在啓動頁中調用，彈出相關界面，具體樣式由不同APP設計決定。
重要性：低
-
推送
目的：接收來自服務器推送。
實現步驟：
iOS：
- 使用原生。
Android：
- 在極光管理界面中新增相關app。
- 將相關SDK添加到APP項目中。
重要性：高
通用測試用例及處理規範
-
規範
- 測試用例應包含所有邏輯覆蓋
- 測試用例應包含所有覆蓋範圍中提出的情況
- 開發應對所有錯誤情況做出處理
-
用例
- 網絡：
|
用例集 |
覆蓋範圍 |
預期結果 |
錯誤情況 |
處理方式 |
邏輯覆蓋 |
|
請求網絡接口 |
所有請求網絡場景 |
正常返回數據 |
用戶斷網 |
提示用戶檢查網絡 |
移動網絡 |
|
接口異常 |
提示用戶重試 |
wifi網絡 |
|||
|
無網絡權限 |
提示用戶無權限，引導用戶設置 |
關閉網絡授權 |
|||
|
關閉所有網絡連接 |
- 權限：
|
用例集 |
覆蓋範圍 |
預期結果 |
錯誤情況 |
處理方式 |
邏輯覆蓋 |
|
請求用戶權限 |
所有請求權限場景：攝像頭、麥克風、文件讀寫、網絡、定位 |
獲取用戶授權 |
用戶從未授權 |
提示用戶授權 |
首次給予授權 |
|
首次拒絕授權 |
|||||
|
用戶拒絕授權 |
提示用戶無權限，引導用戶設置 |
關閉授權後，重新打開授權 |
|||
|
給予授權後，關閉授權 |
- 內存：
|
用例集 |
覆蓋範圍 |
預期結果 |
錯誤情況 |
處理方式 |
邏輯覆蓋 |
|
內存 |
所有界面 |
內存佔用量正常 |
內存泄漏 |
開發排查 |
反覆切換同一界面 |
|
反覆刷新界面數據 |
|||||
|
反覆獲取圖片 |
|||||
|
反覆播放視頻流 |
- 後臺切換操作：
|
用例集 |
覆蓋範圍 |
預期結果 |
錯誤情況 |
處理方式 |
邏輯覆蓋 |
|
後臺切換操作 |
所有界面 |
界面及數據正常 |
界面及數據錯誤，閃退 |
開發排查 |
反覆前後切換 |
|
程序進入後臺後，較長時間切回前臺 |
- 輸入操作：
|
用例集 |
覆蓋範圍 |
預期結果 |
錯誤情況 |
處理方式 |
邏輯覆蓋 |
|
輸入操作 |
所有文本輸入框 |
界面正常 |
界面排版錯誤，閃退 |
限定輸入框字數，提示用戶輸入字符超過限制，顯示省略號 |
在同一輸入框彙總輸入大量字符 |
- 分享：
|
用例集 |
覆蓋範圍 |
預期結果 |
錯誤情況 |
處理方式 |
邏輯覆蓋 |
|
分享 |
所有分享入口 |
正常分享 |
分享失敗 |
開發排查 |
分享至各個平臺 |
|
點擊分享內容中的鏈接 |
|||||
|
分享內容錯誤 |
識別分享內容中的二維碼 |
數據埋點規範
-
事件類型
- 標準用戶操作事件：由用戶操作觸發，比如用戶的一次按鈕點擊或者完成註冊、登陸等
- 頁面事件：進入、離開頁面時觸發
-
事件通用參數
- 用戶唯一標示
- 應用標示
- 事件類型
- 事件自定義參數
- 渠道號
-
事件封裝
- 有統一初始化接口收集應用標示和用戶標示
- 在事件觸發時調用相關事件類型的發送接口
- 事件發送接口封裝了底層的事件網絡請求
-
初始化事件統計式例
WEStatistics.init(appId:”test”, userId:”15901812370”, channelId:”test-channel”);
-
標準用戶操作事件式例
WEStatistics.sendEvent(eventId:”用戶完成註冊”, attr:{“time”:”註冊時間”, “idfa”:”****”});
-
頁面事件式例
- 進入頁面
WEStatistics.sendPageBegin(eventId:”註冊頁面”, attr:{“time”:”進入時間”, “idfa”:”********”});
- 離開頁面
WEStatistics.sendPageEnd(eventId:”註冊頁面”, attr:{“time”:”離開時間”, “idfa”:”*********”});
-
其它功能特性
- 離線緩存：在用戶網絡狀態不佳的情況下，如果事件無法及時發送成功，應換存在本地，在網絡情況正常後，再次發送。因此，統計服務器應有兩種接口：單個事件接口、批量事件接口。
- 底層實現可切換，爲在不同平臺收集數據提供便利
-
常用埋點策略
|
事件名稱 |
事件重要性 |
事件描述 |
|
用戶進入應用 |
高 |
統計用戶啓動應用、活躍用戶、用戶留存、應用使用時長 |
|
用戶完成登陸 |
中 |
統計完成登陸流程的用戶比例 |
|
用戶完成註冊 |
高 |
統計完成註冊的用戶比例，新用戶數量 |
|
用戶開始支付 |
高 |
統計用戶支付傾向 |
|
用戶完成支付 |
高 |
統計實際支付用戶數量 |
|
用戶退出應用 |
低 |
配合用戶進入應用，統計用戶使用時長 |
|
用戶點擊推廣 |
中 |
統計應用內展示推廣被點擊數 |
|
用戶進入頁面 |
低 |
統計進入具體頁面次數 |
|
用戶退出頁面 |
低 |
配合進入頁面事件，統計頁面使用時長 |
-
源代碼管理規範
-
分支類型
- master：主分支，只做發版用，不直接修改
- hotfix：線上bug修復分支，一般從master分支中切出，修改完bug後，合併回master分支。
- develop：主開發分支，一般從master分支中切出，功能開發及最終測試完成後，合併回master，極少直接修改。
- function：功能分支，一般衝develop分支中切出，功能及單元測試完成後合併回develop分支。主要的功能迭代分支，可以有多個並行。
-
分支使用
- 開發人員應該在自己的開發分支（例如：justin_dev）或者功能分支（login）上進行開發，完成開發之後，彙集到develop分支上，一般develop不直接進行修改。
- 測試及產品人員在develop版本上獲取開發成品進行測試和驗收，測試驗收完成之後，應該由開發人員將develop分支合併到master分支上進行發佈。