得物App白屏优化系列｜归因篇

一、前言

本系列前面两篇文章已经分别在图片库和网络库的角度介绍了诸多白屏问题的定位和解决方案，但都是相对独立的问题，并且像OSCP，CDN节点异常之类的第三方问题无法彻底根治，因此为了长治白屏并发掘更多问题，就需要一套相对完善的白屏检测+问题归因体系。

本文将介绍从用户视角出发的白屏检测方案以及线上白屏问题的大致归因思路。

二、白屏归因平台概览

三、客户端

检测思路

直接将白屏检测写到图片库里似乎是比较合适的方案，但是基础库的改动也可能出bug导致图片加载失败，例如图片请求的url被某个bug置空，这样展示的效果就是接口正常但是图片全都展示占位图，如果写在图片库里将无法发现该问题。

因此为了规避类似的事件发生，我们需要一个完全使用系统API来实现的白屏检测方案，站在用户视角来判断当前是否发生了白屏，而图片库和网络库提供的信息仅作为前置判断和现场日志。

整体流程图

屏上图片获取

既然是站在用户视角，那么我们就只需要检测屏上的ImageView即可，根据线上用户反馈的信息，白屏问题主要集中在动态流和商品流这类存在大量图片加载的recyclerView中，那么根据recyclerView的特性，我们最终是采用了View类的onAttachedToWindow和onDetachedFromWindow回调来作为对单张图片检测的开始和结束。

这样可以做到和用户视角完全一致，即在图片可见时开始检测，完全不可见时停止检测。此外图片库的上屏请求发起时机也是同样的方法，这样后续获取现场信息也无需再做时间对齐。

像素抽样检测

为了检测ImageView的展示内容是否正常，我们需要获取到其真实展示的Bitmap。为了减少对内存的占用，我们通过draw方法将屏上的ImageView绘制到指定的50*50的Bitmap中，这里注意必须要使用draw来获取Bitmap，不可以从图片库直接获取，因为主线程卡顿也有可能造成白屏，如果从图片库获取就会掩盖这一问题。

由于此处是异步执行ImageView的draw方法，并且我们持有的其实是ImageView的弱引用，因此需要在draw之前判断下其内部的bitmap是否已经被回收，如果是圆角图还需要判断下path对象是否已经被回收，防止出现访问已经回收的native对象的崩溃。

之后从该Bitmap中居中均匀的取出NN个像素点（这里以33为例），按其色值进行统计，找出占比最高的色值的比例，如果其占比超过一定阈值，说明他是白图（不一定是白色，因为占位图背景是淡灰色）。

性能优化

白屏问题作为仅次于crash和ANR的稳定性问题，线上将会全量开启功能，因此对检测性能要求比较严格。

尽管像素抽样检测能够在一定程度上降低内存使用，但是在异步现场频繁调用view的draw方法还是会有性能损耗，如果恰好检测的同时主线程在绘制某一帧，对帧绘制较慢的低端机而言势必会影响体验，因此需要尽可能降低像素抽样检测频次。

离屏检测

onAttach和onDetach仅适用于recyclerview，对于其他的布局在图片上屏/离屏时未必会触发这两个回调，因此需要做些适配。