App WebView白屏检测及解决总结,包括Android 和 iOS

App上WebView白屏

  • 在移动端上场景的H5页面白屏问题,根据平台分为Android和ios端上H5白屏问题(相关解决和优化基于移动端侧)之前在自己博客发布过,最近有做朋友问就再发出来下,希望能帮助更多人,重要的是了解白屏问题的原理和解决思路。

  • Android的的白屏问题表现现对比较多些,按问题类型大致可以概括为:

机型兼容造成
JS语法兼容造成
网络加载获取数据造成
软件系统版本兼容造成
内存或者渲染进程造成
android上疑难杂症
  •  IOS的问题造成白屏的原因现对较少,因为WKWebView来说通过系统组件来保障,相对Android系统webview碎片化要好的多:

网络加载获取数据造成
系统软件版本造成
JS语言兼容造成
内存不足造成

Android端白屏问题(APP侧解决方案)

  •  常见的语法造成白屏相关

使用了es6的语法对低版本未做兼容引入了三方外部插件,外部插件语法存在兼容性问题
语法错误造成页面无法渲染
  • • webview加载H5界面时,H5中的一些控件标签可能使用后android中不支持设置如下方式

// 解决对某些标签的不支持出现白屏
webSettings.setDomStorageEnabled(true);
  •  一些机型硬件加速相关问题

webView.setBackgroundColor(ContextCompat.getColor(this,android.R.color.transparent));
webView.setBackgroundResource(R.color.black);//根据需求修改
  • 网络资源获取造成的白屏

 这种情况与获取的资源有关系,可以通过loading状态和箭听webviewClient方法进行处理
 (这次主要调研基于业务的本地化内存造成的白屏)

内存相关造成白屏

  • 内存导致的白屏或者其他异常问题,有时白屏显示,有时界面渲染失败等奇怪现象,但是内存白屏是最不好处理,又需要给用户友好体验的问题。

  •  webview自身内存问题:本身webview自身比较重,切存在activity或fragment里就牵涉到声明周期和创建的问题,和声明周期里回收问题,一般解决方法在声明周期销毁时先destory在设置null 。先加载null内容的过程需要实际代码验证。

  if (mWebView != null) {
        mWebView.loadDataWithBaseURL(null, "", "text/html", "utf-8", null); 
        mWebView.clearHistory(); 
        mLayout.removeView(mWebView); 
         mWebView.destroy(); 
         mWebView = null; 
    } 
  •  独立进程的方式,一般不采用涉及跨进程数据通信,加大维护难度

  • 加载内容内存问题造成的白屏:可以从以下几个思路进行解决

 监控webview的渲染进程状态
 监测H5页面白屏页面
 监测webview里的内存
 
1. 监控WebView渲染进程(适合项目应用)
  • webView的内存从4.4变为基于Google的Chromium的实现

  •  Chromium的架构可以看到(Android 8.0默认打开多进程),Render Process 是单独的进程通过IPC来交互数据,GPU Process仍然为Browser Process的一个线程

We use separate processes for browser tabs to protect the overall application from bugs and glitches in the rendering engine. We also restrict access from each rendering engine process to others and to the rest of the system. In some ways, this brings to web browsing the benefits that memory protection and access control brought to operating systems.
We refer to the main process that runs the UI and manages tab and plugin processes as the "browser process" or "browser." Likewise, the tab-specific processes are called "render processes" or "renderers." The renderers use the Blink open-source layout engine for interpreting and laying out HTML.
  • 官网架构里解释了相关多进程的目的,browser是单独的进程,确保渲染在出现故障的时候可以不影响browser的进程显示。

  • 我们相关的白屏的出现除了之前的因素和语法问题之前,就是渲染进程出现了问题。因为我们白屏主要出现在渲染进程,那就可以通过渲染进程查找出问题时相关的状态信息,问题就转化为我们如何知道Render Process的相关状态和监控

  •  关于Render进程可以在文档里查到关于webview的Termination Handling ,通过该方法检测到渲染进程, 通过实现client里的onRenderProcessGone方法。

  •  原理和实现:

当检测到渲染进程被页面大内存消耗导致被杀或者异常终止时,
移除当前webview实例并消耗,否则新渲染进程会失效
通过新的实例加载出新的执行逻辑,可以reload页面或者其他业务逻辑, (而browser进程不死用户无感知)
防止当前reload页面如有大内存死循环,可能直接会被系统kill
(要考虑到系统版本限制问题,并适用于X5WebView)
  • • 代码demo可以联系我,目前暂时未放gitlab上

