Android开发习惯

首先是命名规范。命名规范这种东西每个人都有自己的风格，Google 也有自己的一套规范（多看看 Android 系统源码就明白了）。好的规范可以有效地提高代码的可读性，对于将来接手代码的小伙伴也是一件幸事。可以自行 Googol 一下 Java （Android）命名规范，会有不少的博客介绍。


其次是注释。严格来说这个应该属于命名规范的范畴。注释一方面是帮助自己记忆 ，另一方面是团队协作中的一个规范，特别是对于开发 API 的小伙伴来说，总不能天天被人跟在屁股后面问你这个接口是什么作用，你这参数是什么意思？好的注释配合好的命名规范，可以省去很多沟通上的成本。 注释至少要有如下几方面的内容：
该接口（或类）的作用。注意写的应该是作用，而不是你做了什么；
参数列表的各个参数说明；
返回值的说明；
如果有异常抛出，对抛出异常的说明；
如果注释是在类上的，总得留个联系方式吧，免得以后出了问题都找不到原作者。当然了，如果类设计的过于让人蛋疼，我也可以联系到作者，约出来，打一顿的嘛。
其他你认为有必要解释。


再者是版本控制。就算是自己一个人写代码，版本控制也是有必要的。Git 也好，SVN 也好，都是有帮助的。版本控制一方面是对自己代码的一个备份，另一方面，如果想回滚到历史版本也是极有帮助的。所以最好能够熟悉一下 Git 或者 SVN 的使用。


第四是名词表。这个应该属于肥肥自创。Android 是围绕四大组件特别是 Activity 和 Service 进行开发的，但是如果项目庞大，有多个 Activity 存在，那么记住每一个 Activity 的类名是很难得，但是记住每一个 Activity 的功能却相对容易。故而肥肥在带项目的过程中自创了名词表这一东东。记录了每一个模块、组件、甚至是每一个 Activity 的官方统一名称（比如，功能是作品列表的 Activity，名称就叫作品列表页，对应的类是 WorksListActivity），在沟通过程中，大家（包括测试人员等项目相关人员）统一说“作品列表页”。当时的初衷是解决测试团队的Bug 描述过于模糊（如果有多个列表页，测试人员往往会写列表页****问题）。


第五是不要重复制造轮子。这个适用于代码层面以及业务层面。


第六是千万不要饿着肚子写代码。先挖这个坑，吃了东西再找时间继续写。


第七这一点应该不算是习惯，但是却需要每一个 Android 程序猿需要慎重再者慎重的地方---内存管理。Android 虽然延续了 Java 的垃圾回收机制，但是并不意味 Android 应用程序就不会出现内存问题。在 Android 中引起内存开销过大的往往是 BitMap 对象。BitMap.java实际上是 Skia 引擎中对图片处理部分的 Java 层代码而已（真正工作的是 C++层代码，通过 JNI 封装，最后提供 Java 层的接口），那么你创建 BitMap 对象实际上是创建了两部分内存，一部分是 Java 层的，就是 BitMap对象，Java 的垃圾回收会在合适的时机回收这一部分内存。另一部分是 C++层面的，也就是通过 JNI 调用 C++层的代码分配的那一部分内存。Java 的垃圾回收是不会回收这一部分内存的，所以如果不手动释放的话就容易引起内存问题。


第八是千万不要阻塞用户主线程。用户主线程就是 UI 线程，主要负责 UI 的绘制（除 SurfaceView 外，其他 View 对象都是需要在 UI 线程中进程操作的）。为了保证 App 的交互尽可能的流程，请不要在 UI 线程中进行耗时操作（文件读写、Http 请求（4.0之前可以在主线程中发起）等）。否则会引起两种可能的问题：第一是造成用户交互极度不流畅，第二容易触发 ANR 的超时机制（UI 线程5秒，广播10秒）。


第九是严格把控生命周期（Activity、Service、ContentProvider 等）。在每一个生命周期事件中，明确应该做什么不应该做什么是很有必要的，不然也会容易造成各种莫名其妙的问题（比如 onCreate 中使用了 onResume 中才初始化的对象）。


第十是在使用 XML 文件进行 UI 布局时，应该尽量减少 Layout 的嵌套层级。Layout 的过度嵌套会造成渲染时资源开销过大的问题。