问题排查 | 客户端突如其来的“白屏”等待

本文涉及的产品
mPaaS订阅基础套餐,标准版 3个月
简介: 一起由离线包重构引起的“白屏”等待现象的排查和解决案例

今日暂停营业一起爬山公众号首图.jpg

——本文选自《阿里云SRE技术期刊》2021年02月刊

移动端的混合架构模式给 App 开发带来了崭新的空间,通过 H5 构建的业务模块可以实现高效快速的版本迭代,满足多样化的业务需求。为了弥补 H5 技术的部分性能不足,mPaaS 客户端框架为开发者提供了“离线”机制。


开发者在接入 mPaaS H5 容器后,配合 mPaaS 移动发布服务,可以让客户端方便地从本地加载 H5 业务包,极大地提升了 H5 应用的加载效率。需要注意的是,这套离线机制的接入过程必须要严格按照文档来进行,一些细微的错误可能导致离线机制失败,给 H5 应用的加载性能带来影响。


这篇文章将和大家分享一起由离线包重构引起的“白屏”等待现象的排查和解决案例。



1. 问题背景

我们(阿里云金融线 SRE 团队)接到客户的反馈:开发者对所有线上离线包进行了一轮的整合和重构,发版后发现 H5 应用的加载性能出现较大的退化:在网络好的情况下会有一个短暂的“白屏”等待时间,在网络较差的情况下,甚至完全无法完成页面的加载。更详细的信息包括:


1) 前一天晚上在生产环境进行离线包版本更新,发现发布白名单内的用户访问离线包出现性能退化

2) iOS 和 Android 双端均存在这个问题

3) 白名单内共有 20 多个内部用户,非外部用户,对外业务没有实际影响

4) 非白名单内用户访问的还是老版本的离线包,没有出现问题

5) 开发侧的变更内容包括:

a) 全量离线包更新,更新数量大概是60个左右

b) 旧离线包的架构是 1 个公共资源包 + N 个普通资源包

c) 新离线包的架构是 3 个公共资源包 + N 个普通资源包



2. 分析与排查

根据症状 “网络好的情况下会有一个短暂的“白屏”等待时间,网络较差的情况下,甚至完全无法完成页面的加载”,我们首先怀疑的是离线包的“离线”机制失败了,流量 fallback 到了线上资源。推测“白屏”等待时间是 Web 资源网络下载和加载慢导致的,如下图所示:


要验证这个推测,我们需要通过抓取 HTTP 层面的报文来确认这个问题,抓包方法可参考文后资料了解详情[1]。从网络包中我们观察到,每次打开 H5 应用,均存在不同程度的资源文件拉取行为,这些 Web 资源大的有几十 MB,通过网络加载速度较慢,如下图所示:


和客户进一步沟通确认,这部分资源来自于一个新增的公共资源包。根据 mPaaS H5 容器的接入要求,公共资源包的注册需要在容器初始化的时候手动指定,而普通资源包则不需要这样的操作,可参考文后资料了解详情[2],[3]


结合当时的情况(仅进行了离线包的云端重构,新增 3 个全局资源包,客户端 App 并未重新发版)推测:这部分 fallback 流量产生原因是客户端未注册新的公共资源包,因此容器不知道这部分资源在本地的映射,只能从网络 fallback 地址获取,而这里的核心 JS 资源的加载慢导致了“白屏”等待的性能问题。


根据上述分析进行客户端代码检查,确认客户端确实没有对新增的公共资源包进行注册。开发者按照文档重新对这个细节进行处理,打包测试后确认问题消失:不再有 fallback 的请求,“白屏”等待的问题也得到了解决。



3. 小结

开发者在 mPaaS H5 容器在接入和使用上需要对一些细节投入特别的关注,比如离线包的验签和全局包的使用等。因为 H5 容器存在 fallback 机制,所以即使“离线”失败,容器也是可以“正常”加载业务包的内容的,开发阶段开发者往往容易忽略掉“离线”对性能层面的影响。建议开发者在联调和上线的过程中,对于离线机制的工作情况予以检查和确认,可以通过抓包的手段从外部确认没有额外的、非必要的 fallback 请求产生,最终的目的是发挥离线包的性能优势。


参考文档

