安卓开发规范

目录

• 1 前言
• 2 AS规范
• 3 命名规范
• 4 代码格式
• 5 OOP规范
• 6 注释规范
• 7 异常处理
• 8 测试规范

1 前言

• 为了有利于项目维护、增强代码可读性、提升 Code Review 效率以及规范团队安卓开发，故提出以下安卓开发规范，该规范部分参考了《阿里Java开发手册》和 AndroidStandardDevelop.

• 总体代码规范简易概括如下：

  1.总体上要干净整洁

  2.不同的方法间要分得开些

  3.每个方法要有对应注释说明，包括方法的作用以及输入参数的类型和意义

  4.方法中的变量也要进行功能说明

2 AS规范

• 工欲善其事，必先利其器。

1. 尽量使用最新的稳定版的 IDE 进行开发（2.3.3版本的Android Studio）；

2. 编码格式统一为UTF-8；

3. 每行的字符不能太多，最多100个字符。

4. 编辑完.java、 .xml等文件后一定要格式化（基本格式方面使用 AS 默认模板即可）；

5. 删除多余的import，减少警告出现，可利用AS的Optimize Imports(Settings → Keymap → Optimize Imports)快捷键；

3 命名规范

变量命名

1. 变量的名字长度要限制好，最多20个字符

2. 一般变量的名字要采用驼峰命名法来命名，即变量中第一个单词的第一个字母要小写，其余后面的单词的每个首字母要大写，如果只有一个单词，该变量的名字全部采用小写字母就好。例：int index; int arrayIndex

3. 常量需要全部字母大写。例：final int MAXNUM; final int NUM

4. 变量的命名要能够一定程度上反应变量的功能，如用for循环遍历数组时，用到表示下标的变量不要写简单的i，要写成index.

5. 注意不要出现一些个人信息或者一些不明所以的变量名称

6. 对于由比较多单词组成的，可以选择关键词或在单词与单词间用"_"来使变量更加清晰,但要注意整体长度不超过20个字符。如： Button selectButton 可以写成select 或 button_Select

7. 变量的命名不要出现拼音

8. 类中构造的类，要是private的

9. 类非static成员变量并且与子类共享，必须是protected

10. 类static成员变量如果仅在本类使用，必须是private

11. 若是static成员变量，必须考虑是否为final

方法命名

1.对于不需要输入参数的方法，方法的取名要是这个方法的功能。

2.对于要输入参数的方法，除了方法名要体现功能外，还要将需要输入参数的变量写清楚，传入的是什么东西。

类命名

类的命名首字母要大写，类的名字要体现这个类在整个程序中充当一个什么的角色，或能够起到什么作用。如：Background.java在整个程序中充当的就是背景的成分/作用。

包名

包名统一采用完整的英文描述符，由小写字母组成。

接口

接口中的方法统一有public前缀或统一没有，不要出现一些有，一些没有的情况。

4 代码格式

行宽

每行的字符不能太多，最多100个字符。同时要保证完整性，不要因为100个字符而将内容从中间断开，显得语法不通。 正确做法应该是：若要断开，提前断开，保证语法的完整性。

关于大括号的使用

不要这种情况：

if(boolean){Code};

即使只有一条代码语句，也不要出现这样的情况：

if(boolean) Code;

或是这样：

if(boolean)
Code;

最好的情况做到这样：

if(boolean){
    Code;
}

分行

这一类问题主要集中在变量的创建问题。

同是创建变量a,b，不要写成这样：

int a=0,b=0;//a是XXX,b是XXX

而应该写成这样：

int a=0;//a是XXX
int b=0;//b是XXX

还有条件语句或是循环语句等情况也要注意分行（这方面不明显）

不要出现这样的情况：

if(true) System.out.println("Hello World")

while(true) System.out.println("Hello World")

5 OOP规范

1.【强制】避免通过一个类的对象引用访问此类的静态变量或静态方法，无谓增加编译器解析成本，直接用类名来访问即可。

2.【强制】所有的覆写方法，必须加 @Override 注解。

