Android（一）开发规范
1 前言
1.1 为什么需要开发规范
1.基本一个软件生命周期四分之三以上的时间都用于维护。
2.商业项目开发和自己写着玩不一样，基本上没有什么软件整个生命周期都是最初的开发者维护。
3.增加代码可读性，新的开发人员入手简单。
4.方便团队协同合作
5.方便自己维护开发
1.2 开发规范的作用
1.减少维护成本
2.提高可读性
3.加快工作交接
4.减少名字的增生
5.减低缺陷引入机会
6.有利于团队多人开发
1.3 目前有哪些规范
## 1. 阿里云规范
## 2. google规范
33 3. ...
2 命名规范
2.1 常量命名规范
2.1.1 说明
常量用于保存需要常驻内存中并经常使用的数据，定义常量名称需要参照以下的原则。
2.1.2 原则
1.名称全为大写
2.单词之间使用 _ （下划线）连接
3.望文知意原则
2.2 变量命名规范
2.2.1 说明
变量用于保存系统中临时数据，变量命名需参照一下原则。
2.2.2 原则
1.首字母小写
2.JAVA驼峰命名
3.望文知意原则
4.推荐引用变量类型添加前缀“m”
5.如果是View组件变量，则组件命名则是xml中控件id去掉下划线，并且下划线后一位字母大写。
2.3 方法命名规范
2.3.1 说明
方法命名应该遵从简单明了原则。
2.3.2 原则
1.首字母小写
2.JAVA驼峰命名
3.望文知意原则
4.简单明了原则
5.方法里代码不易过长，逻辑代码太长可以拆分多个方法
6.尽量抽取公用方法，提高代码复用率，降低重复和累赘
2.4 类名命名规范
2.4.1 说明
类的命名应该遵从望文知意原则，表达出一个类的作用。
2.4.2 原则
1.首字母大写
2.JAVA驼峰命名
3.望文知意原则
4.需要在类名上加上类生成时间、生成者、类的作用和简介的注释
5.Activity类应以Activity结尾
6.Fragment类应以Fragment结尾
7.Service类应以Service结尾
8.BroadcastReceiver应以Receiver结尾
9.ContentProvider类应以Provider结尾
10.Application类应以Application结尾
11.自定义View应以View结尾
12.自定义Adapter应以Adapter结尾
13.Adapter中自定义Holder应以Holder结尾
14.重写View应以重写之前View为结尾（视情况而定）
15.工具类应以Utils结尾
16.帮助类应以Helper结尾
17.管理类应以Manager结尾
18.实现了应以Impl结尾
19....
2.5 接口命名规范
2.5.1 说明
接口命名应该简洁明了，不宜过长。
2.5.2 原则
1.首字母大写
2.JAVA驼峰命名
3.望文知意原则
4.简单明了原则
5.可以在接口前面带一个“I”，也就是前面两个字母大写。
2.6 包名命名规范
2.6.1 说明
用于分类，管理类的文件夹。遵从简单明了原则。
2.6.2 原则
1.所有字母小写
2.分层级，不能拼接
3.望文知意原则
4.简单明了原则
5.按功能需求划分，例如：工具类可以划分一个utils包名
6.一般Activity类划分在activity包，同理Fragment也是一样。
2.7 目录命名规范
2.7.1 说明
主要存放一些json、so、jar等文件
2.6.2 原则
1.所有字母小写
2.分层级，不能拼接
3.望文知意原则
4.简单明了原则
5.jar一般存放在libs，组件化模块化开发也可以单独拎出来。so也是一样。
2.8 布局控件ID命名规范
2.8.1 说明
一般是XML文件中控件id命名参照以下原则。
2.8.2 原则
1.所有字母小写
2.单词之间使用_（下划线）分隔
3.望文知意原则
4.简单明了原则
5.开头一般是控件简写，例如：TextView简写tv，ImageView简写iv、EditText简写et
2.9 资源文件命名规范
2.9.1 说明
一般是XML文件中控件id命名参照以下原则。
2.9.2 原则
1.所有字母小写
2.单词之间使用_（下划线）分隔
3.望文知意原则
4.简单明了原则
5.drawable开头一般是资源类型，例如：shape、item、sel等
6.activity和fragment分别以activity和fragment开头。
7.自定义View命名一般都是父类名大写字母前面带下划线，变成小写，开头字母不用带下划线。
8.dialog布局文件一般以dialog开头
3. 注释规范
3.1 类注释
在类、接口定义之前当对其进行注释，包括类、接口的目的、作用、功能、继承于何种父类，实现的接口、实现的算法、使用方法、示例程序等。
/**
* Description: desc
* Created by author on yyyy/MM/dd
*
* @author author
*/3.2 方法注释
在方法定义之后对其进行注释，包括方法的目的、作用、功能、使用方法、示例程序、传入的参数说明、返回值类型说明、异常说明等。
/**
* desc:描述
* @param 参数名 参数描述
* @param 参数名2 参数描述
* @return 返回值类型说明
* @throws Exception 异常说明
*/3.3 类成员变量和常量注释
一般常量都会进行注释，变量和常量注释位于其之上。
/**
* 描述
**/ 3.4 内部逻辑注释
内部逻辑注释一般是单行注释或多行注释，注释在需要注释逻辑代码之上。不能注释在代码后面。
//成功
/*失败*/4. 代码顺序
/**
* Description: desc
* Created by author on yyyy/MM/dd
*
* @author author
*/
public class Class {
// （1）成员常量集合
// （2）成员变量集合
// （3）回调方法集合
// （4）生命周期集合
// （5）其他方法集合
}5. 代码风格
5.1 大括号换行
左大括号不换行，右大括号换行；
class ClassName {
private void fun() {
if (...) {
// ...
} else if (...) {
// ...
} else {
// ...
}
}
}5.2 小括号空格
if (...) {
...
} 5.3 行代码长度
1. 一行代码不易过长，不宜超过100个字符。除以下情况：
（1）注释
（2）import
这里限制主要是需要阅读的代码，例如：逻辑代码等。
5.4 声明变量
1. 一般一行只声明一个变量。
2. 方便注释
3. 简介干净，不显得臃肿。
5.5 if-else语句
1. if后面一定带{}，哪怕只有一行代码，这样可以减少格式错误。
2. 参照5.1和5.25.6 for语句
1. 当在for语句的初始化或更新子句中使用逗号时，避免因使用三个以上变量，而导致复杂度提高。
2. 若需要，可以在for循环之前(为初始化子句)或for循环末尾(为更新子句）使用单独的语句。
5.7 while语句
1. 与只有if语句类似，只是把if改成while，其他格式不变。
while (condition) {
statements;
}5.8 do-while语句
do {
statements;
} while (condition);5.10 switch语句
1. 每当一个case顺着往下执行时（因为没有break语句），通常应在break语句的位置添加注释。
2. 都要一个default，哪怕你现在不用。
switch (condition) {
case A:
...
/* falls through */
case B:
...
break;
case C:
....
break;
default:
....
break;
}6. 异常命名规范
6.1 异常名称规范
定义异常的时候，异常后缀以Exception结尾
6.2 try-catch语句
try {
statements;
} catch (ExceptionClass e) {
statements;
}6.3 try-catch-finally语句
try {
statements;
} catch (ExceptionClass e) {
statements;
} finally {
statements;
}7 其他
7.1 使用TODO注释
1. 对那些临时性的、短期的、够棒但不完美的代码，请使用 TODO 注释。
2. TODO 注释应该包含全部大写的 TODO，后跟一个冒号：
// TODO: Do something7.2 线程使用
1. 尽量多使用线程池，少用裸露的线程。
2. 复杂定时线程少用Timer线程，可以使用线程池。
3. 具体详情可以参考阿里云命名规则和google命名规则。
7.3 Log的使用
1. 尽量多使用自定义Log，避免正式环境打印log影响性能。
后续如果有新的再补充....
