安卓编码规范

参考资料

1)、https://github.com/ribot/android-guidelines

1、IDE工具:

首推使用Android Studio,因为他是由谷歌开发,最接近Gradle,默认使用最新的工程结构,已经到release阶段(目前已经有release 2.2了),它就是为Android开发定制的。并使用Square's Java and Android projects code style settings作为code style。

2、Gradle 配置

常用结构参考Google's guide on Gradle for Android

小任务除了(shell, Python, Perl, etc)这些脚本语言,你也可以使用Gradle 制作任务。 更多信息请参考Gradle's documentation

密码在做版本release时你app的build.gradle你需要定义signingConfigs.此时你应该避免以下内容:

不要做这个. 这会出现在版本控制中。

signingConfigs {release {storeFile file("myapp.keystore")storePassword"password123"keyAlias"thekey"keyPassword"password789"}}

而是,建立一个不加入版本控制系统的gradle.properties文件。

KEYSTORE_PASSWORD=password123

KEY_PASSWORD=password789

那个文件是gradle自动引入的,你可以在buld.gradle文件中使用,例如:

signingConfigs {release {try{storeFile file("myapp.keystore")storePasswordKEYSTORE_PASSWORDkeyAlias"thekey"keyPasswordKEY_PASSWORD}catch(ex) {thrownewInvalidUserDataException("You should define KEYSTORE_PASSWORD and KEY_PASSWORD in gradle.properties.")}}}

使用 Maven 依赖方案代替使用导入jar包方案如果在你的项目中你明确使用了 jar文件,那么它们可能成为永久的版本,如2.1.1.下载jar包更新他们是很繁琐的, 这个问题Maven很好的解决了,这在Android Gradle构建中也是推荐的方法。你可 以指定版本的一个范围,如2.1.+,然后Maven会自动升级到制定的最新版本,例如:

dependencies {compile'com.netflix.rxjava:rxjava-core:0.19.+'compile'com.netflix.rxjava:rxjava-android:0.19.+'compile'com.fasterxml.jackson.core:jackson-databind:2.4.+'compile'com.fasterxml.jackson.core:jackson-core:2.4.+'compile'com.fasterxml.jackson.core:jackson-annotations:2.4.+'compile'com.squareup.okhttp:okhttp:2.0.+'compile'com.squareup.okhttp:okhttp-urlconnection:2.0.+'}

3、命名

3.1. 布局文件中的id命名

规则:使用驼峰命名,前缀+逻辑名称,类变量名和布局文件id名称保持一致,不需要下划线分割

控件缩写前缀

TextView/EditTexttext

ImageViewimg

Button/RadioButton/ImageButtonbtn

RelativeLayout/LinearLayout/FrameLayoutlayout

ListViewlistView

WebViewwebView

CheckBoxcheckBox

ProgressBarprogressBar

seekBarseekBar

其他控件控件名首字母缩写作为前缀

如:TextView @+id/textTitle

如:EditView @+id/textName

如:Button @+id/btnSearch

3.2. 布局文件命名

规则:使用前缀_逻辑名称命名,单词全部小写,单词间以 下划线 分割。

布局类型布局前缀

Activityactivity_

Fragmentfragment_

Includeinclude_

Dialogdialog_

PopupWindowpopup_

Menumenu_

Adapterrecycler_item_

3.3. 资源文件命名

规则:使用前缀_用途命名,单词全部小写,单词间以 下划线 分割。

图片资源文件命名

前缀说明

bg_xxx各类背景图片

btn_xxx这种按钮没有其他状态

ic_xxx图标,一般用于单个图标

bg_描述_状态1[_状态2]用于控件上的不同状态

btn_描述_状态1[_状态2]用于按钮上的不同状态

chx_描述_状态1[_状态2]选择框,一般有2态和4态

第三方资源文件,不管在value、drawable

必须携带第三方资源前缀

umeng_socialize_style.xml

pull_refresh_attrs.xml

3.4. 类和接口命名

规则:使用驼峰规则,首字母必须大写,使用名词或名词词组。要求简单易懂,富于描述,不允许出现无意义或错误单词。

类描述例如