3.【强制】对外暴露的接口签名，原则上不允许修改方法签名，避免对接口调用方产生影响。接口过时必须加@Deprecated 注解，并清晰地说明采用的新接口或者新服务是什么。

4.【强制】不能使用过时的类或方法。

5.【强制】Object 的 equals 方法容易抛空指针异常，应使用常量或确定有值的对象来调用。

6.【强制】所有的相同类型的包装类对象之间值的比较，全部使用 equals 方法比较。

7.【强制】序列化类新增属性时，请不要修改 serialVersionUID 字段，避免反序列失败。

8.【强制】构造方法里面禁止加入任何业务逻辑，如果有初始化逻辑，请放在 init 方法中。

9.【推荐】使用索引访问用 String 的 split 方法得到的数组时，需做最后一个分隔符后有无内容的检查，否则会有抛 IndexOutOfBoundsException 的风险。

10.【推荐】 类内方法定义顺序依次是：公有方法或保护方法 > 私有方法 > getter/setter方法。

11.【推荐】setter 方法中，参数名称与类成员变量名称一致，this.成员名=参数名。在 getter/setter 方法中，尽量不要增加业务逻辑，增加排查问题的难度。

12.【推荐】final 可提高程序响应效率，声明成 final 的情况： 不需要重新赋值的变量，包括类属性、局部变量。 对象参数前加 final，表示不允许修改引用的指向。 类方法确定不允许被重写。

13.【推荐】慎用 Object 的 clone 方法来拷贝对象。

6 注释规范

1. 每个新建的变量都要有注释注明其作用

2. 每个方法的上方都要写明方法的用途，若需要传入参数要写明参数的类和用途，并写上这个方法的伪代码

3. 在类的开头要写明这个类的作用

7 异常处理

1.【强制】不要捕获 Java 类库中定义的继承自 RuntimeException 的运行时异常类，如： IndexOutOfBoundsException / NullPointerException，这类异常由程序员预检查来规避，保证程序健壮性。

正例：

if(obj != null) 
{...}

反例：

try { obj.method() } 
catch(NullPointerException e)
{...}

2.【强制】异常不要用来做流程控制，条件控制，因为异常的处理效率比条件分支低。

3.【强制】对大段代码进行 try-catch，这是不负责任的表现。catch 时请分清稳定代码和非稳定代码，稳定代码指的是无论如何不会出错的代码。对于非稳定代码的 catch 尽可能进行区分异常类型，再做对应的异常处理。

4.【强制】捕获异常是为了处理它，不要捕获了却什么都不处理而抛弃之，如果不想处理它，请将该异常抛给它的调用者。最外层的业务使用者，必须处理异常，将其转化为用户可以理解的内容。

5.【强制】有 try 块放到了事务代码中，catch 异常后，如果需要回滚事务，一定要注意手动回滚事务。

6.【强制】finally 块必须对资源对象、流对象进行关闭，有异常也要做 try-catch。

说明：如果 JDK7，可以使用 try-with-resources 方式。

7.【强制】不能在 finally 块中使用 return，finally 块中的 return 返回后方法结束执行，不会再执行 try 块中的 return 语句。

8.【强制】捕获异常与抛异常，必须是完全匹配，或者捕获异常是抛异常的父类。说明：如果预期对方抛的是绣球，实际接到的是铅球，就会产生意外情况。

9.【推荐】方法的返回值可以为 null，不强制返回空集合，或者空对象等，必须添加注释充分说明什么情况下会返回 null 值。调用方需要进行 null 判断防止 NPE 问题。

说明：本规约明确防止 NPE 是调用者的责任。即使被调用方法返回空集合或者空对象，对调用者来说，也并非高枕无忧，必须考虑到远程调用失败，运行时异常等场景返回 null 的情况。

10.【推荐】防止 NPE，是程序员的基本修养，注意 NPE 产生的场景：

1）返回类型为包装数据类型，有可能是 null，返回 int 值时注意判空。 反例：public int f(){ return Integer 对象}; 如果为 null，自动解箱抛 NPE。

2）数据库的查询结果可能为 null。

