ViewBindings未提供程序化inflater是否存在技术层面的原因？

先明确View Binding的当前工作方式 #

你说的没错，当调用ActivityMainBinding.inflate(getLayoutInflater())时，它本质上还是走LayoutInflater的标准XML加载流程，只是在布局加载完成后，自动生成了获取各个View的代码（替代findViewById），并没有跳过XML解析和文件系统调用。

为什么不直接生成代码创建视图？ #

这里有几个关键的技术和设计原因：

• 动态资源与配置适配的需求
  XML布局里大量使用的主题、样式、资源引用（比如@dimen/xxx、@color/xxx）是运行时动态解析的——比如横竖屏切换、黑暗模式切换、不同语言区域适配，这些都需要LayoutInflater在运行时根据当前设备配置加载对应资源值。如果编译时直接生成硬编码的视图创建代码，要么得为所有可能的配置生成对应代码（会让APK体积急剧膨胀），要么就完全丢失动态适配能力，这显然不符合Android的设计理念。

• 布局复用与嵌套的复杂性
  XML中的<include>、<merge>标签，以及RecyclerView这类组件的布局复用逻辑，都是LayoutInflater在运行时动态处理的。如果改成编译时生成代码，需要把所有嵌套布局、include的内容提前展开，这会让生成的代码极度臃肿，还会完全丢失XML布局的可读性和复用性——开发者维护XML和生成的代码会变成两套逻辑，反而增加成本。

• 第三方自定义视图的兼容性
  很多自定义视图的初始化依赖LayoutInflater传递的AttributeSet参数，用来解析XML里定义的自定义属性。如果用硬编码创建视图，得手动把所有XML中的属性转换成代码调用，这对复杂的自定义视图来说几乎不可行——每个自定义视图的属性解析逻辑都不一样，编译时生成代码很难覆盖所有场景，容易出现兼容性问题。

• 框架生态的兼容性约束
  LayoutInflater是Android布局系统的核心组件，Fragment、Adapter等大量系统组件都是基于它设计的。View Binding作为官方框架的一部分，必须和这些现有组件兼容。如果改成硬编码创建视图，会打破现有生态，导致大量现有代码无法正常工作，这显然是Google不愿看到的。

有没有类似的替代方案？ #

如果你追求“用代码创建视图提升性能”的目标，官方推荐的方案是Jetpack Compose——它完全抛弃XML，直接用Kotlin代码构建UI，不仅性能比XML inflate更优，还能提供更灵活的UI构建方式。

曾经有第三方库如Anko尝试用代码构建UI，但因为前面提到的动态适配、兼容性等问题已经停止维护，而Compose已经成为官方主流UI方案。

总结 #

目前View Binding不会改成直接生成代码创建视图，主要是因为XML布局的动态特性、布局复用的复杂性、第三方视图兼容性以及框架生态约束这些原因。如果想绕过XML inflate的性能问题，迁移到Jetpack Compose是更合适的选择。

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