开发规范
首先，我这篇开发规范，只是针对于刚进入职场的萌新来写的，已经形成自己开发风格的可以自行绕过。其次，这些也只是我在工作当中自己总结的一些经验，也许有不恰当，大家可以共同讨论。最后，所谓规范，我只想说，这个东西并不是限制每个人开发的囚笼，只是为了一个团队更快、更好、更有效的阅读他人代码的助力，所以，千万别说什么都要按照这个来，那要注释干什么呢~~~（这个只是对那些死板的学院派吐槽啊，不喜随便喷）
现在来讲讲我对开发规范化的理解：
1、常量与变量
这个是所有开发人员对于命名最头疼的一个地方，为什么这么说呢，常量一般来说都是用来判断状态或者说是有功能性的，如果命名不够干净整洁，当其他人看代码的时候，很难理解该常量的用途，这样问题就来了，到底该如何命名呢？
我在开发初始的时候，采用的是以功能名称_模块。
例：
public static final int LOGIN_CLIENT=1;
这样看起来是真的很唯美，但是大家忽略了一个重要的问题，功能很直观，模块很清晰，但是他的用途在哪呢？很多人还需要找代码，然后看的一脸懵逼。
这时，我觉得很不直观，而且，在我接手其他人代码的时候，一直都是在找找找，我真是想仰天长叹一句玛德智障。
我采取了《代码整洁之道》中，对常量命名的方式，以功能名称_所在模块_常量用途_是否通用来命名，这样在他人阅读代码的过程中，可以最有效的了解常量的用途。
例：
public static final int LOGIN_CLIENT_STATUE_NOTCOMM = 1;
当然在记录某个值的时候，就需要以记录值名称_功能名称_所在模块_常量用途_是否通用来记录；
public static final String USERNAME_LOGIN_CLIENT_SAVE_COMM = “123”;
现在常量说完了，该说变量了，变量在android开发中，我认为可以分为两类，第一类，就是不同的变量，这类变量，我建议使用驼峰式命名，直观且有效。
例：
public int mClientStatue = 0;
注：我的朋友们啊，你们可千万别写个int a = 0；这玩意就是上帝什么的也猜不透你这个变量是要干什么。
第二类，就是android中的控件变量，这类变量一般是表示控件在当前界面中的功能。
一般采用三种命名方式：
1、采用控件缩写_功能_描述
例：
public TextView tv_login_username；
2、采用以m开头+功能+描述+控件
例：
public TextView mLoginUsernameTextView;
3、采用以控件缩写+功能+描述
例：
public TextView tvLoginUsername
注：
在这个方面没有明确的规范，开发中都可以，但是第二种方式，是android原生的命名方式，在这方面还是看企业的要求，再次就不做强行要求了。
2、类名
首先为大家附上一个我做的表格，这个表格只是比较笼统的来说明，大家可以作为了解性质的观看，后面会意义为大家讲解。
类描述例如
Activity 类Activity为后缀标识欢迎页面类WelcomeActivity
Adapter类Adapter 为后缀标识新闻详情适配器 NewDetailAdapter
解析类Parser为后缀标识首页解析类HomePosterParser
工具方法类Util或Manager为后缀标识（与系统或第三方的Utils区分）或功能+Util线程池管理类：ThreadPoolManager日志工具类：LogUtil（Logger也可）
打印工具类：PrinterUtil
数据库类以DBHelper后缀标识新闻数据库：NewDBHelper
Service类以Service为后缀标识时间服务TimeService
Receiver类以Receiver为后缀标识推送接收JPushReceiver
ContentProvider以Provider为后缀标识
自定义的共享基础类以Base开头BaseActivity,BaseFragment
在大家看完这个表格之后，大概有了个了解，现在为大家讲解下，几个在开发中比较常见的类的命名。
1、Activity类
先在这里说一句，这个表格制作的比较笼统，有时候可能会对大家造成误导，为什么这么说呢，
因为在开发，大家可能会开发很多很多模块，这时大家，就会出现根据功能进行分包来区分不同的功能，这时，你单独的用单词来描述可能会让阅读代码的人出现短暂的混乱。
而且，随着用户的需求越来越多，可能对于单一模块，所需求的功能点也越来越多，如果单独放在一个package里面，维护人员会很难定位到相应的类中，所以可能在模块中，又会对功能进行区分。这时，Activity的准确命名就尤为重要了。
在这里，我主要采用的命名方式是模块名称+功能点+Activity后缀标识
例：
用户的修改密码界面：UserChangePwdActivity
注：这种命名方法我觉得基本大家都能读懂，如果在同功能点的时候，存在不同的分支，可以在功能点后加上一些描述。
2、Adapter类
这里的大家都应该知道，Adapter类主要用于ListView、GridView或者RecycleView这中控件，所以我的建议还是用引用Adapter的类名去命名就好。
例：
商户客户列表页使用的Adapter:ShopClientAdapter;
3、Receiver类
现在开发中，Receiver我认为的作用都是有明确的目的性，每个Receiver都会有其在项目精确定位的功能点，所以，在此时咱们对于Receiver的名称，把功能说明白就哦了。
例：时间通知TimeReceiver
4、Service类
这个类要特别说一下，其实我在看开源代码的时候，有些人会使用Service，但是命名一直都不是很有针对性，有可能会出现让人读起来很莫名其妙的感觉，所以呢 ，我才用自己的一套命名方法，就是功能点+功能分类+Service
例：ShopTimeService
注：其实这样会增多Service的个数，但是我个人认为Service在项目中使用并不是很多，所以多一两个也是可以接受的，同时可以单独去区分，从后期功能修改也是有又是的。
5、Utils类
这个我一定要使劲的说啊，这个东西的命名真是让我吃了很多苦头，在最初工作的时候，真的是因为各种各样的命名与功能不符，那真的让人猛掉头发啊。
再发现了这些问题后，我就开始规范Utils这个类，说真的这个在看了多篇博文后，我觉得还是用两种方式去命名比较好。
这个Utils是否是Common的，这种通用的Utils类，我才用的方式Com+功能+Utils
例如：ComScreenUtils
如果不是通用时，采用使用Utils的模块+功能+Utils（基本很少有不通用的哈）；
例如：ShopSendCarUtils;
还有一种方式，就是根据功能详尽描述去命名，会用两三个单词讲解清楚。
例如：AppVersionUtils;
剩下的在开发中，使用的就比较少了，大家依照表格和讲解相结合的命名就好了。^^
3、方法
动词或动名词，采用小驼峰命名法例如:onCreate(),run()
方法说明
initXX()初始化相关方法,使用init为前缀标识，如初始化布局initView()
isXX()checkXX()方法返回值为boolean型的请使用is或check为前缀标识
getXX()返回某个值的方法，使用get为前缀标识
processXX()对数据进行处理的方法，尽量使用process为前缀标识
displayXX()弹出提示框和提示信息，使用display为前缀标识
saveXX()与保存数据相关的，使用sav为e前缀标识
resetXX()对数据重组的，使用reset前缀标识
clearXX()清除数据相关的
removeXXX()清除数据相关的
drawXXX()绘制数据或效果相关的，使用draw前缀标识
4、资源文件（图片drawable文件夹下）
全部小写，采用下划线命名法，加前缀区分命名模式：activity名称_逻辑名称/common_逻辑名称
如果有多种形态如按钮等除外如btn_xx.xml（selector）
名称功能
btn_xx按钮图片使用btn_整体效果（selector）
btn_xx_normal按钮图片使用btn_正常情况效果
btn_xx_press按钮图片使用btn_点击时候效果
bg_head背景图片使用bg_功能_说明
def_search_cell默认图片使用def_功能_说明
icon_more_help图标图片使用icon_功能_说明
seg_list_line具有分隔特征的图片使用seg_功能_说明
sel_ok选择图标使用sel_功能_说明
命名后缀：
后缀说明
unit在使用xml的tilemode来配图片时，element图片使用此后缀
nor图片的状态，代表普通状态
hl图片的状态，代表高亮状态
press图片的状态，代表按下状态
select图片的状态，代表其所占的view被选中
unselect图片的状态，代表其所占的view没有被选中
5、资源布局文件（XML文件（layout布局文件））：
全部小写，采用下划线命名法
1)．contentview命名, Activity默认布局，以去掉后缀的Activity类进行命名。不加后缀：
功能模块.xml
例如：main.xml、more.xml、settings.xml
或则：activity_功能模块.xml
例如：activity_main.xml、activity_more.xml
2)．Dialog命名：dialog_描述.xml
例如：dlg_hint.xml
3)．PopupWindow命名：pop_描述.xml
例如：ppw _info.xml
4). 列表项命名listitem_描述.xml
例如：listitem_city.xml
5)．包含项：include_模块.xml
例如：include_head.xml、include_bottom.xml
6)．adapter的子布局：功能模块_item.xml
例如：main_item.xml、
6、动画文件（anim文件夹下）：
全部小写，采用下划线命名法，加前缀区分。
//前面为动画的类型，后面为方向
动画命名例子规范写法
fade_in淡入
fade_out淡出
push_down_in从下方推入
push_down_out从下方推出
push_left推像左方
slide_in_from_top从头部滑动进入
zoom_enter变形进入
slide_in滑动进入
shrink_to_middle中间缩小
7、layout中的id命名
命名模式为：view缩写_模块名称_view的逻辑名称
view的缩写详情如下：
控件缩写
LayoutViewlv
RelativeViewrv
TextViewtv
Buttonbtn
ImageButtonimgBtn
ImageViewmgView 或则 iv
CheckBoxchk
RadioButtonrdoBtn
analogClockanaClk
DigtalClockdgtClk
DatePickerdtPk
EditTextedtTxt
TimePickertmPk
toggleButtontglBtn
ProgressBarproBar
SeekBarskBar
AutoCompleteTextViewautoTxt
ZoomControlszmCtl
VideoViewvdoVi
WdbViewwebVi
RantingBarratBar
Tabtab
Spinnerspn
Chronometercmt
ScollViewsclVi
TextSwitchtxtSwt
ImageSwitchimgSwt
listViewlVi 或则lv
ExpandableListepdLt
MapViewmapVi
Android编码规范建议（别人弄的觉得蛮有道理）
1.Java代码中不出现中文，最多注释中可以出现中文
2.局部变量命名、静态成员变量命名
只能包含字母，单词首字母除第一个外，都为大写，其他字母都为小写
3.常量命名
只能包含字母和_，字母全部大写，单词之间用_隔开
4.图片尽量分拆成多个可重用的图片
5.服务端可以实现的，就不要放在客户端
6.引用第三方库要慎重，避免应用大容量的第三方库，导致客户端包非常大
7.处理应用全局异常和错误，将错误以邮件的形式发送给服务端
8.图片的.9处理
9.使用静态变量方式实现界面间共享要慎重
10.Log(系统名称模块名称接口名称，详细描述)
11.单元测试（逻辑测试、界面测试）
12.不要重用父类的handler，对应一个类的handler也不应该让其子类用到，否则会导致message.what冲突
13.activity中在一个View.OnClickListener中处理所有的逻辑
14.strings.xml中使用%1$s实现字符串的通配
15.如果多个Activity中包含共同的UI处理，那么可以提炼一个CommonActivity，把通用部分叫由它来处理，其他activity只要继承它即可
16.使用button+activitgroup实现tab效果时，使用Button.setSelected(true)，确保按钮处于选择状态，并使activitygroup的当前activity与该button对应
17.如果所开发的为通用组件，为避免冲突，将drawable/layout/menu/values目录下的文件名增加前缀
18.数据一定要效验，例如
字符型转数字型，如果转换失败一定要有缺省值；
服务端响应数据是否有效判断
(这个真的是从一篇博文里面看到的，真的觉的很有道理，所以引用过来)
整篇文章写完了，把自己的一点心得写了出来，希望大家能够喜欢，也希望大家能够互相交流。
仅供参考，只要形成一个团体上的统一即可，简单知道他的意思就可以了。
程序员养成良好的编码习惯和命名规范，对于自己和整个团队都有好处。