3）集合里的元素即使 isNotEmpty，取出的数据元素也可能为 null。

4）远程调用返回对象，一律要求进行 NPE 判断。

5）对于 Session 中获取的数据，建议 NPE 检查，避免空指针。

6）级联调用 obj.getA().getB().getC()；一连串调用，易产生 NPE。

11.【推荐】在代码中使用“抛异常”还是“返回错误码”，对于公司外的 http/api 开放接口必须使用“错误码”；而应用内部推荐异常抛出；跨应用间 RPC 调用优先考虑使用 Result 方式，封装 isSuccess、“错误码”、“错误简短信息”。 说明：关于 RPC 方法返回方式使用 Result 方式的理由： 1）使用抛异常返回方式，调用方如果没有捕获到就会产生运行时错误。 2）如果不加栈信息，只是 new 自定义异常，加入自己的理解的 error message，对于调用端解决问题的帮助不会太多。如果加了栈信息，在频繁调用出错的情况下，数据序列化和传输的性能损耗也是问题。

12.【推荐】定义时区分 unchecked / checked 异常，避免直接使用 RuntimeException 抛出， 更不允许抛出 Exception 或者 Throwable，应使用有业务含义的自定义异常。推荐业界已定义过的自定义异常，如：DAOException / ServiceException 等。

13.【参考】避免出现重复的代码（Don’t Repeat Yourself），即 DRY 原则。 说明：随意复制和粘贴代码，必然会导致代码的重复，在以后需要修改时，需要修改所有的副本，容易遗漏。必要时抽取共性方法，或者抽象公共类，甚至是共用模块。 正例：一个类中有多个 public 方法，都需要进行数行相同的参数校验操作，这个时候请抽取：

private boolean checkParam(DTO dto)
{...}

8 测试规范

1. 测试说明

1.1 测试目的及原则

• 测试的目的：

为了尽可能多地找出产品中的漏洞。漏洞包括产品界面的错误，功能需求实现与功能需求说明书不符的产品内容，产品运行中出现的错误，用户使用感受不佳的设计。

• 测试的原则：

从用户的角度去测试产品，通过自己的测试检测出产品存在的问题并解决，为用户提供使用过程方便，使用体验良好的产品。

• 为了实现以上原则，要注意以下几点：

  (1)设计测试用例时应该考虑各种情况：包括正常条件，边界条件，异常条件。

  (2)产品的每一个功能需求都需要进行相应的测试，测试用例测试每一个功能需求尽可能小而多而不是一次性设计一个复杂的测试用例之后就转入下一个功能需求。

  (3)每一次测试之后出现异常要在当日与小组成员说明，小组成员更改后要及时更改测试用代码和产品。

  (4)对当天的测试内容和结果进行记录，妥善保存测试文档。

1.2 测试范围

  对该款在Android7.1.1平台上进行开发的游戏进行测试，测试范围包括功能需求说明上设计的所有用户需求，产品各功能衔接情况，用户感受。

1.3 用户对象

  该产品没有特别指定的用户对象，广泛面向所有使用搭载Android7.1.1及以上版本平台手机的用户。

2. 参考文献

• URL：
  • 手机游戏测试规范：http://www.docin.com/p-239150002.html
  • 软件测试规范：http://ishare.iask.sina.com.cn/f/10159141.html?qq-pf-to=pcqq.c2c
  • 软件测试基础：http://www.cnblogs.com/shengtianlong/archive/2010/08/01/1790030.html
• 书籍：《构建之法》邹欣著 2014.9 人民邮电出版社出版

3. 测试方法

3.1 测试分类

• 按照测试用例设计方法来分类：

1)黑盒测试：分别测试每一个功能属性，只检测每一个单元部件是否满足功能需求说明书的设计。

2)白盒测试：按照产品内部结构调试程序，检测产品每个功能是否顺利衔接，完成用户用例设计。

• 按照测试步骤分类：

3.2 完整测试流程

• 完整流程：编写测试计划→设计测试用例→执行测试用例→测试评估→提交测试结果→根据测试结果将意见反馈到设计组修改

