yuyu的官网

v1.2 更新摘要#

v1.2 的首页去掉了那块占据大面积屏幕的插画卡片，“关于”页也不再重复加载横幅图；浏览页面顶部只保留一枚从原品牌图缩小压缩而来的标识。品牌仍是用户指定的那张图，但它不再以 16:9 大图形式占据浏览器新标签页或 APP 官网首屏。网站首页的视觉布局随之改为单列介绍、下载入口和简洁的信息区。

这一版还针对标签回调做了重绘优化：后台 WebView 仍可更新自己的 URL、进度和导航状态，但不再因为这些变化频繁要求整个浏览器界面重建。默认搜索引擎切换立即保存；桌面版用户代理即时设置并刷新当前页；JavaScript 开关会应用到内存中保留的 WebView 并刷新这些页面。新增的“复制当前网页链接”让分享之外多一个更直接的出口。APP 官网独立部署在 https://yubrowser.iyu6.com/；原 https://iyu6.com/ 主站和其隐私声明保持独立，应用更新清单改为子站根目录的 update.json。

这些改动是有明确代码路径的性能和交互改进，并没有建立同一组真机、同一批网页、同样网络条件下的对照基准，因此本文不把“提升 50%”写成已测量的事实。性能比例需要在目标设备上测量切换耗时、帧时间和内存峰值后才能报告。

一、为什么还要做一个浏览器#

手机浏览器市场早已成熟。用户并不缺少能够打开网页的应用，真正缺少的往往是符合自己使用习惯、打开后足够直接的工具。一个新浏览器如果只是把地址栏换个颜色、把几个按钮挪个位置，并不能自然地产生价值。雨浏览器从一个更务实的问题出发：在不自建完整浏览器内核的前提下，能否提供一套轻盈、清楚、容易理解的日常浏览界面？

这个问题把项目的范围划得比较明确。网页渲染交给 Android 设备系统中的 WebView；应用本身负责地址输入、标签状态、书签、历史、下载记录、浏览设置与交互反馈。这样做有明显好处：APK 不需要把一整套浏览器引擎都塞进去，网页能力也能随着设备 WebView 组件更新。但它同样意味着应用无法完全控制底层内核版本、网站兼容性和所有渲染细节。轻量不是“没有代价”，而是对职责做取舍。

另一个出发点是界面节制。浏览器不一定需要在每个页面上同时展示十几种推荐、账号入口和服务卡片。雨浏览器把常用操作集中在浏览页面周边，把收藏、历史和设置放在容易找到的位置；用户不需要时，它们也不会持续占据页面中心。设计的目标并不是让功能越少越好，而是让必要功能有清楚的位置，让不必要的噪声少一点。

二、产品定位：轻，不等于阉割#

“轻量浏览器”容易被理解为功能很少，或者网页能力被刻意削弱。雨浏览器采用的定义更接近“把复杂性留在合适的地方”：地址栏既可访问网址也可处理关键词；浏览页面可以前进、后退、刷新或停止加载；标签页提供普通浏览与隐私浏览；常用网页能够加入书签；本地浏览历史可以查询和清理；网页可以调用桌面版用户代理、关闭 JavaScript、分享链接或下载文件。

这些功能并不意味着浏览器已经具备大型产品的所有能力。雨浏览器目前没有云端账号、跨设备同步、密码管理器、广告过滤规则中心或扩展生态，也没有尝试替代 Android 系统的下载管理器和安全安装流程。它把力量集中在基础浏览链路上：用户输入，页面打开；用户切换，标签状态得到保留；用户需要控制时，可以从设置调整行为。

当前应用的最大标签数为 8。这个数字是产品策略而不是 WebView 的技术极限，它在手机屏幕面积、系统内存和多任务需求之间做了一个保守选择。页面不是标签越多越好：更多 WebView 意味着更多网页脚本、图片解码、缓存和原生视图资源同时存在。雨浏览器允许用户打开多个页面，但没有把所有标签都永远留在内存里，而是让近期切换体验与整体资源占用保持平衡。

三、技术结构：Flutter 负责应用，WebView 负责网页#

雨浏览器 v1.2 是一个 Flutter Android 项目。Flutter 负责绘制应用外壳、地址栏、底部工具栏、设置面板、标签列表和各类本地信息；flutter_inappwebview 将 Android WebView 能力接入应用。网页本身并不是用 Flutter 控件重新排版，也不是被截图后显示，而是由系统 WebView 真正加载和渲染。

