Android资源命名规范
2015-11-05 19:54
281 查看
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的图片资源
代码如下:
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即可。
最近几个月,大量涉及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的图片资源
代码如下:
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即可。
相关文章推荐
- [Android学习笔记一] ContentProvider组件开发详解
- Android基础入门教程——2.3.1 TextView(文本框)详解
- Android基础入门教程——2.2.6 AbsoluteLayout(绝对布局)
- Android基础入门教程——2.2.5 GridLayout(网格布局)
- Android基础入门教程——2.2.3 TableLayout(表格布局)
- Android基础入门教程——2.2.4 FrameLayout(帧布局)
- Android jdwp 原理
- Android基础入门教程——2.2.2 RelativeLayout(相对布局)
- Android之水平ProgressBar多彩背景颜色
- Android基础入门教程——2.2.1 LinearLayout(线性布局)
- Android实现欢迎界面的自动跳转
- Android 中的 Service 全面总结
- Android基础入门教程——1.2 开发环境搭建
- 分享个用Android Studio多渠道打包教程链接
- Android 中Handler
- Android HandlerThread
- Android ListView 使用及MVC关系概要
- android中if判断引起的crash
- Arcgis Android 常见问题
- android之AsyncTask