企业官网建设流程全解析

前阵子接了一个艺考机构的题库App需求，目标平台锁定在 OpenHarmony，业务端要求做真题打点、题目详情、答题反馈这些核心模块。当时第一反应就是走 Flutter 这条路，正好赶上了 Flutter for OpenHarmony 的适配方案日趋成熟，最后折腾了两周多，把一套题库列表和题目详情页整体跑通，期间踩了不少坑，也整理出一些对后来者比较有用的实操要点。这篇就围绕这个项目的实战过程，把题目详情的实现拆开讲一讲，包括方案选型、数据模型、页面布局、状态管理、性能优化和真机排坑这几个方向。适合正在评估 Flutter 跨端能力的团队，也想给准备在 OpenHarmony 上做教育类工具App的同学一份可以直接参考的落地经验。

1. 项目拆解与方案选型思路

1.1 艺考真题题库到底在解决什么问题

做题库类产品的人都知道，这类App的核心不是“堆题”，而是在做题场景里把“刷题闭环”做顺。艺考生和普通文化课考生的使用习惯不太一样，他们需要按专业科目分类练习，比如美术类的素描、色彩、速写，音乐类的乐理、听音，舞蹈类的剧目分析，播音类的即兴评述等。真题内容往往包含大量图片素材，题目形式也远比普通选择题复杂，可能有图片题、听力材料题、材料分析题、多选评分题。

所以这个项目的核心需求其实很清晰：考生能按分类找到真题，进入题目详情完成作答，提交后立刻看到答案和解析，同时能对拿不准的题目做收藏和标记。题目详情页是使用时长最高的页面，考生的主要时间都花在这里，因此标题单独把“题目详情实现”拿出来并不夸张。把这一屏的交互、布局、状态和性能做好了，整个App的用户体验就有了基本盘。

1.2 为什么选 Flutter for OpenHarmony 这套组合

这次选型没有太多纠结。项目要求覆盖多个目标平台，已有的一套Flutter业务代码可以直接复用，如果改用原生开发，意味着同样的题目详情交互要写两套，成本直接翻倍。Flutter 在 OpenHarmony 上的价值，是通过适配层把原生的图形渲染和系统能力映射给 Flutter 引擎，使原有业务代码改动很小就能运行在新平台上。

可能有人会担心适配层的稳定性，从我这次实践看，目前已经可以支撑题库类中重度应用。题目详情页里涉及滚动列表、图片加载、状态切换、动态布局这些典型的Flutter能力，实际跑下来表现完全可用。另外，对产品团队来说，Flutter 的声明式UI让页面结构非常直观，题目详情这种状态多、交互密的场景，表达起来比命令式原生代码清晰得多。

1.3 影响范围：谁需要参考这份实战

这次实战记录适合三类人：

1. 团队想快速出 OpenHarmony 版本，业务以表单、资料浏览、题库为主，评估Flutter是否满足需求；
2. 个人开发者在学习 Flutter 跨端适配，需要理解工程配置和常见排坑思路；
3. 产品经理想了解题目详情页的功能边界和交互闭环，方便规划需求。

影响范围不止单端。一套题库业务代码同时覆盖多个平台，后续维护成本低，新增一个考试品类、增加一种题型，工作量都集中在一处。所以这套思路对整个教育工具类项目都有参考价值。

2. 环境准备与工程骨架搭建

2.1 依赖引入与运行环境配置

先说明一下基础环境。Flutter SDK用的稳定版，OpenHarmony对应的适配SDK需要严格匹配Flutter版本，这个匹配关系在适配层的说明里会有对应表。建议创建工程前先把版本号确认清楚，我身边已经有同事因为版本不匹配，在编译阶段折腾了快两天。

操作流程大概是这样：

1. 用Flutter标准命令创建工程；
2. 在工程的pubspec中引入OpenHarmony适配插件；
3. 配置OpenHarmony侧的模块信息文件，声明网络访问、离线缓存等权限；
4. 用构建命令生成OpenHarmony目标产物；
5. 在模拟器或真机上完成首次运行。

特别提醒一句：网络权限必须提前在系统配置文件里申请。题库应用要拉取题目数据，缺少权限的话页面会一直空白，而且报错不太明显。我这次就是先做真机调试，跑起来之后图片全部加载失败，排查了半小时才发现是权限声明漏了。

2.2 题库数据模型设计：一个题到底要存多少字段

题目详情页做得好不好，很多时候不是布局问题，而是数据模型设计的问题。我这次一开始就把题目的数据结构定义得相对完整，后面少改了很多代码。核心模型参考下面这个设计：

