★ FEATURED ARTICLE 这个系列写到现在播放器内核、首页推荐、歌单详情其实都已经过了一遍。第13期为什么单独拎出歌手列表来做因为它在音乐App里是一个看似简单、实际很容易做得粗糙的模块。很多人第一反应是“歌手列表不就是头像加名字排一排嘛”但真做起来就会发现数据怎么建模、头像裁切怎么做、字母索引怎么联动、点击之后怎么把歌手对象安全传到下一个页面每一项都有讲究。尤其是在 Flutter for OpenHarmony 这个组合下面虽然Flutter的UI框架本身跨端一致但底层像素、字体渲染、图片加载策略都跟Android/iOS上有差异不能想当然。这篇文章会把歌手列表从数据模型到UI、从路由跳转到OpenHarmony适配的完整链路拆开讲按你直接抄作业的标准来写。1. 歌手列表在音乐App里到底承担什么角色1.1 为什么这几期要把歌手列表单独拿出来做音乐播放器的用户路径往往不是单一的。用户可能打开首页点推荐歌单也可能进搜索页找某首歌还可能顺着“最近播放”继续听。歌手列表是所有这些路径里一个频繁出现但又容易被忽视的入口。用户在听某首歌的时候大概率会点一下歌手名字进去看看这位歌手还有哪些作品所以歌手列表页不仅要长得好看还要能承载后续的跳转它是歌手维度内容的一个导航中枢。从整个App的结构看我的项目里歌手列表并不是孤立页面它承担了三个职责第一展示歌手的基本信息和作品规模让用户对歌手有个总览印象第二把用户引导到歌手详情页这一步要传递干净的歌手模型对象不能靠拼字符串当参数第三在一些首页推荐模块里歌手卡片和歌手列表页还会互跳所以页面级的跳转参数协议需要提前定好不然后面做首页聚合时又要返工。1.2 前后模块的耦合关系我这次实现前先捋了一下已经完成的页面首页推荐、歌单详情、播放页、搜索页。搜索页里有一个搜索结果会展示歌手歌单详情里每一首歌也带歌手信息播放页的歌曲信息栏同样需要点击歌手跳详情。如果不提前建一个统一的歌手模块这几个地方可能会各写各的跳转逻辑到时候数据格式不统一排查起来会非常痛苦。所以这一期写的歌手列表本质上是把“歌手”这个实体在全局范围内规范化一次。先把歌手模型定下来再把列表页、详情页的路由通道打通之后首页、搜索页、播放页只要复用了这套模型和路由规则所有入口的点击行为都能保持一致。这就是为什么我在项目里宁可多花一点时间做数据层设计也不在前面抢着堆UI。1.3 适合谁来参考如果你在做一个Flutter项目并且要往OpenHarmony设备上跑这一期的参考价值会比较大。当然纯做Android/iOS的读者也能看大部分代码是跨端通用的。建议你已经至少跑通了一个Flutter页面对ListView.builder、FutureBuilder这些基础组件有概念再来读这一期否则代码里的细节会比较多容易晕。如果遇到OpenHarmony环境下特有的编译配置问题可以直接翻到第5章看适配排查部分。2. 歌手数据模型与列表数据加载设计2.1 歌手模型字段到底该定哪些歌手列表显示什么直接决定模型要写什么字段。我一开始走了个弯路把歌手模型设计成了“大而全”把专辑数、歌曲数、粉丝数、简介、头像、背景图全塞进去结果列表页只需要其中一小部分详情页又觉得字段不够最后两头都在改。后来我按照“列表页、详情页、搜索页三端需求交集”来倒推字段才把模型稳定下来。class SingerModel { final String id; // 歌手唯一ID列表页跳详情页传这个就够了 final String name; // 歌手名 final String avatarUrl; // 头像地址 final int songCount; // 歌曲数 final int albumCount; // 专辑数 final String category; // 流派/分类比如流行、摇滚、民谣 final String description; // 简介详情页才会用到列表页可不展示 const SingerModel({ required this.id, required this.name, required this.avatarUrl, this.songCount 0, this.albumCount 0, this.category , this.description , }); factory SingerModel.fromJson(MapString, dynamic json) { return SingerModel( id: json[id]?.toString() ?? , name: json[name]?.toString() ?? 未知歌手, avatarUrl: json[avatarUrl]?.toString() ?? , songCount: json[songCount] ?? 0, albumCount: json[albumCount] ?? 0, category: json[category]?.toString() ?? , description: json[description]?.toString() ?? , ); } MapString, dynamic toJson() { return { id: id, name: name, avatarUrl: avatarUrl, songCount: songCount, albumCount: albumCount, category: category, description: description, }; } }字段设计的一个关键点是id的数据类型。网上很多接口会把ID返回成数字但你千万别在Dart里把id定义成int因为真实的歌手ID很可能超过int范围而且未来要跟字符串类型的接口做联调直接用String最稳妥。我在Dart侧做了一层防御性转换json[id]?.toString()这样无论上游返回数字还是字符串都能兜底。2.2 mock数据先行真实接口后置我在项目最开始阶段并不要什么服务端去提供歌手数据通常都是自己写一个mock类把固定JSON塞进去保证页面开发不被后端阻塞。但mock数据一旦写得不对后面切换到真实数据的时候就会出问题。比如我在mock里用了假的图片链接直接用了本地asset图片切到线上时发现网络图加载失败因为OpenHarmony环境下的网络权限和在浏览器里调试时的行为不太一样。我建议的做法是给数据层做一个抽象接口页面只依赖这个接口不直接依赖具体实现。mock和真实接口都实现同一个接口这样后面切换时页面代码不用动。abstract class SingerRepository { FutureListSingerModel fetchSingers(); } class MockSingerRepository implements SingerRepository { override FutureListSingerModel fetchSingers() async { // 模拟网络延迟 await Future.delayed(const Duration(milliseconds: 600)); // 实际开发中把JSON做成模拟数据文件放asset里 return [ SingerModel(id: 1, name: 林晚, avatarUrl: assets/images/singer_linwan.png, songCount: 42, albumCount: 8, category: 流行), SingerModel(id: 2, name: 陈砚, avatarUrl: assets/images/singer_chenyan.png, songCount: 68, albumCount: 11, category: 摇滚), // 更多... ]; } } class ApiSingerRepository implements SingerRepository { override FutureListSingerModel fetchSingers() async { // 这里写真实的网络请求 final response await http.get(Uri.parse(https://api.example.com/singers)); final data jsonDecode(response.body) as List; return data.map((e) SingerModel.fromJson(e as MapString, dynamic)).toList(); } }这样做的另一个好处是测试和演示的时候可以直接跑mock版本不需要纠结后端接口是否稳定。我在模拟项目X里甚至做了一个简单的可选注入用编译常量控制走哪一个Repository方便不同环境打包。2.3 加载状态的细致处理加载中、空数据、失败重试歌手列表的加载状态是最容易做秃的。很多人用FutureBuilder就只写了等待和成功两个分支结果遇到空数据页面白屏、网络错误直接红屏非常影响体验。我在这个项目里是明确画了三种状态的加载中显示骨架屏数据为空显示一个带按钮的占位页请求失败显示错误提示和重试按钮。骨架屏不一定要用复杂的第三方库我自己写了一个简单的灰色圆块加两条灰色矩形用AnimatedOpacity让透明度循环变化效果就够用了。空数据的页面也别只写一行字给一个“暂无歌手”的文案加一个刷新按钮用户至少知道下一步可以做什么。失败状态同理关键是按钮点击后要能重新触发加载你不能把按钮写成一个摆设。Widget _buildLoadingSkeleton() { return ListView.builder( itemCount: 6, itemBuilder: (context, index) { return Padding( padding: const EdgeInsets.symmetric(horizontal: 16, vertical: 12), child: Row( children: [ Container( width: 56, height: 56, decoration: const BoxDecoration(color: Colors.grey, shape: BoxShape.circle), ), const SizedBox(width: 12), Expanded( child: Column( crossAxisAlignment: CrossAxisAlignment.start, children: [ Container(width: 120, height: 16, color: Colors.grey), const SizedBox(height: 8), Container(width: 200, height: 12, color: Colors.grey), ], ), ), ], ), ); }, ); }这三个状态做完整之后用户体验会上升一个档次。尤其OpenHarmony设备上有些低端机网络加载慢骨架屏能明显降低等待期的焦虑感这是我在实际测试中观察到的。3. 歌手列表页UI实现卡片布局、字母索引、下拉刷新3.1 页面结构和状态管理选型歌手列表页我采用的是比较经典的三段式结构上方一个固定的搜索框区域中间是歌手列表主体右侧浮着A-Z字母索引条。有些App会把字母索引放在列表Header吸顶但我觉得普通列表页不需要搞那么重加上右侧索引条已经足够手指操作了。状态管理方面这一期没有盲目引入复杂框架。列表页的数据是“拉一次、展示、刷新”的简单逻辑用StatefulWidget加FutureBuilder就能搞定。如果整个项目的路由和播放器状态已经用了Provider那你可以顺手用Provider管理歌手列表的loading状态和数据缓存但如果项目里还没引入就不用为了这个页面单独引入Provider。我这边的经验是小页面尽量少依赖重型状态管理保持代码可读优先。代码骨架大致是这样的class SingerListPage extends StatefulWidget { const SingerListPage({super.key}); override StateSingerListPage createState() _SingerListPageState(); } class _SingerListPageState extends StateSingerListPage { late FutureListSingerModel _singersFuture; final ScrollController _scrollController ScrollController(); override void initState() { super.initState(); _singersFuture _loadSingers(); } FutureListSingerModel _loadSingers() { final repo SingerRepositoryFactory.create(); return repo.fetchSingers(); } void _reload() { setState(() { _singersFuture _loadSingers(); }); } override Widget build(BuildContext context) { return Scaffold( appBar: AppBar( title: const Text(歌手), backgroundColor: Theme.of(context).colorScheme.surface, ), body: Column( children: [ _buildSearchBar(), Expanded( child: FutureBuilderListSingerModel( future: _singersFuture, builder: (context, snapshot) { if (snapshot.connectionState ConnectionState.waiting) { return _buildLoadingSkeleton(); } if (snapshot.hasError) { return _buildErrorView(_reload); } final singers snapshot.data ?? []; if (singers.isEmpty) { return _buildEmptyView(_reload); } return _buildSingerList(singers); }, ), ), ], ), ); } }这种写法最直观每个状态对应一个独立Builder方法页面逻辑一眼就能看明白。后面你如果要把歌手列表做成带分类Tab的也可以在这个基础上继续扩展。3.2 歌手卡片布局的细节歌手列表里最核心的视觉单元就是卡片。很多新手会直接用ListTile我只能说能用但不专业。ListTile的高度、内边距都被系统预设了很难做出现代音乐App那种“大图丰富信息”的卡片效果。我更推荐自己组合Container、Row、Column来实现虽然代码稍微多一点但每一个像素都控制在自己手里。我的卡片结构是这样的左边56x56的圆形头像右边两行文字第一行是歌手名字体稍大加粗第二行是歌曲数和专辑数字体偏小颜色偏灰。右侧放一个右箭头图标提示可点击。Widget _buildSingerCard(SingerModel singer) { return InkWell( onTap: () { Navigator.pushNamed(context, /singer/detail, arguments: singer); }, borderRadius: BorderRadius.circular(12), child: Container( margin: const EdgeInsets.symmetric(horizontal: 12, vertical: 6), padding: const EdgeInsets.symmetric(horizontal: 12, vertical: 10), decoration: BoxDecoration( color: Theme.of(context).colorScheme.surfaceContainerHighest.withAlpha(80), borderRadius: BorderRadius.circular(12), ), child: Row( children: [ ClipOval( child: SizedBox( width: 56, height: 56, child: _buildAvatar(singer.avatarUrl), ), ), const SizedBox(width: 12), Expanded( child: Column( crossAxisAlignment: CrossAxisAlignment.start, mainAxisAlignment: MainAxisAlignment.center, children: [ Text( singer.name, maxLines: 1, overflow: TextOverflow.ellipsis, style: const TextStyle(fontSize: 16, fontWeight: FontWeight.w600), ), const SizedBox(height: 6), Text( ${singer.songCount}首歌曲 · ${singer.albumCount}张专辑, maxLines: 1, overflow: TextOverflow.ellipsis, style: TextStyle(fontSize: 13, color: Colors.grey.shade600), ), if (singer.category.isNotEmpty) Padding( padding: const EdgeInsets.only(top: 4), child: Text( singer.category, style: TextStyle(fontSize: 12, color: Colors.grey.shade500), ), ), ], ), ), Icon(Icons.chevron_right, size: 20, color: Colors.grey.shade400), ], ), ), ); }头部圆形裁切这里要注意一个坑。ClipOval如果直接包一个Image.network加载过程中图片还没下载完会先显示一片空白区域圆形里会闪过一大块白。我的改进方案是给头像包一层背景色或者先用本地占位图让裁切后的区域始终有颜色填充这样视觉上更平滑。另一个细节是InkWell的圆角要跟Container的圆角保持一致否则点击时水波纹会溢出到圆角外面看着很粗糙。我在测试里曾因为漏传borderRadius参数导致水波纹是矩形的跟圆角卡片不匹配那个视觉效果真的很劝退。3.3 右侧字母索引从A到Z的联动实现音乐App的歌手列表几乎都有A-Z字母索引它解决的问题是当歌手数量很多时用户能快速定位到指定拼音首字母的位置。实现思路并不复杂核心有两点左侧列表要能够滚动到指定位置右侧字母条要能感知当前滚动到了哪个字母。右侧字母条我用了竖向排列的A到Z文本列表外面包一个GestureDetector监听手指滑动。根据手指的Y坐标计算当前命中的字母然后通过ScrollController把列表滚到对应位置。计算位置的逻辑是先拿到当前手指在字母条内的相对高度除以字母条总高度再乘以26个字母取整就能得到字母索引。void _onIndexDrag(DragUpdateDetails details) { final renderBox _indexKey.currentContext?.findRenderObject() as RenderBox?; if (renderBox null) return; final position details.localPosition.dy.clamp(0, renderBox.size.height); final index (position / renderBox.size.height * (_letters.length - 1)).round(); final targetLetter _letters[index]; final targetIndex _getIndexForLetter(targetLetter); if (targetIndex 0) { _scrollController.animateTo( targetIndex * 72.0, // 前提是你知道每行卡片的固定高度 duration: const Duration(milliseconds: 200), curve: Curves.easeOut, ); } }这里有一个前提条件左侧列表必须使用固定高度卡片才能用卡片高度x目标索引直接算出滚动偏移。如果卡片高度不固定用这个算法滚不准。我在项目里先用72.0这个估算高度跑通后来发现某些歌手名字过长换行后卡片高度变了滚动位置就会偏差。最终我改成了按列表项真实高度累加计算的方式或者干脆给每项固定高度并启用shrinkWrap。如果你不想被这个问题纠缠最简单的做法是让卡片固定高度比如身高固定为80文字溢出部分用ellipsis处理。联动还有个反向过程就是列表滚动时高亮右侧对应的字母。这个用监听ScrollController的滚动事件也能做但计算成本略高。简易实用方案里我用的是列表项首字母去推断当前区段在stop scrolling时更新一下高亮字母。这一期先不做实时高亮等后面如果做通讯录式跳转再补上。3.4 下拉刷新和搜索框的处理歌手列表页的数据虽然不算高频变化但用户可能有下拉刷新习惯。我在Flutter里用了RefreshIndicator但它直接包ListView的时候会出现刷新指示器颜色和背景不匹配的问题。OpenHarmony上这个问题的表现尤其明显指示器有时候会藏到状态栏后面去解决办法是确保ListView始终在Scaffold的body区域内部不要嵌在自定义滚动视图里。搜索框我放在了列表页顶部作用是对当前加载的歌手列表做本地过滤。也就是说初始的数据还是从Repository拉全量歌手用户输入关键词后再内存里用where过滤。这里有个细节过滤的是歌手的name或category字段匹配时要用toLowerCase()统一大小写避免用户输入英文时匹配不上。ListSingerModel _filterSingers(ListSingerModel singers, String keyword) { if (keyword.trim().isEmpty) return singers; final kw keyword.toLowerCase(); return singers.where((s) { return s.name.toLowerCase().contains(kw) || s.category.toLowerCase().contains(kw); }).toList(); }搜索状态如果用TextEditingController监听要注意监听器的释放不然在页面销毁的时候会报内存泄漏警告。我习惯在dispose里把controller释放掉这是Flutter开发者很容易忽略的小问题。4. 从歌手列表进入歌手详情路由与参数传递4.1 直接传对象还是传ID再查一遍我从歌手列表点击卡片进入歌手详情页最直接的想法是Navigator.push直接把SingerModel对象传过去。这个做法对简单的单页跳转是没问题的因为Dart对象在内存里传递非常快也不会牵扯到序列化问题。但一旦页面被系统回收或者跨进程使用直接传对象就不太可靠了比如从通知栏点击进入详情页时你手里可能只有一个歌手ID没有完整的歌手对象。所以我的项目里做了两层设计列表页跳详情页直接传对象仅供正常操作路径使用详情页内部再做一次兜底如果发现对象缺失或者详情数据不是最新的就根据id重新向Repository拉一次。这样两个入口的行为都能得到保证。class SingerDetailPage extends StatefulWidget { final SingerModel? singer; final String? singerId; const SingerDetailPage({super.key, this.singer, this.singerId}); override StateSingerDetailPage createState() _SingerDetailPageState(); }详情页在initState里判断如果widget.singer为空就用widget.singerId去加载。这个设计新增的代码量很少但健壮性一下子提高了不少后续你要做推送通知跳转或者是DeepLink都会舒服很多。4.2 命名路由还是页面直接跳转我在歌手列表这期里选择了命名路由也就是在MaterialApp的routes里把/singer/detail注册好这样后续从搜索页、播放页跳过去时都复用同一个路由配置。命名路由传参的方式是通过arguments字段接收端在取参数时注意做类型校验因为arguments是Object类型直接强转可能会抛类型异常。MaterialApp( routes: { /singer/detail: (context) const SingerDetailPage(), }, ); // 跳转时 Navigator.pushNamed(context, /singer/detail, arguments: singer);这里我踩过一个坑如果SingerModel直接作为arguments传入进入详情页后要立刻把arguments转成SingerModel但这个SingerModel不一定是深拷贝来的页面里如果改了它的某个字段可能会影响上一层列表页的数据。歌手模型在项目里一般不会被单独修改所以问题不大但如果你的模型里有List或Map类型的可变字段最好在详情页里拷贝一份副本再使用。4.3 Hero动画的取舍歌手列表跳到歌手详情页很多音乐App会让圆形头像做一次缩放飞入的转场动画这个效果在Flutter里用Hero组件实现非常顺滑。我在列表页的头像外层包了Herotag用的就是歌手id详情页的头像也用同样的tag这样Flutter会自动找匹配的Hero做动画。但这里有个容易踩的坑如果歌手列表页的头像是列表项里多个实例共用一个tag或者列表页和详情页的tag不唯一Flutter会抛“There are multiple heroes that share the same tag”异常。我一开始给列表页所有歌手头像都写了同一个tag字符串直接崩溃后来改成用歌手id拼接比如singer_avatar_${singer.id}才能确保唯一。Hero( tag: singer_avatar_${singer.id}, child: ClipOval( child: SizedBox( width: 56, height: 56, child: _buildAvatar(singer.avatarUrl), ), ), )同时要记得详情页的头像Hero要保持同样的tag否则动画不会触发。如果某个页面因为头像加载失败而用了占位图它仍然会参与Hero动画这一点不影响。5. OpenHarmony适配与性能优化实录5.1 Flutter for OpenHarmony的构建流程我在项目里用的是社区维护的Flutter for OpenHarmony适配分支整体流程大致是这样先把适配分支的Flutter SDK下载下来再在项目里通过flutter config指定SDK路径之后用常规的flutter pub get和flutter build命令生成OpenHarmony产物。然后在DevEco Studio里打开工程中的ohos目录把生成的Flutter模块作为依赖引入最终打包成hap安装包。一个容易踩的坑是SDK版本和OpenHarmony版本要匹配否则编译期大概率会碰到“接口不存在”之类的报错。我的经验是先看当前分支的README里写着支持的最低OpenHarmony版本再对照自己手头设备的系统版本不要无脑用最新DevEco和最新设备系统否则要被莫名其妙的问题折磨很久。另外需要注意OpenHarmony侧对资源文件的打包路径和Android是有区别的。Flutter的assets在使用时通过AssetManager加载但是OpenHarmony分支的实现细节可能会让asset加载路径多一层前缀我之前把图片资源放到assets/images后引用路径没问题但放到assets/singers/images时在OpenHarmony模拟器上会有偶发加载不出来的情况最后把目录层级拍平后就稳定了。这个建议按你实际适配分支的表现去调整。5.2 列表滚动性能优化歌手列表几百个歌手是很常见的。直接在外层套一个ListView.builder的话Flutter的懒加载机制会自动帮你按需构建性能瓶颈更多出在item内部头像图加载、阴影、圆角、透明度陷阱都会增加绘制成本。我的优化手段有三个。第一列表卡片用Container的decoration来实现阴影不要用Material的elevation属性后者在OpenHarmony分支上有时会产生额外的合成层第二头像裁剪优先用ClipOval少用带有边框的圆形装饰因为ClipOval直接走GPU裁剪路径成本更低第三列表项里的文字颜色尽量用固定的Color值避免用withOpacity去做半透明叠加绘制流程里头半透明颜色会触发额外的混合计算。实测下来最有效的还是给ListView.builder加上itemExtent固定高度。当itemExtent不为空时Flutter滚动引擎可以直接跳过部分布局工作来估算滚动位置列表的滑动流畅度会有非常直观的提升。我上一节提到按72.0计算跳转位置最终也是跟itemExtent配合两边参数一致滚动体验才真正稳。5.3 图片加载与缓存策略歌手头像在网络图片加载失败时会显示一个裂图或者空白这在OpenHarmony设备上特别显眼。我没直接用Image.network的原始能力而是包了一个自己写的拓展方法优先尝试本地缓存缓存没有命中才走网络同时强制设置loadingBuilder和errorBuilder。Widget _buildAvatar(String url) { return Image.network( url, fit: BoxFit.cover, loadingBuilder: (context, child, loadingProgress) { if (loadingProgress null) return child; return Container( color: Colors.grey.shade200, child: const Center(child: CircularProgressIndicator(strokeWidth: 2)), ); }, errorBuilder: (context, error, stackTrace) { return Container( color: Colors.grey.shade200, child: const Icon(Icons.person, color: Colors.grey), ); }, ); }OpenHarmony分支里Image.network的底层实现如果没有支持内存缓存频繁滑动列表会反复触发网络请求我实测下来的确发现同一张头像在短时间内会被重复拉取很多次。解决办法是引入一个简单的内存缓存工具类用Map或LRU策略存住已经加载过的ImageProvider命中直接复用。这样列表回滚时不会看到图片闪一下重新加载的样子。6. 常见问题排查与坑点速查6.1 我实际踩过的典型问题记录这一节我把做歌手列表过程中碰到的、并且网上资料比较少的问题整理成一个速查表你在自己的项目里如果遇到类似现象可以按图索骥。问题列表与排查思路现象可能原因排查与解决歌手列表空白数据加载失败Repository层异常未捕获FutureBuilder只显示了error分支在FutureBuilder的snapshot.hasError分支打印异常堆栈检查网络权限配置头像圆形裁切后中间闪白ClipOval直接包Image图片加载中无占位背景给头像外层加背景色或使用loadingBuilder返回灰底占位列表点击水波纹是矩形InkWell的borderRadius与卡片圆角不一致给InkWell设置与Container一致的borderRadius值为12右侧字母索引点击跳转位置不准卡片高度未固定导致用固定高度计算偏移错误给ListView.builder设置itemExtent或者改为逐项累计高度Hero动画报tag重复异常多个Hero用了相同tag给tag拼接唯一id比如singer_avatar_${singer.id}OpenHarmony安装后图标资源找不到asset路径层级过深适配分支加载有兼容问题尝试把资源目录拍平或调整AssetManifest路径写法列表滚动时卡片白底闪烁卡片出现了不必要的透明度合成层用固定不透明色替代带alpha的颜色值状态栏下方列表内容顶上去RefreshIndicator外层的布局没有给足可用高度让ListView直接作为Expanded的子项避免嵌套在SingleChildScrollView里排查这些问题的顺序我的经验是先看日志有没有异常再看是不是渲染层的问题最后才怀疑数据源。因为Flutter的ErrorWidget有时候会被FutureBuilder吞掉一部分你得在调试模式里跑一遍把所有异常打印出来很多晦涩问题立刻就有线索了。6.2 一个让我花了一晚上排查的诡异问题歌手列表在OpenHarmony真机上偶发点击卡片没反应但在模拟器上却一切正常。当时我怀疑是InkWell的问题、路由的问题、手势冲突的问题排查了一圈都没结果。后来打开日志才发现是某次网络请求失败了页面其实已经切换到了错误状态但错误视图的背景色和列表背景色一样用户误以为页面还在列表所以怎么点都没用。这个经验让我养成了一个习惯每个页面状态之间切换背景色或UI结构要尽量做出明显区分尤其是错误态和空白态不能跟正常态太像。像这种“偶发不可交互”的问题先确认当前屏幕到底渲染的是哪个状态再谈后续排查。日志里打一行当前state名称能帮你省下大量怀疑人生的时间。6.3 实测下来值得保留的小技巧关于OpenHarmony上调试我个人的建议是不要只依赖Hot Reload。我在开发歌手列表时经常用Hot Reload跑UI但OpenHarmony分支对Hot Reload的支持偶尔不稳定会出现界面更新了但状态没重置的情况。遇到这种问题先把应用彻底停止再重新运行不要怀疑自己的代码大概率是Reload链路的问题。列表页性能测试建议在低端真机上跑OpenHarmony模拟器性能虚高很多滚动卡顿在模拟器上是测不出来的。我最后一遍优化就是在一台配置偏低的设备上反复滑动才发现了itemExtent和阴影合成的优化收益。数据量也别只用二三十条试建议直接在代码里生成几百条模拟数据把列表撑到远超一个屏幕的高度这样才能暴露真实性能问题。7. 最后再说一点个人体会歌手列表这个模块做完之后我最大的感触是越是看起来简单的页面越要把数据模型和路由协议先想清楚。你当然可以五分钟堆一个LocalListTile出来但后面搜索页要做歌手入口、播放页要做点击跳转、详情页要做缓存回刷到时候这种草率实现会在每一个环节都给你找麻烦。我这几期反复在强调“先定模型再写界面”就是因为吃过太多返工的亏。实际开发中先把SingerModel、Repository、路由规则这三件套定下来然后任何页面需要歌手数据都走同一套逻辑整个项目的复杂度反而会降低。这一期内容写到这里代码量不算大但里面的坑和数据设计思路应该能帮你在做类似模块时少走不少弯路。
阅读完成 · 觉得有帮助？
