大家好,又见面了,我是你们的朋友全栈君。
移动端开发规范
引言:最近得空,整理一些平时工作中要求的开发规范,浅薄之处还请大家多指教。
目录
代码规范
基本原则
-
代码清晰
又清晰又简洁的代码当然是最好的了,但简洁不如清晰重要。总的讲不要使用单词的简写,除了非常常用的简写以外,尽量使用单词全称。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分支上进行发布。
发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/152731.html原文链接:https://javaforall.cn
【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛
【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...