使用 AndroidX 增强 WebView 的能力

在应用开发过程中,为了在多个平台上保持一致的用户体验和提高开发效率,许多应用程序选择使用 H5 技术。在 Android 平台上,通常使用 WebView 组件来承载 H5 内容以供展示。

WebView 存在的问题

自 Android Lollipop 起,WebView 组件的升级已经独立于 Android 平台。然而,控制 WebView 的 API(android.webkit) 仍然与平台升级相关。这意味着应用开发者只能使用当前平台所定义的接口,而无法充分利用 WebView 的全部能力。例如: WebView.startSafeBrowsing API 在 Android 8.1 上被添加,该 Feature 由 WebView 提供,即使我们在 Android 7.0 更新 WebView 拥有了该 Feature ,由于 Android 7.0 没有 WebView.startSafeBrowsing API ,我们也没办法使用该功能。

WebView 的实现基于 Chromium 开源项目,而 Android 则基于 AOSP 项目,这两个项目有着不同的发布周期,WebView 往往一个月就可以推出下一个版本,而 Android 则需要一年的时间,对于 WebView 新增的 Feature 我们最迟需要一年才能使用。

AndroidX Webkit 的出现

为了解决上面平台能力和 WebView 不匹配的问题,我们可以独立于平台之外定义一套 WebView API ,并让它随着 WebView 的 Feature 更新 API ,这样解决了现有的问题却导入了另一个问题——如何将新定义的 WebView API 和 WebView 进行衔接。

从应用开发的角度,系统 WebView 难以修改,自己编译定制一个 WebView 并随着 apk 提供是一个很好方案。这时候,我们可以轻松的解决衔接问题,并能够按照需求,任意增改 Feature 而不必等官方更新。同时解决了兼容问题和 WebView 内核碎片化的问题。腾讯 X5 ,UC U4 等都是这个方案。维护一份 WebView 并不是一件容易的事,需要投入更多的人力支持,因为将 WebView 打入包中,还伴随着包体积的急剧增加。

从 Android 官方的角度,可以推动 WebView 上游支持该 WebView API , 而这正是 AndroidX Webkit 的解决方案。Android 官方将定义的 WebView API 放置到 AndroidX Webkit 库,以支持频繁的更新,并在 WebView 上游增加“胶水层”与 AndroidX Webkit 进行衔接,这样在旧版的 Android 平台上,只要安装了拥有"胶水"层代码的 WebView ,也就拥有了新版平台的功能。

“胶水层” 是在某个版本之后才后才支持的,旧版本的 WebView 内核并不支持,这也是为什么在调用之前始终应该检查 isFeatureSupported 的原因。

AndroidX Webkit 的功能

初步了解了 AndroidX Webkit 的产生和实现原理,下面带领大家看一下它都提供了哪些新能力能够增强我们的 WebView 。

向下兼容

如上文分析,AndroidX Webkit 提供了向下的兼容,如下面代码所示,由 WebViewCompat 提供兼容的接口调用。

需要注意的是在调用之前对 WebViewFeature 的检查,对于每个 Feature ,AndroidX Webkit 会取平台和 WebView 所提供 Feature 的并集 ,在调用某个 API 之前必须进行检查,如果平台和 WebView 均不支持该API则将抛出 UnsupportedOperationException 异常。

如果我们扒开 WebViewCompat 的外衣查看他的源码(如下所示),会发现如果在当前版本 Platform API 提供了接口,就会直接调用 Platform API 的接口,而对于低版本,则由 AndroidX Webkit 和 WebView 的"通道"提供服务。

对比上面的代码,使用平台 API(old code)时仅可以支持 90% 的用户,而使用 AndroidX Webkit(new code) 则可以覆盖大约 99% 的用户。

代理功能支持

一直以来WebView 的代理设置异常繁琐,当遇到复杂的代理规则就无能为力了。在 AndroidX Webkit 中增加了 ProxyController API 用于为 WebView 设置代理。ProxyConfig.Builder 类提供了设置代理以及配置代理的绕过方式等方法,通过组合可以满足复杂的代理场景。

