我的作品 xiuyuantech 博客 – 可参考借鉴的 Android 开发规范

jason2020(jason) · 2026年03月20日 · 13 次阅读

xiuyuantech 博客: https://xiuyuantech.github.io/

参考 Google 官方 Java 代码风格规范,中文翻译参考版链接。 本文档用于指导开发人员在项目开发过程中类名、资源文件名、变量名等开发约定以及命名规范,方便工程的后期维护,提高代码整体质量、可读性。

命名规范:

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

1、包命名

规则:包名全部小写,采用反域名命名规则,一级包名是顶级域名,通常为 com, edu, gov, net, org 等,二级包名,通过为公司名或部门名或者个人名,三级包名通常为项目名,四级包名为模块名或者层级名。

2、类命名

规则:采用大驼峰式命名法,首字母大写,尽量避免缩写,除非该缩写是众所周知的,比如 HTML,URL,如果类名称包含单词缩写,则单词缩写的每个字母均应大写。以下列举的是 android 中几种最为常用的类的命名。

3、接口命名

规则:命名规则与类命名一样采用大驼峰式命名法,首字母大写,多以 able, ible, er 结尾。

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

4、方法

规则:采用小驼峰命名法,首字母小写,方法名采用动词或动名词结构。方法的命名应该与方法的真正行为具有对应关系,下面给出一些方法名的动词前缀标示的建议。

getXX() 获取某个属性的返回值 ;setXX() 设置某个属性值 ;initXX() 初始化方法,如初始化布局 initView() ;isXX() 判断是否 true 的方法;

5、常量

规则:常量使用全大写字母加下划线的方式命名。

6、变量

规则:采用小驼峰命名法,首字母小写。变量名应简短且能描述其用途,尽量避免拼音,无意义地缩写。除非是临时变量,否则不建议使用单个字符的变量名,如 i, j, k。对于变量命名,还有一种风格是 google 的以字母 m 为前缀(m 为 member 缩写),在 android 源码中随处可见。

更多还可参考阿里巴巴 Java 开发手册 注意:所有的 VO(值对象)统一采用标准的 lowerCamelCase 风格编写,所有的 DTO(数据传输对象)就按照接口文档中定义的字段名编写。

7、控件变量名

规则:首先需要满足第 6 条变量的规则, 模式:逻辑名 + view 缩写

8、控件 ID

规则:view 缩写模块名逻辑名

9、layout 的文件命名

规则:全部小写,采用下划线命名法。layout 文件命名:组件类型{模块}功能.xml

10、drawable 的文件命名

模式:前缀{控件}{范围}{_后缀},控件、范围、后缀可选

11、动画的文件命名

规则:模块名{范围}动画类型_动画方向。

12、strings.xml

模式:activity 名{范围}逻辑名

13、colors.xml

模式:前缀{控件}{范围}{_后缀}, 控件、范围、后缀可选。

代码风格:

原则

不要直接忽略 Exceptions

import 采用完全限定名

if 括号风格

使用空格来缩进:使用 4 个空格缩进来代表块,而绝不使用 tab 键; 使用 8 个空格来代表行包裹,包括函数调用。

注释规范:

类注释

每个类完成后应该有作者姓名和联系方式的注释,对自己的代码负责。具体可以在 AS 中自己配制,Settings → Editor → File and Code Templates → Includes → File Header,输入自定义信息。

方法注释

每一个成员方法(包括自定义成员方法、覆盖方法、属性方法)的方法头都必须做方法头注释。 在方法前一行输入/** + 回车或者设置 Fix doc comment(Settings → Keymap → Fix doc comment) 快捷键,AS 便会帮你生成模板,我们只需要补全参数即可。

块注释

块注释与其周围的代码在同一缩进级别。它们可以是/* … /风格,也可以是// …风格 (//后最好带一个空格)。 对于多行的/ … /注释,后续行必须从开始, 并且与前一行的对齐。注释不要封闭在由星号或其它字符绘制的框架里。Tip:在写多行注释时,如果你希望在必要时能重新换行 (即注释像段落风格一样),那么使用/ ... */。

资源文件注释  例如 : <!--红色 --> 

总结:

好的命名规则能够提高代码质量,使得新人加入时降低理解难度;

规矩终究是死的,适合团队的才是最好的;

命名规范需要团队齐心协力来维护,在团队里谁都不可能独善其身;

刚刚开始可能会有些不习惯,持之以恒,总会成功的。

业务咨询:https://soloist.pages.dev

原文地址:https://xiuyuantech.github.io/2026/03/19/android-rule/

暂无回复。
需要 登录 后方可回复, 如果你还没有账号请 注册新账号