是否有关于如何命名资源的约定？

是否有约定如何在Android中命名资源？例如，按钮，textViews，菜单等。

我不知道是否有官方建议。

对于具有小部件和容器的布局中的ID，我使用约定：

<layout>_<widget/container>_<name>

对于在这些布局中使用的所有变暗，字符串，数字和颜色，我都采用相同的策略。但是，我确实尝试概括。例如，如果所有按钮都具有通用的textColor，则不会在布局前添加名称前缀。资源名称将为“ button_textColor”。如果所有textColors都使用相同的资源，它将被命名为'textColor'。对于样式，通常也是如此。

对于菜单资源，我使用：

menu_<activity>_<name>

动画只是有所不同，因为您不能使用大写字母。我相信，可绘制的xml资源也是如此。

Android SDK将是一个不错的起点。

例如，我尝试在活动中确定ID的范围。

如果我有一个活动，ListView它将直接@android:id/list参与所有活动。
但是，如果我有两个列表，然后我会用更加具体@id/list_apple和@id/list_orange

因此，泛型（ids，...）在重新使用时会被重用，R.java file而唯一的（ids，...）在某些情况下会被重用下划线分隔的泛型前缀。

我观察到，下划线是一回事，例如：

布局宽度是layout_width在XML和layoutWidth中码，所以我尽量坚持下去的list_apple

因此，将有一个登录按钮login，但是如果我们有两个登录名，则login_foo和login_bar。

取自Android文档。关于这个主题还有更多。

要回答您的问题：是的。

例如，您可以通过Google搜索找到许多此类文件。而且没有最佳的命名约定。它始终取决于您的需求和项目属性（最重要的是范围）。

最近，我从Jeroen Mols 阅读了相当不错的博客文章，内容涉及Android XML中的资源命名。作者提到了所有资源都应遵循的基本原理，然后将这种约定应用于每种资源类型。两者都在Android资源命名备忘单上进行了描述：

然后，他详细描述了每个元素和每种资源类型。

我会说您可以在中小型项目中使用此约定（个人使用，几个月的合同申请）。虽然，我不建议在具有50多个活动或1000多个字符串的长期项目中使用它。

在如此大规模的项目中，关于资源价值的惯例需要对如何使用它们进行更多的研究。以字符串为例。可能会受到团队规模，正在使用的翻译中心（如果有），正在使用的VCS（例如，以避免合并冲突）等因素的影响。您甚至可能考虑将字符串拆分成多个文件。

我认为您正在寻找开始的东西。因此，我推荐我提到的博客文章。这对初学者很有好处，您绝对可以以此为灵感来创建自己的良好命名约定。

还请记住，随着项目的发展，许多需求和要求可能会随时间变化。因此，完全合适的做法是，最初适合的命名约定将在两年后不再适用。而且完全没问题。您不应该尝试预测未来。只需选择一个约定并遵守即可。您会发现它是否适合您和您的项目。如果不适合，请考虑为什么不适合并开始使用其他东西。

资源中使用了一些约定：

• 对于作为单独文件存在的资源，它们必须为lower_case_underscore_separated。appt工具可确保您的文件仅是小写，因为使用大小写混合会导致不区分大小写的文件系统出现问题。
• 对于仅在值/ ...（属性，字符串等）中声明的资源，约定通常为mixedCase。
• 有时会使用一种约定，以“分类”标记名称以具有简单的名称空间。例如，在这里您看到诸如layout_width和layout_alignLeft之类的内容。在布局文件中，即使视图和父布局管理是不同的所有者，它们的属性也会混合在一起。“ layout_ *”约定确保这些名称之间没有冲突，并且很容易理解该名称影响哪个实体。

此“ layout_blah”约定也已在其他一些地方使用。例如，有“ state_blah”属性，它们是视图可以具有的可绘制状态。

同样由于这两个约定（对于文件，使用underscore_separated，对于声明的资源，使用mixedCase），您会发现许多不一致之处。例如，可以使用文件或显式值声明颜色。通常，对于所有这些，我们都希望坚持使用underscore_separated，但这并不总是会发生。

最终，我们不必担心资源的命名约定。我们保持一致的一个主要方面是属性的“ mixedCase”，以及使用“ layout_blah”来标识布局参数属性。

另外，在此处浏览公共资源也应该使您对这些约定有一个良好的感觉：

http://developer.android.com/reference/android/R.html

您会看到所有属性都是非常一致的（只要您了解layout_约定），可绘制对象都是用underscore_separated等的。

对于任何一种语言或框架，这都是一个普遍的问题，但是只要您避免保留字，就可以假设您能记住自己所说的东西就可以了。

我确实注意到Android限制了xml资源文件名，但下划线似乎没问题。ADT实际上指出

基于文件的资源名称只能包含小写的az，0-9或_。

