这次 UI 鉴赏的主角是一个用 Flutter 开发的追番看漫 App：AFAN。我拿到这类项目时，第一反应不是去数它用了多少控件，而是先看它在“追番”和“看漫”这两条主流程上的信息层级。AFAN 没有做特别夸张的动效，但首页卡片、底部导航、详情页的追番状态、阅读页的进度表达，整体逻辑是顺的。如果你正准备做内容型 App，或者刚把 Flutter 环境搭好，想找一套能练手的 UI 来复刻，AFAN 这套界面比那些纯组件示例更接近真实产品。
下面我从 UI 拆解、Flutter 环境准备、页面实现、性能判断、常见报错这几个角度过一遍。代码和参数以通用做法为主，具体落到你本机时，还是要以当前 Flutter 版本和环境为准。
1. 鉴赏前先明确：这套 UI 是为了两条主流程服务的
很多 UI 鉴赏只看截图好不好看，这是最容易跑偏的地方。截图里最容易被忽略的，其实是交互状态。AFAN 作为追番看漫 App，真正要服务的是两条完全不同的用户路径：追番是周期性等待，看漫是连续性阅读。
1.1 追番流程里，UI 的重点不是好看，而是状态可见
追番场景下，用户关注的核心问题很集中：这部番我看过没有？追到第几集了？下一集什么时候更新？
所以 UI 里最值得抄的不是卡片圆角，而是状态标签的摆放。AFAN 这类 App 的首页卡片上，通常在封面图角落放更新提醒，在标题下面放“在看 / 想看 / 已看完”这类状态。这样用户不用点进详情页，就可以完成大多数日常判断。
如果状态不放在列表层，用户就必须进入详情页才能知道“这部我看过没有”。按这个逻辑设计的 UI，看着干净，实际使用效率很低。
1.2 看漫流程里，UI 的重点是连续阅读和进度记忆
看漫画和刷信息流不一样，用户会长时间停留在一本漫画里。阅读页的 UI 最忌讳的是控件堆叠过头。一个 30 分钟阅读场景里，用户需要的是快速翻页、随时调整亮度、快速调到下一话，而不是被页面上十几个按钮反复打断。
AFAN 在阅读流程上比较值得参考的地方，是它把目录、亮度、设置这些功能统一放到同一层浮层里，阅读时默认隐藏。点击屏幕中间呼出浮层，点左右区域翻页，这种交互几乎成了内容阅读类 App 的标配。
所以鉴赏这套 UI，其实是用两条主流程来检查界面：追番路径上状态是否一眼可读，看漫路径上阅读是否足够连续。
2. 核心界面拆解：从首页到阅读页到底在表达什么
纯 UI 鉴赏如果只停留在“这个配色挺好看”就太浅了。真正有参考价值的拆解，是看每个页面为什么要把信息放在那个位置。
2.1 底部导航和首页卡片流
AFAN 的底部导航属于典型内容型 App 结构，数量控制在 4 到 5 个。常见切法是“首页、追番、书架、我的”。底部导航最怕超过 5 项，因为用户记忆成本和点击成本都会上升。
首页做主推内容流，卡片是最核心的视觉单位。一张卡片里同时出现封面图、标题、状态标签、更新信息时，就需要考虑信息优先级。
我的判断标准是：封面图占最高视觉权重，标题其次，状态标签再次，更新信息只需要小字号补充。如果卡片所有元素都设计得一样大，页面会显得很吵，用户反而不知道先看哪里。
这里最容易踩坑的是封面图比例不统一。动漫封面和漫画封面比例不同，一旦列表里混入 3:4、1:1、16:9 的图，卡片高度就会不停跳。做 Flutter UI 时，建议在列表层固定一个封面比例，比如统一用 3:4 的占位容器，图片加载完成后用 BoxFit.cover 填充。这样列表高度稳定，滚动性能也会更好。
2.2 详情页里的追番按钮和进度模块
详情页最忌做成简介堆叠。用户来到详情页，想知道的无非是：目前更新到第几话、我追到第几话、下次更新是什么时候。
AFAN 这类 App 的做法，通常是把追番按钮放在封面下方或标题右侧，再紧跟一个进度模块。进度模块不要只给“第 3 话”这种文字，最好加一条很轻的进度条，让用户对剩余内容有直观感受。
如果你要复刻这套 UI，记住一点：详情页的信息顺序应该是“当前状态 + 操作按钮”优先，然后才是简介、标签、相关推荐。很多新手会把简介放在最上面，用户每次都要滑很久才能看到追番按钮，这就违背了 UI 的主流程设计。
2.3 阅读页的暗色模式和浮层控件
阅读页是 UI 实现里最容易翻车的地方。黑白漫画要保证图片对比度，彩色漫画要避免颜色偏色，夜间模式还要考虑背景色不能太亮。
暗色模式不是简单地把背景改成黑色。AFAN 这类的阅读页，通常会避免纯黑背景，因为纯黑在强光和纯暗环境下都会让眼睛很累。更稳妥的做法是深灰背景，比如 #121212 这类接近 Material 设计规范的色值，再配一个中低亮度的页面底色。
浮层控件的设计，核心是“默认收起、按需呼出”。如果用户每次翻页都要经过一排按钮，那就不是阅读页，而是操作面板。
3. 复刻这套 UI 前，先把 Flutter 环境准备到能跑通
做 UI 不像看设计稿，最终要落到可运行代码。很多 Flutter 项目死在第一步：环境没跑通，后面写再多组件也看不到效果。
3.1 开发机检查项
无论你在 Windows、macOS 还是 Linux 上开发，新建 Flutter 项目之前，至少要做这几项检查：
- Flutter SDK 已经安装，并且
flutter命令可以在终端里直接使用。 flutter doctor能识别你打算运行的设备：Android 模拟器、真机、iOS 模拟器或桌面端。- 编辑器已经装好 Flutter 和 Dart 插件。VS Code 和 Android Studio 都可以，没有绝对好坏。
- 如果你要跑 Android，先确认已经安装对应版本的 Android SDK 和构建工具。
我一般会先跑一次flutter doctor，确认环境再动手。这里不要急，环境问题在项目刚开始处理成本最低，等写了几百行代码再回头查 SDK，会非常浪费时间。
3.2 创建工程和基础依赖
环境检查通过后，新建一个工程作为 UI 复刻基底：
flutter create --org com.example --project-name afan_ui --platforms android,ios afan_ui cd afan_ui flutter pub add cached_network_image provider flutter run--platforms的作用是只生成你需要的平台目录，避免每个项目都带一堆用不上的桌面端目录。cached_network_image用来处理网络封面图缓存，provider用来做轻量状态管理。这两个不是必须选的，但做内容型 App 时很常用。
新建工程后，先不要急着改代码。我建议先直接运行默认的计数器工程，确认从编译到安装再到启动的整条链路是通的。如果这里能跑起来，后面写 UI 报错时，就可以先把“环境问题”排除掉。
注意：新建工程后先不加任何业务代码，直接运行默认工程，确认本机 Flutter 环境能完整跑通一遍编译、安装、启动链路。
3.3 主题和基础 UI 库怎么选
搜索“Flutter UI 库”的时候，很容易被各种组件库吸引。但我个人建议，内容型 App 先不要整包引入大型 UI 库。AFAN 这类界面用到的核心组件并不多：NavigationBar、Card、SliverAppBar、图片组件、列表组件，Material 3 本身已经覆盖大半。
引入 UI 库前先问自己三个问题：
- 这个库是否支持暗色主题？
- 它的列表组件是否方便替换成自己的数据结构？
- 如果只用到其中一两个组件，引入整个库是否值得？
很多时候，真正决定 UI 质量的不是组件库，而是间距、字号、圆角、阴影和图片比例是否统一。把这些固定到主题文件里，比引入任何 UI 库都重要。
4. 用 Flutter 还原这套 UI 的关键实现
UI 鉴赏到最后，还是要落到代码上。我不主张把 AFAN 整个界面逐像素复刻，但几个核心结构可以按下面的思路实现。
4.1 底部导航骨架
底部导航用NavigationBar就可以，这是 Material 3 风格下比较省事的组件。如果你的 Flutter 版本较老，也可以用BottomNavigationBar替代。
Scaffold( body: IndexedStack( index: _currentIndex, children: const [ HomePage(), FollowPage(), ShelfPage(), ProfilePage(), ], ), bottomNavigationBar: NavigationBar( selectedIndex: _currentIndex, onDestinationSelected: (index) { setState(() { _currentIndex = index; }); }, destinations: const [ NavigationDestination( icon: Icon(Icons.home_outlined), selectedIcon: Icon(Icons.home), label: '首页', ), NavigationDestination( icon: Icon(Icons.favorite_outline), selectedIcon: Icon(Icons.favorite), label: '追番', ), NavigationDestination( icon: Icon(Icons.book_outline), selectedIcon: Icon(Icons.book), label: '书架', ), NavigationDestination( icon: Icon(Icons.person_outline), selectedIcon: Icon(Icons.person), label: '我的', ), ], ), )这里用IndexedStack而不是PageView，是因为底部导航切换时，我们希望保留每个页面的状态。比如首页已经滚到很靠下的位置，切走再切回来，不应该恢复到顶部。IndexedStack会同时保持页面状态，但要注意四个页面会一起初始化，如果每个页面都加载大量数据，首屏成本会变高。
注意：如果底部导航页面包含视频播放或滚动位置较深，不要每次切换都重建页面。用
IndexedStack能保留状态，但要关注多页面同时初始化带来的开销。
4.2 首页卡片列表
首页核心是竖向卡片流。直接用ListView或ListView.separated按行构建即可。
ListView.separated( padding: const EdgeInsets.all(16), itemCount: _items.length, separatorBuilder: (context, index) => const SizedBox(height: 12), itemBuilder: (context, index) { final item = _items[index]; return AnimeCard(item: item); }, )这里的separatorBuilder用来控制卡片间距，不要用每个 Card 外部再套Padding，那样间距逻辑会很散。卡片内部建议拆成Row或Column，封面区固定宽高，文字区用Expanded撑满剩余空间。
如果列表项高度基本固定，可以给ListView设置itemExtent或prototypeItem，帮助 Flutter 预判滚动位置，减少滚动时的布局计算。列表元素超过几百条时，这个优化效果会更明显。
4.3 详情页和阅读页的代码思路
详情页可以用CustomScrollView加SliverAppBar实现封面折叠效果，也可以先用普通ListView跑通逻辑。UI 鉴赏阶段，不要一开始就上复杂手势，先把数据展示清楚更重要。
阅读页要单独处理生命周期。用户读到一半切到后台，再回来看的时候，应该恢复进度，而不是回到第一页。Flutter 里可以通过WidgetsBindingObserver监听应用生命周期：
class ReaderPage extends StatefulWidget { const ReaderPage({super.key}); @override State<ReaderPage> createState() => _ReaderPageState(); } class _ReaderPageState extends State<ReaderPage> with WidgetsBindingObserver { @override void initState() { super.initState(); WidgetsBinding.instance.addObserver(this); } @override void dispose() { WidgetsBinding.instance.removeObserver(this); super.dispose(); } @override void didChangeAppLifecycleState(AppLifecycleState state) { if (state == AppLifecycleState.paused) { // 在这里保存阅读进度 } } }理解 Flutter 生命周期很重要，尤其是做阅读器、播放器这类长时间停留的页面。只会在页面initState里加载数据的习惯，到了阅读场景是不够的。
4.4 把 UI 和状态管理接起来
UI 只是表现层。AFAN 里的追番状态、更新话数、阅读进度，都不能直接写死在卡片里。
我建议先用一个简单的页面模型管理数据，比如AnimeItem包含标题、封面、进度、状态。再通过Provider或ValueNotifier把状态暴露给 UI。先用假数据跑通页面，等 UI 稳定后再把假数据替换成接口请求。
不要每个页面都自己setState管理所有数据。最开始这样做确实很爽，但只要出现“首页状态变了，详情页也要变”的需求，就会非常被动。
5. 判断 UI 能不能用的四个参数
UI 鉴赏不能只看效果图，还要看它在真机上的表现。下面四个参数是我判断一套 Flutter UI 是否值得落地的核心标准。
5.1 首帧和滚动流畅度
界面再好看，首屏转半天，用户也等不起。判断首帧快慢，不要用 Debug 模式，要切到 Release 或 Profile 模式看。Debug 模式本身有大量检查逻辑，跑起来慢是正常的，不能代表真实性能。
滚动流畅度主要看快速滑动列表时是否明显掉帧。遇到掉帧，优先看是不是每张卡片都在重复加载图片，或者列表项没有被正确复用。
5.2 图片内存和封面图缓存
内容型 App 最耗资源的往往不是代码，而是封面图。图片尺寸越大、数量越多，内存压力越明显。
AFAN 这类追番看漫 App，封面图会非常频繁出现。加载时建议不要直接用原图，根据列表缩略图和详情大图做两套尺寸。cached_network_image自带缓存能力，但如果你有清晰的图床，最好自己控制缩略图 URL。
注意：不要一上来就用原图覆盖全屏，封面图统一按列表缩略图和详情大图两套尺寸处理。
5.3 屏幕适配和状态栏
不同手机宽度差异很大。卡片间距、封面比例、底部导航高度，都要在常见机型上跑一遍。
状态栏也容易忽略。打开 App 后，状态栏文字颜色和页面配色要匹配。浅色页面用深色状态栏图标，暗色页面用浅色状态栏图标。Flutter 里用AnnotatedRegion<SystemUiOverlayStyle>或系统主题配置来处理。
5.4 低配置设备上的降级策略
能在高配手机跑得顺，不代表低配手机没问题。如果目标用户里有很多中低端 Android 设备，需要做降级：
- 关闭或减少大图预加载。
- 列表滚动时延后加载非首屏图片。
- 减少同一时间弹入的动画。
- 阅读页不要一次把所有章节图片全部加载到内存。
可以参考下面这张表快速排查：
| 检查项 | 判断标准 | 优先排查方向 |
|---|---|---|
| 首帧速度 | 从点击图标到首页可操作的时间 | 首屏图片数量、接口耗时、路由初始化逻辑 |
| 滚动帧率 | 快速滑动时是否明显掉帧 | 卡片重建次数、图片缓存、列表是否使用 builder |
| 图片内存 | 内存占用是否随浏览持续上涨 | 封面图尺寸、缓存策略、是否使用缩略图 |
| 暗色适配 | 阅读页无刺眼反光、文字可读 | 主题色、图片蒙层、是否跟随系统 DarkMode |
判断标准不用追求绝对数值，关键是能复现。每次改动之后再跑同一批页面，对比前后变化，比听别人给的数据更可靠。
6. 还原过程中最常见的报错和排查顺序
Flutter UI 还原过程里，报错是常态。很多问题不是模型能力不行，而是环境、依赖、路径或输入格式没有处理干净。下面按我的排查顺序列一下。
6.1 启动失败：先看设备、版本和依赖
flutter run跑不起来，先按这个顺序查：
- 当前有没有可用设备？
flutter devices看一下。 - 依赖有没有拉全？
flutter pub get跑一次。 - 报错信息里有没有提示需要更新 Flutter SDK 或 Android Gradle 插件？
- 如果还不行，用
flutter run -v看详细日志。
不要一上来就怀疑代码。很多 UI 项目启动失败，都是设备没连接、依赖版本冲突或者 SDK 没配置好。
6.2 图片不显示：路径、域名、磁盘权限走一遍
本地图片不显示，先看路径大小写和资源声明。网络图片不显示，就检查：
- 图片 URL 是否真的能访问。
- Android 上是否配置了网络权限。
- 域名是不是 http，Android 和 iOS 对明文流量的限制不同。
- 图片格式是否被 Flutter 解析支持。
图片问题看起来像是控件问题，实际往往是输入源和权限问题。
6.3 页面跳转异常和状态丢失
页面跳转不回去，先看Navigator.push和Navigator.pop是否成对。页面状态莫名其妙丢失，先看 Tab 切换时页面有没有被重建。
用底部导航时，如果切 Tab 后页面回到顶部，多半是页面被销毁了。可以给页面加AutomaticKeepAliveClientMixin，或者在父级用IndexedStack统一管理。阅读页尤其要注意进度保存，不能只依赖内存里的变量。
6.4 Android 构建提示 Gradle 插件问题
Android 构建时报 Gradle 相关错误，尤其是看到类似 “You are applying Flutter's main Gradle plugin imperatively using the apply script” 这类提示时，不要去乱改 Gradle 配置，先看项目里的settings.gradle、build.gradle是否按当前 Flutter 版本的要求配置了插件。
这类问题往往是 Flutter 版本升级后，插件应用方式变了，但项目还沿用旧写法。处理时先确认当前 Flutter 版本，再对照官方迁移说明调整，不要凭记忆改版本号。
7. 把这套 UI 变成自己项目的几个落地点
最后说几个落地点。UI 鉴赏最怕的是看完觉得好，但不知道从哪里开始改。
7.1 只借鉴信息层级，不要照搬尺寸
AFAN 的间距、字号、圆角是给它的屏幕和内容风格服务的。换到你的项目，不一定完全适用。我建议把封面比例、卡片间距、主题色、文字字号抽成变量，先定一套自己的设计规范，再对着参考项目调整。
7.2 状态和视觉分离
追番状态、阅读进度、更新提醒这些数据，不要散落在每个 widget 里。先把数据模型定义清楚，再让 UI 去消费。这样后续接真实接口时，不用反过来改 UI。
7.3 先做单条流程，再做批量内容
不要一上来就做一个巨大的首页，塞满假数据。先 mock 一部番剧，跑通“首页卡片 -> 详情页 -> 追番状态 -> 阅读页 -> 进度保存”这条单链，然后再扩展成列表、书架和多内容源。
我个人更建议从首页卡片列表开始，把它跑稳了再看详情页和阅读页。等你把这几页拆完，就会发现 Flutter UI 不再是一个个控件，而是一整套信息流和状态表达。
