1. 前言
   为了有利于项目维护、增强代码可读性、提升 Code Review 效率以及规范团队安卓开发，故提出以下安卓开发规范。

2. Android Studio 规范
   尽量使用最新的稳定版 Android Studio 进行开发；
   编码格式统一为 UTF-8；
   编辑完 .java、.xml 等文件后一定要 格式化，格式化，格式化（如果团队有公共的样式包，那就遵循它，否则统一使用 AS 默认模板即可，在 Android Studio 中，
   Mac 下可以使用快捷键 cmd + alt + L 进行代码格式化，
   Window 下可以使用快捷键 ctrl + alt + L 进行代码格式化）；
   删除多余的 import，减少警告出现，
   Mac 下可以使用快捷键 ctrl + alt + O 进行 import 优化，
   Window 下可以使用快捷键 ctrl + alt + O 进行 import 优化；

3. 命名规范
   代码中的命名严禁使用拼音与英文混合的方式，更不允许直接使用中文的方式。正确的英文拼写和语法可以让阅读者易于理解，避免歧义。

注意：即使纯拼音命名方式也要避免采用。但 alibaba、taobao、youku、hangzhou 等国际通用的名称，可视同英文。

3.1 包名
包名全部小写，连续的单词只是简单地连接起来，不使用下划线，采用反域名命名规则，全部使用小写字母。一级包名是顶级域名，通常为 com、edu、gov、net、org 等，二级包名为公司名，三级包名根据应用进行命名，后面就是对包名的划分了，关于包名的划分，推荐采用 PBF（按功能分包 Package By Feature）。

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

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

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

接口（interface）：命名规则与类一样采用大驼峰命名法，多以 able 或 ible 结尾，如 interface Runnable、interface Accessible；或者以 I 为前缀。

fix：这里是否需要注明使用组件化时，组件对外提供的接口和实现类命名。

补充：表格中放不下，特意放在下面。上面提到工具类以 Util 和 Tool 为后缀，那么 Util 和 Tool 的区别是什么？Util 是无业务逻辑的，Tool 是有业务逻辑的。比如 HttpUtil 只是包含了基本网络请求，而 HttpTool 中包含了项目的一些配置，如在每个请求增加 token 。也可以这么说，HttpUtil 可以跨项目使用，而 HttpTool 只能在该项目中使用。

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

方法名通常是动词或动词短语。

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

每个常量都是一个 static final 字段，但不是所有 static final 字段都是常量。在决定一个字段是否是一个常量时，得考虑它是否真的感觉像是一个常量。例如，如果观测任何一个该实例的状态是可变的，则它几乎肯定不会是一个常量。只是永远不打算改变的对象一般是不够的，它要真的一直不变才能将它示为常量。

// Constants
static final int NUMBER = 5;
static final ImmutableListNAMES = ImmutableList.of("Ed", "Ann");
static final Joiner COMMA_JOINER = Joiner.on(','); // because Joiner is immutable
static final SomeMutableType[] EMPTY_ARRAY = {};
enum SomeEnum { ENUM_CONSTANT }

// Not constants
static String nonFinal = "non-final";
final String nonStatic = "non-static";
static final SetmutableCollection = new HashSet();
static final ImmutableSetmutableElements = ImmutableSet.of(mutable);
static final Logger logger = Logger.getLogger(MyClass.getName());
static final String[] nonEmptyArray = {"these", "can", "change"};

3.5 非常量字段名
非常量字段名以 lowerCamelCase 风格的基础上改造为如下风格：基本结构为 scope{Type0}VariableName{Type1}、type0VariableName{Type1}、variableName{Type1}。

说明：{} 中的内容为可选。
**
注意：所有的 VO（值对象）统一采用标准的 lowerCamelCase 风格编写，所有的 DTO（数据传输对象）就按照接口文档中定义的字段名编写。
**
3.5.1 scope（范围）
非公有，非静态字段命名以 m 开头。

静态字段命名以 s 开头。

其他字段以小写字母开头。

例如：

public class MyClass {
    public int publicField;
    private static MyClass sSingleton;
    int mPackagePrivate;
    private int mPrivate;
    protected int mProtected;
}