Application类Application为后缀标识XXXApplication

Activity类Activity为后缀标识闪屏页面类SplashActivity

解析类Handler为后缀标识

公共方法类Utils或Manager为后缀标识

线程池管理类ThreadPoolManager

日志工具类LogUtils

数据库类以DBHelper后缀标识MySQLiteDBHelper

Service类以Service为后缀标识播放服务:PlayService

BroadcastReceiver类以Broadcast为后缀标识时间通知:TimeBroadcast

ContentProvider类以Provider为后缀标识单词内容提供者:DictProvider

直接写的共享基础类以Base为前缀BaseActivity,BaseFragment

3.5. 方法的命名

规则:使用驼峰规则,首字母必须小写,使用动词。要求简单易懂,富于描述,不允许出现无意义或错误单词。

方法说明

initXX()初始化相关方法,使用init为前缀标识,如初始化布局initView()

httpXX()http业务请求方法,以http为前缀标识

getXX()返回某个值的方法,使用get为前缀标识

saveXX()与保存数据相关的,使用save为前缀标识

deleteXX()删除操作

resetXX()对数据重组的,使用reset前缀标识

clearXX()清除数据相关的

isXX()方法返回值为boolean型的请使用is或check为前缀标识

processXX()对数据进行处理的方法,尽量使用process为前缀标识

displayXX()弹出提示框和提示信息,使用display为前缀标识

drawXXX()绘制数据或效果相关的,使用draw前缀标识

3.6. 变量命名

规则:使用驼峰规则,首字母必须小写,使用名词或名词词组。要求简单易懂,富于描述,不允许出现无意义或错误单词。

成员变量命名,自定义变量前添加m前缀,布局控件变量不用添加m前缀

常量命名,全部大写,单词间用下划线隔开

4、资源文件 Resources

命名遵循前缀表明类型的习惯,形如type_foo_bar.xml。例如:fragment_contact_details.xml,view_primary_button.xml,activity_main.xml.

组织布局文件若果你不确定如何排版一个布局文件,遵循一下规则可能会有帮助。

考虑使用Designtime attributes 设计时布局属性,Android Studio已经提供支持,而不是硬编码android:text(译者注:墙内也可以参考stormzhang的这篇博客链接)。

作为一个经验法则,android:layout_****属性应该在 layout XML 中定义,同时其它属性android:****应放在 style XML中。此规则也有例外,不过大体工作的很好。这个思想整体是保持layout属性(positioning, margin, sizing) 和content属性在布局文件中,同时将所有的外观细节属性(colors, padding, font)放在style文件中。

例外有以下这些:

android:id明显应该在layout文件中

layout文件中android:orientation对于一个LinearLayout布局通常更有意义

android:text由于是定义内容,应该放在layout文件中

有时候将android:layout_width和android:layout_height属性放到一个style中作为一个通用的风格中更有意义,但是默认情况下这些应该放到layout文件中。

使用styles几乎每个项目都需要适当的使用style文件,因为对于一个视图来说有一个重复的外观是很常见的。 在应用中对于大多数文本内容,最起码你应该有一个通用的style文件,例如:

@dimen/font_normal@color/basic_black

应用到TextView 中:

你或许需要为按钮控件做同样的事情,不要停止在那里。将一组相关的和重复android:****的属性放到一个通用的style中。

将一个大的style文件分割成多个文件你可以有多个styles.xml文件。Android SDK支持其它文件,styles这个文件名称并没有作用,起作用的是在文件 里xml的标签。因此你可以有多个style文件styles.xml,style_home.xml,style_item_details.xml,styles_forms.xml。 不用于资源文件路径需要为系统构建起的有意义,在res/values目录下的文件可以任意命名。

colors.xml是一个调色板在你的colors.xml文件中应该只是映射颜色的名称一个RGBA值,而没有其它的。不要使用它为不同的按钮来定义RGBA值。

不要这样做

#FFFFFF#2A91BD#5F5F5F#939393#FFFFFF#FF9D2F...#323232

使用这种格式,你会非常容易的开始重复定义RGBA值,这使如果需要改变基本色变的很复杂。同时,这些定义是跟一些环境关联起来的,如button或者comment, 应该放到一个按钮风格中,而不是在color.xml文件中。

