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

原文:A SUCCESSFUL XML NAMING CONVENTION 

A successful XML naming convention

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

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

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

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

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

基本准则

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

what_where_description_size

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

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

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

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

(可选)

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

(e.g. 24dp, small))

Resource naming cheat sheet

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

好处

  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

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

what_where.xml

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

前缀用处
activityactivity的布局
fragmentfragment的布局
view一个自定义view所要inflated的布局
itemrecycler或者gridview中使用的布局
layoutinclude标签中用来重用的布局

例子:

  • activity_main: MainActivity的布局

  • fragment_articledetail:  ArticleDetailFragment的布局

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

  • item_article: ArticleRecyclerView中的item

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

STRINGS

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

where_description.xml

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

all_description.xml

Examples:

  • articledetail_title: ArticleDetailFragment的标题

  • feedback_explanation:  FeedbackFragment中的feedback explanation

  • feedback_namehint: hint of name field in FeedbackFragment

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

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

DRAWABLES

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

where_description_size.xml

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

all_description_size.xml

还可以选择性的添加元素,可以是准确的大小如“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所在的页面,最后可以选择性的跟上一个描述,以区别同一页面的相似元素。

what_where_description.xml

例子:

  • tablayout_main -> MainActivity中的TabLayout

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

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

DIMENSIONS

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

因此你最常用的是:

what_all_description_size.xml

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

what_where_description_size.xml

其中是以下名称之一:

PrefixUsage
widthwidth in dp
heightheight in dp
sizeif width == height
marginmargin in dp
paddingpadding in dp
elevationelevation in dp
keylineabsolute keyline measured from view edge in dp
textsizesize 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方便查阅哦!

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