前阵子接了一个艺考机构的题库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 影响范围谁需要参考这份实战这次实战记录适合三类人团队想快速出 OpenHarmony 版本业务以表单、资料浏览、题库为主评估Flutter是否满足需求个人开发者在学习 Flutter 跨端适配需要理解工程配置和常见排坑思路产品经理想了解题目详情页的功能边界和交互闭环方便规划需求。影响范围不止单端。一套题库业务代码同时覆盖多个平台后续维护成本低新增一个考试品类、增加一种题型工作量都集中在一处。所以这套思路对整个教育工具类项目都有参考价值。2. 环境准备与工程骨架搭建2.1 依赖引入与运行环境配置先说明一下基础环境。Flutter SDK用的稳定版OpenHarmony对应的适配SDK需要严格匹配Flutter版本这个匹配关系在适配层的说明里会有对应表。建议创建工程前先把版本号确认清楚我身边已经有同事因为版本不匹配在编译阶段折腾了快两天。操作流程大概是这样用Flutter标准命令创建工程在工程的pubspec中引入OpenHarmony适配插件配置OpenHarmony侧的模块信息文件声明网络访问、离线缓存等权限用构建命令生成OpenHarmony目标产物在模拟器或真机上完成首次运行。特别提醒一句网络权限必须提前在系统配置文件里申请。题库应用要拉取题目数据缺少权限的话页面会一直空白而且报错不太明显。我这次就是先做真机调试跑起来之后图片全部加载失败排查了半小时才发现是权限声明漏了。2.2 题库数据模型设计一个题到底要存多少字段题目详情页做得好不好很多时候不是布局问题而是数据模型设计的问题。我这次一开始就把题目的数据结构定义得相对完整后面少改了很多代码。核心模型参考下面这个设计class ArtQuestion { final String id; final String category; // 专业分类如美术、音乐、舞蹈 final String type; // 题型single / multiple / judge / material final String stem; // 题干文本 final ListString images; // 题干图片支持多图 final ListString options; // 选项列表判断题也可以映射为对/错选项 final Listint 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 编译与运行异常速查这个阶段整理几个最有代表性的问题都是我实操中或同事实际遇到过的高频问题。现象大概率原因处理思路编译时找不到引擎产物Flutter版本与适配SDK版本不匹配对照匹配表重新安装对应版本运行后白屏或仅显示背景色引擎初始化未成功检查工程模块配置和系统权限开启完整日志查看NAPI报错网络请求全部失败缺少网络权限声明在系统配置中补齐网络权限构建过程极慢或卡住依赖源网络问题配置镜像源或提前缓存依赖文件安装到真机失败签名信息或目标设备架构不匹配确认签名配置和打包产物架构排查思路要遵循一个原则先看适配版本是否匹配再看系统权限是否齐全最后才怀疑业务代码。很多新手第一步就去调试Dart代码方向反了。5.2 布局与交互疑难杂症中英文混排换行错乱如果正文里出现英文、数字和中文混排可能出现换行位置难看的现象。解决思路是给文本组件设置合理的断行策略同时统一使用系统字体族减少字体回退的消耗。题目详情内嵌图片列表时横向图片和滚动器的手势容易打架。解决方式是把图片区块设计成单张大图纵向排列除非是严谨的画作对比场景才做横向滑动。这个取舍让手势冲突少了大半。键盘顶起问题简答题有时候需要文本输入底部固定操作栏会被键盘遮挡。常规思路是监听可视区域变化键盘弹出时把底部栏隐藏或上推。这个细节一定不要漏否则在真机上体验很糟。点击态不明显的问题选项点击后高亮反馈太弱考生容易以为没点上。可以针对选项容器加轻微缩放和描边变化不依赖大水花阴影给页面视觉增加确认感。5.3 真机调试与发布注意事项真机调试时热重载并不像在原生Flutter上那样百分百可靠。适配层涉及原生工程的重新生成有时候代码改了但页面没变化这时候需要触发一次热重载或完整重启而不是反复修改代码。记住一个经验修改逻辑代码可以热重载修改系统配置或依赖声明时直接完整重新构建。发布阶段注意签名和包名规范。早期版本反复安装签名混乱会导致卸载重装仍然报签名不一致的问题。建议一开始就沿用统一签名不要测试阶段用一套签名、上架前又换一套。5.4 独家避坑从一次线上问题聊聊缓存一致性这里分享一个我踩过的比较深的坑。列表页和详情页同时读收藏状态原本设计是同一个本地表但上线后发现问题了列表页的收藏状态不会在返回时立即更新因为列表页面被缓存在页面栈里重新可见时没有主动刷新数据。解决思路是在路由回归时增加刷新回调列表页被重新可见时重读一次本地收藏表。这个逻辑一定要写在生命周期回调里不要依赖详情页返回时传参。传参方式第一次可用一旦页面栈层级变深参数传递就会丢失状态同步。所以核心原则是共用状态以本地存储为准页面只负责展示。这个教训对后续做做题记录同步也有帮助。6. 项目上线之后还能怎么迭代6.1 错题本与智能推题题目详情页沉淀下来的做题记录最直接的应用就是错题本。按科目、知识点、错误次数分类考生最需要的是把错题重新做一遍。结合做题记录还能做简单的智能推题错得多的知识点提高推送权重答对的降低频率。这个功能在艺考冲刺阶段是刚需而底层的记录数据在题目详情实现阶段就已经保存了后续做只加页面和排序算法即可。6.2 学习报告与数据可视化当把做题时间、正确率、连续学习天数记录下来之后可以给考生生成阶段学习报告。报告可以包含总刷题数、平均正确率、各专业科目强弱分析、相对于前一周的进步幅度。这对教育产品有很强的留存和付费转化价值会触发考生持续使用。实现层面重视数据展示即可图表渲染在OpenHarmony适配层上尽量用轻量组件避免复杂交互图表。6.3 内容运营与合规管理题库内容从哪里来、怎么更新是运营层面要长期关注的问题。题目详情页要支持后台动态下发包括题干图片更新、答案解析修正、材料题新增。同时要保证内容来源清晰有版权合规意识避免不授权内容上架。做完这个项目再回头看我个人体会最深的一点是题目详情页不是简单的UI页面它是整个题库产品的数据中枢和交互中枢。把数据模型定义清楚、把状态边界画清楚、把性能冗余控制住后续所有新增功能都是水到渠成的事。如果让我重做一遍我会在一开始就按这个方式设计省下的返工时间绝对不止现在这一篇记录的量。