[最新] Android 代码规范大全（Android开发速看）

编程不规范，亲人两行泪。今天就来分享一下最新的 Android 代码规范大全。
原文地址：代码规范大全

前言

虽然我们项目的代码时间并不长，也没经过太多人手，但代码的规范性依然堪忧，目前存在较多的比较自由的「代码规范」，这非常不利于项目的维护，代码可读性也不够高。

此外，客户端和后端的研发模式也完全不同，后端研发基本都是基于 SOA 思想的，通常一个子系统 3 个人一起维护就已经是很充分的人力了，更多时候就是 1 个主力 + 1 个 backup 的人力配置。

而客户端却完全不同，大家的代码都是相互交叉的，一个模块的代码可能要经历数十人的蹂躏，所以形成一个一致的开发规范迫在眉睫。

为什么需要一致的代码规范？

核心还是减少沟通成本，提升我们的 Code Review 效率，让我们的代码更加易于维护。此外，一个一致的代码规范可以造成更少的 bug，也就意味着更节省时间和金钱。

当然，规范是约定的，本系列文字全是笔者多年来博采众长，积累而成，所以有任何不同意见，欢迎评论拍砖。

1. Android 的工具规范

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

由于 Android 基本都基于 Android Studio 进行开发，所以工具规范全部以 Android Studio 为前提。

1. 必须使用最新的稳定版本的 Android Studio 进行开发；

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

3. 删除多余的 import，减少警告出现，可利用 AS 的 Optimize Imports（Settings -> Keymap -> Optimize Imports）快捷键，设置自己的喜好。

   

4. 编辑完 .java、.kt、.xml 等文件后必须格式化（需要在设置好以下几点的前提下）

Reformat Code 的必要性，一定需要保证 IDE 配置一致为前提，尽可能贴切于 Android Studio 默认。
强烈建议对于比较长的老代码局部格式化，不全局格式化

• 每行字符数不得超过 160 字符，设置 Editor -> Code Style

  

• 全部设置为单路径引用，kotlinx.android.synthetic.main 除外。

  

  Java Code Style

Kotlin Code Style

XML Code Style

以上几处设置完毕，其他采用 Android Studio 默认方式，再进行 Reformat Code 快捷键即可。

Reformat Code 快捷键设置

2. Android 的分包规范

前面强调了工具的统一配置，再利用 Android Studio 本身的功能便可把代码风格变得一致。接下来就带来第二部分：Android 的分包规范。

对于分包，我们需要达成一致，我们采用 PBF 方式，不推荐使用 PBL 方式。

PBF（按功能分包 Package By Feature）
PBL（按层分包 Package By Layer）

PBF 可能不是很好区分在哪个功能中，不过也比 PBL 要好找很多，且 PBF 与 PBL 相比较有如下优势：

• package 内高内聚，package 间低耦合
  哪块要添新功能，只改某一个 package 下的东西，而PBL 需要改多个 package，非常麻烦。

• package 有私有作用域（package-private scope）
  原则上一个 package 下的不允许其他类访问都是不应该加上 public 的。

• 很容易删除功能
  统计发现新功能没人用，这个版本那块功能得去掉。如果是 PBL，得从功能入口到整个业务流程把受到牵连的所有能删的代码和 class 都揪出来删掉，一不小心就完蛋。如果是 PBF，好说，先删掉对应包，再删掉功能入口（删掉包后入口肯定报错了），完事。

• 高度抽象
  解决问题的一般方法是从抽象到具体，PBF 包名是对功能模块的抽象，包内的 class 是实现细节，符合从抽象到具体，而 PBL 弄反了。PBF 从确定 AppName 开始，根据功能模块划分 package，再考虑每块的具体实现细节，而 PBL 从一开始就要考虑要不要 dao 层，要不要 com 层等等。

• 只通过 class 来分离逻辑代码
  PBL 既分离 class 又分离 package，而 PBF 只通过 class 来分离逻辑代码。

• package 的大小有意义了
  PBL 中包的大小无限增长是合理的，因为功能越添越多，而 PBF 中包太大（包里 class 太多）表示这块需要重构（划分子包）。

3. Android 的命名规范

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

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

3.1 包名

Android 里面有 package 的概念，所以需要约定一下包名命名规范。

包名全部小写，不允许出现中文、大写字母或者下划线，前面为子模块命名，再根据 PBF 方式进行命名。

3.2 类名

类名都以 UpperCamelCase 风格编写。

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

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

类	描述	例如
Activity 类	模块名 + Activity	闪屏页类 SplashActivity
Fragment 类	模块名 + Fragment	主页类 HomeFragment
Service 类	模块名 + Service	时间服务 TimeService
BroadcastReceiver 类	功能名 + Receiver	推送接收 JPushReceiver
ContentProvider 类	功能名 + Provider	ShareProvider
自定义 View	功能名 + View/ViewGroup(组件名称)	ShapeButton
Dialog对话框	功能名+Dialog	ImagePickerDialog
Adapter 类	模块名 + Adapter	课程详情适配器 LessonDetailAdapter
解析类	功能名 + Parser	首页解析类 HomePosterParser
工具方法类	功能名 + Utils 或 Manager	线程池管理类：ThreadPoolManager

日志工具类：LogUtils（Logger 也可）
打印工具类：PrinterUtils |
| 数据库类 | 功能名 + DBHelper | 新闻数据库：NewsDBHelper |
| 自定义的共享基础类 | Base + 基础 | BaseActivity, BaseFragment |
| 抽象类 | Base / Abstract 开头 | AbstractLogin |
| 异常类 | Exception 结尾 | LoginException |
| 接口 | able / ible 结尾 / I 开头 | Runnable, Accessible ，ILoginView |

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

接口（interface）：命名规则与