Android开发实用技巧

正式工作半年多了,在团队里磕磕碰碰积攒了一些经验,总结下

遵循编码规范

关于编码规范,可以参考谷歌的Android编程规范和Java编程规范。这些规范都是经过实践的,在实际编码实践中证明是有效的,遵守这些编码规范有助于写出合格,便于阅读维护的代码。Google Java Code StyleAndroid Code Style

掌握合适的调试方式

最基本的调试方式是看日志,这也是日常开发中最常用的调试手段。一般我们会使用过滤器来查找我们感兴趣的日志,而且DDMS默认会将展示日志限制在我们的应用产生的日志里,但有的时候,有些系统层级的日志是隐藏在其他日志(如系统产生的)中,所以调试疑难Bug的时候可以尝试在这些日志里查找线索。另一种强大的调试方式是使用单步调试功能。我们通过在程序里打上断点,在目标程序运行到断点的时候单步执行,调试,查看过程中各类产的取值,以便确定问题。

使用 android.support.annotation 包提供的注解

这个包提供的注解能帮我们在开发的时候避免很多的坑。比如可以通过它来保证方法运行在主线程或者非线程里,保证线程安全。还可以通过它要求调用方传入一个非空变量。编译器会在编译的时候根据这些要求进行检查,提前帮我们保证这些限制不被违反。这个包在21版本的support包上默认引入(具体是support.v4包依赖到它)

建立自己的demo工程,并将它逐步建成自己的toolbox

很多时候你会想要验证一个猜想,测试一些方案,得到一些数据。然后你会发现,为了达到这个目的,你可能只需要写一点点代码,但为了这些代码能运行,你要新建一个工程,额外写更多的代码来驱动它,这两部分的占比保守估计是20%和80%。这么做无疑是低效率的。为了改变这种情况,推荐建立一个专门用于编写demo的工程,前期的阵痛是难免的,但我们在编写demo的过程中,要有意识的把实践过程中有重用价值的代码抽出来重用,后续的demo编写就能通过利用它们快速开发。

关键位置输出Log

Log是我们确定应用是否正确运行的依据。对于异常路径,一定要输出日志,这样在程序不按预期运行的时候才能从日志中发现线索。对于程序运行的关键节点,如果有必要,建议输出日志标记下。日志等级同样也要规范使用,切勿为了方便调试的时候看到自己的log,而使用error级别的log进行高亮,这在通过用户日志排查问题的时候,将会成为日志噪音,影响正常的log阅读。

对于log的tag,常见的做法是用类名做tag,有的人为了方便,通过类名.class.getSimpleName()对tag进行赋值,如果应用最终会被混淆的话,获取到的类名会跟我们实际的不一致,这里最好硬编码进来。经过一段时间的编码开发,现在我的会按模块组织我的tag,比如网络模块统一以Network为前缀,不同的部分再添加不同的归类信息,如BasicNetwork使用Nework:Basic,Dispatcher使用Network:Dispatcher。然后将这些TAG作为静态变量定义在同一个的地方,后续排查log的时候就能通过模块名tag过滤出模块相关的log,在进一步根据归类信息细化log调整范围。

对于log的message,如果需要输出变量信息的话,建议使用String.format来格式化输出。输出的格式也建议统一,如:String.format("<some message> >>> [isDone=%b, errorMsg=%s]", isDone, errMsg),这样的log格式统一,便于阅读,后续变更log也容易维护。

功能需求和统计需求

避免使用广播,startService比sendBroadcast要可靠

使用handler将异步化的任务变成单线程异步化保证顺序

android.support.design

toolbox

本地变量持有全局变量

动态修改类定义 完善的注释动机CDD as本地保存修改 代码模板,缩写 测试:基础组件的改动要知会测试,避免场景覆盖不周