Android ViewBinding两种初始化写法的区别及最佳实践

核心差异点 #

• 初始化时机完全不同
  第一种lateinit var的写法是主动式初始化：你必须在Activity的onCreate生命周期里手动执行inflate和赋值，只要你在赋值前访问binding，会立刻抛出未初始化异常，代码执行时机完全由你控制。
  第二种by lazy的写法是懒加载初始化：你不需要提前手动赋值，只有第一次访问binding变量的时候，才会自动执行lambda里的inflate逻辑。但注意你贴出来的lazy写法本身就是错误代码：lambda里在inflate之后直接调用setContentView，没有返回binding实例，根本无法通过编译，属于网上流传的抄漏了的错误示例。
• 变量可变性不同
  lateinit声明的是var可变变量，后续代码里如果误操作重新给binding赋值，编译器不会做任何拦截，存在被意外篡改的风险。
  by lazy声明的是val只读变量，一旦初始化完成就无法重新赋值，从语法层面避免了实例被篡改的可能。
• 异常风险与排查成本不同
  lateinit的异常场景非常明确：只有漏写赋值才会崩，崩溃栈直接指向访问位置，排查成本极低，也可以通过::binding.isInitialized在访问前主动判断初始化状态。
  lazy的异常场景更隐蔽：如果在Activity还没attach到Window（比如super.onCreate执行前）就第一次访问binding，这时候layoutInflater还没初始化，会直接崩溃；如果像你贴的错误示例那样把setContentView写在lazy块里，要是第一次访问binding的时机晚于onCreate执行阶段，会出现界面不渲染、甚至生命周期错乱的问题，而且崩溃栈会夹杂Kotlin委托类的内部逻辑，排查成本更高。
• 性能开销不同
  lateinit只是普通的变量声明，没有任何额外开销。by lazy是Kotlin的属性委托，会额外生成委托对象持有锁和实例，虽然这点开销对于Activity来说几乎可以忽略，但属于完全没必要的额外支出。

更优方案选择 #

官方给出的lateinit标准写法是生产环境的最优选择，原因非常直接：

1. 生命周期完全对齐：inflate、setContentView的逻辑严格放在onCreate里执行，完全符合Android的Activity生命周期规则，不会出现任何时机错乱导致的玄学bug，代码可读性极强，任何开发者接手看onCreate就能理清视图初始化流程。
2. 没有隐藏逻辑：所有初始化逻辑都是明写的，不存在藏在委托里的隐式执行代码，后续维护、加日志排查问题都更方便。
3. 不存在错误传播的可能：网上流传的lazy写法很多都像你贴的那样，把setContentView塞在lazy块里，属于典型的为了省一行代码埋坑的写法，抄的人很容易不注意时机问题，线上出了问题很难定位。

如果实在不想写lateinit的手动赋值，即使用lazy，也绝对不能把setContentView放进lazy块里，必须把setContentView逻辑放在onCreate里明确调用，但这种写法相比标准写法没有任何实质收益，反而引入了额外的时机风险，完全不推荐。

内容的提问来源于stack exchange，提问作者Alex20280