这种分工把浏览器分成几个层次。第一层是应用界面：用户输入网址、打开新标签、切换搜索引擎、查看书签和设置。第二层是标签模型：应用记下每个标签的 ID、URL、标题、是否加载、前进/后退能力以及普通或隐私属性。第三层是 WebView 控制器：它执行网页导航、刷新、停止、读取标题并接收加载事件。第四层则是 Android 提供的网页运行环境，负责 HTML、CSS、JavaScript、Cookie、网页缓存及媒体行为。

当某一层的职责清楚，性能问题也较容易定位。比如标签按钮确实触发了状态切换，但若代码把当前 WebView 删除，再用 URL 创建一个新的 WebView，网页就必须重新建立连接、请求资源、执行脚本和恢复页面。看起来像是“点击没有反应”，实际上是点击完成之后要等待较长的加载过程。v1.1 的优化便不是重新设计按钮，而是修正标签视图的生命周期。

Flutter 让应用界面、状态和平台插件可以在一套项目中共同维护，但这并不会消除原生平台差异。下载、Cookie、系统分享、文件存储和 Android 生命周期仍由平台 API 参与。项目因此保留了明确的边界：Android 系统处理最终安装确认；设备 WebView 决定网页内核行为；应用只对自己管理的界面、记录和下载流程负责。

四、从地址栏到网页：一条完整的浏览路径#

地址输入是浏览器的主要入口。用户提交的内容如果是可识别的网址，应用就把它交给活动标签加载；如果看起来是普通关键词，则使用当前搜索引擎构造搜索请求。默认搜索服务为百度，用户可以在浏览设置里切换到必应。搜索引擎属于外部服务：改变默认选项会改变请求发往的服务方，但不会让雨浏览器成为搜索结果的提供者。

网页进入加载阶段后，WebView 会通过事件回报开始加载、进度变化、页面标题、访问历史变化和加载结束等状态。地址栏随着当前标签的 URL 更新，页面标题则用于标签列表与历史记录。加载状态可以显示在地址栏附近，刷新按钮在合适时机也能执行停止加载。页面成功完成后，应用读取标题和前进/后退能力，再把普通标签的访问整理进历史记录。

导航按钮所对应的动作也尽量保持明确。前进与后退调用 WebView 的会话导航；主页入口返回应用的新标签起始界面；刷新重新请求当前页面；停止则中止正在进行的加载。每个网站的实现不同，某些单页应用会自己处理返回动作，也有网站会屏蔽页面或弹窗。因此，浏览器按钮能不能执行某项网页历史操作，仍然取决于 WebView 当前提供的状态和网站行为。

为了限制不安全的本地文件访问，当前 WebView 关闭了网页对任意文件和内容 URI 的访问能力；普通网页导航主要允许 HTTP 或 HTTPS。遇到 mailto: 与 tel: 等链接时，应用尝试交给外部系统处理，而不是把它们当网页加载。这里的安全策略并不意味着所有网页都安全，它只是把浏览器自己需要开放的通道收窄一些。

五、多标签：先保证可理解，再考虑更快#

多标签是移动端浏览器最直接的效率工具之一。用户可以先打开搜索结果，再保留另一篇文章；或把临时查阅的网页留在旁边，稍后切回。雨浏览器最多允许 8 个标签，并支持新建、切换、关闭普通标签和隐私标签。标签面板让当前页面有一个可见的“集合”，用户不必依赖系统返回键在一串网页历史中来回寻找。

标签不仅是几个标题，它实际上维护着多个互相独立的浏览上下文：URL、网页标题、前进/后退状态、加载状态、私密标记、桌面版模式，以及与当前网页绑定的 WebView 控制器。切换标签时，应用需要决定这些上下文是继续存在、暂时休眠，还是完全销毁。若全部都销毁，页面切换就会变成重新打开；若全部永久保留，又可能让八个复杂网页在后台持续消耗内存和 CPU。

v1.1 选择了一个简单、明确的策略：保留最近使用的两个有内容标签。应用按最近使用顺序维护一个小型 LRU 列表；当一个标签离开当前页时，它可以仍留在最近缓存中。活动标签与缓存中的标签通过 IndexedStack 保留界面实例，避免近期页面因为父级状态切换而被卸载。切换时仍有短暂淡入动画，但不需要因为视图被重新创建而从零加载整个网页。

当最近列表超过两个网页时，最旧的非活动标签会退出保留集合，控制器被清空，加载进度与前进/后退状态复位。此时标签本身并不被用户关闭：它仍在标签列表中、URL 仍可显示，只是对应的 WebView 资源不再常驻。用户再次点回它时，应用重新构建网页视图，网页可能从原 URL 加载。这是一个有意的内存权衡，而不是一次意外丢失标签。

