Android 国际化开发命名规范

原文地址：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.