class ArtQuestion { final String id; final String category; // 专业分类：如美术、音乐、舞蹈 final String type; // 题型：single / multiple / judge / material final String stem; // 题干文本 final List<String> images; // 题干图片，支持多图 final List<String> options; // 选项列表，判断题也可以映射为对/错选项 final List<int> answerIndexes; // 正确答案索引，单选长度1，多选长度>1 final int score; // 分值，用于多选评分规则 final String analysis; // 题目解析 final String material; // 材料题的材料内容 final int year; // 真题年份 final String source; // 来源院校或考试名称 }

这里有几个关键点需要解释一下。用 answerIndexes 而不是单个 answer 字段，是为了兼容多选和混合题型，材料题虽然选项结构复杂，但也可以用统一的选项列表表达。analysis 建议直接用 Markdown 文本或分段JSON，因为综合题的解析很长，需要标题、段落、甚至配图，原始字符串最灵活。score 单独拎出来，是因为多选和判断题的评分策略不完全一样，后面做题记录和错题统计都会用。

这个模型设计相当于给整个题库功能画了一条边界，列表页、详情页、做题记录、错题本都围绕这一条数据流来转，后续加功能不太会推倒重来。

2.3 目录结构与基础层封装

工程目录我按照业务功能划分得比较清晰：

lib/ pages/ home_page.dart question_list_page.dart question_detail_page.dart answer_card_page.dart models/ art_question.dart answer_record.dart services/ api_service.dart storage_service.dart widgets/ question_image_view.dart option_item.dart analysis_panel.dart utils/ answer_parser.dart format_util.dart

基础层主要封装了两个服务。网络服务统一处理请求地址、超时、错误码和脱机逻辑；本地存储服务负责收藏、做题记录和草稿缓存，这样详情页的收藏按钮和做题状态可以从本地快速读取，不依赖网络接口的实时返回。对题库场景来说，离线可用非常关键，艺考生很多使用场景在画室、路上，信号不稳定，先把本地缓存做好，体验能提升一个台阶。

3. 题库列表与题目详情核心实现

3.1 题库分类与列表页搭建

列表页不用做得特别花哨，重点是分类清晰、切换顺畅。顶部一个分类Tab栏，下面跟一个懒加载列表，数据量大的时候按年份或知识点分批加载。

分类筛选的逻辑处理起来比较直接：每个分类请求对应一个接口参数，切换Tab时重置分页，重新请求数据。需要注意一个细节：快速切换Tab时，上一次请求可能还没返回，结果把旧数据渲染到新分类下面，造成数据错乱。我习惯给每次请求加一个自增序号，返回时检查序号是否还是最新的，不是就丢弃。这个逻辑放在列表请求里通用性很强，也方便后面扩展搜索功能。

列表项展示的核心信息一般是题型标签、年份、科目小类，右侧放一个收藏状态图标。收藏状态建议实时读取本地缓存，不要依赖列表接口返回，因为列表刷新频率低，本地状态反而更准确。

3.2 题目详情页布局：把一屏的答题场景拆成六个区块

题目详情页是整个项目的核心，页面信息量非常大，需要把一屏内容拆清楚。我最终的布局方案是顶部工具栏、题干区、选项区、答题反馈区、解析区和底部操作栏六个区块，整体放在滚动容器里，保证内容多的时候可以上下滑动。

顶部工具栏是返回按钮、当前题目序号和收藏入口，做成固定展示，不跟随滚动。题干区包含题型标签、题目年份分值、题干文本和图片。选项区根据题型动态渲染，这块是交互密度最高的地方。答题反馈区在提交答案后出现，显示对错结论和得分情况。解析区默认收起，答完或点击解析后再展开，避免一进来就刷屏。底部操作栏放答题卡入口、上一题和下一题按钮，固定底部。

这里有个实用的页面结构建议：用列表驱动协议搭建整页布局，比嵌套多个独立滚动组件更容易控制嵌套滚动冲突。每一区块作为列表的一个元素，需要展开解析或切换题目的时候，直接刷新对应区块，这样既保持滚动位置，又不会出现双滚动条那种灾难现场。

3.3 题型差异化的答题交互：一套逻辑覆盖四种题型

艺考真题的题型不少，但交互模型可以归纳为单选、多选、判断、材料题四种。判断本质是二选一；材料题是在题干预区块显示材料，再展示普通的单选或多选子题目。

交互核心是选型状态管理。我定义了一个全局的选择状态容器，记录当前题号的选中索引集合，每次点击选项时更新这个集合，再局部刷新选项区。

单选交互：

• 点击某个选项时，替换当前选中项；
• 再次点击同一项不取消（如果需求允许空答，就要支持取消）；
• 提交答案时直接比较 answerIndexes 的单元素索引。

多选交互：

• 有效选项被高亮，再次点击取消选中；
• 提交时做集合比对。
• 这里需要注意评分规则，院校真题常有多选“选全才给分”“少选给一半分”的差异，实现时可以抽一个评分函数，方便不同科目单独配置。

判断题直接渲染“正确”“错误”两个选项，底层复用二选一的处理逻辑。材料题是在题干下面展示材料内容，然后把材料后的子题按单选或多选处理。

做完这层抽象之后，我最大的体会是：题型差异只是视觉表现不同，核心状态只有“已选索引集合”和“是否已提交”，用一套数据模型就能覆盖，别为每个题型各写一套页面。如果一开始就搞四套页面，后续维护会非常痛苦。

3.4 解析、收藏、做题记录联动

题目详情页除了做题，还要沉淀学习数据。解析和收藏是用户最依赖的两个功能，做题记录则是后面错题本和统计报告的数据基础。

收藏功能我直接落在本地存储表里，键值为题目ID，值为收藏时间。详情页和列表页读取同一张表，这样列表页的星标状态和详情页保持一致。收藏交互上，收藏状态切换后不必弹提示，图标状态变化本身就是反馈。

做题记录建议在提交答案后写入本地，同时异步同步云端。记录内容包括题目ID、选中答案、实际用时、提交时间。这些字段未来都是学习行为统计的原始数据。本地写入失败的概率很小，但如果网络同步失败，需要有重试机制，避免数据丢失。

解析区的展开收起状态单独保存，不跟随题目切换而重置。比如考生做到第二题时，再返回第一题，如果第一题之前展开过解析，应当保持展开状态，这个细节体验差异其实不小。

4. 题目详情页性能优化与体验打磨

4.1 图片加载与素材处理

艺考题干的图片通常包括作品照片、乐谱、场景图，分辨率不低，图片加载和缓存直接决定详情页的流畅度。实战中总结下来有三条原则：

• 图片要开启本地缓存和磁盘缓存，避免重复下载。同样一张作品图，在列表页缩略图和详情页大图之间切换，加载速度差距非常明显。
• 加载大图时用占位容器占住位置，避免图片加载完成后页面高度跳动，这是滚动体验的大忌。
• 加载失败要有备选状态，比如显示一个轻量的“点击重试”占位块，不让用户面对一片空白。

还有一个容易被忽略的技巧：题目图片建议在详情页加载完成后，预加载下一题的图片数据。考生做完当前题，点击下一题的瞬间，如果图片已经提前就位，翻页会感觉非常顺。代价只是多消耗一点流量，对题库App来说是值得的。

4.2 状态管理与局部刷新策略

题目详情页的状态非常多：题号变化、选中项变化、收藏状态、解析展开、提交结果。如果这些状态全都放在页面顶层，任何一个更新都会触发整页重建，性能会明显下降。

我的做法是按区域隔离状态：

• 选项区的选中状态用一个状态对象管理，单独监听刷新；
• 收藏状态单独监听，只刷新工具栏收藏图标；
• 解析区展开状态单独保存，只刷新解析区块内容；
• 题号切换时，才重置整页状态。

这个思路听起来简单，落实的时候要注意一点：初始化时不要把所有监听器都挂在整页状态上，而是把状态对象传递给对应子组件，让子组件自己监听变化。这样每个区块可以最小范围更新，滚动过程中的卡顿也能降到最低。

如果题目详情里有一些高成本的布局计算（比如长文本的高度测量、复杂富文本解析），可以把它的结果缓存起来。同一道题切换几次，解析内容不会变，不必重复计算。

4.3 适配层运行特点与性能调优点

Flutter 跑在 OpenHarmony 适配层上，与原生 Flutter 环境相比有一些差异，实际调试时要特别关注几个方面。

首先是内存表现。题目详情页图片大、数量多，如果页面回收不及时，连续翻二十题就会出现卡顿。建议在详情页释放时主动清除被预加载但未展示的图片缓存，给引擎留出余量。

其次是滚动和动画。在适配层上，复杂的动画效果建议优先使用开关转换和不透明度动画这类廉价效果，避免连续大量阴影和裁剪运算。题库场景里需要的动画本来就不多，控制成本是正确取舍。

还有文本布局。详情页用户在持续高亮阅读场景下，文字量很大，建议避免过度复杂的富文本样式。默认文本样式统一设置，比每个答案区都单独塞几层样式效率高得多。排查卡顿的时候可以优先看解析区是不是在重复解析富文本，基本就是性能瓶颈所在。

5. 常见问题与排坑实录

5.1 编译与运行异常速查

这个阶段整理几个最有代表性的问题，都是我实操中或同事实际遇到过的高频问题。

排查思路要遵循一个原则：先看适配版本是否匹配，再看系统权限是否齐全，最后才怀疑业务代码。很多新手第一步就去调试Dart代码，方向反了。

5.2 布局与交互疑难杂症

• 中英文混排换行错乱，如果正文里出现英文、数字和中文混排，可能出现换行位置难看的现象。解决思路是给文本组件设置合理的断行策略，同时统一使用系统字体族，减少字体回退的消耗。

• 题目详情内嵌图片列表时，横向图片和滚动器的手势容易打架。解决方式是把图片区块设计成单张大图纵向排列，除非是严谨的画作对比场景，才做横向滑动。这个取舍让手势冲突少了大半。

• 键盘顶起问题：简答题有时候需要文本输入，底部固定操作栏会被键盘遮挡。常规思路是监听可视区域变化，键盘弹出时把底部栏隐藏或上推。这个细节一定不要漏，否则在真机上体验很糟。

• 点击态不明显的问题：选项点击后高亮反馈太弱，考生容易以为没点上。可以针对选项容器加轻微缩放和描边变化，不依赖大水花阴影，给页面视觉增加确认感。

5.3 真机调试与发布注意事项

真机调试时，热重载并不像在原生Flutter上那样百分百可靠。适配层涉及原生工程的重新生成，有时候代码改了但页面没变化，这时候需要触发一次热重载或完整重启，而不是反复修改代码。记住一个经验：修改逻辑代码可以热重载，修改系统配置或依赖声明时，直接完整重新构建。

发布阶段注意签名和包名规范。早期版本反复安装，签名混乱会导致卸载重装仍然报签名不一致的问题。建议一开始就沿用统一签名，不要测试阶段用一套签名、上架前又换一套。

5.4 独家避坑：从一次线上问题聊聊缓存一致性

这里分享一个我踩过的比较深的坑。列表页和详情页同时读收藏状态，原本设计是同一个本地表，但上线后发现问题了：列表页的收藏状态不会在返回时立即更新，因为列表页面被缓存在页面栈里，重新可见时没有主动刷新数据。

解决思路是在路由回归时增加刷新回调，列表页被重新可见时重读一次本地收藏表。这个逻辑一定要写在生命周期回调里，不要依赖详情页返回时传参。传参方式第一次可用，一旦页面栈层级变深，参数传递就会丢失状态同步。所以核心原则是：共用状态以本地存储为准，页面只负责展示。这个教训对后续做做题记录同步也有帮助。

6. 项目上线之后还能怎么迭代

6.1 错题本与智能推题

题目详情页沉淀下来的做题记录，最直接的应用就是错题本。按科目、知识点、错误次数分类，考生最需要的是把错题重新做一遍。结合做题记录，还能做简单的智能推题：错得多的知识点提高推送权重，答对的降低频率。这个功能在艺考冲刺阶段是刚需，而底层的记录数据在题目详情实现阶段就已经保存了，后续做只加页面和排序算法即可。

6.2 学习报告与数据可视化

当把做题时间、正确率、连续学习天数记录下来之后，可以给考生生成阶段学习报告。报告可以包含总刷题数、平均正确率、各专业科目强弱分析、相对于前一周的进步幅度。这对教育产品有很强的留存和付费转化价值，会触发考生持续使用。实现层面重视数据展示即可，图表渲染在OpenHarmony适配层上尽量用轻量组件，避免复杂交互图表。

6.3 内容运营与合规管理

题库内容从哪里来、怎么更新，是运营层面要长期关注的问题。题目详情页要支持后台动态下发，包括题干图片更新、答案解析修正、材料题新增。同时要保证内容来源清晰，有版权合规意识，避免不授权内容上架。

做完这个项目再回头看，我个人体会最深的一点是：题目详情页不是简单的UI页面，它是整个题库产品的数据中枢和交互中枢。把数据模型定义清楚、把状态边界画清楚、把性能冗余控制住，后续所有新增功能都是水到渠成的事。如果让我重做一遍，我会在一开始就按这个方式设计，省下的返工时间绝对不止现在这一篇记录的量。