移動端開發規範
引言:最近得空,整理一些平時工作中要求的開發規範,淺薄之處還請大家多指教。
目錄
代碼規範
基本原則
-
代碼清晰
又清晰又簡潔的代碼當然是最好的了,但簡潔不如清晰重要。總的講不要使用單詞的簡寫,除了非常常用的簡寫以外,儘量使用單詞全稱。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分支上進行發佈。