相反,这样做:

#FFFFFF#323232#888888#dddddd#999999#27D34D#2A91BD#FF9D2F#FF432F

向应用设计者那里要这个调色板,名称不需要跟"green", "blue", 等等相同。 "brand_primary", "brand_secondary", "brand_negative" 这样的名字也是完全可以接受的。 像这样规范的颜色很容易修改或重构,会使应用一共使用了多少种不同的颜色变得非常清晰。 通常一个具有审美价值的UI来说,减少使用颜色的种类是非常重要的。

像对待colors.xml一样对待dimens.xml文件与定义颜色调色板一样,你同时也应该定义一个空隙间隔和字体大小的“调色板”。 一个好的例子,如下所示:

22sp18sp15sp12sp40dp24dp14dp10dp4dp60dp40dp32dp

布局时在写 margins 和 paddings 时,你应该使用spacing_****尺寸格式来布局,而不是像对待String字符串一样直接写值。 这样写会非常有感觉,会使组织和改变风格或布局是非常容易。

避免深层次的视图结构有时候为了摆放一个视图,你可能尝试添加另一个LinearLayout。你可能使用这种方法解决:

即使你没有非常明确的在一个layout布局文件中这样使用,如果你在Java文件中从一个view inflate 到其他views当中,也是可能会发生的。

可能会导致一系列的问题。你可能会遇到性能问题,因为处理起需要处理一个复杂的UI树结构。 还可能会导致以下更严重的问题StackOverflowError.

因此尽量保持你的视图tree:学习如何使用RelativeLayout, 如何optimize 你的布局和如何使用标签.

小心关于WebViews的问题.如果你必须显示一个web视图, 比如说对于一个新闻文章,避免做客户端处理HTML的工作, 最好让后端工程师协助,让他返回一个 "" HTML。WebViews 也能导致内存泄露当保持引他们的Activity,而不是被绑定到ApplicationContext中的时候。 当使用简单的文字或按钮时,避免使用WebView,这时使用TextView或Buttons更好。

TextView使用官方标准字体

style="@style/TextAppearance.AppCompat.Display4"style="@style/TextAppearance.AppCompat.Display3"style="@style/TextAppearance.AppCompat.Display2"style="@style/TextAppearance.AppCompat.Display1"style="@style/TextAppearance.AppCompat.Headline"style="@style/TextAppearance.AppCompat.Title"style="@style/TextAppearance.AppCompat.Subhead"style="@style/TextAppearance.AppCompat.Body2"style="@style/TextAppearance.AppCompat.Body1"style="@style/TextAppearance.AppCompat.Caption"style="@style/TextAppearance.AppCompat.Button"

5、项目结构

如果项目比较小的话:

app——Application Activity Fragment Presenter等的顶级父类

config——API,常量表等

model——数据层

entities——数据模型

presenter——MVP的P

view——MVP的V

utils——工具类集合

widget——各个可复用View集合

如果项目比较大,上面的方式一定会造成presenter和view里近百个文件。 推荐下列方式:

app

config

model

entities

module——将界面层以功能模块分配包。

launch

main

account

news

music

……

utils

widget

#6、配置主题

##6.1 先在color.xml中写好需要的颜色:

#ff5722#673AB7#311B92#fff#888888#dddddd#999999

注意color.xml是配色表。应该是描述颜色而不是对字体颜色,背景颜色等的定义。这样能防止相近的颜色重复定义,而导致界面颜色不统一。

##6.2 在style.xml里定义主题:

@color/DeepPurple@color/DeepPurple900@color/Orange

在res目录下,创建一个values-v21目录,再创建一个style.xml:

true?colorPrimaryDark

然后在AndroidManifest.xml文件中修改application的theme属性为上面定义的AppTheme,即可实现沉浸式状态栏。

7、 其他规范

Activity继承BaseFragmentActivity或SwipeBackActivity,可以使用ButterKnife注解代替findViewById

方法

拆分臃肿方法,每个方法只作一件事

做同一个逻辑的方法,尽量靠近放到一块,方便查看