起初让我感到困扰的是缺少带有ID的名称空间，但是如果您有两个ID，则通常可以忽略这一点，而同一Android将仅重用已定义的ID。

对于id，我使用3字母限定符，后跟骆驼符号所指的内容，例如lblFoo表示静态文本标签（或textview），txtFoo表示可编辑文本框（Android中的edittext）。乍一看似乎很奇怪，但是自VB6以来，我一直在使用它，这些控件被称为标签和文本框。

这里是我更常用的一些：

• btnFoo-按钮
• 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＃中的WinForms和VB.NET，Android和Python中使用它们已有十多年了。我永远不需要记住Android是否将其称为文本框或edittext。我只需要知道lblFoo是静态标签，而txtFoo是用户在其中输入内容。

最后一点要注意的是，无论您决定采用哪种约定，重要的事情都是正确且一致地命名控件，这样您就不会为模糊的默认ID（例如TextView5或其他约定的混合物）所困扰。

对于设计师和开发人员的有用链接- 在这里

尺寸和大小，命名约定，样式和主题，九个补丁等等。

我认为Google没有推广任何标准约定。我见过人们以各种不同的方式命名事物的方法，即使在不同的官方Google应用程序中也是如此。

当试图在一个目录层次结构中理解100个布局（或可绘制对象，菜单等）文件时，对您有最大帮助的方法。

简短的答案：如果您想向Android开发人员学习，一个很好的例子是支持库v7（https://dl-ssl.google.com/android/repository/support_r21.zip）

否则，这就是我考虑的资源命名方式：
1.编写代码时轻松查找资源
2.读取代码时轻松理解资源
3.使名称对翻译者有用（R.string.*仅资源）
4.重复使用布局<include/>（R.id.*资源冲突）
5.处理与图书馆项目

从逻辑上讲，安排资源应该与将Java类分组到程序包（或将文件放入文件夹）没有什么不同。但是，由于Android资源没有名称空间，因此必须在资源名称中添加前缀以实现相同的名称（例如，com.example.myapp.photo成为com_example_myapp_photo）。

我建议将应用程序分为多个简短的唯一名称（可用作资源前缀）的独立组件（活动，片段，对话框等）。通过这种方式，我们将具有相关功能的资源分组在一起，这使它们易于查找（第1点），同时又避免了<include/>与库项目（第4点和第5点）的命名冲突。请注意，多个组件共有的资源仍可以带有前缀（例如R.string.myapp_ok_button）。

在前缀之后，名称应告诉我们该资源的用途（要执行的操作，要显示的内容等）。选择一个好名字对于理解很重要（要点2和3）。

有时，“ component_name”将为我们提供足够的信息，如果类型已经由R类提供，则尤其如此（在R.string.myapp_name_string第二个“字符串”中是多余的）。但是，显式添加类型可以改善理解（例如，对于翻译人员来说，区分吐司或标签可能会有所帮助）。有时，“名称”和“类型”部分可以互换，以允许基于类型的过滤（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  

如果您在Android文档中四处摸索，就会提及“最佳做法”，但是肯定没有具体的规则。例如，在“ 图标设计指南”中，Google建议使用“ ic_”前缀命名图标。

提供资源可能是一个不错的起点。

如果您想了解Google开发人员的工作方式，请在SDK源代码/示例以及Android开发人员博客中进行深入研究。

我发现了方便的字符串下一个命名约定：

[<action>]_<object>_<purpose>

例如，clear_playlist_text，delete_song_message，update_playlist_positivebutton_text。而且这里的“动作”是可选的。

您可以阅读Google文档中的代码样式以在此处了解想法

我通常遵循资源ID的Java命名约定（不适用于文件的文件），除了在ID之前添加“ x”例如：

<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（通常是android建议的命名约定）和xTvName在布局文件中被命名为android TextView的Id（x表示XML）的一部分，我遵循了此类对象的命名约定，例如Buttons和EditText等。

在XML IDS中：xViewTypeSpecificName

在Java中：mViewTypeSpeficName

当创建复杂的布局时，以上约定使我的生活更加轻松。只是尝试使您的名字尽可能短，并且最好让它们对其他共同开发者来说是可以理解和有意义的（但可能并非每次都一样），希望我的经验对他人有所帮助，欢迎提出建议。

在我们的android项目中，有很多组件，例如按钮，标签，文本框。如此简单的名称（例如“名称”）很难识别“名称”是标签还是文本框。主要是在维护其他开发人员开发的项目时发生。

因此，为了避免这种混淆，我在Buttons TextBoxes或Labels中使用了以下名称

范例：

 btnName
 labName
 txtName
 listName

可能对您有帮助。

有一些限制：

1. 资源名称应包含az，0-9，_
2. 资源名称应以az，_开头

顺便说一句，建议您遵循准则或从标准代码中学习。