| 序号 | 问题 | 建议 |
| 1 | 圈复杂度 | 不超过10 |
| 2 | synchronized的范围 | 控制范围，缩小粒度 |
| 3 | 出现伪重载，多个不同修饰符 | 重载函数的修饰一致 |
| 4 | 参数多 | 不超过5个，多个合并为个参数类 |
| 5 | 加锁必要性 | 如果非多线程使用场景，去掉锁 |
| 6 | 容器类如StringBuilder，hashMap制定预设大小 | |
| 7 | 优先使用JDK工具函数 | |
| 8 | 锁对象选择 | 最优是new byte[0]作为锁对象 |
| 9 | 类的对外接口个数，即函数的修饰是否合理 | 不要一股脑的public，控制对外暴露的风险 |
| 10 | 判断逻辑里条件个数太多，理解困难 | 判断逻辑里超过4个即整理为一个独立函数 |
| 11 | 资源释放问题 | 在finally或1.8后的try |
| 12 | 函数逻辑规整 | 使用空格 归类逻辑 |
| 13 | 函数名 | 见名知意，首先要使用正确的单词；不能太长，太长也意味函数包含太多逻辑；设置/获取数值型的函数名称需要带上数值单位 |
| 14 | 函数的抛出异常 | 需要在注释里说明，或者使用throws |
| 15 | 有效代码行数 | 40 |
| 16 | 无效代码清理 | |
| 17 | 局部变量距离最近使用 | 不超过3行 |
| 19 | 防范式编程 | 异常或值校验，要先做，尤其是对外接口 |
| 20 | 注释 | public 必须注释 |
| 21 | 方法逻辑清晰 | 功能单一和函数名称切合，如有修改逻辑及时修改注释 |
| 22 | 对之前版本的兼容 | 对外接口函数，旧函数如果要替换，需要一个弃用过程，并提示替换的方案 |
| 23 | 参数名称 | 见名知意，参数如果有多个单位层级，需要独立一个参数表示单位，如时间单位，磁盘大小的单位 |
| 24 | 函数功能的对称性，如有 | 如add 就要remove，init 对应destroy |
| 25 | 防止死锁，查看锁对象的应用位置 | |
| 26 | 使用线程池 | 控制线程大学，和任务队列大小，Exctors方法谨慎使用。 |
| 27 | 多算法的合理组合 | 如快速排序是286个以下，以上就使用合并排序 |
| 28 | 函数参数的信息量太大，不可测，如一个对象传进来，只是使用了对象的一个属性 | 坚持够用就好 |
| 29 | 入参数被修改 | 不要修改入参，和C/C++相反，如有修改是拷贝副本，处理后再return |
| 30 | 多个判断逻辑混乱，出现执行路径不可达或重复执行 | |
| 31 | 跨平台传输数值 | 使用String方法，尤其是浮点数 |
| 32 | JNI/NDK的内存回收问题 | 全局引用（Global reference），局部引用（Local reference），弱全局引用（Weak global reference）。 全局引用的生存期为创建之后，直到程序员显式的释放它。 局部引用的生存期为创建后，直到程序员显式的释放他们，或在当前上下文（可以理解成Java程序调用Native代码的过程）结束之后没有被JVM发现有JAVA层引用而被JVM回收并释放。 弱全局引用的生存期为创建之后，到程序员显式的释放他们或JVM认为应该回收它的时候（比如内存紧张的时候）进行回收而被释放。 |
| 33 | 日志打印收集 | 日志必须有统一工具进行打印收集 |
| 34 | 使用高效序列化工具 | FlatBuffer |
| 35 | 配置属性，使用SP导致阻塞 | SP数据不能太大，分开到不同XML。建议使用MMKV，datastore |
| 36 | JUC的加锁容器，不是万全的 | 这些只是对象函数是线程安全，但容器本容易被其他线程操作 |
| 37 | 参数或成员变量的类泛化程度 | 入参是context，但函数却要强制转换为activity，应该直接定义为activity |
| 38 | 对象复用 | 如Android的Message 使用obtain获取对象，不是一味new Message |
| 39 | 序列化控制 | transient关键字，不需要序列化的属性前添加 |
| 40 | 数据容器的结合场景使用 | 如查询多的使用Arraylist或Vector，增删多的使用LinkedList， |
| 41 | 键值对容器 | 取名把key -value 体现在 名字上 |