以上代码定义了一个复杂的代理场景,我们为 WebView 设置了两个代理服务器,localhost:1080 仅当 localhost:7890 失败的情况下启用,addDirect 声明了如果两个服务器都失败则直连服务器,addBypassRule 规定了 www.bing.com 和以 .so 结尾的域名始终不应该使用代理。

白名单代理

如果仅有少量的 URL 需要配置代理,我们可以使用 setReverseBypassEnabled(true) 方法将addBypassRule 添加的 URL 转变为使用代理服务器,而其他的 URL 则直连服务。

安全的 WebView 和 Native 通信支持

建立 WebView 和 Native 的双向通信是使用 Hybrid 混合开发模式的基础,在之前 Android 已经提供了一些机制能够让完成基本的通信,但是已有的接口都存在一些安全和性能问题,在 AndroidX 中增加了一个功能强大的接口 addWebMessageListener 兼顾了安全和性能等问题。

代码示例中将 JavaSript 对象 replyObject 注入到匹配 allowedOriginRules的上下文中,这样只有在可信的网站中才能被使用此对象,也就防止了不明来源的网络攻击者对该对象的利用。

调用上述方法之后,在 JavaScript 上下文中我们就可以访问 myObject ,调用 postMessage 就可以回调 Native 端的 onPostMessage 方法并自动切换到主线程执行,当 Native 端需要发送消息给 WebView 时,可以通过 JavaScriptReplyProxy.postMessage 发送到 WebView ,并将消息传递给 onmessage 闭包。

文件传递

在以往的通讯机制中,如果我们想传递一个图片只能将其转换为 base64 等进行传输,如果曾经使用过 shouldOverrideUrlLoading 拦截 url 大概率会遇见传输瓶颈,AndroidX Webkit 中很贴心的提供了字节流传递机制。

Native 传递文件给 WebView

WebView 传递文件给 Native

深色主题的支持

Android 10 提供了深色主题的支持,但是在 WebView 中显示的网页却不会自动显示深色主题, 这就表现出严重的割裂感,开发者只能通过修改 css 来达到目的,但这往往费时费力还存在兼容性问题,Android 官方为了改善这一用户体验,为 WebView 提供了深色主题的适配。

一个网页如何表现是和prefers-color-scheme and color-scheme 这两个 Web 标准互操作的。 Android官方提供了一张表阐述了他们之间的关系。

上面这张图比较复杂,简单来说如果你想让 WebView 的内容和应用的主题相匹配,你应该始终定义深色主题并实现 prefers-color-scheme ,而对于未定义 prefers-color-scheme 的页面,系统按照不同的策略选择算法生成或者显示默认页面。

以 Android 12 或更低版本为目标平台的应用 API 设计过于复杂,以 Android 13 或更高版本为目标平台的应用精简了 API ,具体变更请参考官方文档

JavaScript and WebAssembly 执行引擎支持

我们有时候我们会在程序中运行 JavaScript 而不显示任何 Web 内容,比如小程序的逻辑层,使用 WebView 本能够满足我们的要求但是浪费了过多的资源,我们都知道在 WebView 中真正负责执行 JavaScript 的引擎是 V8 ,但是我们又无法直接使用,所以我们的安装包中出现了各种各样的引擎:HermesJSCV8等。

Android 发现了这”群雄割据“的局面,推出了AndroidX JavascriptEngine,JavascriptEngine 直接使用了 WebView 的 V8 实现,由于不用分配其他 WebView 资源所以资源分配更低,并可以开启多个独立运行的环境,还针对传递大量数据做了优化。

代码展示了执行 JavaScript 和 WebAssembly 代码的使用:

更多支持

AndroidX Webkit 是一个功能强大的库,由于篇幅原因上文将开发者比较常用的功能进行了列举,AndroidX 还提供对 WebView 更精细化的控制,对 Cookie 的便捷访问、对 Web 资源的便捷访问,对 WebView 性能的收集,还有对大屏幕的支持等等强大的 API,大家可以查看发布页面查看最新的功能。

参考链接


Flutter格式化排除代码段

前置条件
  • ubuntu 24.04.2 LTS
  • Visual Studio Code 1.98.2
  • Android Studio Meerkat | 2024.3.1
  • Flutter 3.29.1
问题描述

