Android资源命名规范

Android资源命名规范

最近几个月，大量涉及android资源的相关工作。对于复杂的应用而言，资源命名的规范很有必要。除了开发人员之外，UI设计人员（或者切图相关人员）也需要对资源使用的位置非常清楚，这样，沟通就会直接。缺点是资源名字长一些，但是从整体价值来看，值得。

命名模板为：缩写_主界面_功能部分

(一) 缩写：

ic ----------------------icon

bg---------------------background

di----------------------divider

sl-----------------------selector

cl-----------------------color

bt----------------------button

ic主要用在app的图标

bg主要用于布局和子布局的背景

di主要用于分隔线，不仅包括Listview中的divider，还包括普通布局中的线

sl主要用于某一view多种状态，不仅包括Listview中的selector，还包括按钮的selector

cl主要用于颜色值

bt主要用于按钮的表示，有时我们会在ic和bt之间犹豫，简单的区分即是功能视图，如果一个view执行的时back或者confirm或者cancel的功能，则命名上则应该使用bt

(二) 主界面：

主要的功能页面，即app主要的Activity。对于Browser而言，例如BrowserActivity，BookmarkActivity，SettingActivity，AboutActivity。

(三) 功能部分：

即每一个主界面对应的功能区域，以BrowserActivity为例，包含的功能部分：1，titlebar，2，speedial 3，toolbar，4，menu等

在这里注意的是，功能的划分，是以在某一个界面所显示的内容特点来区分。例如，虽然，menu由toolbar来控制，但是不在toolbar下再细分。

(四) 后缀名

unit--------------------------在使用xml的tilemode来配图片时，element图片使用此后缀

nor---------------------------图片的状态，代表普通状态

hl-----------------------------图片的状态，代表高亮状态

press-------------------------图片的状态，代表按下状态

select----------------------图片的状态，代表其所占的view被选中

unselect-------------------图片的状态，代表其所占的view没有被选中

(五) 其他

1， 对于功能而言，相对的状态，比如打开全屏和关闭全屏。那么对应的图片，应当为_fullscreen和_unfullscreen。这样，整齐统一，只需要记住一种状态的命名。

2， Xml中id的命名，建议直接根据意义命名，不必使用以上复杂的定位，因为findViewById只在某指定layout中find。

3，本文主要论述的theme相关的命名，其他的命名，这位同学总结的也不错，可以参考。

http://my.eoe.cn/yyz168/archive/5551.html

Android Application Theme的实现

一， 原理

1， theme的形式

    1-1 内置theme （一组特定前缀后缀的图片）

    1-2 外置theme (只包含规范命名图片的apk)

2， 实现

   根据特定theme获取指定图片资源，并设置在view上。

   步骤：

   2-1 获得指定包名的Context

   2-2 通过Context获得指定theme的图片资源

代码如下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

public  Context getThemeContext() {                 if  (mType == ThemeManager.THEME_TYPE_NATIVE)                        return  mDefContext ;                 if  (mContext !=  null )                        return  mContext ;                 if  (TextUtils.isEmpty( mPkg)                             || mDefContext.getPackageName().equals(mPkg ))                        mContext = mDefContext;                 try  {                        mContext = mDefContext.createPackageContext(mPkg ,                                    Context. CONTEXT_INCLUDE_CODE                                                  | Context.CONTEXT_IGNORE_SECURITY );                }  catch  (NameNotFoundException e) {                       e.printStackTrace();                }                 return  mContext ;         }

2-3 其他事件

    Theme的安装和卸载会影响theme列表，需要处理。

    Theme的切换需要update()

二， 关注点

1， 本质

    Theme架构完成之后，剩余的工作就是图片资源的管理。

   1-1规范的命名

    通过名字直接定位到具体页面的具体图标，这是目标。所以命名上的冗长是必须的。设计师和工    程师之间，会节约大量的沟通成本。

参看之前blog: http://mikewang.blog.51cto.com/3826268/1020693

   1-2流程

    大约完成几个theme之后，设计师和工程师会有基本的感觉，有一些重复的工作。相关人员，参与相应的讨论，优化流程。

设计师：

       设计方案的分类，基本类型涵盖三类

       使用ps模板，省却命名的时间（经验证明）

工程师：

       功能的细分，也有相应的模板。比如menu的实现有两种方式，则准备

       对UI的敏感，能迅速发现ui的错误，这需要时间培养。之前有总结，参看博文：

http://mikewang.blog.51cto.com/3826268/1003333

其他：鱼与熊掌的问题：图片资源的复用/额外的筛选工作量

复用包括两方面：

              一，复用主程序资源，比如背景

              二，theme内部资源的复用，比如back键

一旦涉及复用，其实每一套theme的图片的总数是不定的，需要筛选，

很麻烦，工作量不少。我现在倾向于设计师给出全版本的图。这样工程师

的工作只需要调图即可。如果按照这个工作流程，出去设计一个theme

半天就可以完成发布。

2， 架构的兼容性

   2-1 以设计为先导，用测试保证兼容性

   Theme的前提就是follow设计师的设计，所以代码上必须保持灵活性或者兼容性

以保证不同的设计能在一个架构下实现。所以至少在三类设计下测试，保证兼容性。

因为一旦发布出去，此主程序和此theme便产生一一对应的关联，未来主程序对一

Theme的兼容性修改，都有可能导致其他theme不兼容。

   2-2 主程序的升级和theme的升级

   当主程序不断增加新功能，对应的增加新UI元素。而已发布的theme需要增加一

些图片。通过定升级的协议，保证升级的提醒。

本文主要从技术点和项目管理方面谈了谈Theme，希望有所帮助。

附件给出theme workflow,需要修改文件名，删除后面的rar即可。