光明新区建设网站,做英语陪同翻译兼职的网站,php网站接入支付宝,什么是网络营销道德「能正常跑的代码就尽量不要动」#xff0c;这句话再一次证明了它的立场#xff0c;实际上确实不少程序员都存在「代码洁癖」#xff0c;喜欢对代码进行「清洗」和「重构」#xff0c;但是优雅的背后#xff0c;很多时候也伴随着看不见的坑在等着你。 你以为上一代的人为什…「能正常跑的代码就尽量不要动」这句话再一次证明了它的立场实际上确实不少程序员都存在「代码洁癖」喜欢对代码进行「清洗」和「重构」但是优雅的背后很多时候也伴随着看不见的坑在等着你。你以为上一代的人为什么就偏要写的「那么蠢」回到正题近日不少人在#180842中反馈当 Flutter 升级后点击带有 AutoFill 的输入框时键盘会像“抽风”一样先弹起、收缩、再弹起这个咋一看好像也没什么问题但是如果在 Flutter 3.38.7 的版本里它的表现是这样的这么一对比就可以很直观看出来这是一个负优化特别是对于刚升级的用户来说这就显示很莫名其妙而从目前的情况来看问题的来源是以下这个 PR 它是一个用来修复 autofill 上下文清理的提交在这个 commit 里他对FlutterTextInputPlugin.mm进行重构主要是简化输入视图的生命周期管理但是在这个过程里它修改了removeFromSuperview的调用时机看起来合理是在清理无用 view但问题在于调用顺序在多输入框切换A → B时Flutter 平台侧的调用顺序通常是TextInput.clearClient(A)TextInput.setClient(B)也就是说旧字段先被 clear紧接着新字段被 set但是如果在clear 阶段就把承载输入的_activeView从 view hierarchy 里 remove 那么iOS 会认为“输入上下文结束”系统可能触发键盘 dismiss 和高度重算下一帧新字段becomeFirstResponder键盘又被拉起对比 3.38 里当时采用的是“懒清理”策略即使输入客户端关闭底层的原生视图activeView依然挂载在视图树上。而 3.41 一旦clearTextInputClient被调用就会立即执行removeFromSuperview因为在 iOS 上当系统检测到输入框支持自动填充AutoFill时它会发送两次键盘显示通知第一次是普通高度第二次是加上“自动填充工具栏”后的高度而在 iOS 准备计算第二次高度、弹出工具栏的微秒时间内Flutter 执行了“清理逻辑”强行把焦点所在的activeView删除了iOS 发现“焦点视图没了”于是键盘收回紧接着Flutter 的下一个逻辑又激活了新视图键盘再次弹出而这个情况在 iOS 18 之后的的输入栈 AutoFill / Password suggestion UI 更敏感登录/密码场景下系统会在键盘上方插入 suggestion 条键盘 frame / safe area 会更频繁变化中间态更容易被放大成视觉抖动实际上述的修改如果不是现在「马后炮」来看正在体验里和逻辑上看都不会觉得有什么问题。而这就是导致键盘在屏幕内高低闪动的原因而实际上类似问题在 RN 上也出现过因为无论是 Flutter 还是 RN它们都不是“原生实时渲染”而是通过一个中间层与 iOS 通讯所以 RN 也有过类似键盘高度计算等问题 不过 RN 上主要是 AutoFill UI layout 竞态导致的问题。而针对这个问题造成问题的原作者也对此提交了新的修复 PR #182661 在FlutterTextInputPlugin.mm引入了全新状态不再直接removeFromSuperview而是标记一个_pendingInputViewRemoval YESPR 的目的是将真正的移除动作放到hideTextInput阶段也就是确保resignFirstResponder已经完成从而对齐原本的系统节奏。可以看到这原本也不是什么大改动出发点也是好的但是这种细节的边界情况往往也是造成大问题的稻草这种 Bug 对于用户来说虽然不影响实际使用但是在体验上确实是致命缺陷。所以很多时候你可能觉得为什么一些简单的修改Flutter 整这么久都没合并或者提交其实这就是一个典型例子谁能保证 feature 有被完整回归说人话就是我究竟要不要为这个东西的未来去背锅所以每个历史屎山代码大多都有它存在的原因单纯因为屎而屎的也有但是更多时候大家还是更倾向于屎上雕花除非这一坨当初就是自己拉的你还知道它臭在哪里。目前 https://github.com/flutter/flutter/pull/182661 已经合并到 master 。