这个策略也解释了一个重要体验边界：连续在最近两个网页间切换通常更快，因为它们的 WebView 状态仍在；从较早的第三个或更早标签跳回，速度就可能取决于网络和网站缓存。标签多、网页很重或系统内存紧张时，WebView 还可能受到 Android 自身回收影响。应用能做的是避免每次切换都主动重建，并控制自己保留的数量，不能向系统保证每个页面永远驻留。

六、从 v1.1 到 v1.2：性能优化从等待感出发，而非只改动画#

v1.1 的性能改造起因是非常具体的操作反馈：点击标签后，界面长时间没有呈现出预期页面，容易让人怀疑按钮逻辑错误。第一步不是增加更明显的点击动效，而是沿着一次切换的代码路径检查视图和控制器是否还存在。问题找到之后，重点转向两个部分：保留近期 WebView 实例，以及限制 UI 因高频加载事件而反复重绘。

WebView 加载进度回调可能非常频繁。若每个进度值都触发一次整个 Flutter 页面 setState，不仅进度条本身变化，包含工具栏、标签状态和其他组件的祖先也可能反复参与布局或绘制。v1.1 把进度转换为五个百分点一个刻度：进度从 0 到 100 的过程中，大约每提升 5% 才更新一次应用界面。100% 完成时仍会走完成状态，用户看得见加载过程，但不需要为了每一个百分之一的变化都重建界面。

浏览记录也与加载事件相关。页面加载期间，URL、标题和进度会多次更新；这些临时状态不都需要立即序列化到本地。当前流程以页面完成事件为关键点读取标题与导航状态，再将普通标签的访问写入历史和持久化状态。隐私标签不会被加入普通浏览历史。这减少了一些没有必要的重复写盘工作，同时让记录发生的时机更清楚。

图像解码和特效是另一个容易被忽略的资源点。项目沿用用户指定的官网插画作为品牌来源，但应用首页不需要常驻一张 1920×1080 横幅。v1.1 曾将图像缓存尺寸限制在显示尺寸附近；v1.2 更进一步，移除首页与“关于”页的大幅图片控件，并让 Flutter 运行时仅打包约 4 KB 的小尺寸品牌缩略图。若按 RGBA 解码估算，原首页横幅缓存 1200×675 像素约占 3.09 MiB，“关于”页 800×450 约占 1.37 MiB；这些是理论像素缓冲占用，不等于真机总内存变化，实际解码与复用由引擎和系统决定。界面仍用柔和渐变、半透明色面和细描边形成玻璃层次，避免为装饰堆叠大面积实时模糊。

页面间的切换动画仍然存在，标签内容采用短时淡入；关键改动不是动画时长变短，而是动画背后要展示的网页尽量已经准备好。一个 140 毫秒的淡入无法掩盖几秒钟的网络等待，反过来，即便没有动画，只要每次都强制重载网页，用户仍会感觉迟钝。因此 v1.1 把生命周期、渲染频率、图像解码与视觉效果一起考虑，而不是用更花哨的动效掩盖问题。

性能体验与实际设备、网页脚本、网络质量和 Android WebView 版本有关。本次验证确认代码通过 Flutter 静态分析与首页 Widget 测试，并成功构建了分架构 Release 包；当前没有公开在一组手机上测量帧率、内存峰值或切换耗时的基准数据。真实设备测试仍然重要。若某台设备只在特定网站或低内存环境中卡顿，下一轮应针对那一类页面采样，而不是把所有问题都归因于按钮。

七、白色液态玻璃：视觉层次要为浏览内容让路#

雨浏览器的视觉方向是纯白、轻柔、半透明的液态玻璃。它不是为了把每一块卡片都变成厚重的模糊面板，而是用低饱和的蓝色、少量青色渐变和轻微透明度来建立层次。地址栏、卡片与浮层需要与网页内容区分开，同时不能让工具本身比网页更抢眼。白色空间提供安静的底色，玻璃边缘和浅阴影则帮助用户识别哪些部分可以交互。

设计上还有一个特意保留的原则：品牌以用户提供的原图为准，不用新造的水滴图标替代。Android 启动器资源仍由用户提供的 https://iyu6.com/images/albums/AcgExample/19.webp 适配生成；运行中的 Flutter UI 和 APP 官网只引用缩小压缩后的品牌标识。v1.2 移除了浏览器首页插画大卡片以及产品官网 Hero 大图，不裁切并放大整张横图来占据首页屏幕。文章封面仍按作者给定的 URL 展示，它与应用内运行时图片资源是两件不同的事。

