Android开发规范和架构总结

前言

在开发中，一个良好的开发习惯以及一个开发规范可能会让你少走很多弯路，也会一定程度上的提高代码的可读性，可维护性和可拓展性。当随着需求的不断变更，需要维护项目的时候。当随着项目的代码量的提升，需要重构的时候。你会明白一个好的开发规范多么多么的重要。
这里整理一下自己android开发中的一些规范。希望对各位有帮助。

命名规范

包命名规范

• 包名全部采用小写

• 主包名采用[公司性质].[公司名称].[项目名称]的命名方式
  如果根据不同情况进行分包的话，可以将包名分别命名为base，model，view等。我这里采用的是MVP架构

代码命名规范

命名规则有很多高大上的名词，比如大驼峰，小驼峰，匈牙利命名法。其实最简单的就是按照谷歌命名学习。

• 常量、枚举等均采用大写形式，用下划线区分各单词。使用static final
  例如：private static final String TAG_FOR_ACTIVITY = "XXXX";

• 类名、接口名、枚举名。第一个和后面的单词都要第一个字母大写
  例如：MainActivity,PersonalLoginActivity

• 资源文件命名
  例如：activity_main.xml，fragment_main.xml，ic_launcher.png
  注意图片文件命名只能用小写字母、数字，否则会导致R文件无法编译出来。也是比较费心的。

• 继承自安卓组件的类，一般采用父类名作为后缀，
  例如：class LoginActivity extends Activity{}

• 自定义异常必须以Exception结尾

• 全局变量添加所有者前缀：实例成员变量前缀m（表示member），类静态变量前缀s（表示static），
  例如：protected Subscription mSubscription;

• 控件变量添加组件前缀，顺序在所有者前缀之后，控件缩写button->btn,textview ->tv,listview->lv等
  例如：全局名称mBtnNext局部名称btnNext

• 构造方法采用递增方式（参数多的写在后面），参数少的调用参数多的构造函数。这样也减少初始化代码。比如开源库PagerSlidingTabStrip

编程规范

• 源文件编码格式为 UTF-8。

• java代码中不出现中文，最多注释中可以出现中文

• 服务端可以实现的，就不要放在客户端

• 引用第三方库要慎重，避免应用大容量的第三方库，导致客户端包非常大

• 处理应用全局异常和错误，将错误以邮件的形式发送给服务端

• 图片的.9处理

• 使用静态变量方式实现界面间共享要慎重

• 单元测试（逻辑测试、界面测试）

• 不要重用父类的handler，对应一个类的handler也不应该让其子类用到，否则会导致message.what冲突

• activity中在一个View.OnClickListener中处理所有的逻辑

• strings.xml中使用%1$s实现字符串的通配

• 数据一定要效验，例如字符型转数字型，如果转换失败一定要有缺省值；服务端响应数据是否有效判断

• 对于未完成的方法，使用TODO加以标记

• 若功能已完成，但存在效率等潜在问题时，使用XXX加以标记

• 若代码存在严重问题或仅用于调试，使用FIXME加以标记

• values目录下文件名称较固定，不得随意更改

代码提交规范

我们使用的无论是git，还是svn都需要遵守下面这些规范。

• 工作目录要及时更新，不要和服务器有太大的差别

• 提交代码时，如果出现冲突，必须仔细分析解决，不可以强行提交

• 提交代码之前先在本地进行测试，确保项目能编译通过，且能够正常运行，不可盲目提交

• 必须保证服务器上的版本是正确的，项目有错误时，不要进行提交

• 提交之前先更新

• 提交时注意不要提交本地自动生成的文件，比如我们Android Studio项目中的 idea,build文件夹是不需要提交的。

• 不要提交自己不明白的代码

• 提前协调好项目组成员的工作计划，减少冲突

• 对提交的信息采用明晰的标注（写注释）

使用git以及github，相信stormzhang的从0开始学习 GitHub 系列会对你有很大的帮助。

架构规范

这是我整个系列文章从零开始搭建android框架系列的重点，所以这里放在最后面。

架构方式

是选择MVP，MVC，MVVM ，Flux还是clean 架构？
，+dagger2？+rxjava？+Retrofit/okhtttp?+loader？+databinding？+contentProvider?

开源库的选取以及封装

对开源库的选取，一般都需要选择比较稳定的版本，还有作者在维护的项目
，比如这里在github搜索image，出现的安卓中的图片加载库。除了考虑star，还要考虑作者对issue的解决，以及开发者的知名度等各方面。

选取之后，一定的封装是必要的。

架构提示

这里尽量写出自己想到的点。

抽象层面上：

• 提高架构的拓展性是有必要的。
  以前的框架可能会出现功能不足的情况，但是因为这点是不可预见的，所以我们选择框架时一定要了解好框架本身的扩展性如何，或者对框架有较深的理解，能够自己扩展框架，

• 提高架构的稳定性

• 架构的文档也是必不可少的。

具体操作时：

• activity和fragment里面都会有许多重复的操作以及操作步骤，所以我们都需要提供一个BaseActivity和BaseFragment，让所有的activity和fragment都继承这个基类。
  来看看我们BaseActivity中都提供了哪些操作：

• 必要的注释真的会一定程度上的降低你的工作量，而不是提高。

• 多用组合, 少用继承

• 提取方法, 去除重复代码。
  

  对于必要的工具类抽取也很重要，这在以后的项目中是可以重用的。

• 不要使用魔鬼数字/字符串/尺寸值/颜色值，正确的命名等
  

• 引入Dagger2 减少模块之间的耦合性
  Dagger2 是一个依赖注入框架，使用代码自动生成创建依赖关系需要的代码。减少很多模板化的代码，更易于测试，降低耦合，创建可复用可互换的模块。
  

• 为你的项目引入Rxjava+RxAndroid这些响应式编程吧。极大的减少逻辑代码，让你爱上写代码停不下来。

• 通过引入 Event Bus 。它允许我们在Data Layer中发送事件，以便View Layer中的多个组件都能够订阅到这些事件。比如DataManager中的退出登录方法可以发送一个事件，订阅这个事件的多个Activity在接收到该事件后就能够更改它们的UI视图，从而显示一个登出状态。
  当然你也可以有很多的选择，EventBus，Otto，自定义RxBus等。减少回调。

• 添加日志打印，用于查找错误等。
  我推荐使用logger。
  需要使用BuildConfig.DEBUG标记对Log进行封装，只在调试时输出重要信息，正式版不输出

• TODO  more