移动端开发规范

大家好，又见面了，我是你们的朋友全栈君。

移动端开发规范

引言：最近得空，整理一些平时工作中要求的开发规范，浅薄之处还请大家多指教。

目录

移动端开发规范

代码规范

基本原则

代码清晰

一致性

通用规范

类命名

方法命名

变量命名

常量命名

枚举类型命名

图片命名

通用规范

通用设计规范

开屏页版本号

版本检查

开屏页广告

推送

通用测试用例及处理规范

规范

用例

数据埋点规范

事件类型

事件通用参数

事件封装

初始化事件统计式例

标准用户操作事件式例

页面事件式例

其它功能特性

常用埋点策略

源代码管理规范

分支类型

分支使用

代码规范

基本原则

• 代码清晰

又清晰又简洁的代码当然是最好的了，但简洁不如清晰重要。总的讲不要使用单词的简写，除了非常常用的简写以外，尽量使用单词全称。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. 开发应对所有错误情况做出处理

• 用例
• 网络：

• 权限：

• 内存：

• 后台切换操作：

• 输入操作：

• 分享：

数据埋点规范

• 事件类型

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分支上进行发布。

发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/152731.html原文链接：https://javaforall.cn