动画只在能帮助理解操作的地方出现。主页到网页内容切换、标签之间的视觉衔接，可以有轻微淡入；按钮有短促的状态反馈；滚动和菜单动效不能拖慢主要任务。用户系统设置了减少动态效果偏好时，视觉动效也应降低。好的转场不是要求用户等待它结束，而是在不遮挡操作的前提下，让状态变化更容易被看见。

纯 CSS 或 Flutter 中的玻璃效果都需要克制使用。大面积模糊可能产生额外 GPU 合成压力，尤其是在低性能设备、复杂网页或同时播放媒体时更容易暴露。项目把表面材质拆成层：底层是淡色背景，中层是半透明容器，顶部使用一像素左右的亮边，阴影只做轻微空间分离。对用户来说，这依然有液态玻璃的感觉；对渲染管线而言，则尽量避免无意义的全屏实时滤镜。

八、书签、历史与本地状态#

浏览器的基础功能，不只是把页面打开。用户还需要在一次会话之外找回有用的内容。雨浏览器支持添加、移除书签，查看和清理浏览历史，并把常用的搜索设置与必要浏览器状态保存在设备本地。应用使用本地偏好存储来恢复普通标签、收藏、浏览记录和下载列表；它没有设计一套云端账号来自动同步这些内容。

历史记录只对普通标签工作。完成页面加载之后，应用获取标题、URL 和时间，整理成可读条目；同一网页的频繁变化不必每一刻都变成一次新写入。用户可以从设置中查看历史并进行清理。书签则由用户主动维护，添加和移除的动作应立即反映到首页或书签面板上。对于一款轻巧浏览器，本地可控往往比暗中上传后再依赖账户管理更符合使用者的直觉。

本地并不等于永久。Android 清除应用数据或卸载应用时，应用私有空间内的信息可能被移除。设备备份、系统厂商的存储政策与用户分享行为都可能影响数据是否继续存在。雨浏览器没有做跨设备同步，因此也不会承诺换机后自动恢复收藏和历史。用户如果有长期保存需求，应按自己的需要使用系统提供的导出或备份方式。

普通标签与隐私标签的记录策略并不相同。普通浏览记录可以在应用内查看；隐私标签不进入本地历史清单。用户从浏览器切换隐私模式，应该理解成“应用减少留下哪些本地痕迹”，而不是改变互联网服务本身如何记录请求。详情请参阅随项目附带的隐私说明以及 iyu6.com 的官网隐私声明。

九、隐私标签与真实隐私边界#

“无痕”“私密”或“隐私标签”这些词很容易被理解成一种强大的匿名保障。雨浏览器不会这样宣传。它当前使用 WebView 的无痕/独立缓存设置，并且不把隐私标签访问写入应用自己的普通历史记录；这可以帮助用户减少设备上由应用保存的浏览痕迹，但不能改变网站服务器收到请求这一事实。

目标网站仍可能看到连接请求中的 IP 地址、浏览器与设备相关信息、访问时间和路径；搜索服务会按其服务规则处理搜索请求；网络运营者可能看到连接元信息；如果用户在网站上登录账户，网站也可能把访问与账户会话联系起来。第三方 Cookie、页面自身脚本和服务器日志也不受雨浏览器历史记录设置的控制。清除应用历史不是服务器删除请求记录，关闭标签也不是撤回已发送的数据。

项目因此把隐私标签解释为一个有限的本地保护功能：不写入应用浏览历史，使用 WebView 私密上下文相关设置；它并不声称消除所有缓存、下载文件、截图、系统网络日志或第三方账户痕迹。下载行为可能会留下保存的文件；用户主动分享网页，也会把链接交给系统或其他应用。请在使用时审阅目标网站自身的隐私政策，并且避免在公共设备上登录不必要的个人账户。

同样，普通模式也不是故意过度收集。当前应用没有账号注册或云同步接口，书签、历史和设置留在本机。为版本检查访问官网公开的 JSON 时，站点或 CDN 在通常的 HTTP 服务过程中可能记录访问日志；这与浏览器向第三方网站发起浏览请求是两个不同场景。官网隐私声明说明 iyu6.com 网站的日志、Cloudflare 与评论系统情况，应用内的隐私说明则补充本地浏览数据的处理方式。

十、下载与网页分享#

