Android开发代码规范
一. 命名
- 基本的命名规则：遵循驼峰命名法（小驼峰或大驼峰），除了需要全部大写或全部小写的情况以外。
- 代码中的命名均不能以下划线或美元符号开始，也不能以下划线或美元符号结束。
- 代码中的命名严禁使用拼音与英文混合的方式，更不允许直接使用中文的方式，固有名词除外。
- 类名必须使用 UpperCamelCase 风格（大驼峰命名法），固有名词除外。Android系统组件的，必须以系统组件名称为结尾，如xxxActivity.java、xxxFragment.java、xxxService.java、xxxAdapter.java，MVP中presenter为xxxPersenter，涉及所有Model、View、Presenter的接口都以I为前缀。
- 全局变量按照驼峰规则命名，首字母以m开头（非静态变量）
- 方法名、参数名、成员变量、局部变量必须统一使用 lowerCamelCase 风格（小驼峰命名法），固有名词除外。
- 局部变量尽量避免单个字符如a, b，i，j, 除非是临时变量循环变量在for循环中使用。
- 常量命名全部大写，单词间用下划线隔开，力求语义表达完整清楚，不要嫌名字长。
- 抽象类命名使用 Abstract（Abs） 或 Base 开头。
- 包名统一使用小写，点分隔符之间有且仅有一个自然语义的英语单词。包名统一使用单数形式，但是类名如果有复数含义，类名可以使用复数形式。包名命名规则为com.公司名.项目名.模块名，如果是以组件化或插件化的方式开发，单个模块或单个插件中的子包划分按照PBL(按层分包Package By Layer)。
- 杜绝完全不规范或非公认的缩写，避免望文不知义。
- 资源文件的命名以及资源名称统一以小写单词+下划线的方式命名，anim、color、dimen、string等命名格式为：资源类型_模块名_逻辑名称/业务功能
- drawable资源的命名，以对应的用途开头，如分割线以divider_开头，图标以ic_开头、背景图以bg_开头，按钮以btn_开头，选择器状态以对应状态结尾，如xxx_normal、xxx_pressed、xxx_selected等。如果UI设计提供多套资源图标则必须按照mdpi ：hdpi：xhdpi：xxhdpi：xxxhdpi = 2：3：4：6：8的比例放入对应的drawable文件夹中。
- layout布局文件，Activity、Fragment、Dialog等命名格式为activity/frgament/dialog_模块名_逻辑名称/业务功能, include的布局文件统一以layout_开头, layout_模块名_xxx, 列表项的item布局统一以item_开头, item_模块名_xxx
- 布局文件中涉及到string、color、dimen等的，需要提取到对应的xml文件中，以@资源的形式引用
- 控件id的命名格式为，控件缩写+下划线+逻辑名，常见控件缩写表：
| 控件 | 缩写 |
|---|---|
| LinearLayout | ll |
| RelativeLayout | rl |
| FrameLayout | fl |
| ConstraintLayout | cl |
| ListView | lv |
| GridView | gv |
| ScollView | sv |
| RecyclerView | rv |
| TextView | tv |
| EditText | et |
| Button | btn |
| ImageView | iv |
| CheckBox | cb |
| RadioButton | rb |
| RadioGroup | rg |
| WebView | wv |
其它控件的缩写推荐使用小写字母并用下划线进行分割，例如：ProgressBar 对应的缩写为progress_bar；DatePicker 对应的缩写为date_picker。
17 . 代码中涉及到控件的命名，规则为【控件逻辑名称】+【控件名称】，即跟布局文件中id的命名顺序反过来。其中控件名称可以用缩写，但是不能缩写到两个字母，如xxxImageView可以缩写为xxxImage, 不能缩写为xxxIv, xxxEditText可以缩写为xxxEdit, 不能缩写为xxxEt。
二. 常量
- 超过一次以上引用的魔法值(共享值)，不允许直接出现在代码中。（即跨方法、跨类、跨页面等用到魔法值必须共享常量）
- 在 long 或者 Long 赋值时，数值后使用大写的 L，不能是小写的 l，小写容易跟数字1 混淆，造成误解。
- 代码中不允许直接出现中文字符串，使用string资源引用或者常量代替。
三. 代码格式
- Android Studio/Eclispse编写的代码必须进行代码格式化（包括 .java、.xml文件，使用快捷键按照默认风格）。
- 大括号的使用约定。非空代码块则：
1） 左大括号前不换行。
2） 左大括号后换行。
3） 右大括号前换行。
4） 右大括号后还有 else 等代码则不换行；表示终止的右大括号后必须换行。 - 左小括号和字符之间不能出现空格；同样，右小括号和字符之间也不能出现空格；而左大括号前需要空格。 if (a == b)
- if/for/while/switch/do 等保留字与括号之间都必须加空格。
- 任何二目、三目运算符的左右两边都必须需要加一个空格。（包括赋值运算符=、逻辑运算符&&、加减乘除符号等。）
- 单行代码过长时，必须换行（在Android Studio中以编辑面板的右侧竖线为换行标志），换行时遵循如下原则：
1） 第二行相对第一行缩进 4 个空格，从第三行开始，保持与第二行对齐。
2） 运算符与下文一起换行。
3） 方法调用的点符号与下文一起换行。
4） 方法调用中的多个参数需要换行时，在逗号后进行。
5） 在括号前不要换行。 - 方法参数在定义和传入时，多个参数逗号后边必须加空格。
- 一行一个语句，每个语句后要换行。
- 每次只声明一个变量，不要推荐使用组合声明，比如int a, b;。如非必须，变量在需要的时候才去声明并初始化。
- 方法参数不宜过多，如果方法参数太多，函数声明方法名会很长，可以考虑用实体类来封装参数。
- 方法中的行数不宜过多，一个方法中代码超过80行时，必须进行方法提取（refactor）
四. OOP规约
- 必须用类名来访问此类的静态变量或静态方法，避免通过类的对象变量去引用，无谓增加编译器解析成本。
- 所有的覆写方法，必须加@Override 注解。
- 只有相同参数类型并且相同业务含义的，才可以使用 Java 的可变参数，可变参数类型避免使用 Object。可变参数必须放置在参数列表的最后。
- 外部正在调用或者二方库依赖的接口，不允许修改方法签名，避免对接口调用方产生影响。接口过时必须加@Deprecated 注解，并清晰地说明采用的新接口或者新服务是什么。
- 必须使用常量或确定值的对象来调用equals，避免空指针异常。
- 所有相同类型的对象之间值相等的比较，全部使用 equals 方法比较，不能用==（除非是判断相同对象引用或基本数据类型除外）。
- 构造方法里面禁止加入任何业务逻辑，如果有初始化逻辑，请放在 init 方法中。
- 通过用 String.split(xxx); 方法得到的数组，使用前必须做长度检查，否则会有抛 IndexOutOfBoundsException 的风险。
- 避免在getter/setter 方法中增加复杂的业务逻辑，增加排查问题的难度。
- 循环体内String的拼接，必须使用 StringBuilder 的 append方式。
- 不允许被修改的类、对象、方法必须添加final关键字。
- 避免出现重复的代码（Don’t Repeat Yourself），即 DRY 原则。（避免不停的复制黏贴代码，使用OO思想提取重复代码）
- 方法或构造函数中传递过多的参数时，请使用对象封装。如set(ParamWrap param)
- 把一个基本数据类型转为字符串时，一律使用String.valueOf(数据) 的方式，包装类型可使用数据类型.toString()，避免使用数据 + ""的方式
五. 集合处理
- 关于 hashCode 和 equals 的处理，遵循如下规则：
1） 只要重写 equals，就必须重写 hashCode。
2） 因为 Set 存储的是不重复的对象，依据 hashCode 和 equals 进行判断，所以 Set 存储的对象必须重写这两个方法。 - 使用集合转数组的方法，必须使用集合的 toArray(T[] array)，传入的参数必须是类型完全一样的数组（否则强转数组类型时将出现 ClassCastException），并且大小就是 list.size()。
- 使用 Arrays.asList()把数组转换成集合时，不能对集合使用其修改的相关方法， 调用add/remove/clear 等方法会抛出 UnsupportedOperationException 异常。
- 泛型通配符来接收返回的数据，此写法的泛型集合不能使用 add 方法，而不能使用 get 方法，作为接口调用赋值时易出错。（第一、频繁往外读取内容的，适合用。第二、经常往里插入的，适合用）
- 不能在 foreach 循环里进行元素的 remove/add 操作。remove 元素请使用 Iterator方式，如果并发操作，需要对 Iterator 对象加锁。
- 在 JDK7 版本及以上，Comparator 实现类要满足如下三个条件，不然 Arrays.sort，Collections.sort 会报 IllegalArgumentException 异常。
说明：三个条件如下
1） x，y 的比较结果和 y，x 的比较结果相反。
2） x>y，y>z，则 x>z。
3） x=y，则 x，z 比较结果和 y，z 比较结果相同。 - 可以对集合进行快速去重操作时，避免使用 List 的 contains 方法进行遍历、对比、去重操作，可以利用 Set 元素唯一的特性。
- 必须高度注意 Map 类集合 K/V 能不能存储 null 值的情况，如下表格：
| 集合类 | Key | Value | Super | 说明 |
|---|---|---|---|---|
| Hashtable | 不允许为null | 不允许为null | Dictionary | 线程安全 |
| ConcurrentHashMap | 不允许为null | 不允许为null | AbstractMap | 锁分段技术（JDK8:CAS） |
| TreeMap | 不允许为null | 允许为null | AbstractMap | 线程不安全 |
| HashMap | 允许为null | 允许为null | AbstractMap | 线程不安全 |
由于 HashMap 的干扰，很多人认为 ConcurrentHashMap 是可以置入 null 值，而事实上，存储 null 值时会抛出 NPE 异常。
六. 控制语句
- 在一个 switch 块内，每个 case 要么通过 break/return 等来终止，要么注释说明程序将继续执行到哪一个 case 为止；在一个 switch 块内，都必须包含一个 default 语句并且放在最后，即使空代码。
- 在 if/else/for/while/do 语句中必须使用大括号。即使只有一行代码，避免采用单行的编码方式：if (condition) statements;
- 如果非得使用if()…else if()…else…方式表达逻辑，避免超过 3 层, 以至于后续代码维护困难。（可以使用卫语句、策略模式、状态模式等来实现）
- 不要在if/while等条件判断中执行其它复杂的语句，将复杂逻辑判断的结果赋值给一个有意义的布尔变量名，以提高可读性。
- 不要在for循环体中执行 try-catch 操作， 如有需要放在外层。
- 避免采用取反逻辑运算符。如 if (!isOk)
- 在for循环之前, 必须对集合变量进行判空和lengh检查，避免出现NPE或IndexOutBounds异常。
七. 注释规约
- 类、类属性、类方法的注释必须使用 Javadoc 规范，必须使用/*内容/格式，不得使用// xxx方式。
- 方法内部单行注释，必须在被注释语句上方另起一行，使用//注释。避免使用行尾注释。方法内部多行注释使用/* */注释，注意与代码对齐。
- 所有的抽象方法（包括接口中的方法）必须要用 Javadoc 注释说进行说明含义。
- 所有的类都必须添加创建者和创建日期，类的说明。（可以用AS快捷键或模板生成）
- 无用的、过时的注释必须删除，避免维护代码时造成阅读歧义和困惑。
- 反常规、反常识的代码以及核心业务逻辑，必须添加代码注释。
- 注释掉的代码，可以直接删除，如果保留，则需要注释说明是干什么的。
- 方法的代码修改时，如果该方法之前有注释，则也要对注释进行相应的修改，尤其是参数、返回值、异常、核心逻辑等的修改。
- 如果是临时处理或者打算留待将来处理的，必须添加TODO标记备忘，并且在上线提测之前检查工程中的TODO是否已经全部完成（十分重要）。如果是多人协作开发的项目，TODO后面必须添加作者。如果是错误，不能工作的代码，或者目前难以修复的bug，必须用FIXME来注释。
八. 异常处理
- 注意防止 NPE，是程序员的基本修养。注意 NPE 产生的场景：
1）使用全局对象变量和方法传递进来的对象变量之前，必须进行判空操作。
2）返回类型为基本数据类型，return 包装数据类型的对象时，自动拆箱有可能产生 NPE。 反例：public int f() { return Integer 对象}， 如果为 null，自动解箱抛 NPE。
3） 数据库的查询结果可能为 null。
4） 即使集合是 isNotEmpty，集合里取出的数据元素也可能为 null。
5） 调用一个其他方法返回的对象时，一律要求进行空指针判断，防止 NPE。
6） 级联调用 obj.getA().getB().getC()；一连串调用，易产生 NPE。
7） 注意可控与不可控场景，如当前方法内new出来的对象内容是可控的，而接口返回的数据解析生成的对象是不可控，将NPE的重点放在不可控的对象上。 - 方法的返回值为 null的，必须添加@Nullable注释，方法参数同样需要添加。
- catch 时请分清稳定代码和非稳定代码，稳定代码指的是无论如何不会出错的代码。对于非稳定代码的 catch 尽可能进行区分异常类型，再做对应的异常处理。对大段代码进行 try-catch，使程序无法根据不同的异常做出正确的应激反应，也不利于定位问题，这是一种不负责任的表现。
- 捕获异常是为了处理它，不要捕获了却什么都不处理而抛弃之（至少要添加Log输出）。如果不想处理它，请将该异常抛给它的调用者。最外层的业务使用者，必须处理异常，将其转化为用户可以理解的内容。
- 有 try 块放到了事务代码中，catch 异常后，如果需要回滚事务，一定要注意手动回滚事务。
- finally 块必须对资源对象、流对象进行关闭，有异常也要做 try-catch。（如果 JDK7 及以上，可以使用 try-with-resources 方式。）
- 不要在 finally 块中使用 return。
- 捕获异常与抛异常，必须是完全匹配，或者捕获异常是抛异常的父类。
- 传递资源id的方法，必须用Android注释类，标明参数id类型，如setText(@ResId id), 否则有异常风险。
- log输出必须添加TAG, TAG不能为空，方便根据tag定位问题。
九. Android基本组件
- Activity 间的数据通信，对于数据量比较大的，避免使用Intent + Parcelable的方式，以免造成TransactionTooLargeException，可以考虑其他替代方案。
- Activity 间通过隐式Intent 的跳转，在发出Intent 之前必须通过resolveActivity检查，避免找不到合适的调用组件，造成ActivityNotFoundException 的异常。
- 避免在Service#onStartCommand()/onBind()方法中执行耗时操作，如果确实有需求，应改用IntentService 或采用其他异步机制完成。
- 避免在BroadcastReceiver#onReceive() 中执行耗时操作，如果有耗时工作，应该创建 IntentService 完成，而不应该在BroadcastReceiver 内创建子线程去做。
- 避免使用隐式Intent 广播敏感信息，信息可能被其他注册了对应BroadcastReceiver 的App 接收。
- 如非必须，避免使用嵌套的Fragment。
- Service 需要以多线程来并发处理多个启动请求，建议使用IntentService，可避免各种复杂的设置。
- 对于只用于应用内的广播，优先使用LocalBroadcastManager 来进行注册和发送，LocalBroadcastManager 安全性更好，同时拥有更高的运行效率。
- 当前Activity 的onPause 方法执行结束后才会创建（onCreate）或恢复（onRestart）别的Activity，所以在onPause 方法中不适合做耗时较长的工作，这会影响到页面之间的跳转效率。
- Activity 或者Fragment 中动态注册BroadCastReceiver 时，registerReceiver() 和 unregisterReceiver() 要成对出现。一般为onCreate/onDestroy或onResume/onPause。
- Android 基础组件如果使用隐式调用，应在 AndroidManifest.xml 中使用 或在代码中使用 IntentFilter 增加过滤。
十. UI 与布局
- 布局中不得不使用ViewGroup 多重嵌套时，不要使用LinearLayout 嵌套，改用RelativeLayout，可以有效降低嵌套数。
- 源文件统一采用UTF-8 的形式进行编码。
- 禁止在非UI 线程进行View 相关操作。
- TextView等文本大小使用sp，View 宽高间距大小使用单位dp。
- 禁止在设计布局时多次为子View 和父View 设置同样背景进而造成页面过度绘制，推荐将不需要显示的布局进行及时隐藏。
- 尽量不要使用AnimationDrawable展示过多的图片资源（如几十个），它在初始化的时候就将所有图片加载到内存中，特别占内存，并且还不能释放，释放之后下次进入再次加载时会报错。
- 不能使用ScrollView 包裹 ListView/GridView/ExpandableListVIew; 因为这样会把ListView 的所有Item 都加载到内存中，要消耗巨大的内存和cpu 去绘制图面。
- 使用Adapter 的时候，如果你使用了ViewHolder 做缓存，在 getView() 的方法中无论这项convertView 的每个子控件是否需要设置属性(比如某个TextView 设置的文本可能为null，某个按钮的背景色为透明，某控件的颜色为透明等)，都需要为其显式设置属性(Textview 的文本为空也需要设置 setText(“”)，背景透明也需要设置)，否则在滑动的过程中，因为adapter item 复用的原因，会出现内容的显示错乱。
- 灵活使用布局，推荐merge、ViewStub 来优化布局，尽可能多的减少UI布局层级，推荐使用FrameLayout，LinearLayout、RelativeLayout 次之。
十一. 进程、线程与消息通信
- 获取单例对象需要保证线程安全，其中的方法也要保证线程安全。
- 不允许在应用中自行显式创建线程（如new Thread().start()）, 必须通过线程池提供（AsyncTask 或者ThreadPoolExecutor 或者其他形式自定义的线程池工具类），并且要限制最大线程数，减少系统资源的消耗。创建线程池避免使用Executors 去创建，而是通过 ThreadPoolExecutor 的方式。
- 对多个资源、数据库表、对象同时加锁时，需要保持一致的加锁顺序，否则可能会造成死锁。（线程一需要对表 A、B、C 依次全部加锁后才可以进行更新操作，那么线程二的加锁顺序也必须是 A、B、C，否则可能出现死锁。）
- 并发环境下，单例模式避免使用双重检查锁（double-checked locking）实现延迟初始化的方式， 可以采用静态内部类的方式实现。
- 在高并发场景中，避免使用”等于”判断作为中断或退出的条件。
- 不要通过Intent 在Android 基础组件之间传递大数据（binder transaction 缓存为1MB），可能导致 OOM。
- 在Application 的业务初始化代码加入进程判断，确保只在自己需要的进程初始化。特别是后台进程减少不必要的业务初始化。
- 子线程中不能更新界面，更新界面必须在主线程中进行，网络操作不能在主线程中调用。
- 谨慎使用Android 的多进程，多进程虽然能够降低主进程的内存压力，但会遇到如下问题：
1）首次进入新启动进程的页面时会有延时的现象（有可能黑屏、白屏几秒，是白屏还是黑屏和新Activity 的主题有关）；
2）应用内多进程时，Application 实例化多次，需要考虑各个模块是否都需要在所有进程中初始化。
十二. 文件与数据库
- 任何时候不要硬编码文件路径，请使用Android 文件系统API 访问。
- 当使用外部存储时，必须检查外部存储的可用性。
- 应用间共享文件时，不要通过放宽文件系统权限的方式去实现，而应使用FileProvider。
- SharedPreference 中只能存储简单数据类型（int、boolean、String 等），复杂数据类型建议使用文件、数据库等其他方式存储。
- 数据库Cursor 必须确保使用完后关闭，以免内存泄漏。可以使用JDK1.7推荐的try-with-resource语法简化操作。
- 多线程操作写入数据库时，需要使用事务，以免出现同步问题。
- 执行SQL 语句时，应使用SQLiteDatabase#insert()、update()、delete()，不要使用SQLiteDatabase#execSQL()，以免SQL 注入风险。
- 如果ContentProvider 管理的数据存储在 SQL 数据库中，应该避免将不受信任的外部数据直接拼接在原始 SQL 语句中。推荐使用selectionWhere和selectionArgs搭配。
十三. Bitmap、Drawable 与动画
- 当你不得不手动去加载一张图片到内存中去展示的时候，一定要注意图片的宽高尺寸，不管来源是sd卡、网络还是应用内置的背景图片，因为图片的宽高和格式决定了它的内存占用大小，避免OOM，推荐使用Glide等第三方图片加载库。
- 展示大图之前，必须进行尺寸压缩，应根据实际展示需要，压缩图片尺寸，而不是直接显示原图。手机屏幕比较小，直接显示原图，并不会增加视觉上的收益，但是却会耗费大量内存并易导致OOM。
- 网络传输图片之前必须进行质量/体积压缩，以减少流量，加快上传速度，推荐使用三方库压缩处理。
- 加载大图片或者一次性加载多张图片，应该在异步线程中进行。图片的加载，涉及到 IO 操作，以及CPU 密集操作，很可能引起卡顿。
- 在ListView，ViewPager，RecyclerView，GirdView 等组件中使用图片时，应做好图片的缓存，避免始终持有图片导致内存溢出，也避免重复创建图片，引起性能问题。建议使用Fresco、Glide等图片库。
- png 图片使用TinyPNG 或者类似工具压缩处理，减少包体积。（尤其针对UI设计师提供过来的图标资源）
- 使用 RGB_565 代替 RGB_888，在不怎么降低视觉效果的前提下，减少内存占用。
- 谨慎使用 gif 图片，注意限制每个页面允许同时播放的 gif 图片，以及单个 gif 图片的大小。
- 在 Activity#onPause() 或 Activity#onStop() 回调中，关闭当前 activity 正在执行的的动画。
- 在动画或者其他异步任务结束时，应该考虑回调时刻的环境是否还支持业务处理。例如Activity 的 onStop() 函数已经执行，且在该函数中主动释放了资源，此时回调中如果不做判断就会空指针崩溃。
- 在有强依赖 onAnimationEnd 回调的交互时，如动画播放完毕才能操作页面， onAnimationEnd 可能会因各种异常没被回调建议加上超时保护或通过 postDelay 替代 onAnimationEnd。
- 当View Animation 执行结束时，调用 View.clearAnimation() 释放相关资源。
十四. 安全
- 将 android:allowbackup 属性必须设置为false，阻止应用数据被导出。
- 确保应用发布版本的 android:debuggable 属性设置为 false。
- 不要把敏感信息打印到 log 中，发布版必须关闭开发模式的log输出，log工具类必须设置开关。
- 在SDK 支持的情况下，Android 应用必须使用 V2 签名，这将对 APK 文件的修改做更多的保护。
- 所有的 Android 基本组件（Activity、Service、BroadcastReceiver、ContentProvider 等）都不应在没有严格权限控制的情况下，将 android:exported 设置为 true。
- WebView 应设置 WebView#getSettings()#setAllowFileAccess(false)、
WebView#getSettings()#setAllowFileAccessFromFileURLs(false)、
WebView#getSettings()#setAllowUniversalAccessFromFileURLs(false)，阻止 filescheme URL 的访问。 - 本地加密秘钥不能硬编码在代码中，更不能使用 SharedPreferences 等本地持久化机制存储。应选择 Android 自身的秘钥库（KeyStore）机制或者其他安全性更高的安全解决方案保存。
- 在 Android 4.2（API Level 17） 及以上，对安全性要求较高的应用可在Activity中，对 Activity 所关联的 Window 应用WindowManager.LayoutParams.FLAG_SECURE，防止被截屏、录屏。但要注意的是，一个 Activity 关联的 Window 可能不止一个，如果使用了 Dialog / DialogFragment 等控件弹出对话框，它们本身也会创建一个新的 Window，也一样需要保护。
- zip 中不要包含 …/…/file 这样的路径，可能被篡改目录结构，造成攻击。
- 使用Android 的 AES/DES/DESede 加密算法时，不要使用 ECB 加密模式，应使用 CBC 或 CFB 加密模式。
- 应用开启混淆必须十分小心，注意必须keep的类，尤其第三方的库，否则将导致release版本调用异常。
- 应用中涉及到so库时，必须注意保证每一个armeabi文件夹中so的数量一致（尤其是多module大量依赖三方的时候），否则将导致应用加载so异常崩溃。如非必要，只保留一个armeabi文件夹。
十五. AS配置
- 组件化插件化的方式下，多个module依赖相同的依赖库，依赖库版本必须集中控制，如建立公共的gradle文件来管理。同样compileSdkVersion、minSdkVersion、targetSdkVersion也需要集中控制。
- 签名文件、IP Host、一些key或控制开关等尽量使用配置文件，通过gradle去配置，在变更时避免修改代码。高效使用BuildConfig文件可以避免很多麻烦。