这里找到一个比较全面的java编码规范，大家可以看看。
Android 资源命名规范：
1.layout中的id命名
命名模式为：view缩写_模块名称_view的逻辑名称
view的缩写详情如下
LayoutView：lv RelativeView:rv TextView:tv ImageView:iv ImageButton:im Button:btn
2.activity中的view变量命名
命名模式为：逻辑名称+view缩写
建议：如果layout文件很复杂，建议将layout分成多个模块，每个模块定义一个moduleViewHolder，其成员变量包含所属view
3.strings.xml中的id命名
命名模式：activity名称_功能模块名称_逻辑名称/activity名称_逻辑名称/common_逻辑名称
strings.xml中，使用activity名称注释，将文件内容区分开来
4.drawable中的图片命名
命名模式：activity名称_逻辑名称/common_逻辑名称
Android 代码常见问题：
一、异常
如果像下面的代码这样，对catch后的异常作空处理，就像埋下地雷一样让人感觉到毛骨悚然：
错误的做法：
[i]
void setServerPort(String value) {
try {
serverPort = Integer.parseInt(value);
} catch (NumberFormatException e) {
}
}[/i]
正确的做法：
void setServerPort(String value) {
try {
serverPort = Integer.parseInt(value);
} catch (NumberFormatException e) {
throw new RuntimeException("port " + value " is invalid, ", e);
}
异常处理作经常被误用，使用try catch 语句吞没了异常，如果发生异常将得不到任何出错信息。必须对异常做出处理，无论是恢复处理还是输出异常信息。
同时，大小通吃也是不对的，这样会让你在错误出现时难以定位到错误原因，一般异常无法用统一方法进行异常处理。
try {
someComplicatedIOFunction(); // may throw IOException
someComplicatedParsingFunction(); // may throw ParsingException
someComplicatedSecurityFunction(); // may throw SecurityException
// phew, made it all the way
} catch (Exception e) { // I'll just catch all exceptions
handleError(); // with one generic handler!
}
二、资源的持有与释放
1、使用缓存cache。通过使用WeakReference代替强引用，弱引用可以让您保持对对象的引用，同时允许GC在必要时释放对象，回收内存。对于那些创建便宜但耗费大量内存的对象，即希望保持该对象，又要在应用程序需要时使用，同时希望GC必要时回收时，可以考虑使用弱引用。
2.cursor
保证Cursor 占用的内存被及时的释放掉，而不是等待GC来处理。并且 Android明显是倾向于编 程者手动的将Cursor close掉，一种比较好的方式是使用try catch finally语句，在finally中关闭cursor。
3.bitmap
及时的销毁，设置一定的采样率,减少内存使用，尽量使用小图片去绘制，使用.9图片等等。
4. 尽量避免static成员变量引用资源耗费过多的实例,比如Context.
三、ListView优化
1).复用convertView2 @$ f& D' H6 H( r- [% G2 v* D
在getItemView中，判断convertView是否为空，如果不为空，可复用。如果couvertview中的view需要添加listerner，代码一定要在if(convertView==null){}之外。并使用静态的view对象避免创建过多的view。一般方式为Static class ViewHolder 。
x6 w. i7 f' M0 j%
2).异步加载图片# k: k ]8 ~% M& J: A1 h. s
item中如果包含有webimage，那么最好异步加载# z6 T9
3).快速滑动时不显示图片: U" B' j) F E( j
当快速滑动列表时（SCROLL_STATE_FLING），item中的图片或获取需要消耗资源的view，可以不显示出来；而处于其他两种状态（SCROLL_STATE_IDLE 和SCROLL_STATE_TOUCH_SCROLL），则将那些view显示出来.
4).BaseAdapter避免内存溢出0 q% V2 P9 H4 y0 e/ S" q
如果BaseAdapter的实体类有属性非常消耗内存，可以保存到文件；为提高性能，可以进行缓存，并限制缓存大小。
四、一般Handler的使用
当用户点击一个按钮时如果执行的是一个常耗时操作的话，处理不好会导致系统假死，用户体验很差，而Android则更进一步，如果任意一个Acitivity没有响应5秒钟以上就会被强制关闭，因此我们需要另外起动一个线程来处理长耗时操作，而主线程则不受其影响，在耗时操作完结发送消息给主线程，主线程再做相应处理。通常我们会用到Handler。
但是如果在UI线程的Handler中做大量耗时操作，一样会出现ANR。更安全的方式是使用
HandlerThread，如：
HandlerThread handlerThread;
Handler mHandler;
if (handlerThread == null) {
handlerThread = new HandlerThread("mhandler");
handlerThread.start();
mHandler = new Handler(handlerThread.getLooper());
}
这时handler在非UI线程上运行，不会出现ANR。
五、Activity启动方式
GoogleAPI中定义了四种应用启动方式。即"standard", "singleTop","singleTask", "singleInstance"。
standard模式，是默认的也是标准的Task模式，在没有其他因素的影响下，使用此模式的Activity，会构造一个Activity的实例，加入到调用者的Task栈中去，对于使用频度一般开销一般什么都一般的Activity而言，standard模式无疑是最合适的，因为它逻辑简单条理清晰，所以是默认的选择。
而singleTop模式，基本上于standard一致，仅在请求的Activity正好位于栈顶时，有所区别。此时，配置成singleTop的Activity，不再会构造新的实例加入到Task栈中，而是将新来的Intent发送到栈顶Activity中，栈顶的Activity可以通过重载onNewIntent来处理新的Intent（当然，也可以无视...）。这个模式，降低了位于栈顶时的一些重复开销，更避免了一些奇异的行为（想象一下，如果在栈顶连续几个都是同样的Activity，再一级级退出的时候，这是怎么样的用户体验...），很适合一些会有更新的列表Activity展示。一个活生生的实例是，在Android默认提供的应用中，浏览器（Browser）的书签Activity（BrowserBookmarkPage），就用的是singleTop。
singleTask，和singleInstance，则都采取的另辟Task的蹊径。
标志为singleTask的Activity，最多仅有一个实例存在，并且，位于以它为根的Task中。所有对该Activity的请求，都会跳到该Activity的Task中展开进行。singleTask，很象概念中的单件模式，所有的修改都是基于一个实例，这通常用在构造成本很大，但切换成本较小的Activity中。最典型的例子，还是浏览器应用的主Activity（名为Browser...），它是展示当前tab，当前页面内容的窗口。它的构造成本大，但页面的切换还是较快的，于singleTask相配，还是挺天作之合的。
singleInstance显得更为极端一些。在大部分时候singleInstance与singleTask完全一致，唯一的不同在于，singleInstance的Activity，是它所在栈中仅有的一个Activity，如果涉及到的其他Activity，都移交到其他Task中进行。这使得singleInstance的Activity，像一座孤岛，彻底的黑盒，它不关注请求来自何方，也不计较后续由谁执行。在Android默认的各个应用中，很少有这样的Activity，
如果编写的Activity经常被其他应用调动或者启动，那么我们应该考虑将主界面设置为singleTask一般界面设置为singleTop.