探讨Android开发值得注意的规范

有人说，国内一个开发者写出的代码可能有十种风格，国外十个开发者写出的代码却是同一种风格。我最初在项目开发时深有体会（本人在开发初期也不注重代码规范），一个项目里面可能同时有picasso、imageLoader、fresco等多种图片加载框架，可能有OkHttp、Volley、XUtil等多种网络请求框架，可能各自自定义BaseActivity，每个类、方法、成员变量没有具体注释，没有从strings.xml引用字符串而是直接写上，有些引用可能会空指针抛出空指针（null）没有做异常处理。这一系列的不规范将成为项目维护以及后续的痛点。总结一下，统一规范的架构、代码具有良好可读性，利于项目维护和后续开发，便于团队内部协同合作。

一、统一开发框架

开发前期应具体分析，敲定各种需要用到的框架：图片加载、网络请求、数据库操作、日志分析、内存管理以及泄漏检测等，抽取一个BaseActivity出来，所有子类Activity都继承它，指定每个类、方法、成员变量所注释的要点。这可能会花费一定的时间，但磨刀不误砍柴工，完善的框架为项目开发奠定良好的基础。

二、注意代码编写规范

1、字符串的引用

Toast、Log、Dialog这些用户交互提示常常用到字符串，有些开发者为了方便直接在使用地方写上字符串，而没有从strings.xml引用。这样有一个明显缺点：后续要修改字符串内容，需要到该文件里找到字符串才能对应修改。如果是统一从strings.xml引用字符串，那么就能快速定位快速修改了。所以建议大家统一从strings.xml引用字符串。

2、尺寸与风格的引用

尺寸（dimension）与风格（style）一般是在xml文件里面用到，建议大家在dimens.xml配置各种尺寸，在styles.xml自定义风格，然后在xml文件引用。原因与字符串引用一样，可以快速定位修改。这只是一个微小细节，也许对于多数开发者来说微不足道。但也就是众多细节才构成庞大体系，规范应该从细节做起。

3、注意命名规范

命名应该通俗易懂，给别人看到类名、方法名或者变量名就知其用途的感觉，主要包括如下三点：

（1）包名、文件夹、xml、drawable等单词都是小写，其中xml与drawable的命名单词之间是下划线连接；

（2）类名是每个单词首字母大写，后面小写，遵循全驼峰规则；

（3）方法名、变量名是首个单词全部小写，后面的单词首字母大写，遵循驼峰规则；

三、警惕异常产生以及处理

1、空指针

有些if条件判断需要加上空指针（null）判断却没有做出对应判断，造成抛出空指针异常，甚至导致程序崩溃；有些if条件判断不可能发生空指针却加上判断，多一个语句判断，多一个指令周期，降低程序执行效率。那么，需要开发者准确判断是否有空指针发生的可能性，如果有就有必要加上空指针判断。可能产生空指针的情景包括：从网络请求数据解析成一个bean，该bean可能为null；使用new运算符来创建一个File，执行语句为new File（path），传入参数path可能为null；从数据库查询返回一个cursor对象，马上调用cursor.moveToNext（）方法，但是cursor可能为null。

        情景1：

直接使用bean-->   

String userName = loginBean.getName();

加上空指针判断-->

String userName = loginBean != null ?loginBean.getName() : "";

       情景2：

直接使用path-->

File mFile = new File(path);

加上空指针判断-->

if(path != null && !path.equals("")){
   File mFile = new File(path);
}

情景3：

直接使用cursor-->

while(cursor.moveToNext){
   ...
}

加上空指针判断:

if(cursor == null)
   return;
while(cursor.moveToNext){
   ...
}

四、同步关键字的用法

同步关键字synchronized作用于变量（variable）时，变量的属性应该是加上final。有时候变量使用到synchronized，前面却没有加上final修饰符，这样使用android studio的lint静态代码检测时就会提示synchronization on a non-final field。给出对应的解决方案是在变量前面加上final修饰符。

五、强制类型转换

java语言允许强制类型转换，开发者在不确定左右双方类型是否一致的情况下，往往加上强制类型转换。这也就可能导致没必要的类型转换，因为双方的类型已经一致。

比如：

View mView = (View) findViewById(R.id.my_view);

其实两者类型已经都是View，那么右边的强制类型转换变成多余。这样并不会导致程序无法执行，只是不够简洁。lint静态代码检测时会提示Type conversion is redundant。

六、集合转换成数组

使用toArray（）把集合转换成数组，应该传入数组长度也就是集合的长度。自定义一个长度的做法是不恰当的。如果是传入的数组长度小于实际长度，就无法完成转换。

比如：

直接指定数组长度-->

List<String> var = entry.getValue();
String[] mArray = var.toArray(new String[5]);

正确做法是传入集合长度-->

List<String> var = entry.getValue();
String[] mArray = var.toArray(new String[var.size()]);

七、String、StringBuffer与StringBuilder的正确使用

String通过“+”来拼接字符串，而StringBuilder是通过append（）来拼接的。两者的用法相信大家都很清楚，但有时会相互混淆，虽然不会影响程序执行，但是lint静态代码检测时，会提示用法混乱。比如：只需要用String就可以，却用StringBuilder代替；StringBuilder里面混合使用“+”来拼接。StringBuffer和StringBuidler都是用append来拼接比较复杂的字符串，但是静态代码检测时，如果是单线程的情况下，会建议采用StringBuilder来代替StringBuffer，因为StringBuilder比StringBuffer效率要高。

情景1：

使用StringBuilder来做简单字符串拼接-->

StringBuilder sb = new StringBuilder();
sb.append("群组").append(group.getGroupName());

使用String代替StringBuilder-->

String mGroup ="群组"+group.getGroupName();

情景2：
StringBuilder里面混合使用“+”来拼接-->

StringBuilder sb = new StringBuilder();
sb.append("群聊（" + group.getGroupName() + "）创建成功");

应该是纯append来拼接-->

StringBuilder sb = new StringBuilder();
sb.append("群聊（").append(group.getGroupName()).append("）创建成功");

八、if与switch的用法

if用作条件判断，switch用于开关语句，两者有共同点有时可以相互代替。但是判断条件单一情况下，建议使用switch，这样使得代码结构清晰，可读性强。

情景1：

使用if进行判断-->

 if (fileType.equals("wav")) {
            return R.drawable.filelook_icon_mp3;
        } else if (fileType.equals("mp3")) {
            return R.drawable.filelook_icon_mp3;
        } else if (fileType.equals("txt")) {
            return R.drawable.filelook_icon_txt;
        } else
            return R.drawable.filelook_icon_unknow;

     }

使用switch代替-->

 switch (fileType) {
            case "wav":
                return R.drawable.filelook_icon_mp3;
            case "mp3":
                return R.drawable.filelook_icon_mp3;
            case "txt":
                return R.drawable.filelook_icon_txt;
            default:
                return R.drawable.filelook_icon_unknow;
        }

最后，建议大家形成编写规范代码的习惯，良好的习惯从细节做起，让习惯称为自然。如果是采用Android Studio开发，可以使用Analyze导航栏里面的lint进行静态代码检测，里面有各种规范约束，如果有不规范之处，会有相应提示，也给出相应的解决方法。