体验专题—1688商家版如何解决困扰用户的白屏问题
背景
客户端的白屏问题对开发同学来说一直是一个棘手的长尾问题，其成因也不胜枚举。随着千牛用户逐渐迁移以及APP DAU的不断增长，1688商家版中用户反馈白屏问题的数量也随之水涨船高。但由于商家版缺乏好的排查手段以及反馈内容不明确等原因，一直无法很好地定位具体的白屏原因。因此，我们需要对商家版整体的白屏情况痛殴制定标准化的检测方式来摸清现状，并且针对重点场景进行定向治理，以期降低白屏率并提升用户体验。
现状摸底
首先我们需要定义出白屏的特征，并且引入一套检测白屏的算法，从而对商家版的页面白屏情况做一个摸底。
白屏定义
从舆情反馈的现场和对客户端实现的理解将白屏的定义为：在一定时间内，页面元素得不到及时的展现，导致页面布局出不来，或者出现错误的打底页面，或者部分的图片出不来的页面，定义为白屏。根据该定义，我们可以制定一套白屏的检测算法来统计白屏的数据。
检测算法
截屏图像检测算法：基于同颜色像素占比判定。
1.首先会对屏幕做一个截屏，使用的是PixelCopy.request方法（这种方式比直接从DecorView获取截图准确性更高，尤其是在webview、播放器、Surface/Texture 等直接渲染的渲染页面中，注意Android 8.0以上才能使用），最终会生成一个Bitmap，为了减小内存，会对图片做一个等比缩小的操作。
2.在图片宽高范围内进行取点，从上到下，从左到右，取到所有的像素点
3.遍历像素点并记录各个点的rgb值
4.遍历所有rgb值，是否某种rgb值超过阈值，目前的阈值为90%（不仅是纯白色，纯色也能检测到）
5.超过90%的截屏页面会被视作白屏并上报。
白屏检测时机
离开页面时，且当前页面停留时间>X，触发白屏检测，X=6
进入后台时，且当前页面停留时间>X，触发白屏检测（iOS没有）
数据分析
有了白屏检测的数据之后，接下来就是对现有的数据进行分析。通过各业务之间白屏率的比较以及与其他app页面之间的对比，我们发现订单列表页、订单详情页、物流管理页、生意参谋页等页面白屏率偏高，将会作为本期重点治理的页面。同时，我们也根据目前白屏率的平均水位以及参考业内的水准定义出了白屏率的基线，超过基线的页面将会收到预警并重点关注。
问题分析
排查手段
H5日志排查
可能导致白屏的问题：
SSL证书错误：
WVUCWebViewClient#onReceivedSslError
WindVane/WVUCWebViewClient: onReceivedSslError url: xxxxx errorMsg: xxxxx
网络资源请求错误（主要是Html资源）：
WVUCWebViewClient#onReceivedError
WindVane/WVUCWebViewClient: Received error: xxxxx desc: xxxxx
浏览器进程Crash（出现这种日志可能会导致webview白屏）
WVUCWebViewClient.sandbox：onRenderProcessGone webview: xxxx crash:xxxxx priority
keywords: sandbox, onRenderProcessGone
登录态排查
通过agoo查询用户是否登录
通过ut打点日志查看进入webview时是否带有cookie
排查case
这里举出了几个白屏case的排查过程，可以作为后续类似问题解决的一个范式
case1
新版物流详情页的一个白屏case：同一个物流页面，不同入口，从旺旺页入口进入时，有部分iOS机型会“白屏”（其实是内容被上移了，向下滑动页面可以看到）。
问题原因：排查发现由于消息聊天入口老页面路由的地址还是旧版物流的地址，旧版会重定向到新版物流，导致ios端动态计算webview页面高度的时候会出现数值上较大的偏差，导致了视频里面的问题。避免页面重定向解决了此问题。
治理后：该页面的白屏率也迅速下降到了正常的水位。
case2
现象
某一时刻开始多名用户反馈进入订单页显示加载失败
通过集团h5日志解析平台解析用户的tlog日志，发现用户都出现了onReceivedSslError错误日志，均指向pcookie.1688.com这个域名
对这个域名进行连接测试，发现pcookie.1688.com证书确实存在问题
sre同学排查发现三条主要线路的ip对业务域名 pcookie.1688.com 均不可用
# 49.79.227.133 pcookie.1688.com # 114.112.207.37 pcookie.1688.com # 223.109.146.132 pcookie.1688.com 59.82.14.134 pcookie.1688.com'
将该域名回滚之后问题解决
case3
现象：商家端物流管理页在首次安装时会反复进行重定向跳转，最后才会进入目标页
原因：在排查中发现商家版启动登录库会自动拉取cookie，但是没有拉倒cookie1，导致所有使用http请求的前端页面，在首次启动无法获取登录态，会跳转登录页。分析问题应该是登录库服务侧需要某些配置。
简单讲就是这个页面基于纯Web技术，走的是Web接口，没有走Mtop请求， 所以不会调用端内的Mtop，自然不会携带端Mtop的登录态给后端。 此时后端返回了类似 session not found 之类的错误，前端跳了havana统一登录， havana统一登录又调用了端上的mtop bridge去验证用户登录态，发现用户有登录态之后， 带参跳转了 pass.1688.com 的中间页，然后种了cookie进来，然后用户就能正常访问了
主客获取cookie1堆栈
商家版获取cookie堆栈
治理手段及效果
接入zcache
ZCache是一种在线资源的强缓存方案，可以让前端在 ZCache 发布平台将页面使用的 html、js、css 等资源打包，客户端会在合适的时机下载或者直接预置的方式将资源保存到本地，使得用户在浏览页面的时候不需要再去下载资源，有效提升 Web、Weex 等页面的加载性能，改善用户体验。
由于历史原因，商家端一直没有接入过ZCache。这次通过接入ZCache缓存机制来提升页面加载速度及成功率，从容降低页面白屏率。一期主要在订单相关页面上接入了zcache。接入之后，Android侧相关页面白屏率下降20%，iOS下降25%，白屏率均降至千一以下。
登录态优化
基于双端webview cookie经常丢失的问题，我们作出了以下优化
在进入webview之前主动进行cookie的检测，如果cookie失效则直接注入cookie
前端在业务代码中通过cookie检验登录302的跳转方式需修改为由列表接口判断是否登录，然后通过JS唤起登录浮层。
部分商家版的cookie在启动时未配置拉取导致进入页面时反复重定向至登录页，重新配置该cookie后恢复正常
网络优化
弱网优化
为了提升弱网下前端页面的请求成功率，端侧可接入网络多通道能力，当用户处于WiFi弱网下，在一定的策略下会通过蜂窝网络使用移动数据来进行网络补充请求。
一般来说我们把用户网络波动、信号强度弱、时延RT大称之为弱网环境
手淘网络多通道方案优化数据：在2022年的双十一期间双端日改善卡顿请求5.5亿+，对请求超时率减少30%以上。
在H5白屏治理中发现白屏case中弱网和非弱网状态下的白屏数（日均值）对比，每天白屏数中弱网白屏占比约19%。
功能描述：当网络请求发出超过一定时间未返回数据后，触发切换蜂窝网络重试的请求，原先流程的请求不中断，使用优先的通道请求响应。前置场景为当用户设备连接了WIFI，并且4G/5G蜂窝网络可用时。
接入方式：接入手淘的networkSDK，通过代码设置开启网络多通道配置，同时通过orange配置开关、文案、白名单等参数。
优化效果：目前商家版Android端接入弱网优化后日均卡顿率下降24%，核心页面白屏率下降20%
Xquic落地
QUIC是用来代替TCP、SSL/TLS的传输层协议，在传输曾之上还有应用层，我们熟知的应用层协议有HTTP、FTP、IMAP等，这些协议理论上都可以运行在QUIC之上，其中运行在QUIC之上的HTTP协议称为HTTP/3。
下图可以看出HTTP/3首次连接只需要1RTT，后面的连接更是只要0RTT。
Xquic在iOS端侧已全量发布。截止8月09日，全版本quic协议请求占比为65%
性能优化效果
平均耗时降低35ms，P85降低40ms，P95降低66ms
接入iTrace
参考https://ata.alibaba-inc.com/articles/141259?spm=ata.25287382.0.0.22a226b0q7C8oy#ErqDRAxt
U4内核中本身就包含白屏检测的能力，同时也包含诸多错误日志的上报。通过接入iTrace，我们可以接收U4内核在各个客户端监控上报的线上白屏事故，对这些信息进行聚合计算，并提供一个操作界面给到业务方进行监控和问题的定位分析。
目前iOS试点页面（新版物流页和新版生意参谋页）的监控大盘中，如下图所示：API成功率较低，排查后发现是物流页面使用了高德的接口导致，即使页面正常渲染，也会有大量的API请求错误，后续可以和交易侧物流页负责人共同推动治理此问题。
此外，也可根据占比较大的js和资源异常，推动前端的同学进一步分析和排查，降低页面的白屏率。
重定向问题优化
Android在打开前端页面时，如果前端触发了重定向逻辑，Android会重新打个一个新的Activity，导致在进入目标页并返回后，会回到一个白屏页，必须要返回多次才能返回原来的页面，对用户产生较为糟糕的体验。
解决方式：在触发重定向时不打开新页面，而是重新加载页面url
webView.loadUrl(targetUrl);
整体效果
本期白屏优化后核心页面白屏率均降至0.1%以下，用户柯南反馈每周较峰值下降70%
用户调研
我们希望对用户白屏反馈问题进行周期性的调研以帮助我们更好地了解优化是否有效，包括但不限于：
白屏相关工单统计
白屏相关体验月报
白屏反馈页面统计
总结
白屏治理是一项长期性的工作，随着时间的推移，原有的一些治理好页面很可能会出现腐化。因此，在白屏治理的过程中，我们需要沉淀出一套体系化的治理方式，结合已有平台并完善相关能力，从采集观测、问题分析、治理优化三个步骤来解决端侧的白屏问题，如下图所示。通过这些方式，我们希望能提供给用户更好的使用体验，将白屏类的问题扼杀在摇篮里。