许多网页会提供文档、图片、压缩包或其他文件下载。雨浏览器监听 WebView 的下载事件，检查目标 URL 只允许 HTTP 或 HTTPS，并从服务器建议的文件名中清理不适合本地文件名的字符。随后应用发起 HTTPS/HTTP 请求，在适当情况下沿用该 WebView 对目标网站的 Cookie 与 User-Agent，将响应写入应用私有目录下的下载文件夹，并在本地下载列表中记下文件名、路径、来源地址和时间。

文件写入应用私有空间的好处是减少对公共共享目录权限的依赖，也避免把网页提供的文件无差别散落到用户的下载根目录。相应地，其他应用不能像扫描公共 Downloads 文件夹那样自动发现这些文件。用户可以在雨浏览器的下载管理里选中记录，调用 Android 系统分享面板，再自行选择保存到别处、使用其他应用打开或发送给他人。分享是用户主动触发的操作，不会由浏览器自动发送文件。

下载失败可能来自网络超时、服务器拒绝、网页登录状态变化、文件本身不可访问或目标网站限制。大型网页也可能要求特殊的请求头、跳转、分片或身份验证方式；当前实现以常见直接 HTTP(S) 下载为目标，不保证兼容每种下载服务。浏览器会使用网页会话相关 Cookie，但并不因此代表它拥有或能恢复所有站点的登录状态。涉及高风险文件时，请检查文件来源，并由 Android 安全机制和可信应用处理。

网页分享则是更简单的流程：从更多菜单选择分享网页，应用把当前标题与 URL 交给系统分享接口，后续由用户挑选通讯软件、笔记应用或其他目标。雨浏览器只负责发起系统面板，不会替用户选择联系人或自动发布内容。这个区分很重要：应用提供工具，但对外发送仍应是可见、可控的用户动作。

十一、版本更新：一个 JSON 文件，不是后台推送#

雨浏览器 v1.2 的版本检测采用静态 JSON 清单，而不是完整的自动更新平台。应用在启动及从后台回到前台时，以 HTTPS 请求 APP 子站的公开地址 https://yubrowser.iyu6.com/update.json，并附加时间戳和不缓存请求头。返回状态正常后，应用读取 versionCode、versionName、downloadUrl 和 releaseNotes，与本机版本号进行比较。iyu6.com 主站仍是独立站点，不需要把 APP 子站覆盖到其根目录。

Flutter 按 ABI 分拆 APK 时，会给不同架构的 Android 版本号使用平台偏移。当前客户端在比较前会把这类偏移归一化，所以公开 JSON 里填写的是 pubspec.yaml 的基础 build number，而不是 arm64 APK 显示出来的偏移版本号。当前 v1.2.0 使用基础 build number 3；已安装版本低于 3 时才会出现更新提示。版本号没有更高时，正常自动检查保持安静；用户从设置主动检查时，应用会反馈当前是否为最新版本或清单暂时不可用。

发现更高版本后，页面展示清单中的版本名与发布说明。用户选择“前往下载”时，应用校验下载链接必须为 HTTPS，再交给系统打开。之后 Android 按系统规则显示下载、未知来源授权或安装确认；雨浏览器不在后台偷偷替换自身，也不跳过用户确认。这既符合普通网站托管 APK 的能力边界，也让安装过程透明可见。

最重要的区别是：版本 JSON 只能让应用在下一次启动或回到前台时“发现有更新”，不能在应用关闭期间把通知推到用户手机。真正的系统通知需要 FCM 等推送服务、应用通知权限与可发送消息的服务端；静态文件本身不具备主动联系设备的能力。即便用户看到更新提示，也仍要确认下载和安装。网站只是发布渠道，不等于应用商店，也不意味着静默升级。

十二、APK 体积、架构拆分与发布注意事项#

Android 应用可构建为一个通用 APK，也可拆分为针对不同处理器架构的多个文件。雨浏览器使用 --split-per-abi，分别输出 armeabi-v7a、arm64-v8a 和 x86_64 版本。这样每个用户只需要下载自己设备可用的本机代码，而不用把所有架构的 Flutter 引擎动态库都装进同一个 APK。v1.2 这三份 Release APK 实际大小分别为 15.57 MB、18.36 MB 和 19.84 MB（以十进制 MB 计）；arm64 包较 v1.1 的 18.73 MB 减少约 1.96%。具体安装后占用还会受到系统 WebView、设备架构和 Android 存储计算方式影响。应用包体下降可直接从产物测量，但它不等于网页切换速度提升百分比。

