开发规范

一、分类
模块清晰、浏览方便。

XML：
按Android默认方式：与anim,drawable,color,layout,values对应。

Java：
按类型优先、功能其次分包。最外层用类型划分，同一业务或UI模块类比较多时内层再用模块划分。

除非项目非常大，否则不建议用功能优先、类型其次的分包方式：
1.包太多，很容易超出一屏，不利于完整概览
2.包层级太多，一层一层打开太繁琐
3.很多功能包下的类型包里类太少，尤其是只有1-3个类时
4.不利于批量修改。同类型类里往往会用到相同代码，如果发现某块这种代码有bug或者需求变化需要改，采用这种方式已经把同类型类分散了，查找很麻烦。编辑器虽然能搜索，但还是得在不同功能包下一层一层展开。而资源浏览器虽然也能搜索，但修改代码不方便
5.一旦功能名称改掉(业务发生变化导致)，因为改的是外层包名，所以改动的类的数量和代码量会比按类型优先、功能其次分包(改内层包名，类型始终稳定)的多很多

之前一个公司的某个App分包是类似淘宝App的功能优先、类型其次的方式：
package-info.java都不算，按包名(类数量,子包名0(类数量,...),子包名1(类数量,...)...)形式展示如下：
about(2)
activities(adapter(2), history(3), helper(1), ui(4), utils(3)) //指活动，而不是Activity
application(1)
chatbar(event(2), ui(8), utils(3))
login(ui(4))
mine(4, password(3))
person(ui(5))
post(ui(19), event(1), helper(1), utils(1))
push(4, model(6))
rank(2)
register(event(1), ui(1), helper(4))
setting(ui(6), utils(1))
...

淘宝App业务很大，确实可以这样划分，但真的不适合小于这种量级的App。
请以大家这个为分包的反面教材。

二、命名
容易查找、一看就懂。

XML：
1.anim,drawable,color,values(arrays,colors,dimens,strings,styles等)按功能或描述：
如right_push_in, oval, alpha_to_darker, (sexs,white, text_size_middle(改为text_middle更好), loading, topbar_bg)。

2.layout如果有对应java类(Activity,Fragment,Adapter(item),自定义View等)，就以java类名划分:
如setting_activity, user_list_fragment, comment_item, grid_picker_view等;
其它按其功能划分，如list_item等。

Java：
1.只用单词英文全称，不要用拼音或缩写(除非是Impl这种非常普遍的缩写)。

2.含组件名的必须用组件名作为后缀。
如SettingActivity,UserListFragment,GridPickerView。

3.具有通用分类属性的类建议用通用前缀或后缀。
如基类BaseXXX，工具类XXXUtil，管理类XXXManager，监听回调用XXXListener。

4.单词能描述这个类的功能或作用。
如SettingActivity,SettingUtil。

5.单词意思尽量用通用的描述业务逻辑的。
如User,Message等，如果没有对应的可以参考流行App(仿啥用啥，如朋友圈动态Moment)。

6.单词意思不要太过具体，不要和业务耦合，因为业务很容易发生变化。
不管是乘客Passenger还是手艺人Craft等，都用User；联系人(Contacts,Friends)、群成员(Members)等集合属性的都用UserList。
之前一个公司的某个App仿微信朋友圈的模块名改了3次：帖子Post>聊聊吧ChatBar>活动圈ActivityCircle>晒图ShowPicture，导致后期这个模块很多类分别以这几种命名共存，适应和查找都很痛苦。如果都用Moment(微信设置语言为英文可以看到)，就不用改了。

7.单词尽量选简单易懂、没有歧义且不和关键词冲突的。
比如帖子有post,card,note等单词，card容易被认为是信用卡、明信片等，这种场景下不适合使用。

8.单词数量尽量少。
如普通用户(CommonUeser)、会员用户(VIPUser)等都用User；
密码登录(LoginByPassword)、验证码登录(LoginByPhone,LoginByVerify,LoginByAuthCode等)、第三方授权登录(LoginByQQ,LoginByWechat等)都用Login等。
当原有命名已经存在且不能很好地满足新的需求，新增代码多且使用局限，可以使用继承的方式。例如会员用户比普通用户类多不少UI或业务逻辑：VPIUserXXX extends UserXXX。