转载自： https://blog.csdn.net/jun5753/article/details/83786825

1. 前言
   为了有利于项目维护、增强代码可读性、提升 Code Review 效率以及规范团队安卓开发，故提出以下安卓开发规范。
   工具推荐：使用Typora软件编写。

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 控件缩写表

常见的英文单词缩写表

escape esc
icon ic（主要用在 App 的图标）
increment inc
information info
initial init
image img
Internationalization I18N
length len
library lib
message msg
password pwd
position pos
previous pre
selector sel（主要用于某一 view 多种状态，不仅包括 ListView 中的 selector，还包括按钮的 selector）
server srv
string str
temporary tmp
window win
程序中使用单词缩写原则：不要用缩写，除非该缩写是约定俗成的。

10.3 代码隔离
使用runtimeOnly 来隔离代码

参考
Android 开发规范（完结版）

Android Studio 下对资源进行分包

阿里巴巴Android开发手册

Android性能调优

原文：https://blog.csdn.net/jun5753/article/details/83786825