Release 构建还启用 Tree-shake icons 以裁去未使用的 Material 图标字体，并使用 Dart 混淆与 --split-debug-info 保存符号信息。混淆让发布产物中的 Dart 符号不再以开发态形式保留，符号表则用于后续分析混淆堆栈。符号文件应保存在开发者自己的备份里，不需要随网站公开下载。R8 和资源压缩也由 Android Release 构建配置处理。

分 ABI APK 不能随意互换。常见 64 位手机应选 arm64-v8a，较旧的 32 位 ARM 设备选 armeabi-v7a；x86_64 通常用于模拟器或相应硬件。当前 APP 官网静态更新清单只指向 arm64 APK，所以它面向常见的 64 位手机。如果要向多种架构统一发放更新，还需要在客户端或发布策略中按 ABI 选择下载，或提供能够兼容目标架构的通用包；不能把 arm64 文件提供给所有设备后假设它们都可安装。

当前构建使用与此前测试包相同的签名证书，因此已安装该证书版本的用户可以直接升级到 v1.2，而无需先卸载。这个签名目前属于开发/测试路径，并不等同于经过长期保管的正式商店发布密钥。若以后要正式上架或长期通过官网升级，必须在安全位置生成、保管固定的发布签名密钥，并确保之后每一次升级都由同一证书签署。丢失密钥或换用不同证书，可能导致 Android 拒绝覆盖安装。

十三、兼容性、安全与项目维护#

浏览器的复杂度来自它连接了大量不同网页，而不是只来自自己的界面。网页可能使用不同的 Cookie、JavaScript、媒体播放方式、弹窗策略、文件下载流程和桌面端布局。雨浏览器提供 JavaScript 开关、桌面版用户代理、缩放和系统 WebView 支持，以帮助覆盖一些常见需求；但它不承诺所有网站都能呈现完全相同的结果。遇到页面空白时，问题可能来自网络、目标网站封锁、证书异常、WebView 版本或网页脚本，不一定是应用地址栏失效。

安全性也必须按功能边界描述。应用对网页导航协议和下载 URL 做基本筛选，关闭不需要的任意本地文件访问，并把网页下载放到应用私有目录。用户仍然需要自行判断目标网站是否可信，谨慎处理可执行文件与未知附件。雨浏览器并没有宣称具备独立反病毒引擎、全网钓鱼识别、广告过滤或企业级内容审查能力。

在工程维护层面，项目使用 Flutter 和 Dart 管理应用代码，通过本地化依赖覆写解决当前 Android Gradle Plugin 环境与 WebView 插件构建脚本的兼容问题。项目内保留了补丁目录，确保其他开发环境可以复现构建，而不是依赖某一台机器的 Pub 缓存被手工改过。未来如果上游插件发布兼容版本，可以重新评估并移除本地覆写。这是维护成本与当下可构建性之间的折中，需要随插件升级重新验证。

自动检查覆盖了 Flutter 静态分析、首页 Widget 冒烟测试、Android Release 构建和 APK 签名/包信息验证。它们能确认代码可分析、界面启动测试可过、构建产物存在以及包名版本信息正确，却不能代替实体手机上对网页兼容、流畅度、耗电、下载授权、横竖屏和不同厂商系统行为的测试。重要的质量结论要说明测试了什么，也要承认没有测试的部分。

十四、当前已实现与暂未实现#

为了让产品预期保持准确，可以把雨浏览器当前的能力概括为两类。已经实现的是：网址访问与关键词搜索、百度/必应选择、前进后退、刷新和停止、最多 8 个普通/隐私标签、近期 WebView 缓存、书签、浏览历史、本地下载列表、系统分享、桌面版用户代理、JavaScript 开关、启动/回前台版本检查、应用说明与服务条款入口。

当前还没有实现的包括账号与云同步、跨设备共享标签、自动化密码管理、书签导入/导出界面、下载任务后台断点续传、扩展插件、广告过滤和应用关闭后的推送提醒。部分功能看起来与现代大型浏览器相似，但其背后需要云端账号、密钥管理、长期后台任务、规则更新或更复杂的权限模型，不应该仅仅因为界面上多加一个按钮就对外宣称已经具备。

未来的功能顺序应从真实使用反馈中决定。如果用户主要反馈标签恢复问题，可以考虑保存滚动位置或更细的会话恢复；如果大量用户需要异构架构更新，可以先完善 ABI 下载选择；如果无障碍使用需求突出，可以增加字号、对比度和屏幕阅读器优化；如果本地数据需要迁移，可以设计明确可见的导出格式。每个新功能还要评估其对包体、内存、隐私与维护工作的影响，而不是只看展示效果。

