原文地址:http://jeroenmols.com/blog/2016/03/07/resourcenaming/
一、Basic principle(基本原则)
所有的资源文件的命名遵守以下原则:
<WHAT>_<WHERE>_<DESCRIPTION>_<SIZE>
下面我们会首先简明的描述每一个元素。之后,我们这种原则是如何适用于每一种资源类型。
1. <WHAT>标签
表明其代表哪种资源文件,通常代表的是标准的Android视图类。限制了每种资源文件的类型。(eg. MainActivity->activity)
2. <WHERE>标签
描述的是它在逻辑上属于这个应用。多种屏幕使用的资源使用“all”,其他情况使用Android视图子类的部分名称进行命名(View的子类)。(eg.MainActivity->main,ArticleDetailFragment->articledetail)
3. <DESCRIPTION>标签
对同一屏幕上的多种元素进行区分。(eg.title)
4. <SIZE> (optional)标签
一个精确地尺寸或者大致的尺寸。对于“drawable”和“dimensions”可以选择使用。(eg.24dp,small)
二、Advantages
1. Ordering of resources by screen
可以实现依据屏幕排序资源文件。<WHERE>标签描述资源属于哪个屏幕。因此你就可以很容易的为特定屏幕获取IDs,drawables,dimensions,…
2. Strongly typed resource IDs
可以根据资源文件IDs进行分类。对于资源IDs,“WHAT”标签能够描述类名命名的xml元素属于哪。这就使得在调用findViewById()方法的时候很容易的进行类型转换。
3. Better resource organizing
进行更好的组织资源。文件浏览器/项目导航器通常会按照字母排序进行文件的分类。这就是意味着“layouts”和“drawables”会按照各自的“WHAT”(activity,fragment,…)和“WHERE”前缀进行分组。如果这些资源文件在它们自己的文件夹里的话,一个简单的Android Studio插件/功能就可以按照这种方式展示它们。
4. More efficient autocomplete
更有效的自动完成。由于资源文件的名字是可以预测的,使用编辑器的自动功能会变得更简单。通常使用“WHAT”和“WHERE”标签是更加有效的完成有限的资源文件集的自动排序。
5. No more name conflicts
不在存在命名的冲突。在不同屏幕中的相似资源要么使用“all”要么使用不同的“WHERE”标签。一个固定的命名方式可以避免命名的冲突。
6. Cleaner resource names
整齐的资源文件的命名。所有的资源文件的命名更有逻辑性,所以就会有整洁的Android项目。
7. Tools support
工具支持。命名方式应该很容易被Android Studio提供的功能支持:lint要求资源的名字遵守自己的规则,当你改变“WHAT”或者“WHERE”就会重构,这样就会有清晰的项目视图…
三、LAYOUTS
布局就相对简单,因为每一个屏幕界面仅有为数不多的几个布局。因此简化为:
<WHAT>_<WHERE>.xml
<WHAT>标签:
Examples:
activity_main: content view of the MainActivity
fragment_articledetail: view for the ArticleDetailFragment
view_menu: layout inflated by custom view class MenuView
item_article: list item inArticleRecyclerView
layout_actionbar_backbutton: layout for an actionbar with a backbutton(too simple to be a customview)
四、STRINGS
<WHAT>标签对于“Strings”来说是不相干的。所以在这里我们使用<WHERE>标签去说明哪里使用:
<WHERE>_<DESCRIPTION>
或者使用“all”去说明该资源文件整个应用使用:
all_<DESCRIPTION>
Examples:
articledetail_title: title of ArticleDetailFragment
feedback_explanation: feedback explanation in FeedbackFragment
feedback_namehint: hint of name field in FeedbackFragment
all_done: generic "done" string
<WHERE>也是相同的用法。
五、DRAWABLES
<WHAT>对于“drawables”是不相干的。因此我们使用“WHERE”说明资源使用在哪:
<WHERE>_<DESCRIPTION>_<SIZE>
或者使用“all”说明资源文件整个应用使用:
all_<DESCRIPTION>_<SIZE>
当然你可以选择使用<SIZE>,如:“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
对于IDs,<WHAT>标签是在xml布局中的类名。下一步就是在那个屏幕中,后面就是区别于同一屏幕中的其他元素的可选描述。
<WHAT>_<WHERE>_<DESCRIPTION>
Examples:
tablayout_main -> TabLayout in MainActivity
imageview_menu_profile -> profile image in custom MenuView
textview_articledetail_title -> title TextView inArticleDetailFragment
七、DIMENSIONS
应用应该定义一些经常使用的dimensions.对于多数的dimensions默认使用“all”。
一般来说:
<WHAT>_all_<DESCRIPTION>_<SIZE>
特定的变量:
<WHAT>_<WHERE>_<DESCRIPTION>_<SIZE>
对于“where”标签:
其他略;
Examples:
height_toolbar: height of all toolbars
keyline_listtext: listitem text is aligned at this keyline
textsize_medium: medium size of all text
size_menu_icon: size of icons in menu
height_menu_profileimage: height of profile image in menu
八、Known limitations
1.Screens need to have unique names
To avoid collisions in the <WHERE>argument, View (like) classes must have unique names. Therefore you cannot havea "MainActivity" and a "MainFragment", because the"Main" prefix would no longer uniquely identify one <WHERE>.
2.Refactoring not supported
Changing class names does not change alongresource names when refactoring. So if you rename "MainActivity" to"ContentActivity", the layout "activity_main" won't berenamed to "activity_content". Hopefully Android Studio will one dayadd support for this.
3.Not all resource types supported
The proposed scheme currently does not yetsupport all resource types. For some resources this is because they are lessfrequently used and tend to be very varied (e.g. raw and assets). For otherresources this is because they are a lot harder to generalize (e.g. themes/styles/colors/animations).
Your apps colors palette likely wants toreuse the terminology of your design philosophy. Animations can range frommodest (fade) to very exotic. Themes and styles already have a naming schemethat allows you to implicitly inherit properties.