2. 监控WebView页面白屏(适合数据采集)
  • • 内存问题是造成白屏的重要一部分,还有就是其他莫名奇妙问题造成的页面白屏(这种白屏可能不是内存,js语法、网络加载等造成白屏)

  • • 如果能够在APP端检测到白屏页面出现,采取相应的提示或者reload ,也是很好解决疑难杂症的白屏方案

  • • 技术点实现:

对WebView在调用完成后进行截图
遍历截图的像素点的颜色值
设定白色像素点比例确认是否白屏
3. 监测webview里的内存
  • • 目前关于如何监测webView里的内存占用情况,在原生端上还没有更好的思路去处理,需要进一步调研

  • • 在项目里的实现,可以优先使用前2中方案。

Ios端WKWebView白屏

  • • 相对Android上的白屏,ios白屏的出现在app端上大部分为内存占用产生,其他网络、资源、js语言兼容、中文字样ulr等同样也会发生白屏,这类问题需要针对分析。关于内存原因造成的白屏问题可以从下边思路着手解决。

  • • 内存白屏产生的原因:WKWebView 是运行在一个独立进程中的组件,当 WKWebView 上占用内存过大时,WKWebView 所在的 WebContent Process 会被系统 kill 掉,反映在用户体验上就是发生了白屏。

1. ios系统方案 (原理同Android上的RendProcess)

  • WKNavigationDelegate的回调方法webViewWebContentProcessDidTerminate 里直接进行reload

  • 检测 webView.title 是否为空

 尝试在每次请求kWebview前清理缓存
 webview reload

2.白屏像素检测(非内存引起的,适合数据采集或必要reload)

  • 原理:类似于android的白屏检测,通过截图检测像素点,来判断是否白屏

通过获取截图
截图进行缩放
像素点进行遍历色值判断比例
  • 检测时机 : 在loadurl之后 接收到didcommit 或 didfinish回调中进行判断, 另外需在业务项目里核算性能开销

3.疑难问题白屏

  • 渲染异常: 这种白屏问题可以通过检查层级定位相关问题 https://github.com/Flipboard/FLEX,使用flex查看白屏层级,查看异常时view层级( APP测)

  •  资源遇错: H5里进行监测的方式,当出现加载H5资源错误的时候,wkwebview的渲染异常,就根据加载出错重新reload (H5内部监控)

Reload处理白屏

  •  在APP端上除去相关页面元素,加载错误、兼容性,语法错误造成白屏,以上相关方案可以启到检测并尝试重试刷新页面,达到用户无感知,避免白屏的出现和出现白屏瞬间进行切换或者刷新。

  •  reload可以做到解决一部分问题,但同时需要关注reload带来的异常问题和解决内存泄露的根本问题

页面上大内存出现后,短时间内存回收不及时,造成reload后问题依然存在。
reload前需要释放必要的内存资源,否则可能持续内存占用reload不能解决问题。
设置reload的最大重试次数,防止页面意外进入死循环
调试解决耗内存的原因,从根源上进行优化处理

PS: 也欢迎大家评论和交流~ 更多文章也可关注微信公号:良技漫谈

python+opencv简谱识别音频生成系统源码含GUI界面+详细运行教程+数据 一、项目简介 提取简谱中的音乐信息,依据识别到的信息生成midi文件。 Extract music information from musical scores and generate a midi file according to it. 二、项目运行环境 python=3.11.1 第三方库依赖 opencv-python=4.7.0.68 numpy=1.24.1 可以使用命令 pip install -r requirements.txt 来安装所需的第三方库。 三、项目运行步骤 3.1 命令行运行 运行main.py。 输入简谱路径:支持图片或文件夹,相对路径或绝对路径都可以。 输入简谱主音:它通常在第一页的左上角“1=”之后。 输入简谱速度:即每分钟拍数,同在左上角。 选择是否输出程序中间提示信息:请输入Y或N(不区分大小写,下同)。 选择匹配精度:请输入L或M或H,对应低/中/高精度,一般而言输入L即可。 选择使用的线程数:一般与CPU核数相同即可。虽然python的线程不是真正的多线程,但仍能起到加速作用。 估算字符上下间距:这与简谱中符号的密集程度有关,一般来说纵向符号越稀疏,这个值需要设置得越大,范围通常在1.0-2.5。 二值化算法:使用全局阈值则跳过该选项即可,或者也可输入OTSU、采用大津二值化算法。 设置全局阈值:如果上面选择全局阈值则需要手动设置全局阈值,对于.\test.txt中所提样例,使用全局阈值并在后面设置为160即可。 手动调整中间结果:若输入Y/y,则在识别简谱后会暂停代码,并生成一份txt文件,在其中展示识别结果,此时用户可以通过修改这份txt文件来更正识别结果。 如果选择文件夹的话,还可以选择所选文件夹中不需要识别的文件以排除干扰
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值