性能优化也应该保持持续而非一次性。v1.1 解决了“频繁切换就主动销毁 WebView”的核心问题；v1.2 又减少后台标签事件触发的 UI 重建并移除了新标签大图，但当前仍未公布统一真机基准，也不宣称所有网页都能秒开。后续可以在固定设备与公开测试网页集上测量首次加载、重复切换、帧时间和内存峰值；同时观察低内存设备与复杂网页脚本情况下，保留两个 WebView 是否仍然合适。如果证据显示不同设备需要不同缓存数，再考虑自适应策略，而不是凭感觉扩大常驻数量。

十五、如何观察和复现性能问题#

性能问题要能被修复，首先需要从“卡”拆解成可观察的现象。用户说切换很慢，可能指点击后没有即时反馈、地址栏没有立刻变化、网页白屏很久、旧网页重载、动画掉帧，也可能是点按之后应用暂时无法继续响应。这些问题表面上都像是切换迟缓，背后的原因却可能分别落在 Flutter 界面状态、WebView 实例生命周期、网络请求、网页 JavaScript、系统内存回收或设备温度限制上。只更改动画曲线，无法解决网络等待；只加快网络，也不一定消除频繁布局造成的掉帧。

一个有帮助的复现记录，应该先说明问题发生在哪一步。例如：打开应用后输入某个普通公开页面；等页面标题显示且加载停止；再打开第二个网页；在两个近期页面间连续切换几次；继续新建第三个页面；最后切回第一个标签。这样就能区分“最近缓存中的热切换”和“超出两个缓存页面后的再次加载”。如果问题只发生在某个高脚本量的网站，也应注明大概域名和页面类型；分享地址前，先确认它不是包含个人令牌、内部工作信息或私密内容的 URL。

测量时最好分开记录三个阶段：按下标签到应用界面开始响应的时间、从点击到旧网页内容再次可见的时间，以及页面恢复到可以正常交互的时间。一个网页可能很快重新显示，但脚本仍在后台加载；也可能 WebView 已经保留，画面出现得很快，接下来仍要等第三方广告或数据接口返回。把这三个阶段混为一个“加载时间”，会让后续分析失去方向。单次测试会受网络和缓存偶然影响，多次重复后看中位数和慢尾部，比挑一个最好结果更接近真实体验。

尽量固定测试条件也很重要。同一台手机、相同网络、相同的几个公开网页、相同的标签顺序，可以让前后版本比较更有意义。记录应用版本、Android 版本、Android System WebView 版本、设备内存情况和当时是否在播放媒体。若可以，先重启应用或确认测试前没有其他重负载程序，再分别做一次首次冷打开和一次从别的标签返回；不要把首次 DNS、TLS、网站登录或图片缓存都与热切换混在一组数据里。

开发者可以使用 Android Studio 的 CPU Profiler、Memory Profiler 与帧时间工具，观察切换瞬间 Flutter UI 线程、GPU 合成、WebView 进程内存和是否出现页面重建。若切换时 URL 状态立即改变、但 WebView 的首个可见帧很晚，问题更可能是网页重新加载或恢复；如果按钮本身延迟触发，则要再看是否有主线程阻塞或过多同步工作。性能分析工具看到的是设备上的技术信号，不是对用户体验的替代品，因此仍需通过实际操作确认修复有没有改善。

低内存环境也要单独测试。两个保留 WebView 是一个起点，不是对所有型号永远适用的固定答案。系统可能因为后台压力主动回收网页进程；高分辨率图片、多媒体、复杂画布和长时间运行的脚本都可能提高内存负担。验证时可逐步增加标签数，比较返回最近标签与返回更早标签的行为，留意应用是否持续占用过多内存、是否重现页面或出现系统提示。若为了切换更快而无限保留网页，可能损害其他应用甚至导致当前浏览器被系统终止。

反馈内容也应尽可能尊重隐私。当前项目没有设计后台行为分析或账号数据同步来记录用户浏览路径；定位问题可以先使用本地录屏、开发者日志和公开测试页，不需要默认上传历史、Cookie、下载文件或完整网页内容。用户反馈时可以只提供设备环境、操作步骤、问题出现频率与无敏感信息的示例站点。若复现必须依赖个人登录页面，可用同类公开页面说明现象，或者先征求本人同意后再提供经过脱敏的信息。

可以用以下简化模板反馈性能问题：

