Android 架构设计(五)：命名规范与层级规范_android 分层实现命名-CSDN博客

本文链接：https://blog.csdn.net/qq_39731011/article/details/124668332

本文档详细介绍了Android开发中的命名规范，包括包名、类名、方法名、变量名和控件ID的最佳实践，以及层级结构的组织原则，旨在提升代码可读性和复用性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

同系列传送门：

Android 架构设计(一)：设计模式分析_深海呐的博客-CSDN博客_安卓开发框架设计模式很多人把无架构定为MVC ，这边深海要纠正一下，无架构 != MVCMVC与MVC的核心区别：View和Model禁止直接通信。Presenter通常面向界面与界面成一对一的关系，而Controller通常面向业务，服务于一个业务下的所有界面。MVVM与MVP的区别：ViewModel不持有View 而Presenter持有View。MVVM为数据驱动 MVP为事件驱动。https://blog.csdn.net/qq_39731011/article/details/121769646

Android 架构设计(二)：分包和文件结构_深海呐的博客-CSDN博客同系列传送门：Android 架构设计(一)：设计模式分析_赵星海的博客-CSDN博客Android 架构设计(三)：技术选型_赵星海的博客-CSDN博客Android 架构设计(四)：组件化？_赵星海的博客-关于架构设计，首先确定了设计模式之后，然后开始具体实施，这时候首先要考虑如何分包，或者说如何定义文件的层级结构。而分包和文件结构无非两种思想：1.模式包业务，2.业务包模式。如下图：究竟哪种分包方式更好呢？从文件夹的数量上看： 3*2 == 2*3 两种方...https://blog.csdn.net/qq_39731011/article/details/121827039

Android 架构设计(三)：技术选型_深海呐的博客-CSDN博客_android 技术选型同系列传送门：Android 架构设计(一)：设计模式分析_赵星海的博客-CSDN博客Android 架构设计(二)：分包和文件结构_赵星海的博客-CSDN博客Android 架构设计(四)：组件化？关于架构设计的分享，本期深海会和大家分享探讨一些技术选型的问题：网络请求框架选型：这个具体要看项目中网络请求相关业务的复杂度，以及架构设计的侧重点。如果业务复杂度较高，或者架构设计侧重解耦的话，推荐使用RxJava+Retrofit如果业务复杂度较低，或者追求代.https://blog.csdn.net/qq_39731011/article/details/122174725

Android 架构设计(四)：组件化？_深海呐的博客-CSDN博客同系列传送门Android 架构设计(一)：设计模式分析_赵星海的博客-CSDN博客Android 架构设计(二)：分包和文件结构_赵星海的博客-CSDN博客_android 分包结构Android 架构设计(三)：技术选型_赵星海的博客-CSDN博客关于组件化，我这边分三步与大家分享：1定义，2需求，3优劣，4改造步骤（含框架推荐）；1、组件化的定义：各个业务模块可单独运行，模块相互联系只可以使用唯一的入口。如图：2、当前项目是否需要采用组件化？首先看项目大小，..https://blog.csdn.net/qq_39731011/article/details/122358966

命名规范：

程序包： com.xxx.xxx

主要强调其唯一性，一般使用公司域名/简写+APP简写，全小写。

比如：

微信包名：com.tencent.mm
淘宝包名：com.taobao.taobao

业务包： xxx

一般为全小写的单个单词，主要强调其业务范围，业务类型或者功能

比如：

controller
activity
view
utils

类：XxxXxx

一般使用大驼峰命名法。主要强调该类的作用与所属类型

比如：

MainActivity 作用：Main程序入口界面；所属类型：Activity窗口界面。
StringUtils 作用：String字符串处理工具；所属类型：Utils工具类
UserDataAdapter 作用：UserData用户数据适配器；所属类型：Adapter适配器

方法：xxxXxx

一般使用小驼峰命名法。主要强调具体功能与动作

比如：

getUserName 功能：获取用户数据；动作：get 获取
saveUserData 功能：保存用户数据；动作：save 保存
initView 功能：初始化View，动作：init 初始化

变量：mXxx & xxxXxx

一般使用小驼峰命名法。主要强调见名知义

全局变量 :

通常在前面加一个“m”，比如：

mUserDataAdapter，mUserDataViewModler，mDataList；

局部变量

通常为实例的小写，比如：

userDataAdapter，userDataViewModler，dataList；

常量：XXX_XXX

一般使用全大写字母，并使用下划线隔开每一个单词。强调见名知义。

比如：

USER_TAG，SECRET_KEY，APP_ID；

Layout布局：xxx_xxx

一般使用全小写字母，并使用下划线隔开每一个单词，强调类型和用途。

比如：

activity_main，强调类型：activity 视图页；强调用途：main 首页
fragmengt_user，强调类型：fragmengt 碎片页/局部；强调用途：user 用户主页/局部
item_user_list，强调类型：Item 某列表的子条目；强调用途：user_list 用户列表

控件ID：xxx_xxx

一般使用全小写字母，并使用下划线隔开每一个单词，强调唯一性和见名知义。

关于控件ID的命名，有两种主流的命名方式：

第一种“控件类型+作用”，

比如：

text_view_user_name，强调类型：TextView；强调作用：user_name用户姓名
tv_user_name，强调类型：TextView(简写)；强调作用：user_name用户姓名
layout_user_info；强调类型：Layout ；强调作用：user_info 用户信息

第二种“控件位置+作用”

比如：

main_title，强调位置：main首页；强调作用：title标题
main_user_name，强调位置：main首页；强调作用：user 用户姓名
main_user_head；强调位置：main首页；强调作用：user 用户头像

深海强烈强调：控件ID命名的唯一性必须保证，作用必须体现！

反面举例：

图中RecyclerView的ID命名有两个问题：

1.唯一性没有保证！

当你想在代码中反向追溯的时候，无法立即从代码定位到布局文件对应的位置。

2.作用没有体现!

假如你的布局中有多个RecyclerView，无法合理进行区分，无法通过ID立即知道当前RecyclerView的职责作用。

图中还有哪些问题？

红框框中的控件ID命名过度简写问题，“rl”很难让人第一时间想到这是RelativeLayout，关于layout的命名前缀，我不建议过度简写。

命名规范的通用禁止：

关于命名规范的通用禁止，深海总结了以下三点：

1.非特殊情况，禁止使用拼音和数字；

错误示范：变量yongHuData(用户数据) 类Activity1 变量x1 x2 x3

特殊情况举例：包名com.taobao.taobao 部分包名用了拼音确实正常情况，这和公司的简写有关，也和部分大项目的立项命名有关。还有部分变量或者类用了拼音是正常情况，比如某某三方SDK的实例变量，或者公司项目立项类型的命名，XXXUtils,XXXActivity，这里的XXX代表公司项目简写，可能是拼音，也可能是特殊含义的字母。

2.见名知义，禁止过度简写，禁止长度过长；

错误示范：

过度简写：StringBuilder sb = new StringBuilder()

长度过长：StringBuilder userDiskFileWriterStringBuilder = new StringBuilder()

3.方法名和变量名禁止首字母大写，便于区分类和变量的区别

错误示范：StringBuilder UserStringBuilder= new StringBuilder()