移動端開發規範

移動端開發規範

 

引言:最近得空,整理一些平時工作中要求的開發規範,淺薄之處還請大家多指教。

 

目錄

移動端開發規範

代碼規範

基本原則

代碼清晰

一致性

通用規範

類命名

方法命名

變量命名

常量命名

枚舉類型命名

圖片命名

通用規範

通用設計規範

開屏頁版本號

版本檢查

開屏頁廣告

推送

通用測試用例及處理規範

規範

用例

數據埋點規範

事件類型

事件通用參數

事件封裝

初始化事件統計式例

標準用戶操作事件式例

頁面事件式例

其它功能特性

常用埋點策略

源代碼管理規範

分支類型

分支使用


 

 

代碼規範

基本原則

  • 代碼清晰

又清晰又簡潔的代碼當然是最好的了,但簡潔不如清晰重要。總的講不要使用單詞的簡寫,除了非常常用的簡寫以外,儘量使用單詞全稱。API的名稱不要有歧義,一看你的API就知道是以什麼方式做了什麼事情,不要讓人有疑問!

  • 一致性

代碼保持一致,例如:創建UI相關的方法,可以使用統一的方法命名,所見即所得,見表知其意,這樣,既保證了代碼的一致性,也可以方便我們後續維護和管理,也利於團隊代碼風格的一致,協調!

編程中比較常見的有下面三種命名方式

  1. 駝峯(Camel)命名法:又稱小駝峯命名法,除首單詞外,其餘所有單詞的第一個字母大寫。
  2. 帕斯卡(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

  • 通用規範

  1. 第三方的庫統一放在library目錄下
  2. 代碼量控制。單頁代碼最好控制在800行以內,每個方法最好不要超過80行,過多建議對代碼進行重構
  3. 整體代碼風格需要統一。邏輯運算符與代碼之前空一格。注意大括號的位置(“{}”),一種是起首的大括號另起一行,另一種是起首的大括號跟在關鍵字的後面;一般來說這兩種都能夠接受,請儘可能保證在一份代碼中使用一種風格。
  4. 添加必要的註釋。在類的屬性,方法,比較大的代碼塊等位置可以添加必要的註釋。
  5. 刪除未被使用的資源文件
  6. 刪除多餘的方法。如果方法沒有使用到,請刪除它。如果方法沒有執行任何業務邏輯,請刪除它或者給出一定註釋。
  7. 刪除多餘的註釋,刪除註釋掉的代碼,刪除沒有意義的註釋。
  8. 刪除多餘的空行。所有方法與方法之間空1行 所有代碼塊之間空1行

 

 

通用設計規範

  • 開屏頁版本號

目的:方便用戶及運營教學人員瞭解當前APP版本。

實現步驟:

  1. 開屏頁添加Label顯示,樣式由不同APP設計決定。

重要性:中

  • 版本檢查

目的:線上最新版本檢查及更新。

實現步驟:

  1. 後端給出調用接口及參數。
  2. 前端在啓動頁中調用,彈出對話框提醒用戶更新,具體樣式由不同APP設計決定。

重要性:高

  • 開屏頁廣告

目的:線上活動及推廣。

實現步驟:

  1. 後端給出調用接口及參數。
  2. 前端在啓動頁中調用,彈出相關界面,具體樣式由不同APP設計決定。

重要性:低

  • 推送

目的:接收來自服務器推送。

實現步驟:

iOS:

  1. 使用原生。

Android:

  1. 在極光管理界面中新增相關app。
  2. 將相關SDK添加到APP項目中。

重要性:高

 

通用測試用例及處理規範

  • 規範

  1. 測試用例應包含所有邏輯覆蓋
  2. 測試用例應包含所有覆蓋範圍中提出的情況
  3. 開發應對所有錯誤情況做出處理
  • 用例

  • 網絡:

用例集

覆蓋範圍

預期結果

錯誤情況

處理方式

邏輯覆蓋

請求網絡接口

所有請求網絡場景

正常返回數據

用戶斷網

提示用戶檢查網絡

移動網絡

接口異常

提示用戶重試

wifi網絡

無網絡權限

提示用戶無權限,引導用戶設置

關閉網絡授權

關閉所有網絡連接

  • 權限:

用例集

覆蓋範圍

預期結果

錯誤情況

處理方式

邏輯覆蓋

請求用戶權限

所有請求權限場景:攝像頭、麥克風、文件讀寫、網絡、定位

獲取用戶授權

用戶從未授權

提示用戶授權

首次給予授權

首次拒絕授權

用戶拒絕授權

提示用戶無權限,引導用戶設置

關閉授權後,重新打開授權

給予授權後,關閉授權

  • 內存:

用例集

覆蓋範圍

預期結果

錯誤情況

處理方式

邏輯覆蓋

內存

所有界面

內存佔用量正常

內存泄漏

開發排查

反覆切換同一界面

反覆刷新界面數據

反覆獲取圖片

反覆播放視頻流

  • 後臺切換操作:

用例集

覆蓋範圍

預期結果

錯誤情況

處理方式

邏輯覆蓋

後臺切換操作

所有界面

界面及數據正常

界面及數據錯誤,閃退

開發排查

反覆前後切換

程序進入後臺後,較長時間切回前臺

  • 輸入操作:

用例集

覆蓋範圍

預期結果

錯誤情況

處理方式

邏輯覆蓋

輸入操作

所有文本輸入框

界面正常

界面排版錯誤,閃退

限定輸入框字數,提示用戶輸入字符超過限制,顯示省略號

在同一輸入框彙總輸入大量字符

  • 分享:

用例集

覆蓋範圍

預期結果

錯誤情況

處理方式

邏輯覆蓋

分享

所有分享入口

正常分享

分享失敗

開發排查

分享至各個平臺

點擊分享內容中的鏈接

分享內容錯誤

識別分享內容中的二維碼

 

 

數據埋點規範

  • 事件類型

  1. 標準用戶操作事件:由用戶操作觸發,比如用戶的一次按鈕點擊或者完成註冊、登陸等
  2. 頁面事件:進入、離開頁面時觸發
  • 事件通用參數

  1. 用戶唯一標示
  2. 應用標示
  3. 事件類型
  4. 事件自定義參數
  5. 渠道號
  • 事件封裝

  1. 有統一初始化接口收集應用標示和用戶標示
  2. 在事件觸發時調用相關事件類型的發送接口
  3. 事件發送接口封裝了底層的事件網絡請求
  • 初始化事件統計式例

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”:”*********”});
  • 其它功能特性

  1. 離線緩存:在用戶網絡狀態不佳的情況下,如果事件無法及時發送成功,應換存在本地,在網絡情況正常後,再次發送。因此,統計服務器應有兩種接口:單個事件接口、批量事件接口。
  2. 底層實現可切換,爲在不同平臺收集數據提供便利
  • 常用埋點策略

