目录
一, Android 开发框架
https://i.cnblogs.com/EditPosts.aspx?opt=1#_Toc543
二, 命名规范
https://i.cnblogs.com/EditPosts.aspx?opt=1#_Toc31997
2.1 包 (packages) 命名规范
https://i.cnblogs.com/EditPosts.aspx?opt=1#_Toc26192
2.2 类 (classes) 命名规范
https://i.cnblogs.com/EditPosts.aspx?opt=1#_Toc9600
2.3 方法(methods)
https://i.cnblogs.com/EditPosts.aspx?opt=1#_Toc7082
2.4 变量(variables)
https://i.cnblogs.com/EditPosts.aspx?opt=1#_Toc28270
2.5 常量(Constants)
https://i.cnblogs.com/EditPosts.aspx?opt=1#_Toc9479
2.6 资源文件(图片 drawable 文件夹下)
https://i.cnblogs.com/EditPosts.aspx?opt=1#_Toc18558
2.7 资源布局文件(XML 文件(layout 布局文件))
https://i.cnblogs.com/EditPosts.aspx?opt=1#_Toc19584
2.8 资源布局文件(layout 中的 id 命名)
https://i.cnblogs.com/EditPosts.aspx?opt=1#_Toc26808
三, 代码规范
https://i.cnblogs.com/EditPosts.aspx?opt=1#_Toc262
3.1 排版
https://i.cnblogs.com/EditPosts.aspx?opt=1#_Toc40
3.2 注释
四, XML 规范
https://i.cnblogs.com/EditPosts.aspx?opt=1#_Toc23068
一, Android 开发框架
旗鱼移动 Android 开发项目统一采用公司 Android 开发框架.
二, 命名规范
2.1 包 (packages) 命名规范
采用反域名命名规则, 全部使用小写字母. 一级包名为 com, 二级包名为 qiyu, 三级包名根据应用进行命名, 四级包名为模块名或层级名等.
包名 | 此包中包含 |
c om. qiyu . 应用名称缩写 .ui .activit y | 页面用到的 Activity 类 & nbsp;(activities 层级名用户界面层) |
com. qiyu . 应用名称缩写 .ui . fragment | 页面用到的 Fragment 类 |
com. qiyu . 应用名称缩写. adapter | 页面用到的 Adapter 类 & nbsp;(适配器的类) |
com. qiyu . 应用名称缩写. utils/ tools | 此包中包含:公共工具方法类( utils/ tools 模块名) |
com. qiyu . 应用名称缩写. response.data | 网络请求返回 response 层级 1 |
com. qiyu . 应用名称缩写. response.bean | 网络请求返回 response 层级 2 |
com. qiyu . 应用名称缩写. response.entity | 网络请求返回 response 层级 3 |
com. qiyu . 应用名称缩写. bean /entity | 此包中包含:元素类 |
com. qiyu . 应用名称缩写. db | 数据库操作类 |
com. qiyu . 应用名称缩写. view | 自定义的 View 类等 |
com.qiyu. 应用名称缩写. XXXX | 其他定义的包名 |
2.2 类 (classes) 命名规范
采用大驼峰命名法, 尽量避免缩写, 除非该缩写是众所周知的, 比如 html,URL, 如果类名称中包含单词缩写, 则单词缩写的每个字母均应大写.
类 | 描述 | 示 例 |
A ctivity 类 | Activity 为后缀标识 | 欢迎页面类 WelcomeActivity |
Adapter 类 | Adapte 为后缀标识 | 新闻详情适配器 NewDetailAdapter |
解析类 | Data 为 整体 后缀标识 , 二层析类 Bean 为后缀标识,三层为 Entity。 | 首页解析类 HomePoster Data |
公共方法类 | Utils、Tools 或 Manager 为后缀标识 ( 灵活运用 ) | 线程池管理类:ThreadPoolManager 日志工具类: 旗鱼点餐中为 L |
Service 类 | 以 Service 为后缀标识 | 时间服务 TimeService |
BroadcastReceive 类 | 以 Receiver 为后缀标识 | 时间通知 TimeReceiver |
ContentProvider | 以 Provider 为后缀标识 | 时间共享 TimeProvider |
直接写的共享基础类 | 以 Base 开头 | BaseActivity,BaseFragment |
............ | ............ | ............. |
2.3 方法(methods)
动词或动名词, 采用小驼峰命名法例如: onCreate(),run(). 自定义方法定义为 private , 特别需要例外.
方法 | 说明 |
initXX() | 初始化相关方法, 使用 init 为前缀标识,如初始化布局 initView() |
isXX() | checkXX()方法返回值为 boolean 型的请使用 is 或 check 为前缀标识 , 有时必须以 get 开头,如数据库类里。 |
getXX() | 返回某个值的方法,使用 get 为前缀标识 |
processXX() | 对数据进行处理的方法,尽量使用 process 为前缀标识 |
displayXX() | 弹出提示框和提示信息,使用 display 为前缀标识 |
saveXX() | 与保存数据相关的,使用 save 为 前缀标识 |
resetXX() | 对数据重组的,使用 reset 前缀标识 |
clearXX() | 清除数据相关的 |
removeXXX() | 清除数据相关的 |
drawXXX() | 绘制数据或效果相关的,使用 draw 前缀标识 |
initXX() | 初始化相关方法, 使用 init 为前缀标识,如初始化布局 initView() |
.......... | ..................... |
2.4 变量(variables)
采用小驼峰命名法. 类中控件名称必须与 xml 布局 id 保持一致.
用统一的量词通过在结尾处放置一个量词, 就可创建更加统一的变量, 它们更容易理解, 也更容易搜索. 例如, 请使用 strCustomerFirst 和 strCustomerLast, 而不要使用 strFirstCustomer 和 strLastCustomer.
量词列表: 量词后缀说明
First 一组变量中的第一个
Last 一组变量中的最后一个
Next 一组变量中的下一个变量
Pre 一组变量中的上一个
Cur 一组变量中的当前变量
...... .................
2.5 常量(Constants)
全部大写, 采用下划线命名法. 例如: MIN_WIDTH.
2.6 资源文件(图片 drawable 文件夹下)
全部小写, 采用下划线命名法, 加前缀区分, 图片命名遵守图片命名规范, 如有多种形态如按钮, 则命名方式如 bt_功能名_xx.selector(操作).xml 等.
图片文件名后缀 | 状态说明 |
_normal | (default state) |
_pressed | state_pressed |
_focused | state_focused |
_disabled | state_enabled (false) |
_checked | state_checked |
_selected | state_selected |
_hovered | state_hovered |
_checkable | state_checkable |
_activated | state_activated |
_windowfocused | state_window_focused |
2.7 资源布局文件(XML 文件(layout 布局文件))
全部小写, 采用下划线命名法.
模块 | 命名规则 | 示例 |
Activity | a ctivity_ 功能模块 _xx .xml | activity_main.xml 、 activity_ order_detail .xml |
Fragment | fragment _ 功能模块 _xx .xml | fragment_head.xml |
Dialog | dialog_ 描述 _xx .xml | dialog_ hint .xml |
PopupWindow | ppw_ 描述 _xx .xml | ppw_ info .xml |
包含项 include | include_ 模块 _xx .xml | include_head.xml |
adapter 的子布局 | item_功能模块_xx.xml | item_main.xml |
......... | ........... | ................ |
2.8 资源布局文件(layout 中的 id 命名)
命名模式为: view 缩写_view 的逻辑名称_XX. 如 tv_name,tv_name_label.
View 缩写使用 view 中每个大写字母组合拼成小写, 如 TextView 写成 tv 即可.
View 的缩写详情示例如下:
控件 | 命名缩写示例 |
TextView | tv |
EditText | et |
ImageView | iv |
Button | bt |
LinearLayout | ll |
RelativeLayout | rl |
RecycleView | rv |
......... | ........... |
三, 代码规范
3.1 排版
3.1.1 程序块要采用缩进风格编写, 缩进的空格数为 4 个.
说明: 对于由开发工具自动生成的代码可以有不一致.
3.1.2 编程语句长度设置成 160 个字符(非必须).
3.1.3 不允许把多个短语句写在一行中, 即一行只写一条语句.
示例: 如下例子不符合规范.
rect.length = 0; rect.width = 0;
应如下书写:
- rect.length = 0;
- rect.width = 0;
3.1.4 if,for,do,while,case,switch,default 等语句自占一行, 且 if,for,do,while 等语句的执行语句部分无论多少都要加括号{}.
示例: 如下例子不符合规范.
if (pUserCR == NULL) return;
应如下书写:
- if (pUserCR == NULL)
- {
- return;
- }
3.1.5 函数或过程的开始, 结构的定义及循环, 判断等语句中的代码都要采用缩进风格, case 语句下的情况处理语句也要遵从语句缩进要求.
3.1.6 程序块的分界符 (如大括号'{'和'}') 应各独占一行并且位于同一列, 同时与引用它们的语句左对齐. 在函数体的开始, 类的定义, 结构的定义, 枚举的定义以及 if, for, do, while, switch, case 语句中的程序都要采用如上的缩进方式.
示例: 如下例子不符合规范.
- for (...) {
- ... // program code
- }
- if (...)
- {
- ... // program code
- }
- void example_fun( void )
- {
- ... // program code
- }
应书写如下.
- for (...)
- {
- ... // program code
- }
- if (...)
- {
- ... // program code
- }
- void example_fun( void )
- {
- ... // program code
- }
3.1.7 在两个以上的关键字, 变量, 常量进行对等操作时, 它们之间的操作符之前, 之后或者前后要加空格; 进行非对等操作时, 如果是关系密切的立即操作符(如 ->), 后不应加空格.
说明: 采用这种松散方式编写代码的目的是使代码更加清晰.
由于留空格所产生的清晰性是相对的, 所以, 在已经非常清晰的语句中没有必要再留空格, 如果语句已足够清晰则括号内侧 (即左括号后面和右括号前面) 不需要加空格, 多重括号间不必加空格, 因为在 C/C++ 语言中括号已经是最清晰的标志了. 在长语句中, 如果需要加的空格非常多, 那么应该保持整体清晰, 而在局部不加空格. 给操作符留空格时不要连续留两个以上空格.
示例:
(1) 逗号, 分号只在后面加空格.
int a, b, c;
(2)比较操作符, 赋值操作符 "=", "+=", 算术操作符 "+", "%", 逻辑操作符 "&&","&", 位域操作符 "<<", "^" 等双目操作符的前后加空格.
- if (current_time >= MAX_TIME_VALUE)
- a = b + c;
- a *= 2;
- a = b ^ 2;
(3)"!","~","++","--","&"(地址运算符)等单目操作符前后不加空格.
- flag = !isEmpty; // 非操作 "!" 与内容之间
- p = &mem; // 地址操作 "&" 与内容之间
- i++; // "++","--" 与内容之间
(4) if, for, while, switch 等与后面的括号间应加空格, 使 if 等关键字更为突出, 明显.
if (a >= b && c > d)
3.2 注释
3.2.1 一般情况下, 源程序有效注释量必须在 20%以上.
说明: 注释的原则是有助于对程序的阅读理解, 在该加的地方都加了, 注释不宜太多也不能太少, 注释语言必须准确, 易懂, 简洁.
3.2.2 说明性文件 (如. java 文件) 头部应进行注释, 注释必须列出: 版权说明, 版本号, 生成日期, 作者, 内容, 功能, 与其它文件的关系, 修改日志等, 头文件的注释中还应有函数功能简要说明.
示例: 下面这段头文件的头注释比较标准, 当然, 并不局限于此格式, 但上述信息建议要包含在内.
- /*************************************************
- Copyright (C), 2015-2016, nizwo Tech. Co., Ltd.
- File name: // 文件名
- Author: Version: Date: // 作者, 版本及完成日期
- Description: // 用于详细说明此程序文件完成的主要功能, 与其他模块
- // 或函数的接口, 输出值, 取值范围, 含义及参数间的控
- // 制, 顺序, 独立或依赖等关系
- Others: // 其它内容的说明
- Function List: // 主要函数列表, 每条记录应包括函数名及功能简要说明
- 1. ....
- History: // 修改历史记录列表, 每条修改记录应包括修改日期, 修改
- // 者及修改内容简述
- 1. Date:
- Author:
- Modification:
- 2. ...
- *************************************************/
说明: Description 一项描述本文件的内容, 功能, 内部各部分之间的关系及本文件与其它文件关系等. History 是修改历史记录列表, 每条修改记录应包括修改日期, 修改者及修改内容简述.
3.2.3 函数头部应进行注释, 列出: 函数的目的 / 功能, 输入参数, 输出参数, 返回值, 调用关系 (函数, 表) 等.
示例: 下面这段函数的注释比较标准, 当然, 并不局限于此格式, 但上述信息建议要包含在内.
- /*************************************************
- Function: // 函数名称
- Description: // 函数功能, 性能等的描述
- Calls: // 被本函数调用的函数清单
- Called By: // 调用本函数的函数清单
- Table Accessed:// 被访问的表(此项仅对于牵扯到数据库操作的程序)
- Table Updated: // 被修改的表(此项仅对于牵扯到数据库操作的程序)
- Input: // 输入参数说明, 包括每个参数的作用, 取值说明及参 // 数间关系.
- Output: // 对输出参数的说明.
- Return: // 函数返回值的说明
- Others: // 其它说明
- *************************************************/
3.2.4 边写代码边注释, 修改代码同时修改相应的注释, 以保证注释与代码的一致性. 不再有用的注释要删除.
3.2.5 注释的内容要清楚, 明了, 含义准确, 防止注释二义性.
说明: 错误的注释不但无益反而有害.
3.2.6 避免在注释中使用缩写, 特别是非常用缩写.
说明: 在使用缩写时或之前, 应对缩写进行必要的说明.
3.2.7 对变量的定义和分支语句 (条件分支, 循环语句等) 必须编写注释.
说明: 这些语句往往是程序实现某一特定功能的关键, 对于维护人员来说, 良好的注释帮助更好的理解程序, 有时甚至优于看设计文档.
3.2.8 避免在一行代码或表达式的中间插入注释.
说明: 除非必要, 不应在代码或表达中间插入注释, 否则容易使代码可理解性变差.
3.2.9 注释格式尽量统一, 建议使用 "/* ...... */", 类或方法名注释使用 /**.......*/.
3.2.10 注释应与其描述的代码相近, 对代码的注释应放在其上方或右方 (对单条语句的注释) 相邻位置, 不可放在下面, 如放于上方则需与其上面的代码用空行隔开.
示例: 如下例子不符合规范.
例 1:
- /* get replicate sub system index and net indicator */
- repssn_ind = ssn_data[index].repssn_index;
- repssn_ni = ssn_data[index].ni;
例 2:
- repssn_ind = ssn_data[index].repssn_index;
- repssn_ni = ssn_data[index].ni;
- /* get replicate sub system index and net indicator */
应如下书写
- /* get replicate sub system index and net indicator */
- repssn_ind = ssn_data[index].repssn_index;
- repssn_ni = ssn_data[index].ni;
3.2.11 将注释与其上面的代码用空行隔开.
示例: 如下例子, 显得代码过于紧凑.
- /* code one comments */
- program code one
- /* code two comments */
- program code two
应如下书写
- /* code one comments */
- program code one
- /* code two comments */
- program code two
3.2.12 注释与所描述内容进行同样的缩排.
说明: 可使程序排版整齐, 并方便注释的阅读与理解.
示例: 如下例子, 排版不整齐, 阅读稍感不方便.
- void example_fun( void )
- {
- /* code one comments */
- CodeBlock One
- /* code two comments */
- CodeBlock Two
- }
应改为如下布局.
- void example_fun( void )
- {
- /* code one comments */
- CodeBlock One
- /* code two comments */
- CodeBlock Two
- }
3.2.13 在代码的功能, 意图层次上进行注释, 提供有用, 额外的信息.
说明: 注释的目的是解释代码的目的, 功能和采用的方法, 提供代码以外的信息, 帮助读者理解代码, 防止没必要的重复注释信息.
示例: 如下注释意义不大.
- /* if receive_flag is TRUE */
- if (receive_flag)
而如下的注释则给出了额外有用的信息.
- /* if mtp receive a message from links */
- if (receive_flag)
3.3 变量, 结构
3.3.1 去掉没必要的公共变量.
说明: 公共变量是增大模块间耦合的原因之一, 故应减少没必要的公共变量以降低模块间的耦合度.
3.3.2 仔细定义并明确公共变量的含义, 作用, 取值范围及公共变量间的关系.
说明: 在对变量声明的同时, 应对其含义, 作用及取值范围进行注释说明, 同时若有必要还应说明与其它变量的关系.
3.3.3 当向公共变量传递数据时, 要十分小心, 防止赋与不合理的值或越界等现象发生.
说明: 对公共变量赋值时, 若有必要应进行合法性检查, 以提高代码的可靠性, 稳定性.
3.3.4 防止局部变量与公共变量同名.
说明: 若使用了较好的命名规则, 那么此问题可自动消除.
3.3.5 严禁使用未经初始化的变量作为右值.
说明: 引用未经赋值的变量, 经常会引起系统崩溃.
3.3.6 结构的设计要尽量考虑向前兼容和以后的版本升级, 并为某些未来可能的应用保留余地(如预留一些空间等).
说明: 软件向前兼容的特性, 是软件产品是否成功的重要标志之一. 如果要想使产品具有较好的前向兼容, 那么在产品设计之初就应为以后版本升级保留一定余地, 并且在产品升级时必须考虑前一版本的各种特性.
3.3.7 编程时, 要注意数据类型的强制转换.
说明: 当进行数据类型强制转换时, 其数据的意义, 转换后的取值等都有可能发生变化, 而这些细节若考虑不周, 就很有可能留下隐患.
3.3.8 尽量减少没有必要的数据类型默认转换与强制转换.
3.3.9 合理地设计数据并使用自定义数据类型, 避免数据间进行不必要的类型转换.
四, XML 规范
4.1 布局
4.1.1 避免过多嵌套
说明: 嵌套的 LinearLayout 可能会使得 View 的层级结构很深. 使用 LinearLayout 时, 通常我们喜欢用嵌套的布局来动态设置一个 View 的 Visibility , 由于 LinearLayout 是线性的, 因此即使隐藏一个 View 也不会影响到其它 View 的排列. 而在 RelativeLayout 中, View 的位 置都是相对于其它 View 的, 因此, 隐藏之后, 会导致之前的 View 没有参考对象了, 导致的相对位置改变, 这时你可以使用 alignWithParentIfMissing="true" 来处理这种情况.
此外, 嵌套使用了 layout_weight 参数的 LinearLayout 的计算量会尤其大, 因为每个子元素都需要被测量两次. 这对需要多次重复 inflate 的 Layout 尤其需要注意, 比如使用 ListView 或 GridView 时.
示例: 如下布局
- <?xml version="1.0" encoding="utf-8"?>
- <RelativeLayout
- xmlns:android="http://schemas.android.com/apk/res/android"
- android:layout_width="wrap_content"
- android:layout_height="wrap_content">
- <TextView
- android:layout_width="wrap_content"
- android:layout_height="wrap_content"
- android:text="Hello World!"/>
- </RelativeLayout>
可以直接写成如下布局
- <?xml version="1.0" encoding="utf-8"?>
- <TextView xmlns:android="http://schemas.android.com/apk/res/android"
- android:layout_width="wrap_content"
- android:layout_height="wrap_content"
- android:text="Hello World!"/>
4.2 控件
4.2.1 控件中避免使用 drawableLeft,drawableRight,drawableXXXXX.
说明: 使用这种标志在控件中绘制图片, 导致图片大小不可控制, 将产生严重的屏幕适配问题.
4.2.2 ImageView 控件必须明确控制其大小, 除非是适应屏幕宽或高, 即只能使用 match_parent 或者明确值, 如 35dp,35px.
说明: ImageView 不明确设定大小, 而采用 wrap_content, 则产生严重的屏幕适配问题.
4.3.3 控件中使用 background 属性, 且值引用图片, 则控件必须明确控制其大小, 除非是适应屏幕宽或高, 即只能使用 match_parent 或者明确值, 如 35dp,35px.
说明: 不明确设定大小, 而采用 wrap_content, 则产生严重的屏幕适配问题.
4.3.4 控件设定明确的值大小, 必须引用项目框架提供的值.
说明: 不引用项目提供的数据值, 而使用自己设定的值如 30sp,30dp,30px 等, 则产生严重的屏幕适配问题.
4.3.5 可以灵活使用控件, 如 TextView 可以当做 Button 来使用.
来源: http://www.bubuko.com/infodetail-2548976.html