在真正的浏览器里,登录框一出现,密码管理器就会弹出已保存的凭据。但在 WebView 里,那个框始终是空的。在 iOS 上,WKWebView 不会为网页内容提供用户在 Safari / iCloud 钥匙串中保存的密码;在 Android 上,WebView 的自动填充默认关闭,并被 autofill 提示、Activity 上下文与系统自动填充服务层层卡住。宿主自有 runtime 桥接原生凭据提供方——一个到处都能填充的登录框。

iOS:网页内容拿不到钥匙串密码

苹果的 Password AutoFill 文档解释了系统如何借助 textContentType 提供已存凭据——但这适用于 App 自身的原生 UITextField。对于 WKWebView 内部渲染的网页内容,系统并不会像 Safari 那样提供用户在 Safari 中保存的密码。Safari 里针对已存登录弹出的 QuickType 栏,在任意嵌入式 WebView 中并不可靠地出现;用户期望的页面级凭据建议根本不显示。作为 Safari 扩展或凭据提供方扩展运行的第三方密码管理器,也同样不在嵌入式页面之中。结果就是:那个在 Safari 里已保存密码的用户,在你的 App 里只能手动重输。

Android:自动填充默认关闭

Android 的 Autofill 框架从 Chrome 61 起就支持 WebView,但它是条件式且脆弱的。WebView 必须用 Activity 上下文创建,字段必须携带 autofillHints(或正确设置 importantForAutofill),而且设备的系统 Autofill 服务必须已启用、且未被 App 或 ROM 覆盖。大量 WebView 直接禁用了自动填充,而第三方密码管理器在 WebView 内容内的自动填充充其量也是时灵时不灵。同一个在 Chrome 里完美自动填充的登录,在嵌入式浏览器里可能空空如也——而且与 Chrome 不同,页面无法提示用户保存或填充。

自动填充失效时会怎样

  • 每次登录都要手动重输。 用户在浏览器里保存的密码,在 WebView 中两个平台都够不到。
  • 随之而来的是更弱、重复的密码。 当填充很麻烦时,用户会退而使用好记或重复使用的密码——这正是一个金融 App 最不想要的。
  • 一次性验证码也更难。 Safari 原生提供的域名绑定短信 / TOTP 自动填充,在嵌入式页面中并不可靠地出现。
  • 客服量与流失上升。 在浏览器里"开箱即用"的登录,在 App 里变成了摩擦点,客服工单随之增加。

runtime 解法

宿主自有 runtime 桥接原生凭据提供方。页面用标准的 autocomplete 提示标记字段,宿主通过平台凭据提供方解析它——iOS 的 ASPasswordCredentialIdentity / 关联域名 QuickType,Android 的 Autofill 框架与凭据提供方扩展。已存登录、生成的密码与一次性验证码都以原生且一致的方式提供。一次集成,每个引擎,一个被填充的框。

维度WebView宿主自有 runtime
iOS 已存密码网页内容不提供原生凭据提供方
Android 自动填充默认关闭、受卡原生 Autofill + 提供方
第三方管理器页面内缺席桥接到宿主
一次性验证码不可靠原生域名绑定填充
一致性因引擎而异统一

原生 App 能在每台设备上提供已存登录;裸 WebView 几乎在每台设备上都不提供。runtime 给页面一个登录框——以及最终用户自己已存的凭据。

参考来源