使用 1 个字符前缀来表示作用范围，1 个字符的前缀必须小写，前缀后面是由表意性强的一个单词或多个单词组成的名字，而且每个单词的首写字母大写，其它字母小写，这样保证了对变量名能够进行正确的断句。

通过IDE 自动生成get 、set 和构造函数的时候，这个没有任何实际意义的m前缀会被包含到变量名称当中去，显得很low也很容易影响可读性。在 AS 中，Settings -> Editor -> Code Style -> Java -> Code Generation 中，Field Name prefix 设置 m，Static Field Name prefix 设置 s。这样 AS 就可以识别了，自动生成方法的时候会去掉 s 或 m。

3.5.2 Type0（控件类型）
考虑到 Android 众多的 UI 控件，为避免控件和普通成员变量混淆以及更好地表达意思，所有用来表示控件的成员变量统一加上控件缩写作为前缀（具体见附录 [UI 控件缩写表](#UI 控件缩写表)）。

例如：mIvAvatar、rvBooks、flContainer。

3.5.3 VariableName（变量名）
变量名中可能会出现量词，我们需要创建统一的量词，它们更容易理解，也更容易搜索。

例如：mFirstBook、mPreBook、curBook。

3.5.4 Type1（数据类型）
对于表示集合或者数组的非常量字段名，我们可以添加后缀来增强字段的可读性，比如：

集合添加如下后缀：List、Map、Set。

数组添加如下后缀：Arr。

例如：mIvAvatarList、userArr、firstNameSet。

注意：如果数据类型不确定的话，比如表示的是很多书，那么使用其复数形式来表示也可，例如 mBooks。

3.6 参数名
参数名以 lowerCamelCase 风格编写，参数应该避免用单个字符命名。

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

虽然缩写更宽松，但还是要避免用单字符进行命名，除了临时变量和循环变量。

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

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

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

单个的大写字母，后面可以跟一个数字（如：E, T, X, T2）。
以类命名方式（参考[3.2 类名](#3.2 类名)），后面加个大写的 T（如：RequestT, FooBarT）。

4. 代码样式规范
   4.1 使用标准大括号样式
   左大括号不单独占一行，与其前面的代码位于同一行：

class MyClass {
    int func() {
        if (something) {
            // ...
        } else if (somethingElse) {
            // ...
        } else {
            // ...
        }
    }
}

我们需要在条件语句周围添加大括号。例外情况：如果整个条件语句（条件和主体）适合放在同一行，那么您可以（但不是必须）将其全部放在一行上。例如，我们接受以下样式：

if (condition) {
body();
}
1
2
3
同样也接受以下样式：

if (condition) body();

但不接受以下样式：

if (condition)
    body();  // bad!

4.2 编写简短方法
在可行的情况下，尽量编写短小精炼的方法。有些情况下较长的方法是恰当的，因此对方法的代码长度没有做出硬性限制。如果某个方法的代码超出 40 行，请考虑是否可以在不破坏程序结构的前提下对其拆解，一个方法最好只做一件事情。

4.3 类成员的顺序
这并没有唯一的正确解决方案，但如果都使用一致的顺序将会提高代码的可读性，推荐使用如下排序：

1.常量
2.字段（public -> protected -> private）
3.构造函数
4.重写函数和回调 （在Android 中，应该将生命周期的函数放在前面）
5.公有函数
6.私有函数
7.内部类或接口
例如：

public class MainActivity extends Activity {

    private static final String TAG = MainActivity.class.getSimpleName();

    public Long updateTime;
    protected String mContent;
    private String mTitle;
    private TextView mTextViewTitle;

    @Override
    public void onCreate() {
        ...
    }

    public void setTitle(String title) {
        mTitle = title;
    }

    private void setUpView() {
        ...
    }

    static class AnInnerClass {

    }
}

如果类继承于 Android 组件（例如 Activity 或 Fragment），那么把重写函数按照他们的生命周期进行排序是一个非常好的习惯，例如，Activity 实现了 onCreate()、onDestroy()、onPause()、onResume()，它的正确排序如下所示：

public class MainActivity extends Activity {
    //Order matches Activity lifecycle
    @Override
    public void onCreate() {}

    @Override
    public void onResume() {}

    @Override
    public void onPause() {}

    @Override
    public void onDestroy() {}
}

4.4 函数参数的排序
在 Android 开发过程中，Context 在函数参数中是再常见不过的了，我们最好把 Context 作为其第一个参数。

正相反，我们把回调接口应该作为其最后一个参数。

例如：

// Context always goes first
public User loadUser(Context context, int userId);

// Callbacks always go last
public void loadUserAsync(Context context, int userId, UserCallback callback);

4.5 字符串常量的命名和值
Android SDK 中的很多类都用到了键值对函数，比如 SharedPreferences、Bundle、Intent，所以，即便是一个小应用，我们最终也不得不编写大量的字符串常量。

当时用到这些类的时候，我们 必须 将它们的键定义为 static final 字段，并遵循以下指示作为前缀。

说明：虽然 Fragment.getArguments() 得到的也是 Bundle ，但因为这是 Bundle 的常用用法，所以特意为此定义一个不同的前缀。

例如：

// 注意：字段的值与名称相同以避免重复问题
static final String PREF_EMAIL = "PREF_EMAIL";
static final String BUNDLE_AGE = "BUNDLE_AGE";
static final String ARGUMENT_USER_ID = "ARGUMENT_USER_ID";

// 与意图相关的项使用完整的包名作为值的前缀
static final String EXTRA_SURNAME = "com.myapp.extras.EXTRA_SURNAME";
static final String ACTION_OPEN_USER = "com.myapp.action.ACTION_OPEN_USER";

4.6 Activities 和 Fragments 的传参
当 Activity 或 Fragment 传递数据通过 Intent 或 Bundle 时，不同值的键须遵循上一条所提及到的。

当 Activity 或 Fragment 启动需要传递参数时，那么它需要提供一个 public static 的函数来帮助启动或创建它。

这方面，AS 已帮你写好了相关的 Live Templates（只支持Java，不支持Kotlin），启动相关 Activity 的只需要在其内部输入 starter 即可生成它的启动器，如下所示：

public static void start(Context context, User user) {
      Intent starter = new Intent(context, MainActivity.class);
      starter.putParcelableExtra(EXTRA_USER, user);
      context.startActivity(starter);
}

同理，启动相关 Fragment 在其内部输入 newInstance 即可，如下所示：

public static MainFragment newInstance(User user) {
      Bundle args = new Bundle();
      args.putParcelable(ARGUMENT_USER, user);
      MainFragment fragment = new MainFragment();
      fragment.setArguments(args);
      return fragment;
}

注意：这些函数需要放在 onCreate() 之前的类的顶部；如果我们使用了这种方式，那么 extras 和 arguments 的键应该是 private 的，因为它们不再需要暴露给其他类来使用。

4.7 行长限制
代码中每一行文本的长度都应该不超过 100 个字符。虽然关于此规则存在很多争论，但最终决定仍是以 100 个字符为上限，如果行长超过了 100（AS 窗口右侧的竖线就是设置的行宽末尾 ），我们通常有两种方法来缩减行长。

提取一个局部变量或方法（最好）。
使用换行符将一行换成多行。
不过存在以下例外情况：

如果备注行包含长度超过 100 个字符的示例命令或文字网址，那么为了便于剪切和粘贴，该行可以超过 100 个字符。
导入语句行可以超出此限制，因为用户很少会看到它们（这也简化了工具编写流程）。
4.7.1 换行策略
这没有一个准确的解决方案来决定如何换行，通常不同的解决方案都是有效的，但是有一些规则可以应用于常见的情况。

4.7.2 操作符的换行
除赋值操作符之外，我们把换行符放在操作符之前，例如：

int longName = anotherVeryLongVariable + anEvenLongerOne - thisRidiculousLongOne
        + theFinalOne;

赋值操作符的换行我们放在其后，例如：

int longName =
        anotherVeryLongVariable + anEvenLongerOne - thisRidiculousLongOne + theFinalOne;

4.7.3 函数链的换行
当同一行中调用多个函数时（比如使用构建器时），对每个函数的调用应该在新的一行中，我们把换行符插入在 . 之前。

例如：

Picasso.with(context).load("https://blankj.com/images/avatar.jpg").into(ivAvatar);

我们应该使用如下规则：

Picasso.with(context)
        .load("https://blankj.com/images/avatar.jpg")
        .into(ivAvatar);

4.7.4 多参数的换行
当一个方法有很多参数或者参数很长的时候，我们应该在每个 , 后面进行换行。

比如：

loadPicture(context, "https://blankj.com/images/avatar.jpg", ivAvatar, "Avatar of the user", clickListener);

我们应该使用如下规则：

loadPicture(context,
        "https://blankj.com/images/avatar.jpg",
        ivAvatar,
        "Avatar of the user",
        clickListener);

4.7.5 RxJava 链式的换行
RxJava 的每个操作符都需要换新行，并且把换行符插入在 . 之前。

例如：

public Observable<Location> syncLocations() {
    return mDatabaseHelper.getAllLocations()
            .concatMap(new Func1<Location, Observable<? extends Location>>() {
                @Override
                 public Observable<? extends Location> call(Location location) {
                     return mRetrofitService.getLocation(location.id);
                 }
            })
            .retry(new Func2<Integer, Throwable, Boolean>() {
                 @Override
                 public Boolean call(Integer numRetries, Throwable throwable) {
                     return throwable instanceof RetrofitError;
                 }
            });
}

5. 资源文件规范
   资源文件命名为全部小写，采用下划线命名法。

如果是三方库开发，其使用到的资源文件及相关的 name 都应该使用库名作为前缀，这样做可以避免三方库资源和实际应用资源重名的冲突。

如果想对资源文件进行分包，可以

5.1 动画资源文件（anim/ 和 animator/）
安卓主要包含属性动画和视图动画，其视图动画包括补间动画和逐帧动画。属性动画文件需要放在 res/animator/ 目录下，视图动画文件需放在 res/anim/ 目录下。

命名规则：{模块名_}逻辑名称。

说明：{} 中的内容为可选，逻辑名称 可由多个单词加下划线组成。

例如：refresh_progress.xml、market_cart_add.xml、market_cart_remove.xml。

如果是普通的补间动画或者属性动画，可采用：动画类型_方向 的命名方式。

例如：

5.2 颜色资源文件（color/）
专门存放颜色相关的资源文件。

命名规则：类型{模块名}逻辑名称。

说明：{} 中的内容为可选。

例如：sel_btn_font.xml。

颜色资源也可以放于 res/drawable/ 目录，引用时则用 @drawable 来引用，但不推荐这么做，最好还是把两者分开。

5.3 图片资源文件（drawable/ 和 mipmap/）
res/drawable/ 目录下放的是位图文件（.png、.9.png、.jpg、.gif）或编译为可绘制对象资源子类型的 XML 文件，而 res/mipmap/ 目录下放的是不同密度的启动图标，所以 res/mipmap/ 只用于存放启动图标，其余图片资源文件都应该放到 res/drawable/ 目录下。

命名规则：类型{模块名}逻辑名称、类型{模块名}颜色。

说明：{} 中的内容为可选；类型 可以是可绘制对象资源类型，也可以是控件类型（具体见附录[UI 控件缩写表](#UI 控件缩写表)）；最后可加后缀 _small 表示小图，_big 表示大图。

例如：

如果有多种形态，如按钮选择器：sel_btn_xx.xml，采用如下命名：

注意：使用 Android Studio 的插件 SelectorChapek 可以快速生成 selector，前提是命名要规范。

5.3.1 图片位置
大分辨率图片（单维度超过 1000）大分辨率图片建议统一放在 xxhdpi 目录
下管理，否则将导致占用内存成倍数增加 。

正例：

将 144144 的应用图标 PNG 文件放在 drawable-xxhdpi 目录
反例：
将 144144 的应用图标 PNG 文件放在 drawable-mhdpi 目录

5.4 布局资源文件（layout/）
命名规则：类型模块名、类型{模块名}_逻辑名称。

说明：{} 中的内容为可选。

例如：

5.5 菜单资源文件（menu/）
菜单相关的资源文件应放在该目录下。

命名规则：{模块名_}逻辑名称

说明：{} 中的内容为可选。

例如：main_drawer.xml、navigation.xml。

5.6 values 资源文件（values/）
values/ 资源文件下的文件都以 s 结尾，如 attrs.xml、colors.xml、dimens.xml，起作用的不是文件名称，而是 <resources> 标签下的各种标签，比如 <style> 决定样式，<color> 决定颜色，所以，可以把一个大的 xml 文件分割成多个小的文件，比如可以有多个 style 文件，如 styles.xml、styles_home.xml、styles_item_details.xml、styles_forms.xml。

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

例如，不要像下面这样做：

  <resources>
      <color name="button_foreground">#FFFFFF</color>
      <color name="button_background">#2A91BD</color>
      <color name="comment_background_inactive">#5F5F5F</color>
      <color name="comment_background_active">#939393</color>
      <color name="comment_foreground">#FFFFFF</color>
      <color name="comment_foreground_important">#FF9D2F</color>
      ...
      <color name="comment_shadow">#323232</color>

使用这种格式，会非常容易重复定义 ARGB 值，而且如果应用要改变基色的话会非常困难。同时，这些定义是跟一些环境关联起来的，如 button 或者 comment，应该放到一个按钮风格中，而不是在 colors.xml 文件中。

相反，应该这样做：

  <resources>

      <!-- grayscale -->
      <color name="white"     >#FFFFFF</color>
      <color name="gray_light">#DBDBDB</color>
      <color name="gray"      >#939393</color>
      <color name="gray_dark" >#5F5F5F</color>
      <color name="black"     >#323232</color>

      <!-- basic colors -->
      <color name="green">#27D34D</color>
      <color name="blue">#2A91BD</color>
      <color name="orange">#FF9D2F</color>
      <color name="red">#FF432F</color>

  </resources> 

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

注意：如果某些颜色和主题有关，那就单独写一个 colors_theme.xml。

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

<resources>

    <!-- font sizes -->
    <dimen name="font_22">22sp</dimen>
    <dimen name="font_18">18sp</dimen>
    <dimen name="font_15">15sp</dimen>
    <dimen name="font_12">12sp</dimen>

    <!-- typical spacing between two views -->
    <dimen name="spacing_40">40dp</dimen>
    <dimen name="spacing_24">24dp</dimen>
    <dimen name="spacing_14">14dp</dimen>
    <dimen name="spacing_10">10dp</dimen>
    <dimen name="spacing_4">4dp</dimen>

    <!-- typical sizes of views -->
    <dimen name="button_height_60">60dp</dimen>
    <dimen name="button_height_40">40dp</dimen>
    <dimen name="button_height_32">32dp</dimen>

</resources>

布局时在写 margins 和 paddings 时，你应该使用 spacing_xx 尺寸格式来布局，而不是像对待 string 字符串一样直接写值，像这样规范的尺寸很容易修改或重构，会使应用所有用到的尺寸一目了然。 这样写会非常有感觉，会使组织和改变风格或布局非常容易。

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

<style name="ContentText">
    <item name="android:textSize">@dimen/font_normal</item>
    <item name="android:textColor">@color/basic_black</item>
</style>

应用到 TextView 中：

<TextView
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="@string/price"
    style="@style/ContentText"/>

或许你需要为按钮控件做同样的事情，不要停止在那里，将一组相关的和重复 android:xxxx 的属性放到一个通用的 <style>中。

5.7 id 命名
5.7.1 java项目
命名规则：view 缩写{模块名}逻辑名，例如： btn_main_search、btn_back。

如果在项目中有用黄油刀的话，使用 AS 的插件：ButterKnife Zelezny，可以非常方便帮助你生成注解；没用黄油刀的话可以使用 Android Code Generator 插件。

5.7.2 kotlin项目
插件 apply plugin: 'kotlin-android-extensions'，可以在代码中通过 xml 定义的控件 id 直接操作控件，而不用写 findViewById ，所以这里控件的命名直接使用 lowerCamelCase 风格编写。

命名规则：view 缩写{模块名}逻辑名，例如： btnMainSearch、btnBack。

6. 注释规范
   6.1 类注释
   每个类完成后应该有作者姓名的注释，对自己的代码负责。

/**
 * <pre>
 *     author : Blankj
 *     time   : 2017/03/07
 *     desc   : xxxx 描述
 *     version: 1.0
 * </pre>
 */
public class WelcomeActivity {
    ...
}

具体可以在 AS 中自己配制，进入 Settings -> Editor -> File and Code Templates -> Includes -> File Header，输入

/**
 * <pre>
 *     author : ${USER}
 *     time   : ${YEAR}/${MONTH}/${DAY}
 *     desc   :
 *     version: 1.0
 * </pre>
 */

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

6.2 函数的注释
类成员变量、公有和保护方法必须需要写注释，写在被注释元素的上面，并与其上的代码用空行隔开，注释与所描述内容进行同样的缩进排序。

私有变量必须写注释，私有方法，如果方法命名能清晰的表达方法的功能，不需要写注释。

公有和保护方法注释需要列出方法的一句话功能简述、功能详细描述、输入参数、输出参数、返回值、异常等。

对于方法内部用 throw 语句抛出的异常，必须在方法的注释中标明，对于所调用的其他方法所抛出的异常，选择主要的在注释中说明。用 @exception 标注 Runtime 异常，@throws 标注非 Runtime 异常。异常的注释必须说明该异常的含义和什么条件下抛出该异常。

格式如下：

/**
 * 一句话功能描述
 * 功能详细描述
 * @param [参数1] [参数1说明] 
 * @param [参数2] [参数2说明] 
 * @return [返回类型说明]
 * @exception/throws [异常类型] [异常说明] 
 * @see [类、类#方法、类#成员]
 * @since [起始版本]
 * @deprecated [是否废弃] 
 */

6.3 代码块注释
写出代码的目的，而不是行为，行为可以通过具体的代码来判断。

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

可以在项目根目录下 build.gradle文件中增加一个：

ext {
    compile_sdk_version = 27
    min_sdk_version = 16
    target_sdk_version = 27
    support_version = '27.1.1'
}

或者新建一个 config.gradle 文件，将上面的代码放在其中，在项目根目录下 build.gradle文件顶部增加 apply from: "config.gradle"

在 module 的 build.gradle 中引用：

android {
    compileSdkVersion compile_sdk_version
    defaultConfig {
        minSdkVersion min_sdk_version
        targetSdkVersion target_sdk_version
    }
}

dependencies {
    Implementation "com.android.support:appcompat-v7:$support_version"
    Implementation "com.android.support:support-v4:$support_version"
}

8. 第三方库规范
   对开源库的选取，一般都需要选择比较稳定的版本，作者在维护的项目，要考虑作者对 issue 的解决，以及开发者的知名度等各方面。选取之后，一定的封装是必要的。

如下优秀轮子：

Retrofit
RxAndroid
OkHttp
Glide/Fresco
Gson/Fastjson
EventBus/AndroidEventBus

9. 项目规范
   9.1 UI
   使用 start 和 end 替代 left 和 right，使布局能适应 RightRoLeft布局。
   FrameLayout 默认是左上，切换到 RTL 也是左上，所以必须显示的指明布局 android:layout_gravity="start"；
   合理布局，有效运用 <merge>、<ViewStub>、<include> 标签；
   比如content 是一个 FrameLayout ，所以这里简单布局是不需要外层ViewGroup，直接使用 <merge> 来作为布局文件的根ViewGroup就可以了；
   所有布局都需要考虑到大屏幕和小屏幕显示的问题，尤其是对大屏幕一个页面就可以展示完，而对于小屏幕不能展示完，需要增加 <ScrollView> 让页面能够滚动。目前一般情况下最小屏幕是 1280 * 720，如果要考虑极端情况的话，尝试支持 320 * 480 的屏幕。
   字体单位使用 dp 设置字体而不是 sp。
   对于设计图上按钮大小小于 24dp * 24dp，应该使用 padding 将按钮的实际大小控制在大于 24dp * 24dp。
   常见布局只使用 FrameLayout、LinearLayout、FlexboxLayout、ConstraintLayout。
   不要过分依赖通用资源，否则会导致修改困难，该拆分的就拆分，不要在乎资源内容是一样的。
   所有的文本按钮，还是使用 Button，不要使用 TextView ,毕竟系统对 Button 有样式渲染。同理对于图片按钮，应该使用 ImageButton 而不是 ImageView。
   使用Space控件占据不显示内容的空间。
   如果是背景色是白色，那么就不要设置了
   ScrollView 内部嵌套有 ListView 或 RecycleView 等，注意要考虑到ScrollView默认位置不是最顶部的情况。
   考虑过渡绘制，不要直接在整个布局增加背景颜色，考虑是否在布局的一部分设置背景颜色就可以达到UI效果。
   9.2 资源
   9.2.1 文本和颜色不能使用硬编码
   将硬编码的文字和颜色放入资源文件中进行管理，减少定义的颜色，合并类似的，这里如果是使用 Android 系统自带的，全部自己定义，防止出错。

9.2.2 管理资源文件
一个 Module 的资源文件都在 res 目录下，如果一个 Module 涉及到的页面很多，资源文件很多，不方便管理，可以多配置几个资源文件目录，这样我们可以对每个模块的资源都进行具体分类。

方法很简单，配置我们的app文件夹下的 build.gradle 文件，比如：

android {
    ...
    sourceSets {
        main {
            res.srcDirs('src/main/res', 'src/main/res_core', 'src/main/res_sub')
        }
    }
}

配置完之后，sync project 一下就成功了。

9.3 代码规范
1.Android的最小兼容版本到17.

关于Android不同系统版本的市场占比情况详解

2.Activity 和 Fragment 里面有许多重复的操作以及操作步骤，所以我们都需要提供一个 BaseActivity 和 BaseFragment，让所有的 Activity 和 Fragment 都继承这个基类。

3.必须支持界面被系统回收，用户再次打开App的时候能够恢复用户当时的使用状态，分析出具体在哪些情况下需要，哪些情况下不需要。

例如弹窗，恢复弹窗上显示的数据，恢复弹窗的按钮的点击事件。
4.使用Gson中的 @SerializedName 将服务器端返回数据字段不符合命名规范的转换为符合规范的命名，分离服务器和客户端字段的硬绑定。

5.使用ArrayMap、ArraySet、SparseArray替换HashMap<T, T>、HashMap<int, T> 和 HashSet<T>。

6.多用组合，少用继承；

7.方法基本上都按照调用的先后顺序在各自区块中排列；

8.当一个类有多个构造函数，或是多个同名函数，这些函数应该按顺序出现在一起，中间不要放进其它函数；

9.数据提供统一的入口。无论是在 MVP、MVC 还是 MVVM 中，提供一个统一的数据入口，都可以让代码变得更加易于维护。比如可使用一个 DataManager，把 http、preference、eventpost、database 都放在 DataManager 里面进行操作，我们只需要与 DataManager 打交道；

10.提取方法，去除重复代码。对于必要的工具类抽取也很重要，这在以后的项目中是可以重用的。

11.项目引入 RxAndroid 响应式编程，可以极大的减少逻辑代码；

12.通过引入事件总线，如：EventBus、AndroidEventBus、RxBus，它允许我们在 DataLayer 中发送事件，以便 ViewLayer 中的多个组件都能够订阅到这些事件，减少回调；

13.尽可能使用局部变量；

14.及时关闭流；

15.尽量减少对变量的重复计算；

如下面的操作：

for (int i = 0; i < list.size(); i++) {
      ...
}

建议替换为：

for (int i = 0, len = list.size(); i < len; i++) {
      ...
}

尽量采用懒加载的策略，即在需要的时候才创建；

例如：

String str = "aaa";
if (i == 1) {
      list.add(str);
}

建议替换为：

if (i == 1) {
      String str = "aaa";
      list.add(str);
}

不要在循环中使用 try…catch…，应该把其放在最外层；

使用带缓冲的输入输出流进行 IO 操作；

尽量在合适的场合使用单例；

使用单例可以减轻加载的负担、缩短加载的时间、提高加载的效率，但并不是所有地方都适用于单例，简单来说，单例主要适用于以下三个方面：

控制资源的使用，通过线程同步来控制资源的并发访问。
控制实例的产生，以达到节约资源的目的。
控制数据的共享，在不建立直接关联的条件下，让多个不相关的进程或线程之间实现通信。
使用 AS 自带的 Lint 来优化代码结构（右键 module、目录或者文件，选择 Analyze -> Inspect Code）；

内存泄漏的检测；

Kotlin 和 Java 是两种语言，在使用Kotlin的时候应该使用Kotlin中的特性，而不是固执的使用Java特性。比如：对于变量的赋值，如果仅仅是赋值，那么应该直接开放变量权限；如果涉及到一系列后续操作，那么使用方法。

自定义控件的自定义属性，必须使用控件名称作为前缀，否则容易造成同名属性。

不复用字符串，每个组件维护自己的，不要嫌麻烦。

不可不知的 Android strings.xml 那些事

不要通过 Intent 在 Android 基础组件之间传递大数据（binder transaction缓存为 1MB），可能导致 OOM。

新建线程时，必须通过线程池提供（AsyncTask 或者 ThreadPoolExecutor或者其他形式自定义的线程池），不允许在应用中自行显式创建线程 。

子线程中不能更新界面，更新界面必须在主线程中进行，网络操作不能在主线程中调用 。

不要在非 UI 线程中初始化 ViewStub，否则会返回 null。

任何时候不要硬编码文件路径，请使用 Android 文件系统 API 访问。

示例：Android 应用提供内部和外部存储，分别用于存放应用自身数据以及应用产生的用
户数据。可以通过相关 API 接口获取对应的目录，进行文件操作。

android.os.Environment#getExternalStorageDirectory()
android.os.Environment#getExternalStoragePublicDirectory()
android.content.Context#getFilesDir()
android.content.Context#getCacheDir 

当使用外部存储时，必须检查外部存储的可用性 。

SharedPreference 中只能存储简单数据类型（int、 boolean、 String 等），复杂数据类型建议使用文件、数据库等其他方式存储 。

SharedPreference 提 交 数 据 时 ， 尽 量 使 用 Editor#apply() ， 而 非Editor#commit()。一般来讲，仅当需要确定提交结果，并据此有后续操作时，才使用 Editor#commit()。

多线程操作写入数据库时，需要使用事务，以免出现同步问题 。

执行 SQL 语句时，应使用 SQLiteDatabase#insert()、 update()、 delete()，不要使用SQLiteDatabase#execSQL()，以免 SQL 注入风险。

不要通过 Msg 传递大的对象，会导致内存问题。

不能在 Activity 没有完全显示时显示 PopupWindow 和 Dialog。

Activity 间的数据通信，对于数据量比较大的，避免使用 Intent + Parcelable的方式，可以考虑 EventBus 等替代方案，以免造成 TransactionTooLargeException 。

Activity#onSaveInstanceState()方法不是 Activity 生命周期方法，也不保证一定会被调用。它是用来在 Activity 被意外销毁时保存 UI 状态的，只能用于保存临时性数据，例如 UI 控件的属性等，不能跟数据的持久化存储混为一谈。持久化存储应该在 Activity#onPause()/onStop()中实行 。

避免在 BroadcastReceiver#onReceive()中执行耗时操作，如果有耗时工作，应该创建 IntentService 完成，而不应该在 BroadcastReceiver 内创建子线程去做 。

不要在 Activity#onDestroy()内执行释放资源的工作，例如一些工作线程的销毁和停止，因为 onDestroy()执行的时机可能较晚。可根据实际需要，在Activity#onPause()/onStop()中结合 isFinishing()的判断来执行。

不要在 Android 的 Application 对象中缓存数据。基础组件之间的数据共享请使用 Intent 等机制，也可使用 SharedPreferences 等数据持久化机制。

使用 Toast 时，建议定义一个全局的 Toast 对象，这样可以避免连续显示Toast 时不能取消上一次 Toast 消息的情况(如果你有连续弹出 Toast 的情况，避免使用 Toast.makeText)。

10. 组件化规范
    10.1 资源文件
    10.1.2 命名
    因为我们拆分出了很多业务组件和功能组件，在把这些组件合并到“app壳工程”时候就有可能会出现资源名冲突问题，例如A组件和B组件都有一张叫做“ic_back”的图标，这时候在集成模式下打包APP就会编译出错。所以，如果我们的项目使用了组件化，那么在[5. 资源文件规范](#5. 资源文件规范)的基础上，在所有资源文件的名字前增加组件名作为前缀。

10.1.2 拆分
按照资源的使用情况将资源文件分为公用资源和资源自由资源；

字符串拆分要谨慎：不复用字符串，每个组件维护自己的，不要嫌麻烦。参考：不可不知的 Android strings.xml 那些事

10.2 服务
这里服务是指业务组件或功能组件对外提供的功能，在所有组件都依赖的 common 组件编写功能接口，然后在对应的组件实现该接口。通过第三方库，比如 ARouter 来通过接口来调用实现类，实现代码隔离。

附录
UI 控件缩写表

常见的英文单词缩写表

程序中使用单词缩写原则：不要用缩写，除非该缩写是约定俗成的。