[1]如何抓取 HTTP 报文(Mac OS/Charles):https://help.aliyun.com/document_detail/159161.html

[2]Android管理离线包:https://help.aliyun.com/document_detail/112553.html

[3]iOS管理离线包:https://help.aliyun.com/document_detail/112928.html




《阿里云SRE技术期刊》

《阿里云SRE技术期刊》2021年02月刊重磅发布啦,囊括了事件要闻、应用说明、最佳实践、测试环境搭建、问题排查等众多技术干货,感兴趣的小伙伴速来围观~~


关注公众号「mPaaS」回复“SRE期刊”立即下载原文



-END-

动态-logo.gif

目录
打赏
0
0
0
0
80
分享
相关文章
场景题:线上接口响应慢,应该如何排查问题?
面试中常见的接口响应慢排查题旨在考察研发人员的系统性解决问题的能力。回答时需结合业务场景(如大促、高峰期),并运用工具(Arthas、SkyWalking等)进行监控告警、链路追踪和日志分析,明确问题范围及原因。具体步骤包括:1. 定位问题(确认单个接口或整体系统、查看APM指标、分析链路和日志);2. 排查网络、中间件及外部依赖(检测延迟、检查Redis、RocketMQ、MySQL等);3. 服务端性能分析(CPU、内存、磁盘IO、JVM调优)。最后提出优化方案,如代码逻辑、数据库、缓存策略及资源扩容等。总结时可结合实际案例,展示完整的排查与优化流程。
60 2
Android性能测试——发现和定位内存泄露和卡顿
本文详细介绍了Android应用性能测试中的内存泄漏与卡顿问题及其解决方案。首先,文章描述了使用MAT工具定位内存泄漏的具体步骤,并通过实例展示了如何分析Histogram图表和Dominator Tree。接着,针对卡顿问题,文章探讨了其产生原因,并提供了多种测试方法,包括GPU呈现模式分析、FPS Meter软件测试、绘制圆点计数法及Android Studio自带的GPU监控功能。最后,文章给出了排查卡顿问题的四个方向,帮助开发者优化应用性能。
398 4
Android性能测试——发现和定位内存泄露和卡顿
autox.js如何监听异常情况,比如网络中断、内存慢、应用死机或者页面无响应
autox.js如何监听异常情况,比如网络中断、内存慢、应用死机或者页面无响应
|
11月前
|
线上服务假死排查
线上服务假死排查
91 0
浏览器页面卡住定位分析
有童鞋在xxx系统页面反馈,遇到在弹出框后整个页面卡住无法使用的情况,属于必现问题。因此需要跟踪定位问题。
592 0
浏览器页面卡住定位分析
【线上问题排查】内存泄漏排查(模拟真实环境)
【线上问题排查】内存泄漏排查(模拟真实环境)
257 0
客户端浏览器的缓存问题排查
客户端浏览器的缓存问题排查
189 0
前端SameSiteCookie问题排查分享
近期排查客户上报的问题时,遇到了一个比较费解的问题,在这边梳理一下排查的流程、遇到的难点、找到的一些相关资料,来对整一个问题进行一个总结,也借此机会做一个分享SameSiteCookie相关的疑难问题处理
438 0
前端SameSiteCookie问题排查分享
一文带你了解如何排查内存泄漏导致的页面卡顿现象(上)
不知道在座的各位有没有被问到过这样一个问题:如果页面卡顿,你觉得可能是什么原因造成的?有什么办法锁定原因并解决吗?
901 0
一文带你了解如何排查内存泄漏导致的页面卡顿现象(上)
印象最深的一个bug——排查修复问题事件BEX引发的谷歌浏览器闪退崩溃异常
本文记录了目前修复的千千万万个项目的BUG中印象最深的一次BUG,由于问题事件BEX引发的谷歌浏览器闪退崩溃的异常问题.这个BUG因为其不可复现性导致特别难以发现和解决,正是由于这一次的BUG解决过程,让我了解到了一位攻城狮在项目开发维护过程中实际经验的重要性,多思考,多实践,多多积累经验,才是一位攻城狮的成长之路.
30821 2
印象最深的一个bug——排查修复问题事件BEX引发的谷歌浏览器闪退崩溃异常
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等