团队review规范整理

1. 应用按功能划分目录，例如appupgrade, login。
2. Android应用每个功能的下一级目录包含：presenter, ui, utils, bean, api, service, controller。并根据实际场景进行增加或者减少。这个目录定义作为一般功能性的参考，对大部分业务功能有参考价值。
3. 如果能使用已经定义好的全局函数，请一定使用。例如不用使用Android系统自带的Log打印，而是使用我们开发的Logger，原因是以后想控制打印级别，是否打印，非常方便。Logger相当于是自定义Log的一个Proxy。
4. 必须考虑应用退到后台场景，如果有后台轮询，需要关闭轮询，防止耗电和占有系统资源。
5. 颜色命名以模块区分，如果有全局色值（例如通用的color/global_divider_color），优先采用全局色值（这时候要小心是否有对应的夜间色值，如果没有，需要添加，或者使用本模块的通用色值）。举例如下

#e3e2e1

5. 提交代码，如果功能没有完成，请使用TODO注释，举例说明
   //TODO(feixiangant) 需要添加视频轮询功能
   删除代码，如果没有彻底删除，需要添加NOTE说明，举例说明
   //NOTE(feixiangant) 这个功能本期不测试，下期会启动
   Commit提交测试需要添加任务号或者bug号，尽量使用英文，举例说明
   git commit -m “[T11870]delete all codes about mant SDK”

6. 所有新功能都需要考虑PV和点击事件统计。运营可以根据统计数据做需求规划，而不是拍脑袋。

7. 通用代码请形成通用模块或者函数，这是最简单的重构。

8. 当前版本第一个需求就是改版本号。

9. 如果能做单元测试，请尽量做；如果不做，请自行做全面测试。

10. View的优化规范
    降低View树的高度，即减少View的层级嵌套，使用RelativeLayout替代LinearLayout。
    使用include或者merge标签，将布局包含进来。
    使用ViewStub，一些布局文件在正常情况下不会显示出来，可以使用ViewStub使其在使用时在加载。
    不要在onDraw()等类似绘制函数中执行大量操作或者相对耗时的任务，影响View的流畅度。
    不要在onDraw()类似的频繁被调用刷新的函数中创建局部对象，这会耗用大量内存。
    避免过度绘制。出现过度绘制主要是由于View的backgroud重复绘制。首先Window本身就有自己的background，如果要自定义自己的background，得记得把window的background设为null。