为了利于项目维护以及规范开发，促进成员之间Code Review的效率，故提出以下开发规范，如有更好建议，欢迎到GitHub提issue，原文地址: [安卓开发规范(updating)][安卓开发规范(updating)]

工欲善其事，必先利其器。

1. 尽量使用最新版的IDE进行开发；

2. 编码格式统一为**UTF-8**；

4. 删除多余的import，减少警告出现，可利用AS的`Optimize Imports`快捷键；

5. AS常用开发插件可以参考这里～[AS常用开发插件][AS常用开发插件]

包名全部小写，连续的单词只是简单地连接起来，不使用下划线。

| 包名 | 此包中包含 |

| :--------------------------------------- | :----------------------------- |

| com.xx.应用名称缩写.view (或者 com.xx.应用名称缩写.widget ) | 自定义的View类等 |

| com.xx.应用名称缩写.service | Service服务 |

| com.xx.应用名称缩写.receiver | BroadcastReceiver服务 |

类名都以`UpperCamelCase`风格编写。

类名通常是名词或名词短语，接口名称有时可能是形容词或形容词短语。现在还没有特定的规则或行之有效的约定来命名注解类型。

名词，采用大驼峰命名法，尽量避免缩写，除非该缩写是众所周知的， 比如HTML,URL，如果类名称中包含单词缩写，则单词缩写的每个字母均应大写。

测试类的命名以它要测试的类的名称开始，以Test结束。例如：HashTest 或 HashIntegrationTest。

方法名都以`lowerCamelCase`风格编写。

| resetXX() | 重置数据 |

| clearXX() | 清除数据 |

| removeXX() | 移除数据或者视图等，如removeView(); |

常量名命名模式为`CONSTANT_CASE`，全部字母大写，用下划线分隔单词。那，到底什么算是一个常量？

static final Joiner COMMA_JOINER = Joiner.on(','); // because Joiner is immutable

static final SomeMutableType[] EMPTY_ARRAY = {};

enum SomeEnum { ENUM_CONSTANT }

static String nonFinal = "non-final";

final String nonStatic = "non-static";

非常量字段名以`lowerCamelCase`风格的基础上改造为如下风格：基本结构为`scopeVariableNameType`。

参数名以`lowerCamelCase`风格编写。

参数应该避免用单个字符命名。

局部变量名以`lowerCamelCase`风格编写，比起其它类型的名称，局部变量名可以有更为宽松的缩写。

即使局部变量是final和不可改变的，也不应该把它示为常量，自然也不能用常量的规则去命名它。

临时变量通常被取名为i，j，k，m和n，它们一般用于整型；c，d，e，它们一般用于字符型。 如： for (int i = 0; i < len ; i++)。

类型变量可用以下两种风格之一进行命名：

单个的大写字母，后面可以跟一个数字(如：E, T, X, T2)。

更多还可参考～[阿里巴巴Java开发手册][阿里巴巴Java开发手册]

全部小写，采用下划线命名法

必须以全部单词小写，单词间以下划线分割，使用名词或名词词组。

例如：`activity_main.xml`

例如：`dialog_hint.xml`

例如：`ppw_info.xml`

例如：`item_city.xml`

例如：`activity_main_head.xml`、`activity_main_bottom.xml`

例如：`xxxx_title.xml`

全部小写，采用下划线命名法，加前缀区分

全部小写，采用下划线命名法，加前缀区分。

| `shrink_to_middle` | 中间缩小 |

colors的name命名使用下划线命名法，在你的`colors.xml`文件中应该只是映射颜色的名称一个ARGB值，而没有其它的。不要使用它为不同的按钮来定义ARGB值。

``` xml

<resources>

<color name="comment_shadow">#323232</color>

``` xml

<resources>

向应用设计者那里要这个调色板，名称不需要跟"green", "blue", 等等相同。 "brand_primary", "brand_secondary", "brand_negative" 这样的名字也是完全可以接受的。 像这样规范的颜色很容易修改或重构，会使应用一共使用了多少种不同的颜色变得非常清晰。 通常一个具有审美价值的UI来说，减少使用颜色的种类是非常重要的。

像对待colors.xml一样对待dimens.xml文件 与定义颜色调色板一样，你同时也应该定义一个空隙间隔和字体大小的“调色板”。 一个好的例子，如下所示：

布局时在写 margins 和 paddings 时，你应该使用spacing_xxxx尺寸格式来布局，而不是像对待String字符串一样直接写值。 这样写会非常有感觉，会使组织和改变风格或布局是非常容易。

strings的name命名使用下划线命名法，采用以下规则：模块名+逻辑名称

`loading` 加载文字

几乎每个项目都需要适当的使用style文件，因为对于一个视图来说有一个重复的外观是很常见的，将所有的外观细节属性（colors, padding, font）放在style文件中。 在应用中对于大多数文本内容，最起码你应该有一个通用的style文件，例如：

**将一个大的style文件分割成多个文件**， 你可以有多个`styles.xml` 文件。Android SDK支持其它文件，`styles`这个文件名称并没有作用，起作用的是在文件 里xml的`<style>`标签。因此你可以有多个style文件`styles.xml`,`style_home.xml`,`style_item_details.xml`,`styles_forms.xml`。 不同于资源文件路径需要为系统构建起的有意义，在`res/values`目录下的文件可以任意命名。

命名模式为：`view缩写_模块名_逻辑名`，比如btn_main_search

使用 AndroidStudio 的插件 ButterKnife Zelezny，生成注解非常方便，或者也可以使用Android Code Generator插件。

如果想对资源文件进行分包可以参考我这篇文章～[Android Studio下对资源进行分包][Android Studio下对资源进行分包]

Android开发存在着众多版本的不同，比如compileSdkVersion、minSdkVersion、targetSdkVersion以及项目中依赖第三方库的版本，不同的module及不同的开发人员都有不同的版本，所以需要一个统一版本规范的文件。

具体可以参考我写的这篇博文～[Android开发之版本统一规范][Android开发之版本统一规范]

别再闭门造车了，用用最新最火的技术吧，安利一波～[Android 流行框架查速表][Android 流行框架查速表]，顺便带上自己的干货～[Android开发人员不得不收集的代码][Android开发人员不得不收集的代码]

个人推荐team使用Retrofit, RxAndroid, OkHttp, Glide/Fresco, Gson/Fastjson, EventBus/AndroidEventBus, GreenDao,(Dagger2, Tinker)。

为了让他人可以容易看懂你的代码，请在关键地方做好注释。

每个类完成后应该有作者姓名和联系方式的注释，对自己的代码负责。

具体可以在AS中自己配制，Setting → Editor → File and Code Templates → Includes → File Header，输入

这样便可在每次新建类的时候自动加上该注释。

每一个成员方法（包括自定义成员方法、覆盖方法、属性方法）的方法头都必须做方法头注释，在方法前一行输入/\*\*回车，AS便会帮你生成模板，我们只需要补全参数即可，如下所示。

}

块注释与其周围的代码在同一缩进级别。它们可以是`/* ... */`风格，也可以是`// ...`风格(**// 后最好带一个空格**）。对于多行的`/* ... */`注释，后续行必须从`*`开始， 并且与前一行的`*`对齐。以下示例注释都是OK的。

业务开发完成之后，开发人员做单元测试，单元测试完成之后，保证单元测试全部通过同时单元测试代码覆盖率达到一定程度（这个需要开发和测试约定，理论上越高越好），开发提测。

// TODO...

// TODO...

1. 合理布局，有效运用`<merge>`, `<ViewStub>`, `<include>`标签

2. 相关联的方法尽量放在一起