在使用 Flutter 编写代码的时候,如下代码进行格式化

可以发现格式化后的结果变成了如下的样子:

这部分代码我们不希望格式化,尤其是编写加解密算法的时候,里面的置换数组格式化之后会完全乱掉。

可以使用

阻止格式化工具对具体代码块格式化。

比如如下代码:

参考链接


在Visual Studio Code中调试Flutter Dart代码报错未验证断点(Unverified Breakpoint)

前置条件
  • ubuntu 24.04.2 LTS
  • Visual Studio Code 1.98.2
  • Flutter 3.29.1
问题描述

在使用 Visual Studio Code 调试 Flutter 代码的时候,如果在依赖库的代码中设置断点,会无法断点,并且提示断点未验证,"Unverified Breakpoint"。

如下图:

继续阅读在Visual Studio Code中调试Flutter Dart代码报错未验证断点(Unverified Breakpoint)

解决WordPress恶意搜索攻击(网址/?s=****)

最近网站被恶意搜索攻击,收到腾讯云的内容违规通知,内容如下:

这种恶意搜索攻击,其实非常简单,就是通过既定的网址结构不断对网站发起不良关键词搜索访问,比如 WordPress 的搜索网址结构为 域名/?s=搜索词,而且可能还会顺便将访问的地址推送到各大搜索引擎,加快这些恶意网址的收录。这样,你的网站就会沦为这些不法之徒传播不良信息的渠道,这对网站排名是非常不利的,甚至可能会直接被搜索引擎拉入黑名单。

解决方案如下:

1、禁止搜索引擎收录搜索结果页

搜索结果页一般我们都不推荐被收录,所以建议大家还是禁止收录。现在几乎所有搜索引擎都遵循 robots.txt 的规则,也就是我们可以通过 robots.txt 定义规则,阻止搜索引擎收录搜索结果页面。我们可以在网站根目录,创建一个 robots.txt 文件,填入下面的内容:

这样就禁止搜索引擎收录 WordPress 搜索结果页面。

2、在搜索结果为零时,跳转到首页

网上的做法都是直接禁用 WordPress 自带的搜索功能,只是其实这个自带的搜索功能还是蛮好用的,而且目前也没有对服务器造成很大的压力。我这边的想法是保留搜索功能,只是当搜索结果不存在的时候,自动跳转到首页。

目前测试到可行的办法是直接在主题的 functions.php 中增加如下代码:

曾经试过在主题的 content-none.php 中通过 wp_redirect 进行跳转,虽然可见内容不存在了,但是页面源代码中会出现搜索词标签,因此不可行。

测试代码:

也曾经测试过自定义 searchform.php ,也是存在上述问题。

自定义 404.php 是无效的。搜索关键词过滤又实在是太多了,还不如搜索不到结果就返回首页更简单。

参考链接


解决 fetch-pack: unexpected disconnect while reading sideband packet fatal: early EOF fatal: fetch-pack

在克隆仓库或者拉取代码的时候出现类似如下错误:

解决方法:

主要是由于 仓库 内容比较大,或者仓库中有比较大的文件,由于 http 协议 或者 传输数据大小限制导致的,可以通过设置如下参数解决:

参考链接


解决fetch-pack: unexpected disconnect while reading sideband packet fatal: early EOF fatal: fetch-pack

ubuntu 24.04编译webkitgtk

前置条件
  • ubuntu 24.04.2 LTS
解决方案

参考链接

Flutter多平台打包发布

flutter_distributor是一个强大的工具,支持跨平台发布和高级打包选项。

安装

确保 flutter_distributor 已安装:

配置文件

为高级打包配置所需的文件:

  • macOS:

    • 如果打包 DMG 安装包:macos/packaging/dmg/make_config.yaml

    • 如果打包 PKG 安装包:macos/packaging/pkg/make_config.yaml

    • distribute_options.yaml

  • Windows:

    • 如果打包 exe 安装包:windows/packaging/exe/inno_setup.sas

      windows/packaging/exe/make_config.yaml

    • 如果打包 msix windows/packaging/msix/make_config.yaml

  • Linux:

    • linux/packaging/appimage

      有两个文件 linux/packaging/appimage/AppRun

      linux/packaging/appimage/make_config.yaml

    • linux/packaging/deb 文件 linux/packaging/deb/make_config.yaml

    • linux/packaging/rpm 文件 linux/packaging/rpm/make_config.yaml

