Xamarin Forms ListView性能对比：XAML绑定与OnBindingContextChanged

针对你这个使用RecycleElement缓存策略、包含自定义单元格的ListView场景，我来拆解下两种绑定方式的性能差异和适用场景：

核心结论 #

在你的场景下，两种方式的性能差异微乎其微，但XAML直接绑定在可维护性、可读性上优势明显，除非有特殊业务逻辑需求，否则优先选XAML绑定。

具体分析 #

1. RecycleElement的工作逻辑是关键 #

RecycleElement会复用已创建的单元格实例，而不是每次滚动都新建。不管用哪种方式，每次单元格绑定上下文切换时，都会触发更新操作——XAML绑定会自动同步属性，OnBindingContextChanged则需要你手动更新控件属性。这两种操作的开销都集中在属性更新本身，而非控件创建，所以性能差距很小。

2. XAML绑定的性能表现 #

Xamarin Forms的绑定系统经过多年优化，尤其是开启**编译绑定（Compiled Bindings）**后，性能会大幅提升：

• 编译绑定会在编译阶段生成绑定代码，避免了运行时反射的开销，对于你提到的9项绑定来说，这种优化非常明显。
• 对于Image的UriSource绑定，框架本身就内置了图片缓存机制，不会重复下载相同Uri的图片，完全能高效处理你每个单元格两张图片的需求。
• 只要在XAML中正确配置x:DataType指定你的ViewModel类型，并开启x:Compile="True"，绑定的性能几乎和手动赋值持平。

3. OnBindingContextChanged手动处理的利弊 #

手动在代码里更新控件属性，比如：

protected override void OnBindingContextChanged()
{
    base.OnBindingContextChanged();
    if (BindingContext is MyItemViewModel vm)
    {
        MyImage.Source = vm.ImageSource;
        // 其他8项属性赋值...
    }
}

• 理论上会比绑定系统少一点“中间层”开销，但这种差异在RecycleElement的复用场景下几乎感知不到——毕竟只是简单的属性赋值操作。
• 缺点却很突出：代码冗余，每加一个绑定就要手动加一行赋值；容易出错，比如漏写某个属性或者类型转换错误；后期维护成本高，修改绑定逻辑要同时改XAML和代码。

4. 什么时候需要用OnBindingContextChanged？ #

只有当你需要在绑定上下文变化时执行额外逻辑时，才考虑这种方式：

• 比如图片加载前设置占位符，或者根据ViewModel的某个状态动态调整单元格布局；
• 或者对数据做复杂转换（不过这种场景更推荐用IValueConverter，保持XAML的可读性）。

最终建议 #

优先使用XAML编译绑定，配置方式如下：

1. 在XAML根元素添加x:Compile="True"和x:DataType="local:MyItemViewModel"；
2. 保持原有XAML绑定写法，比如<Image Source="{Binding ImageSource}" />。

这种方式既保证了性能，又让代码结构清晰、易于维护，完全能应对你100项列表、多绑定多图片的场景。

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