不要使用 try catch 处理业务逻辑

使用JSON工具类,不要手动解析和拼装数据

控制语句

减少条件嵌套,不要超过3层

if判断使用“卫语句”,减少层级if(obj != null) { doSomething(); }修改为:if(obj == null) { return; } doSomething();

if语句必须用{}包括起来,即便是只有一句

处理“魔数”等看不懂的神秘数字

代码中不要出现数字,特别是一些标识不同类型的数字。

所有意义数字全部抽取到Constant公共类中,避免散布在各位类中。

空行:空行将逻辑相关代码段隔开,简洁清楚,提高可读性

成员变量之间,根据业务形成分组加空行

方法之间加空行

用好TODO标记

记录想法,记录功能点,开发过程中可以利用TODO记录一下临时想法或为了不打扰思路留下待完善的说明

删除无用TODO,开发工具自动生成的TODO,或则已经完善的TODO,一定要删除。

##8、写在最后

什么是架构 软件架构绝对不只是框架的堆砌,架构是为了方便软件可维护、可扩展、安全性、易理解。

##9、附录A软件设计六大原则:

单一职责原则 - Single Responsibility Principle

应该有且仅有一个原因引起类的变更。(如果类需要变更,那么只可能仅由某一个原因引起)

里氏替换原则 - Liskov Substitution Principle

所有引用基类的地方,都能透明地替换成其子类对象。只要父类能出现的地方,子类就可以出现。

依赖倒置原则 - Dependence Inversion Principle:

即“面向接口编程”: 高层模块不应该依赖低层模块,两者都应该依赖其抽象;——模块间的依赖通过抽象发生。实现类之间不发生直接的依赖关系(eg. 类B被用作类A的方法中的参数),其依赖关系是通过接口或抽象类产生的; 抽象不应该依赖细节;——接口或抽象类不依赖于实现类; 细节应该依赖抽象;——实现类依赖接口或抽象类。

接口隔离原则 - Interface Segregation Principle

客户端只依赖于它所需要的接口;它需要什么接口就提供什么接口,把不需要的接口剔除掉。 ——类间的依赖关系应建立在最小的接口上。 即,接口尽量细化,接口中的方法尽量少。

迪米特法则 - Law of Demeter

又称最少知识原则(Least Knowledge Principle),一个对象应该对其他对象有最少的了解。 一个类对自己依赖的类知道的越少越好。也就是说,对于被依赖的类来说,无论逻辑多么复杂,都尽量地的将逻辑封装在类的内部,对外除了提供的public方法,不对外泄漏任何信息。

开闭原则 -Open Closed Principle

对扩展开放,对修改关闭。一个软件实体应该通过扩展来实现变化,而不是通过修改已有代码来实现变化。 一个软件实体应该通过扩展来实现变化,而不是通过修改已有的代码来实现变化。——but,并不意味着不做任何修改;底层模块的扩展,必然要有高层模块进行耦合。 “变化”可分为三种类型: 逻辑变化——不涉及其他模块,可修改原有类中的方法; 子模块变化——会对其他模块产生影响,通过扩展来完成变化; 可见视图变化——界面变化,有时需要通过扩展来完成变化。




原文:https://github.com/qsxiaogang/android-code-style

推荐阅读更多精彩内容

  • Android 自定义View的各种姿势1 Activity的显示之ViewRootImpl详解 Activity...
    passiontim阅读 131,345评论 19 558
  • 文章来自https://github.com/Blankj/AndroidStandardDevelop#安卓开发...
    小庄bb阅读 111评论 0 1
  • Android 编码规范 1. 前言 这份文档是 Google Java Code Style 的译文,并稍有添加...
    人失忆阅读 122评论 0 3
  • 我们总是被父母被老师教导这不能那不能也就慢慢的懂得了一套行为标准,也就养成了大人的循规蹈矩。 现在任何一种行为准则...
    梦游世界阅读 31评论 0 0
  • 身在人潮拥挤的城市,心在空无人烟的空城!2016年的最后一天了,身边没有亲人,没有友人,没有爱人。只有手机和电脑里...
    我是万傲娇阅读 15评论 0 0