Android 开发规范（完结版）

统计发现新功能没人用，这个版本那块功能得去掉。

如果是 PBL，得从功能入口到整个业务流程把受到牵连的所有能删的代码和 class 都揪出来删掉，一不小心就完蛋。

如果是 PBF，好说，先删掉对应包，再删掉功能入口（删掉包后入口肯定报错了），完事。

• 高度抽象

解决问题的一般方法是从抽象到具体，PBF 包名是对功能模块的抽象，包内的 class 是实现细节，符合从抽象到具体，而 PBL 弄反了。

PBF 从确定 AppName 开始，根据功能模块划分 package，再考虑每块的具体实现细节，而 PBL 从一开始就要考虑要不要 dao 层，要不要 com 层等等。

• 只通过 class 来分离逻辑代码

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

没有必要通过 package 分离，因为 PBL 中也可能出现尴尬的情况：

├── service
├── MainService.java

按照 PBL, service 包下的所有东西都是 Service，应该不需要 Service 后缀，但实际上通常为了方便，直接 import service 包，Service 后缀是为了避免引入的 class 和当前包下的 class 命名冲突，当然，不用后缀也可以，得写清楚包路径，比如 new com.domain.service.MainService()，麻烦；而 PBF 就很方便，无需 import，直接 new MainService() 即可。

• package 的大小有意义了

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

如要知道更多好处，可以查看这篇博文：Package by features, not layers，当然，我们大谷歌也有相应的 Sample：todo-mvp，其结构如下所示，很值得学习。

com
└── example
└── android
└── architecture
└── blueprints
└── todoapp
├── BasePresenter.java
├── BaseView.java
├── addedittask
│   ├── AddEditTaskActivity.java
│   ├── AddEditTaskContract.java
│   ├── AddEditTaskFragment.java
│   └── AddEditTaskPresenter.java
├── data
│   ├── Task.java
│   └── source
│   ├── TasksDataSource.java
│   ├── TasksRepository.java
│   ├── local
│   │   ├── TasksDbHelper.java
│   │   ├── TasksLocalDataSource.java
│   │   └── TasksPersistenceContract.java
│   └── remote
│   └── TasksRemoteDataSource.java
├── statistics
│   ├── StatisticsActivity.java
│   ├── StatisticsContract.java
│   ├── StatisticsFragment.java
│   └── StatisticsPresenter.java
├── taskdetail
│   ├── TaskDetailActivity.java
│   ├── TaskDetailContract.java
│   ├── TaskDetailFragment.java
│   └── TaskDetailPresenter.java
├── tasks
│   ├── ScrollChildSwipeRefreshLayout.java
│   ├── TasksActivity.java
│   ├── TasksContract.java
│   ├── TasksFilterType.java
│   ├── TasksFragment.java
│   └── TasksPresenter.java
└── util
├── ActivityUtils.java
├── EspressoIdlingResource.java
└── SimpleCountingIdlingResource.java

参考以上的代码结构，按功能分包具体可以这样做：

com
└── domain
└── app
├── App.java 定义 Application 类
├── Config.java 定义配置数据（常量）
├── base 基础组件
├── custom_view 自定义视图
├── data 数据处理
│   ├── DataManager.java 数据管理器，
│   ├── local 来源于本地的数据，比如 SP，Database，File
│   ├── model 定义 model（数据结构以及 getter/setter、compareTo、equals 等等，不含复杂操作）
│   └── remote 来源于远端的数据
├── feature 功能
│   ├── feature0 功能 0
│   │ ├── feature0Activity.java
│   │ ├── feature0Fragment.java
│ │ ├── xxAdapter.java
│ │ └── … 其他 class
│ └── …其他功能
├── injection 依赖注入
├── util 工具类
└── widget 小部件

3.2 类名

类名都以 UpperCamelCase 风格编写。

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

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

类	描述	例如
Activity 类	Activity 为后缀标识	欢迎页面类 WelcomeActivity
Adapter 类	Adapter 为后缀标识	新闻详情适配器 NewsDetailAdapter
解析类	Parser 为后缀标识	首页解析类 HomePosterParser
工具方法类	Utils 或 Manager 为后缀标识	线程池管理类：ThreadPoolManager
日志工具类：LogUtils（Logger 也可）
打印工具类：PrinterUtils
数据库类	以 DBHelper 后缀标识	新闻数据库：NewsDBHelper
Service 类	以 Service 为后缀标识	时间服务 TimeService
BroadcastReceiver 类	以 Receiver 为后缀标识	推送接收 JPushReceiver
ContentProvider 类	以 Provider 为后缀标识	ShareProvider
自定义的共享基础类	以 Base 开头	BaseActivity, BaseFragment

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

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

注意：如果项目采用 MVP，所有 Model、View、Presenter 的接口都以 I 为前缀，不加后缀，其他的接口采用上述命名规则。

3.3 方法名

方法名都以 lowerCamelCase 风格编写。

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

方法	说明
initXX()	初始化相关方法，使用 init 为前缀标识，如初始化布局 initView()
isXX(), checkXX()	方法返回值为 boolean 型的请使用 is/check 为前缀标识
getXX()	返回某个值的方法，使用 get 为前缀标识
setXX()	设置某个属性值
handleXX(), processXX()	对数据进行处理的方法
displayXX(), showXX()	弹出提示框和提示信息，使用 display/show 为前缀标识
updateXX()	更新数据
saveXX(), insertXX()	保存或插入数据
resetXX()	重置数据
clearXX()