查看 Android 代码库时要记住的几点：
代码审查有时是一个乏味的过程，但我相信我们需要花更多的时间在这上面。 也许这是你学习或分享一些知识的机会。
这里列出了一些在 Android 项目的 Code Review 过程中检查所必需的要点。

Memory Leaks（内存泄漏）：

想象一下以下情况：一个漂亮的应用程序，但同时速度很慢，屏幕之间的导航每次都变慢。
在代码审查期间要检查的一些要点：

• 
  
• 这段新代码是否有任何 Context 保留？
  
• 有没有相关的 RxAndroid 代码？ 如果是，请检查 RxCall 是否在生命周期范围（ViewModel/Fragment/Activity）结束时被释放。
  
• 如果代码有 coroutines(协程)，检查 Job 是否从 ViewModel 范围启动以正确释放。
  
• 代码中有使用 CountDownTimer、AsyncTask 或任何视频/音频播放器的实现吗？ 如果是，则代码应该释放与避免泄漏相关的内存资源。
  
• 是否有新的 Fragment with ViewBinding 方法，代码应该在 onDestroyView 方法处释放绑定。
  

private ResultProfileBinding binding;


@Override

public View onCreateView (LayoutInflater inflater,

                          ViewGroup container,

                          Bundle savedInstanceState) {

    binding = ResultProfileBinding.inflate(inflater, container, false);

    View view = binding.getRoot();

    return view;

}


@Override

public void onDestroyView() {

    super.onDestroyView();

    binding = null;

}

深度布局：

有时我们有一个 ViewGroup 有另一个 ViewGroup 作为子布局。
一个好的建议是始终使用 ViewGroup ConstraintLayouts 来保持布局更平坦。 它可以避免导致性能问题的过度绘制。
Android 文档中提到了一些减少过度绘制的技巧。

资源注释：

Android 世界中的每个资源都有一个标识符，它是一个 Integer 类型。 如何确保我们的 Integer 值代表一个有效的资源 ID？ 注释可以帮助我们解决这个问题。
例如：

fun showMessage(context: Context, val idRes: Int) {

  Toast.makeText(context, idRes, Toast.SHORT_LENGHT).show()

}

在上面的代码中，Code Reviewer 会建议你，在这里使用注释。
例如：

fun showMessage(context: Context, @StringRes val idRes: Int) {

  Toast.makeText(context, idRes, Toast.SHORT_LENGHT).show()

}

其他注释示例在这里。

类似组件：

在 Code Review 期间投入时间非常重要。 尝试按照作者的想法思考，反映他的选择，提出问题以理解代码。
一个新的需求，需要写很多新代码。 应该和项目组成员及时沟通，比如：“此代码与我们在此组件中已有的相同”。 像这样的沟通说明是必不可少的，因为最重要的是重用我们代码库中已经存在的代码。

危险代码区：

如果你有遇到敏感的代码或危险代码区。 危险代码是 Code Reviewer 需要重点查看的，当你发现一些代码没有任何意义的时候。在这种情况下，不要评判作者。与他们交谈以了解该代码背后的原因。 这次谈话可能是一个学习新东西的机会。也有可能是你自己对这块业务考虑不周，没了解到这段代码本质的原因。如果交流后，发现还是确实有问题，就可以把这块代码区的问题给更正了。

架构违规📐：

软件架构是定义在软件各部分之间的通信协议。
Code Review 是识别架构违规等问题的非常有效的手段。 在这种情况下可以做如下沟通是比较合适的：
“你的 ViewModel 正在访问存储库。 我们在它们之间有一个用例。 请看一下 MainViewModel 文件，这是一个可以参考的例子。”
“为什么要在 ViewModel 中使用 Adapter 引用？ 适配器是一个 RecyclerView 组件。 最好把它放在一个 Fragment 中，让它远离我们的 ViewModel。”

小细节决定一切：

• 
  
• 未使用 import；
  
• 未使用的资源，例如 drawables, strings, colors……
  
• 注释代码；
  
• 未格式化的代码；
  
• 变量名、方法名、文件名……
  
• 代码不遵循样式指南。 例如，Kotlin 定义了一个定义明确的样式指南。 它对任何开发人员在现有代码库中快速找到任何软件组件都有很大帮助。
  

结论

静态分析工具在代码审查过程中很有帮助，但它们并不是 100% 有效的。 如果你的团队正在寻找代码质量，关键的 Code Review 是必不可少的。