命令示例

  1. 打包 macOS (DMG 和 PKG)

  2. 打包 Windows (EXE 和 MSIX)

  3. 打包 Linux (DEB、RPM 和 AppImage)

参考链接


Flutter 3.29.1-使用U盾完成数据的加解密(国密算法SKF接口)

参考 Python3-使用U盾完成数据的加解密(国密算法SKF接口),那么相同的功能如何使用 Flutter FFI 实现呢?

  • Flutter 3.29.1
  • ffi 2.1.4
  • pointycastle 3.6.0
  • pkcs7 1.0.5
  • convert 3.1.2

代码参考如下:

 

使用方式:

参考链接


Gtk应用内嵌网页与原生代码交互方法

前置条件

  • Ubuntu 24.04.2 LTS

内容详情

在使用Gtk开发应用程序的过程中,如果需要内嵌网页,那么使用libwebkit2gtk是个非常自然和正确的选择。

那么这里就可能原生程序代码可能需要跟网页交互的问题。

Gtk程序跟网页的交互,主要有两个方面:

需求1,使用 webkit2gtk 的内置 webkit_web_view_run_javascript 函数即可解决

需求2,使用 webkit2gtk 的内置的 web extendsion 扩展支持功能解决 或 window.webkit.messageHandlers..postMessage(value)

不多说看代码吧!

Gtk嵌入网页Demo程序

webviewgtk.c

Web Extension Demo

内嵌的网页示例 webview.html

示例运行

安装依赖:

把webviewgtk.c,web_exten.c,webview.html 放在同一目录下。

编译程序:

运行程序:

参考链接


应用内嵌WebKitGTK报错“Unacceptable TLS certificate”

ubuntu 24.04 系统开发内嵌 webkit2gtk-4.1 的应用,打开部分 HTTPS 网页报错“Unacceptable TLS certificate”, 如下图:

但是相同的页面使用 FireFox/Safari/Chrome/IE/Edge 等主流浏览器打开都是正常显示的。

调试代码,发现是 WebKitWebViewon_load_failed_with_tls_errors 回调函数返回了错误 G_TLS_CERTIFICATE_GENERIC_ERROR64),如下图:

于是安装 Gnome 官方的浏览器 Epiphany 进行测试,该浏览器底层也是调用 WebKit2GTK,在 ubuntu 24.04 系统,可以执行如下命令进行安装:

打开相同的页面,同样报错,显示服务器不可信。

由于 WebKit2GTK 底层的 TLS 通信调用库调用的是 GnuTLS 。于是尝试通过命令行对 TLS 证书认证过程进行验证,执行如下命令:

可以看到,网站的根证书无法通过 GnuTLS 的验证,原因在于网站的证书链中的根证书使用的 RSA-SHA1 签名,该类型签名存在 “弱哈希算法签名的SSL证书(CVE-2004-2761)漏洞” 进而被 GnuTLS 拒绝。

针对此问题的更详细的描述参考 GnuTLS 文档 8.2 Disabling algorithms and protocols

针对此问题的解决方法:

  • 联系网站,更新证书,重新以 RSA-SHA256 签发证书。由于是公司内部网址,因此联系网络更新即可;

  • 应用内嵌网站证书,通过 webkit_web_context_allow_tls_certificate_for_host 要求 webkit 通过提供的证书进行网站验证。此种情况适用于 APP 内嵌自己网站页面的情况,同样适用于自签名证书的情况;

  • 如果纯粹测试,可以在加载页面之前调用

    要求 webkit 无视证书错误。此方法生产环境不可取,非常不安全,仅可用于内部测试

  • 此方案目前测试已经不可用调用 gnutls_sign_set_secure_for_certs API 许可部分不安全的证书签名算法

    相对来说,联系不上网站的情况下,又需要在保证安全的前提下,尽量兼容网站,推荐此种方式;

  • 自行接管证书验证过程,实现比较复杂,极其容易产生安全漏洞,不建议;

参考链接