• 详细步骤：

  1).建立测试计划，每进行一个测试之前先填写测试计划。

  2).组员审核测试计划

  3).根据测试计划编写测试用例：测试用例可能是代码测试，也可能是用户测试。

  4).得到测试结果，如果结果正常，进行下一个目标测试。异常进行分析

  5).将测试记录在测试报告中，包括测试结果及分析。

  6).将测试结果及分析反馈给设计组，说明异常情况，并提出修改建议和意见。

3.3 测试中涉及文档说明

• 测试计划
  • 测试计划内容应该指明测试目的，测试方法，测试完成标准等。
  • 测试计划的内容不要求过于详尽，以免拖延项目时间，但力求完整，可以简化每一部分但决不可以缺少。
  • 用户测试的内容以文档形式写入测试计划中，而用程序进行测试时用例设计要求用伪代码的形式体现出来。
• 测试报告
  • 测试报告中要求体现测试结果，测试结果分析，测试任务安排以及人员分配，测试完成日期等。其余要求同上。

3.4 游戏测试工作及数据统计

在产品开发过程中，测试人员应该做到如下几个方面：

1. 根据新项目的计划及该研发游戏产品的功能写出大概的Test Case（一般为简单的功能测试用例）出来以便后期的测试。

2. 在开始设计的初期，测试人员应该从客户的角度提出一些好的建议（该建议由PM来决定是否作为新功能添加到新产品中）（A-Test)。

3. 当产品初具模型时，测试人员应该根据RD软件工程师的要求做必要的功能性和稳定性的测试（当然此时也可以提出自己新的见解，此见解由PM根据产品的性价比来决定是否作相应的更改或添加）(B-Test)。

4. 当产品已经基本上实现其预期的功能时，测试人员应该做一次Full Test（其中包括：基本功能测试，大量测试，压力测试，边界测试等等）来找出Bug（C-Test）。

5. 对于找出的Bug,测试人员应该每天向Project leader汇报当天找到的Bug,并标识出P1,P2,P3 Bug（P1，P2是Bug的优先级）所占的比例，以便Leader的复查和判断到底是不是Bug。

6. 测试人员要立即将这些Bug及时的反映到Buglist的数据库中，以便RD软件组人员对软件的修改。

7. 当发现的Bug被修改后，测试人员还要对此进行大量的重复测试(即回归测试），以确保Bug不在存在，最后由测试人员来Close Bug。

8. 对于新的版本出现后，测试人员应该根据自己的经验进行快速的功能测试或者先对数据库中Old Bug进行验证，以便快速发现新版本中的Bug。

9. 产品出货后，用户在真正使用时可能会产生一些问题，所以在出货后，测试人员应该在适当的时间内做一次Sustaining Test或者进行一次回归测试，以便为用户提供版本的升级或问题的回复。

4. 游戏评测

• 评测项目（注：依据本人网络游戏评测经验列出的评测内容） 评论应主要根据游戏的画面、游戏性、操作性、适用性四个方面的表现给出综合分数以及相应的评语。
  

• （1）画面

主要从色彩搭配、人物造型、背景描绘以及是否有拖慢现象等图象表现的品质来进行评测。

具体评测内容：游戏画面发色数；游戏主角、NPC造型；背景用色与前景搭配；游戏中是否有拖慢现象。

• （2）游戏性

游戏性主要是从玩家的角度来看待一个游戏是否有趣。包括游戏界面、游戏平衡性、趣味性。通俗的讲就是一个游戏的有趣程度与可玩性。

具体评测内容：游戏界面是否友善便于设置(例如声音是否可以关闭)；敌人、机关设计是否合理；游戏难度的把握。

• （3）操作性

主要从游戏对按键的响应时间、移动方式、按键安排是否合理等几个方面给出分数。

具体评测内容：按键安排是否便于游戏；能否对按键进行设置；游戏对按键反应时间；移动是否有惯性等。

• （4）手机适用性

游戏每多支持一款手机，代表其适用性越好，在实际评价一个手机游戏时一定要考虑这个因素。这意味着手机游戏生命力的旺盛程度和周期长短。