MvxRecyclerView遇HttpClient.SendAsync返回卡顿，如何避免UI线程阻塞？

你遇到的卡顿本质是旧版Mono.Android自带HttpClient实现的线程调度缺陷：其内部LoadIntoBufferAsync方法即便调用时配置了ConfigureAwait(false)，仍会主动将完成回调调度到UI线程执行，刚好和滑动时MvxTemplateSelector匹配30种模板的高CPU占用操作抢占UI线程资源，最终触发数秒无响应。

• 替换HttpClient底层实现：在Xamarin.Android项目属性的「Android选项」配置页，将HttpClient实现从默认的Mono托管实现切换为AndroidClientHandler，该实现基于安卓原生网络栈，不存在线程调度缺陷，请求全程不会占用UI线程资源。
• 优化MvxTemplateSelector性能：给模板选择器新增「ViewModel类型-模板ID」的内存缓存，第一次匹配完成后缓存对应关系，后续滑动时无需重复判断模板类型，大幅降低UI线程在滑动场景的计算负载，即便有短时线程抢占也不会触发明显卡顿。
• 调整同步请求调度逻辑：给用户输入触发的同步请求加200~300ms防抖，避免输入过程中频繁发起请求；同时监听RecyclerView的滑动状态，滑动过程中暂停同步请求，待滑动停止后再补发，从根源上避免两个高耗操作同时执行。
• 规避Mono HttpClient的问题逻辑：若必须使用托管HttpClient实现，调用SendAsync时传入HttpCompletionOption.ResponseHeadersRead参数，仅等待响应头返回就结束异步等待，后续在后台线程手动读取响应流，不调用ReadAsStringAsync/ReadAsByteArrayAsync等默认方法，即可跳过有缺陷的LoadIntoBufferAsync逻辑，参考代码如下：

// 仅读取响应头，不自动加载响应体
var response = await httpClient.SendAsync(request, 
    HttpCompletionOption.ResponseHeadersRead, cancellationToken)
    .ConfigureAwait(false);
// 后台线程手动读取流，避免触发LoadIntoBufferAsync
using var responseStream = await response.Content.ReadAsStreamAsync()
    .ConfigureAwait(false);
// 后续自行处理流解析逻辑

你之前尝试的Task.Run、将请求放到Service中执行无效，是因为卡顿的触发点不在请求发起的线程，而在HttpClient内部的默认回调逻辑，和请求发起位置无关。

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