Android开发经验记录

一、代码规范

定一个规范的主要目的，是为了让不同的开发人员写的代码能保持一致性，方便别人看自己的代码。另外，对个人来说，也能起到让自己看着舒服的作用。

1. 基本

* 使用UTF-8编码

* 使用Tab进行缩进

* 对待旧代码的态度：许多旧代码的风格比较乱，我们没有必要专门全部改一遍，只需要“顺带手”改了就好，例如你改了一个旧的函数，那就顺便把里面的代码风格都统一一下就好，自己看着也舒服

* 采用Java标准方式写大括号，即大括号跟在代码的最右边而不是另起一行：

void funcName() {

     if(a == 0) {

           //...

     }

}

2. 命名

* 所有Java代码采用驼峰命名法：isFavorite、ActivityMain

* 所有xml文件、资源文件采用下划线命名法，首字母小写：activity_main.xml、ic_launcher.png

* 所有类名首字母大写：BaseAPI

* 所有方法首字母小写：requestList()

* 所有变量首字母小写，且成员变量推荐采用小m开头：mContext

* 所有常量全大写，使用下划线连接：DEBUG_PRINT

3. 注释

* 注释的作用是让别人容易看懂我们的代码，所以注释只需要在必要的地方出现即可，更多的时候，我们应该通过起一个好名字（函数、类、变量、常量）来减少注释

* 以下地方必须要有注释：类的说明、类对外提供的函数的说明、类对外提供的变量及常量，且应该使用 /** 式的注释，这样在IDE里能够直接把鼠标放上去看到东西

* 在关键程序段，应该添加注释，例如某段很拗口的逻辑，应该要说明它是做什么用的，注释应主要说明目的而不是过程

* 函数的注释应该说明各个参数的作用，以及返回值

* 要养成做好事留名的习惯，在自己创建的类，应该在类说明里留自己的名字。如果在别人的类里加函数，应该在函数里留下自己的名字。变量、常量也类似

4. 关于第三方库

* 对待第三方库的态度：第三方库能够大大减少我们的工作量，但是使用不当也会让我们陷入泥潭，一般来说遵循一些简单的规则就可以帮助你选择第三方库：

** 复杂度：如果某个功能需要考虑大量异常处理和细节，而且又是十分通用的，那么就应该考虑使用第三方库，典型的例子是：网络访问（Volley）、图片加载（UniversalImageLoader）、JSON解析（FastJSON、GSON）

** 成熟度：一般来说，我们应尽量选择成熟的第三方库，判断的标准包括：发布地点（例如Github）、是否持续维护（看提交记录）、通过搜索查看排名、通过Github搜索查看排名

** 修改规模：有些第三方库我们拿过来并不能直接用，可能需要进行一些修改，这时候我们就需要注意了。如果需要修改的部分（或者是未来可能需要修改的部分）不少，那我们很可能需要考虑自己来写，因为有时候修改花得时间比自己写还要多的多，事实上，无数前车之鉴已经展示了这一点。此外，尽量不要修改第三方库，因为许多第三方库本身会进行升级

* 此外，引入第三方代码有两种方法：

** 把第三方库作为外部库的方式引用：即在工程属性里添加依赖关系，这样做的好处是可以保持工程的独立性，缺点是工作环境下会有好多工程，而且如果修改了依赖的工程，需要clean一下才会生效。

** 把第三方库代码直接放到主工程里：这样的好处是不会有很多外部工程，但缺点是需要把资源文件（res等）也加进来，如果哪天你要删掉这个库，那就蛋疼了。

其实权衡的方法也很简单，如果第三方库的资源文件特别多，那我建议用外部库方式，如果第三方库代码文件比较少，可以考虑直接放到主工程里。

二、多人协作

多人协作时需要注意的问题是如何合理分工，同时保证效率，降低沟通成本，有一些基本经验：

* 划分模块：一般按照界面进行划分是比较合理的，对于公用的数据模型及网络访问函数，可以统一由一个人写，也可以让负责某个界面的人来负责对应的网络函数；

* 不重复造轮子：有些界面控件是通用的，就不要重复写，有些网络访问函数是通用的，就用一份。要做到这些，最重要的是主动沟通，在意识到别人有可能需要自己的代码时尽早沟通；

* 防止svn冲突：两个人写同一个文件（特别是网络访问类）时，容易出现冲突，一些小技巧：

* 把可能会多个人同时写的文件分区块，用多个回车分隔开，然后用注释写上是谁的区域。。。

* 尽量一个文件只有一个负责人。。。

* 养成经常更新代码的好习惯。。。

三、版本发布

在发布版本时，需要按照一定步骤，另外需要注意一些svn的操作方法：

1、首先，完成各个功能的开发，进行自测；

2、自测没问题后，进行签名，密码在代码目录的说明文档里。把apk给测试人员测试；

3、测试人员测出问题，各个模块的负责人进行修改；

4、经过若干轮修正，基本没有大bug，这时就可以发布了，将最后定稿的apk交给产品经理进行发布；

5、确定发布版本后，使用svn，创建一个发布分支，在/branches/release_Vx.x目录下，其中Vx.x是版本号，用于备份发布的版本；

如果发布版本迟迟没有确定，而主线版本又要做下一个功能，可以先创建发布分支，然后如果有bug，就在发布分支修改，然后将改动merge到主线上。注意：一定要保证merge的单向性，即只从发布分支合并到主干，而不是从主干合并到发布，那样一会就乱了；