事件名稱

事件重要性

事件描述

用戶進入應用

統計用戶啓動應用、活躍用戶、用戶留存、應用使用時長

用戶完成登陸

統計完成登陸流程的用戶比例

用戶完成註冊

統計完成註冊的用戶比例,新用戶數量

用戶開始支付

統計用戶支付傾向

用戶完成支付

統計實際支付用戶數量

用戶退出應用

配合用戶進入應用,統計用戶使用時長

用戶點擊推廣

統計應用內展示推廣被點擊數

用戶進入頁面

統計進入具體頁面次數

用戶退出頁面

配合進入頁面事件,統計頁面使用時長

 

 

  • 源代碼管理規範

  • 分支類型

  1. master:主分支,只做發版用,不直接修改
  2. hotfix:線上bug修復分支,一般從master分支中切出,修改完bug後,合併回master分支。
  3. develop:主開發分支,一般從master分支中切出,功能開發及最終測試完成後,合併回master,極少直接修改。
  4. function:功能分支,一般衝develop分支中切出,功能及單元測試完成後合併回develop分支。主要的功能迭代分支,可以有多個並行。
  • 分支使用

  1. 開發人員應該在自己的開發分支(例如:justin_dev)或者功能分支(login)上進行開發,完成開發之後,彙集到develop分支上,一般develop不直接進行修改。
  2. 測試及產品人員在develop版本上獲取開發成品進行測試和驗收,測試驗收完成之後,應該由開發人員將develop分支合併到master分支上進行發佈。
  •  
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章