• 应用版本与安装包架构：
• 手机型号、Android 版本、WebView 版本：
• 复现网页类型或公开网址：
• 操作步骤（从哪个标签切到哪个标签）：
• 页面是否刚打开、是否已加载完成：
• 发生频率，以及最近两个标签和更早标签是否表现不同：
• 是否伴随白屏、重新请求、按钮延迟或应用无响应：

信息越可复现，越容易区分是缓存策略不合适、网页自身过重，还是某个 Android WebView 版本的兼容问题。性能工作最终应回到用户执行任务时的感觉，但要通过可重复的测量找到原因，再通过相同条件验证改动，而不是只凭一句“现在好像快了”宣布问题已经彻底解决。

十六、常见问题#

为什么切换最近两个页面更快，早一些的标签还会重新加载？ 近期两个 WebView 会被保留，较早的非活动页面为了控制内存而回收了视图控制器。它的标签记录仍然存在，但页面可能需要再次加载。这是 v1.1 引入并由 v1.2 延续的内存取舍。

开启隐私标签后，网站还会知道我访问过吗？ 网站仍会收到网络请求，也可能依据 Cookie、账户登录和自己的日志处理访问。隐私标签减少的是应用本地浏览历史记录，并不是匿名代理，也不是网络层的隐身服务。

为什么版本文件已上传，手机还没有弹更新？ 应用只在启动和回到前台时检查，不是在应用关闭期间推送；update.json 的 versionCode 必须大于当前 build number，下载 URL 必须是可访问的 HTTPS 链接，而且当前更新清单指向 arm64 安装包。可以在应用设置里手动检查，或核对服务器/CDN 是否仍缓存旧 JSON。

安装时 Android 为什么还要再确认？ 雨浏览器只是打开 APK 下载地址，最终安装由 Android 系统控制。系统可能要求对当前安装来源授予权限并再次确认；应用不会静默安装。

为什么某些网站显示不正常？ 网页由设备 WebView 和目标网站共同决定。可以检查网络，尝试刷新、切换桌面版或查看 JavaScript 设置；如果问题仍在，记录设备型号、Android 与 WebView 版本、网页地址和复现步骤，才更容易定位。

书签和历史会同步到云端吗？ 当前版本没有账号同步功能，普通标签记录主要保存在本机。卸载或清除应用数据可能导致本地记录丢失；应用不承诺跨设备自动恢复。

以后如何升级到 v1.3？ 需要生成更高 build number 的 APK，更新清单中的 versionCode、versionName、downloadUrl 和 releaseNotes，把 APK 和 JSON 同时上传到 APP 子站的 HTTPS 地址，然后让用户下次启动或回到前台检查。更新包需要使用与已安装应用相同的正式签名证书。

十七、项目地址与联系#

雨浏览器由余余制作。**APP 产品官网为 https://yubrowser.iyu6.com/，原主站保持在 https://iyu6.com/，主站隐私声明为 https://iyu6.com/privacy/。**网站备案查询地址为 https://icp.gov.moe/?keyword=20269978，公开查询显示萌ICP备20269978号。应用的下载与版本说明应以 APP 子站实际发布的文件为准；若网站更新清单，发布者也应同步检查下载链接、版本号、架构和签名。

用户反馈应尽量具体。只说“浏览器不行”很难复现；提供手机型号、Android 版本、雨浏览器版本、遇到的网页域名、是否开了隐私标签、问题出现的步骤、是否每次出现以及是否能稳定复现，会更有助于判断是应用 UI、WebView、网络还是目标网站的问题。涉及个人信息时，不要把账号密码、Cookie、完整下载文件或私密浏览记录直接发到公开渠道。

一个轻量浏览器的价值，并非把所有复杂能力隐藏在一个下载包里，而是清楚说明哪些事情由它完成、哪些事情仍交给系统和网站。雨浏览器目前是一款仍在迭代的 Android 项目：v1.1 先把标签切换时不必要的重载移除；v1.2 移除首页大幅图片、减少后台标签引发的界面重建、让浏览设置即时生效，并增加复制网页链接，再以分架构 APK 和 APP 子站静态版本清单交付。接下来，项目更需要真实设备反馈与谨慎迭代，而不是对“更快”“更安全”“更省电”做没有测量依据的保证。

从这个角度看，轻量不是一句关于文件大小的宣传语，而是一系列产品选择的总和：使用系统 WebView 而不是重复打包完整内核；只常驻最近的网页而不是永远留住全部页面；在隐私模式中明确它能做到与做不到的事；通过公开更新文件提示版本，而不假装有后台推送；把下载与安装交给用户确认。雨浏览器希望在这些有限但实际的边界里，把日常浏览做得更直接一点，也更容易理解一点。