一套 Flutter 代码跑遍手机、电视与桌面：跨端适配的四组取舍

我维护的 Venera-Next 是一套 Flutter 代码打通 Android、Android TV、iOS、Windows、Linux、macOS 的漫画阅读器。很多人问我跨端是不是“写一次，到处运行”就完了。我的体会恰恰相反：编译通过只是起点，真正花时间的地方，是在四个地方反复做取舍。下面这四组取舍，都是我实际踩过坑之后定下来的。

第一组：按窗口尺寸分档，不要按设备类型分档

我最早的写法是判断 Platform.isAndroid、isWindows 之类，再给每种设备写一套布局。很快就崩了：同一台 Windows 电脑，窗口从全屏拖到半屏，布局应该变，但设备类型没变；同一部 Android 手机，横屏和竖屏的可用宽度差一倍，硬按“手机”一套布局，横屏两侧全是空白。

后来我改成只看窗口的实际尺寸和方向：窄屏一列、 medium 宽度两列或左右分栏、宽屏再放开。设备类型只用来决定极少数默认值，比如默认字号和默认列数。这样做的好处是，窗口缩放、折叠屏展开、分屏模式都能自然跟上，不用为每种新设备补分支。踩坑点是：分档阈值不要定得太细。我试过定五档，结果每档都要单独调间距和字号，维护成本直线上升；最后收敛到三档，细节用弹性间距消化，反而更稳。

第二组：输入方式不同，交互必须分开设计

手机是触摸滑动，电视是遥控器方向键，桌面是鼠标加键盘。如果共用同一套交互，电视上会立刻出问题：没有焦点概念的按钮，遥控器按方向键根本选不中；长按、滑动这类手势在电视上不存在。

我的做法是把“焦点”当成电视端的一等公民：可交互元素全部进焦点树，方向键移动时有明确的视觉高亮，返回键有统一的层级处理——先关弹窗，再退回上一级，最后才退出页面。桌面端则反过来利用鼠标悬停和键盘快捷键：方向键翻页、空格下一页、鼠标滚轮连续滚动，这些在手机上不需要，但桌面用户会默认它们存在。取舍在于：不要为了“统一”而砍掉某一端的原生习惯。统一的是数据层和业务逻辑，交互层按输入方式分开写，代码量多一点，但每一端的体验都对味。

第三组：大屏不是把小屏放大，图片策略要反推

漫画阅读器的性能瓶颈几乎都在图片上。手机屏幕小，一页解码一张高清图问题不大；电视和桌面动辄 4K 大屏，同一张图放大后锯齿明显，解码尺寸和内存占用也跟着翻倍。如果直接沿用手机的缓存策略，大屏上要么糊，要么爆内存。

我最后的策略是按显示尺寸反推：先算这一页在当前窗口里实际占多少像素，再决定解码到多大，缓存里只留当前页前后有限的几页，超出就释放。长图列表还要加一层保护：滚动速度快时先显示低分辨率占位，等停稳再换高清，避免滑动过程中反复解码拖垮帧率。这里有个反直觉的结论：缓存越大不一定越流畅。我曾经把缓存上限调得很大，结果旧设备上内存峰值先顶不住，反而在翻页时触发回收、出现卡顿。缓存、预加载、内存上限三者要一起调，单调一个只会把问题推到另一边。

第四组：平台差异收敛到一层薄接口，不要散落在业务代码里

跨端最容易失控的地方，是文件路径、存储权限、网络源这些系统能力。Android 的沙盒路径、Windows 的盘符、Linux 的家目录、macOS 的容器目录，写法全不一样；WebDAV 同步、本地漫画导入这些功能，又处处要碰文件系统。如果业务代码里到处写 if (Platform.isX)，加一个平台就要全量回归。

我的收敛方式是：业务层只认一个抽象接口，比如“给我一个可写目录”“列出这个文件夹下的漫画”，具体实现按平台各写一份，注册进一张表。新增平台时只加实现，不改业务。这个接口层一定要薄：只做“拿到路径、读写文件、申请权限”这类原子事，不要把业务判断塞进去。一旦接口层变厚，里面就会长出第二个业务层，跨端收益就被抵消了。另一个坑是权限申请时机：不要在启动时一次性全要，用户在不需要的功能上看到权限弹窗，只会觉得可疑；用到哪个功能，再在那个功能的入口处申请，说明也写在那个界面上。

结论：跨端省的是重复劳动，不是适配工作

回头看，一套代码跑多端，省掉的是重复写业务逻辑、重复修同一类 bug 的时间；省不掉的是为每一端认真做适配的时间。布局按窗口分档、输入按设备分开、图片按显示尺寸反推、平台差异收敛到薄接口——这四组取舍定下来之后，我加新平台的边际成本才真正降下来。

如果你也在做 Flutter 跨端应用，欢迎看看 Venera-Next 的实现：它是一个免费、无广告、GPL-3.0 开源的跨平台漫画阅读器，支持本地漫画、WebDAV 漫画源与第三方网络漫画源，上面这些取舍都能在代码里找到对应的位置。