有关如何命名资源的约定？
有什么约定如何在Android中命名资源？ 例如，button，文本视图，菜单等
我不知道有没有官方的build议。
对于具有小部件和容器的布局中的id，我使用惯例：
<layout>_<widget/container>_<name> 我对这些布局中的任何维度，string，数字和颜色都采用相同的策略。 不过，我尝试推广。 例如，如果所有的button都有一个共同的textColor，我不会在名称前加布局。 资源名称将是'button_textColor'。 如果所有的textColors使用相同的资源，它将被命名为“textColor”。 对于样式，这通常也是如此。
对于我使用的菜单资源：
menu_<activity>_<name>
animation只是不同的，因为你不能使用大写字母。 我相信，同样的可绘制的XML资源。
Android SDK将是一个很好的开始。
例如，我尝试在活动中范围ID。
如果我有一个ListView它只是在所有的活动@android:id/list 。
但是，如果我有两个列表，那么我会使用更具体的@id/list_apple和@id/list_orange
所以generics（ids，…）被重用在R.java file而唯一的（有时被重用）前缀是用下划线分隔的generics。
我注意到，下划线是一回事，例如：
布局的宽度是xml中的layout_width和代码中的 layoutWidth ，所以我尝试把它作为list_apple
所以一个loginbutton将被login ，但是如果我们有两个login，那么login_foo和login_bar 。
来自Android的文档 。 这个问题上还有更多。
有几个公约用于资源：
- 对于作为单独文件存在的资源，它们必须是lower_case_underscore_separated。 该appt工具确保您的文件只是小写，因为使用混合大小写可能会导致不区分大小写的文件系统的问题。
- 对于仅在values / …（属性，string等）中声明的资源，约定通常是mixedCase。
- 有时会使用一种惯例来标记具有“分类”的名称以具有简单的名称空间。 这是例如你看到layout_width和layout_alignLeft之类的东西的地方。 在布局文件中，View和父级布局pipe理的属性混合在一起，尽pipe它们是不同的所有者。 “layout_ *”约定确保这些名称之间不存在冲突，并且很容易理解该名称所影响的实体。
这个“layout_blah”公约也被用在其他一些地方。 例如，“state_blah”属性是一个视图可以绘制的状态。
同样由于这两个约定（下划线为文件，混合套用声明的资源），你会发现一些不一致的地方。 例如颜色可以用文件或显式值声明。 一般来说，我们希望坚持所有这些的underscore_separated，但它并不总是发生。
最终我们并不担心命名资源的约定。 我们保持一致的最大的是属性的“mixedCase”，以及使用“layout_blah”来标识布局参数属性。
另外浏览这里的公共资源应该给这些公约带来良好的感觉：
http://developer.android.com/reference/android/R.html
你会看到这些属性都是非常一致的（因为你了解layout_ convention），drawables都是underscore_separated，等等。
回答你的问题：是的，有。
你可以通过谷歌searchfind很多例子。 而且没有最好的命名约定。 它总是取决于你的需求和你的项目属性（最重要的是范围）。
最近，我已经阅读了Jeroen Mols在Android XML中命名资源的相当不错的博客文章 。 作者提到所有资源应该遵循的基本原则，然后如何将这个约定应用于每种资源types。 在Android资源命名备忘单上都有描述：
然后他详细描述每个元素和每种资源types。
我会说你可以使用这个从小到中的项目（个人使用，几个月合同申请）的约定。 虽然，我不会推荐它用于像50+活动或1000多个string的长时间项目。
在如此大规模的项目中，资源价值的公约需要更多的关于如何使用这些项目的调查。 以string为例。 可能受到团队规模，使用的翻译中心（如果有），您正在使用的VCS （避免合并冲突）等因素的影响。您甚至可能会考虑将string拆分为多个文件。
我假设你正在寻找一些开始。 所以我会推荐我提到的博客文章。 对于初学者来说，这是很好的，你可以将它作为灵感来创build你自己的良好命名约定。
同时请记住，随着项目的增长，许多需求和需求可能会随时间而改变。 所以，一开始适合的命名惯例2年后就不适合了。 而且完全没问题。 你不应该试图预测未来。 只要select一个约定，并遵循它。 你会发现，如果它适合你和你的项目。 如果没有，请考虑为什么它不适合，并开始使用别的东西。
这是任何语言或框架的常见问题，但只要您避免使用保留字，您应该可以记住所谓的东西。
我没有注意到，Android放置在XML资源文件名称restrction，但下划线似乎是好的。 ADT实际上指出
基于文件的资源名称只能包含小写的az，0-9或_。
起初让我感到沮丧的是缺less带有id的命名空间，但是如果你有两个id，那么通常可以忽略这个id，同样的Android只会重用定义的id。
对于id，我使用了3字母限定词，后面跟着骆驼表示法，例如用于静态文本标签（或textview）的lblFoo，用于可编辑文本框（Android中的edittext）的txtFoo。 这可能起初看起来很奇怪，但自从VB6以来，我一直在使用它，而这些控件被称为标签和文本框。
这里有一些我常用的：
- btnFoo – button
- pwdFoo – 密码
- lstFoo – 列表
- clrFoo – 颜色
- tblFoo – 表
- colFoo – 专栏
- rowFoo – 行
- imgFoo – 图像
- dimFoo – 维度
- padFoo – 填充
- mrgFoo – 保证金
我在java文件中的代码中也使用了相同的代码，所以我不必考虑这个问题，包的范围会让人很开心：
Button btnFoo = (Button)findViewById(R.id.btnFoo);
你可以，如果你喜欢使用下划线，即btn_foo添加一个小间距…我可能会这样做，如果我可以打破旧习惯。
有些人可能会认为缩写这些可能不是理想的，纯粹主义者会争辩说应该使用全名，但是当你命名了几十个控制，并在不同的系统和框架之间转换时，全名就失去了意义，已经在VB，C ++，ASP.NET，C＃和VB.NET，Android和Python中使用了十多年的WinForms。 我从来不需要记住Android是否将其称为文本框或编辑文本。 我需要知道的是lblFoo是静态标签，txtFoo是用户input的内容。
最后一点要注意的是，无论您决定什么样的惯例，重要的事情都是正确和一致地命名控件，以便您不要使用模糊的默认id，例如TextView5或不同惯例的混合
我认为Google没有任何标准惯例。 我已经看到人们用各种不同的方式命名内容，甚至在不同的官方Google应用程序中。
当试图理解一个目录层次结构中的100个布局（或可绘制，菜单等）文件时，无论最有帮助的是什么。
有用的链接devise师和开发人员 – 在这里
尺寸和大小，命名约定，风格和主题，九补丁等。
如果你在Android的文档中徘徊，有很多提到的“最佳实践”，但是当然没有具体的规则。 例如，在图标devise指南中 ，Googlebuild议使用“ic_”前缀命名图标。
一个好的开始可能是提供资源 。
如果您想了解Google开发人员如何执行操作，还可以在SDK源代码/示例以及Android开发人员博客中进行挖掘。
简短的回答：如果您想从Android开发人员那里学习，一个很好的例子就是支持库v7（ https://dl-ssl.google.com/android/repository/support_r21.zip ）
否则，这就是我已经考虑的命名资源：
1.编写代码时很容易find资源
2.阅读代码时容易理解资源
3.使译员名字有用（ R.string.*资源）
4.使用<include/> R.id.*资源冲突）重复使用布局
5.处理图书馆项目
从逻辑上讲，安排资源应该与将java类分组到软件包（或将文件放入文件夹）没有区别。 但是，由于Android资源没有命名空间，因此必须将前缀添加到资源名称才能实现相同（例如com.example.myapp.photo变为com_example_myapp_photo ）。
我build议将应用程序分成独立的组件（活动，片段，对话框等），并使用简短的唯一名称作为资源前缀。 通过这种方式，我们将资源与相关function组合在一起，这使得它们很容易find（点1），同时避免了与<include/>和库项目（点4和5）的命名冲突。 请注意，多个组件共有的资源仍可能有一个前缀（如R.string.myapp_ok_button ）。
在前缀之后，名称应该告诉我们资源用于什么（要执行的动作，要显示的内容等）。 select一个好名字对于理解很重要（第2点和第3点）。
有时候，“component_name”会给我们足够的信息，如果types已经由R类给出（尤其是在R.string.myapp_name_string ，第二个“string”是冗余的），那么情况尤其如此。 但是，明确添加types可以增进理解（例如，翻译人员可以帮助区分敬酒或标签）。 有时，“名称”和“types”部分可以交换，以允许基于types的过滤（ R.string.photo_menu_*将只给我们与菜单相关的项目的照片组件）。
假设我们正在编写一个拍照活动，类com.example.myapp.photo。PhotoActivity。 我们的资源可能如下所示（按“照片”组件分组）：
R.layout.photo //if only a single layout is used R.menu.photo R.string.photo_capture_instructions_label R.id.photo_capture_instructions_label R.id.photo_capture_button R.id.photo_capture_image R.drawable.photo_capture_placeholder R.dimen.photo_capture_image_height
我发现方便的下一个string的命名约定：
[<action>]_<object>_<purpose>
例如，clear_playlist_text，delete_song_message，update_playlist_positivebutton_text。 而“行动”在这里是可选的。
你可以阅读代码风格的谷歌文档来在这里得到一个想法
除了我在id前添加“x”之外，我通常遵循资源id的java命名约定（不适用于文件的文件），例如：
<TextView android:id="@+id/xTvName" android:layout_width="wrap_content" android:layout_height="wrap_content"></TextView>
在java中我们可以简单地使用它（我们也可以简单地记住）
TextView mTvName=(TextView)findViewById(R.id.xTvName);
这里mTvName（这是一般的androidbuild议的命名约定）和xTvName在布局文件中命名为android textview的id（x用于XML）的一部分，我遵循这种types的命名约定的视图对象，如button和EditText等。
在XML IDS中： xViewTypeSpecificName
在Java中： mViewTypeSpeficName
当我创build复杂的布局时，上述约定使我的生活更加轻松。 试着尽可能使自己的名字短一些，如果对其他合作开发者来说是可以理解和有意义的（但是不可能每次都是这样），希望我的经验能够帮助别人，build议也是值得欢迎的。
在我们的android项目中有很多像button，标签，文本框等组件。 所以简单的名字，如“名称”这是非常混乱，以确定“名称”是标签或文本框。 主要发生在维护其他开发人员开发的项目时。
所以为了避免这种混乱，我使用了button文本框或标签的名称
例如：
btnName labName txtName listName
可能是这对你有帮助。
有一些限制：
- 资源名称应该包含az，0-9，_
- 资源名称应该以az，_
顺便说一下，遵循指导方针或从标准代码学习更为明智。
