一种富有成效的资源文件命名规则

原文：A SUCCESSFUL XML NAMING CONVENTION 

你还记得最后一次在strings.xml中寻找要用的字符串吗？还记得自己最后一次不得不浏览完所有的drawable才找到想要的那个图标吗？

每当开始一个新的项目，我们总是化太多心思到配置和架构上，但是对于资源文件的命名，你有自己的一套对策吗？

其实你应该有才对！因为如果缺乏xml的命名规则会让安卓资源文件的管理混乱，尤其是在大项目中。

那么就让我们来介绍一个可以减轻你痛苦的简单方案吧。

这篇博客将阐述其机制、好处、限制，并提供一个可随时查阅的清单。

基本准则

所有的资源文件名称都遵循一个简单的约定。

我们首先简明的描述一下每个元素。然后列举这样做的好处，之后我们将演示如何把它应用到各种类型的资源文件中。

表示到底代表的是什么资源，通常是一个标准的安卓View类，或者能代表view的类。(e.g. MainActivity -> activity)

表示它属于app的什么地方。在多个页面使用的资源用all，其它的使用它们所在页面名称的自定义部分(e.g. MainActivity -> main, ArticleDetailFragment -> articledetail)。

区分同一界面的不同元素
(e.g. title)

(可选)

可以是准确的大小也可以是描述大小的文字。可以选择性的用在drawable和dimension上。

(e.g. 24dp, small))

可以下载和打印我提供的备忘清单方便随时查阅。

好处

1. 按页面组织资源
   WHERE部分描述了一个资源所属的页面。因此可以很容易识别出一个特定页面的所有ID, drawable, dimension。

2. 一眼就能从资源ID判断出类型
   对于资源id，WHAT部分描述了这个id所属的xml元素的类名。这样可以让你更容易知道findViewById()调用之后应该转换成什么类。

3. Better resource organizing 
   File browsers/project navigator通常按照字母顺序排列文件。这意味着布局和drawable是按照他们的 WHAT(activity, fragment,..) 和 WHERE前缀组织的。现在有一个简单的Android Studio插件可以让这些资源看起来就像在自己的文件夹里面一样。

4. 提高自动补全的效率
   因为资源名称非常好预测，使得ide的自动补全更容易了。通常输入WHAT或者 WHERE就足以把自动补全的提示缩小到很窄的范围了。

5. 不再有命名冲突
   不同页面之间相似的资源具有不同的where，或者是使用all。

6. 更清晰的命名
   总体来说资源文件的命名更加有逻辑，使得项目更清晰。

7. Tools support 
   This naming scheme could be easily supported by the Android Studio offering features such as: lint rules to enforce these names, refactoring support when you change a WHAT or WHERE, better resource visualisation in project view,...

LAYOUTS

布局的命名相对简单，因为通常一个页面只有很少的布局。因此规则可以简化成：

其中可以是以下名称之一：

前缀	用处
activity	activity的布局
fragment	fragment的布局
view	一个自定义view所要inflated的布局
item	recycler或者gridview中使用的布局
layout	include标签中用来重用的布局

例子:

• activity_main: MainActivity的布局

• fragment_articledetail:  ArticleDetailFragment的布局

• view_menu: 被自定义view：MenuView所inflate的布局

• item_article: ArticleRecyclerView中的item

• layout_actionbar_backbutton:带有返回按钮的actionbar的布局

STRINGS

Strings的部分无关紧要。所以你要么使用表明string被使用的地方：

要么使用all表示整个app都要使用这个string：

Examples:

• articledetail_title: ArticleDetailFragment的标题

• feedback_explanation:  FeedbackFragment中的feedback explanation

• feedback_namehint: hint of name field in FeedbackFragment

• all_done: 通用的 "done" 字符。

很明显同一视图下的资源都是一样的。

DRAWABLES

Drawables的也不重要。所以要么使用表明drawable被使用的地方：

要么使用all表示整个app都要使用这个drawable：

还可以选择性的添加元素，可以是准确的大小如“24dp”也可以是大小修饰词如“small”。

Examples:

• articledetail_placeholder: placeholder in ArticleDetailFragment

• all_infoicon: generic info icon

• all_infoicon_large: large version of generic info icon

• all_infoicon_24dp: 24dp version of generic info icon

IDS

对于ID，指的是它所属的xml元素的类名。然后是id所在的页面，最后可以选择性的跟上一个描述，以区别同一页面的相似元素。

例子:

• tablayout_main -> MainActivity中的TabLayout

• imageview_menu_profile -> 自定义MenuView中的profile image

• textview_articledetail_title ->ArticleDetailFragment中标题对应的TextView

DIMENSIONS

app应该只定义一套数量有限的常用dimension，这个特性使得dimension一般都默认用all。

因此你最常用的是：

偶尔也可以指定具体的页面:

其中是以下名称之一：

Prefix	Usage
width	width in dp
height	height in dp
size	if width == height
margin	margin in dp
padding	padding in dp
elevation	elevation in dp
keyline	absolute keyline measured from view edge in dp
textsize	size of text in sp

注意这里只包含了最常用的。其它dimension描述如：rotation, scale,...通常只用在drawable上，而且也是很少用。

例子:

• height_toolbar: toolbar的高度

• keyline_listtext: listitem text所要对齐的keyline

• textsize_medium: 所有文字的中等大小

• size_menu_icon: 菜单中图标的大小

• height_menu_profileimage: 菜单中profile image的高度

已知的缺陷

1. 页面必须具有唯一的名称
   了避免参数发生冲突，View（以及可以代表View）的类必须具有独有的名称。所以你不能同时有“MainActivity”和 "MainFragment",因为 "Main" 前缀不再能够识别出一个了。ps：这点其实可以灵活的处理，一般这种情况发生在不需要what的情况下，其实这个时候where我们可以用activity_main来表示，而不是main。

2. 不支持重命名
   修改类的名称并不能同步修改资源名称。所以如果你把 "MainActivity" 改为 "ContentActivity"，布局"activity_main"并不会重命名为"activity_content"。希望哪天Android Studio能添加这种支持。ps：这不算是缺陷吧，又不是这种命名规则引起的。

3. 不能支持所有的资源类型
   这种规则当前不支持所有的资源类型。主要是有些资源不常用（比如raw 和 assets)，还有些资源不是很好归纳（比如：themes/styles/colors/animations）。

WRAP-UP

以上就是本文的内容。一个简单易用的资源文件命名规则。别忘了下载cheat sheet方便查阅哦！

虽然这种规则并不覆盖所有的资源类型，但是它的确提供了一种解决了绝大多数命名问题的方法。