Flutter在OpenHarmony上的分页实战：从状态设计到性能优化

最近把手上一个 Flutter 项目往 OpenHarmony 设备上搬，过程中最让我改得头皮发麻的不是环境配置，也不是平台通道，而是看起来最简单的分页。新闻列表、动态流、评论列表，全都在跑老一套的“滚动加载”方案，到了 OpenHarmony 上却冒出各种诡异问题：滚动卡顿、触底不加载、内存涨得飞快。挖完一圈发现，根子不在框架，而在于分页逻辑里数据层、状态层和 UI 层耦合得太紧，换个环境就全露馅了。

这篇文章只聊一件事：在 Flutter for OpenHarmony 场景下，把 Pagination 分页做对。你会看到一个完整的分页列表如何从数据层设计、状态管理到列表 UI 一步步落地，也会看到我在 RK3568 这类硬件设备和 DevEco Studio 工程里踩过的实际坑。无论你是刚开始学 Flutter 的新手，还是已经在做 OpenHarmony 生态适配的开发者，这都是一份可以直接参考的分页实操笔记。

1. 背景与需求拆解：分页在 OpenHarmony 上为什么容易出问题

1.1 Flutter for OpenHarmony 到底成熟到什么程度了

Flutter 在 OpenHarmony 上能跑，这不是什么秘密。社区很早就开始维护 flutter_flutter 的 ohos 移植分支，配合 OpenHarmony SDK，你可以在 DevEco Studio 里把 Flutter 工程编译成 hap 包，然后跑在开发板上。我自己的实测结论是：基础的功能组件，比如按钮、文本、路由，基本都能和 Android 保持一致；但一涉及高性能场景，比如长列表滚动、复杂动画、图片解码，问题就开始浮现了。

这不是说 Flutter for OpenHarmony 的质量不行，而是它的渲染流程和 OpenHarmony 图形栈之间的适配仍在打磨中。ArkUI 和 Flutter 的 raster 线程在底层是两个体系，上层给到 Flutter 的 vsync 信号、GPU 能力又受制于具体设备。RK3568 这类入门开发板的 GPU 只算是够用水平，和手机旗舰芯片完全不在一个量级。所以同一段分页代码，在骁龙平台上流畅，到 OpenHarmony 的入门开发板上就可能肉眼可见地掉帧。理解这一点，你才能接受后面所做的各种“防呆”设计。

1.2 分页不等于“上拉加载更多”，先拆解业务需求

很多人一提分页，第一反应就是“滚动到底部请求下一页”。但实际上，一个生产可用的分页方案至少要覆盖六个状态：首次加载、加载中、加载成功、加载失败、空数据、没有更多。每一个状态都应该有对应的 UI 反馈，否则用户就会觉得 App 卡死了。而在 OpenHarmony 设备上，由于调试工具链相对原始，很多状态异常你是拍脑袋测不出来的，必须在一开始的数据模型里定义清楚。

我习惯把分页需求拆成三层：数据层负责“取数据”，状态层负责“记录当前在哪一页、是否还有下一页、是否在加载中”，UI 层只负责“渲染列表 + 触发加载事件”。三层如果混在一个 StatefulWidget 里，短期看起来很爽，等以后要加下拉刷新、失败重试、离线缓存的时候，你就知道什么叫牵一发动全身了。这篇文章后面的代码就是按照这个结构展开的。

1.3 分页的三个边界情况，最容易翻车的地方

分页常见的三个边界情况，往往是最容易翻车的地方。第一，数据源刚好整除页大小，下一页返回完整一页数据但实际已经没有了；第二，快速滑动时触发多次加载请求，旧请求比新请求后返回，导致数据乱序；第三，下拉刷新与上拉加载并发，新旧数据合到了一起。在主流平台上你可能还能靠设备好、网络快来蒙混过关，但在 OpenHarmony 的低端设备上，任何一次多余的长列表操作，都会直接体现在掉帧上。

所以分页在 OpenHarmony 上不是“能跑就行”，要用状态机把每个请求的状态管死：同一时刻只允许一个加载中的请求，刷新必须重置分页游标，错误必须停留在当前页而不是无限重试。这套思路并不是 OpenHarmony 特有的，但在 OpenHarmony 上如果你不这样做，问题会放大得特别明显，到最后你很难区分是设备的问题还是自己代码的问题。

2. 分页方案选型：页码、游标与滚动加载的取舍

2.1 三种常见分页模式的对比

传统页码、游标分页、滚动加载是三种主流的分页方案，它们解决的问题有交集但不完全一样。传统页码适合后台管理系统、内容可控的静态列表，用户点第 3 页就是第 3 页，服务端实现简单，但移动端很少用，因为用户没有“翻页”的耐心；游标分页适合超大数据集，用一个不重复的键值承接下一次请求，数据插入也不会导致页码偏移，但 API 设计和客户端状态管理都要跟着变；滚动加载是目前移动端最常见的模式，本质是连续页码加触底事件，用户感知最自然，但对请求并发和去重要求很高。

我见过不少团队把三种模式混着做：服务端支持页码，客户端做滚动加载，中间还塞了一层游标缓存。结果就是代码里全是 if 判断，最后谁也维护不动。做 Flutter for OpenHarmony 的项目，建议直接在方案阶段选定一种模式，并且让前后端一起确认参数规则。尤其是 OpenHarmony 设备的功耗和带宽都有限，一次错误的请求策略，对体验的影响比手机上大得多。

2.2 为什么移动端更偏爱滚动触底加载

滚动触底加载之所以统治移动端，核心原因是它把用户的“等待”拆分成了多个小段：每次只加载一批数据，用户滑到哪，数据加载到哪，永远只保留一部分渲染节点在界面上，内存曲线是可控的。而如果你一次性把所有数据丢给 ListView，节点数量会迅速膨胀，尤其在低内存设备上，可能首屏还没滑完，App 就被系统回收了。

在 OpenHarmony 上，这一点更重要。它的后台应用策略和内存回收机制与手机上不完全一样，很多开发板内存只有 2GB 或者 4GB。你要是一页拉 50 条带图片的数据，瞬间要解码的位图内存就已经非常大了。所以我在工程里强制约束 pageSize 为 20，图片走缓存，每批数据只渲染尽量少的可见 item，从源头上控制内存水位。

2.3 数据层选型：网络请求与本地数据库分页

分页除了网络请求，还有一个经常被忽略的场景：本地数据库分页。热词里那些“flutter 内嵌数据库”“本地数据库加后端同步”的讨论，其实最后都会遇到“本地也有几百上千条数据，怎么分页读取”的问题。用 sqflite 或者 drift 这类方案时，标准做法是 LIMIT/OFFSET，或者把自增 ID 当作游标。前者写起来简单，但在数据频繁插入删除时页码会偏移；后者更稳，只是需要你给表加一个稳定的排序键。

我自己的经验是，本地数据库分页和网络分页尽量共用同一个 Repository 接口。上层只关心 fetch(page, pageSize)，至于数据是来自网络还是本地数据库，那属于实现细节。这样在 OpenHarmony 上做离线缓存时，就能很自然地切换数据源，而不需要改任何 UI 层代码。这是我吃了几次亏之后总结出来的硬性设计原则。

3. 实操核心：Flutter for OpenHarmony 分页列表完整实现

终于到代码环节了。我会用最常见的“文章列表”场景，把数据层、状态层、UI 层完整地串起来。这套代码不依赖外部状态管理库，用 Flutter 自带的 ChangeNotifier 就足够说明问题，你把它换成 Provider、Riverpod 也都是顺手的事。

3.1 工程准备与关键依赖

在 OpenHarmony 上跑 Flutter，环境准备和通常的 Flutter 工程稍微有点区别。我这边用的是社区维护的 flutter_flutter 仓库 ohos 分支，拉下来之后把 flutter 命令指到这个分支，然后正常创建 Flutter 工程。工程创建出来后会多一个 ohos 目录，这个目录要用 DevEco Studio 打开，配置 OpenHarmony SDK 后才能构建运行，构建产物是 hap 包，可以直接安装到开发板或者模拟器。

依赖方面，如果只是做分页，Flutter 自带的 widgets 就够用了，不需要额外引入分页库。我过去用过 infinite_scroll_pagination 这个包，接口设计确实好，但在 OpenHarmony 的早期适配阶段，第三方包的兼容性偶尔会出问题，反而不如自己写一套简单的分页控制器可控。所以这篇文章里的分页控制逻辑完全手写，代码量也不大，好处是出了问题你能一眼定位。

3.2 数据模型与 Repository 设计

我建了一个 Article 模型，只保留最核心的字段：

dart复制class Article {
  final int id;
  final String title;
  final String summary;

  Article({required this.id, required this.title, required this.summary});

  factory Article.fromJson(Map<String, dynamic> json) {
    return Article(
      id: json['id'] as int,
      title: json['title'] as String,
      summary: json['summary'] as String,
    );
  }
}

这个模型很简单，但请注意我刻意把 id 做成了 int 并且让它成为排序键。后面的数据去重、边界判断都要靠这个 id 来兜底。接着是 Repository，我定义一个抽象接口，这样网络实现和本地数据库实现可以随时切换：

dart复制abstract class ArticleRepository {
  Future<List<Article>> fetchArticles({
    required int page,
    required int pageSize,
  });
}

这是一切分页的开始。真正的分页细节先藏在 Repository 里，Controller 和 UI 都只通过 fetchArticles 这个方法拿数据。我见过不少项目把 HttpUtil 直接塞进 Widget 里，一旦要加缓存就得推倒重来，这个坏习惯建议趁早改掉。Repository 的具体实现，我这边先写一个模拟网络请求的版本：

dart复制class MockArticleRepository implements ArticleRepository {
  static const int totalCount = 60;

  @override
  Future<List<Article>> fetchArticles({
    required int page,
    required int pageSize,
  }) async {
    await Future.delayed(const Duration(milliseconds: 600));
    final start = (page - 1) * pageSize + 1;
    if (start > totalCount) return [];
    final end = (start + pageSize - 1).clamp(1, totalCount);
    return List.generate(end - start + 1, (index) {
      final id = start + index;
      return Article(
        id: id,
        title: 'OpenHarmony 实战文章 $id',
        summary: '这是文章 $id 的摘要，用来模拟列表内容。',
      );
    });
  }
}

我在 mock 里设置了 60 条数据上限，用来模拟“没有更多”的情况。等会儿你就能看到这套逻辑是怎么处理边界条件的。

3.3 状态层：分页控制器的状态机设计

分页控制器是整个方案的大脑。它的职责是把“页码、是否加载中、是否还有更多、错误信息”统一管住，并且通知 UI 刷新。我把它做成 ChangeNotifier 的子类：

dart复制class ArticleListController extends ChangeNotifier {
  final ArticleRepository _repository;
  final int pageSize;

  ArticleListController({
    required ArticleRepository repository,
    this.pageSize = 20,
  }) : _repository = repository;

  final List<Article> _articles = [];
  bool _isLoading = false;
  bool _hasMore = true;
  String? _error;
  int _page = 1;
  int _requestSeq = 0;

  List<Article> get articles => List.unmodifiable(_articles);
  bool get isLoading => _isLoading;
  bool get hasMore => _hasMore;
  String? get error => _error;

  Future<void> refresh() async {
    _requestSeq++;
    _page = 1;
    _hasMore = true;
    _error = null;
    await _loadInternal(reset: true);
  }

  Future<void> loadNextPage() async {
    if (_isLoading || !_hasMore || _error != null) return;
    await _loadInternal(reset: false);
  }

  Future<void> _loadInternal({required bool reset}) async {
    _isLoading = true;
    _error = null;
    notifyListeners();

    final seq = ++_requestSeq;
    try {
      final data = await _repository.fetchArticles(
        page: _page,
        pageSize: pageSize,
      );
      if (seq != _requestSeq) return;

      if (reset) _articles.clear();
      _articles.addAll(data);

      if (data.length < pageSize) {
        _hasMore = false;
      } else {
        _page++;
      }
    } catch (e) {
      if (seq != _requestSeq) return;
      _error = e.toString();
    } finally {
      if (seq == _requestSeq) {
        _isLoading = false;
        notifyListeners();
      }
    }
  }
}

几个设计点我单独说一下，不然你不理解我为什么写得这么“啰嗦”。

第一，_requestSeq 是请求序号，每一次新的请求都会让序号递增。当旧请求返回时，如果发现自己的序号已经不是最新，就直接丢弃结果，不更新任何状态。这个机制解决的就是快速滑动、下拉刷新瞬间产生的竞态问题。在 OpenHarmony 低端设备上，请求返回到 UI 的链路延迟不稳定，没有这层保护，数据错乱是大概率事件。

第二，refresh 和 loadNextPage 是分开的。refresh 会把页码重置为 1，清空列表，然后重新加载第一页；loadNextPage 只在非加载中、还有更多、没有错误这三个条件同时满足时才继续。三个条件缺一个，触底加载就会被正确拦住。

第三，_hasMore 的判断我用的是“返回条数小于 pageSize”而不是“后端返回 has_more 字段”。这样设计是为了兼容不同的后端实现。如果你的后端明确返回了 total 或者 has_more，也可以把判断逻辑替换掉，但核心思路是一样的。

3.4 UI 层：列表渲染与触底加载

UI 部分我用了一个 StatefulWidget 来持有 ScrollController 和 Controller。先看列表主体的写法：

dart复制class ArticleListPage extends StatefulWidget {
  const ArticleListPage({super.key});

  @override
  State<ArticleListPage> createState() => _ArticleListPageState();
}

class _ArticleListPageState extends State<ArticleListPage> {
  final ArticleListController _controller = ArticleListController(
    repository: MockArticleRepository(),
  );
  final ScrollController _scrollController = ScrollController();

  @override
  void initState() {
    super.initState();
    _controller.refresh();
    _scrollController.addListener(_onScroll);
  }

  @override
  void dispose() {
    _scrollController.dispose();
    _controller.dispose();
    super.dispose();
  }

  void _onScroll() {
    if (!_scrollController.hasClients) return;
    final position = _scrollController.position;
    if (position.pixels >= position.maxScrollExtent - 200) {
      _controller.loadNextPage();
    }
  }
  ...
}

触底判断我留了 200 像素的提前量，也就是用户还没滚到最底部，就已经开始触发下一页的加载。这个提前量可以根据列表 item 的高度来调，但 200 到 300 是一个比较稳妥的范围。如果设成 0，用户会明显感觉到“到底后再等了一下”，体验很差；如果设太大，又会在用户还没滑到底时就提前发起无谓的请求。

item 的构建我用了 ListView.builder，这样 item 只在即将出现在视口内时才被构建，离屏的 item 会被回收复用。列表的末尾会根据状态动态决定展示 loading 指示器还是“没有更多”的提示：

dart复制@override
Widget build(BuildContext context) {
  return Scaffold(
    appBar: AppBar(title: const Text('文章列表')),
    body: AnimatedBuilder(
      animation: _controller,
      builder: (context, _) {
        if (_controller.isLoading && _controller.articles.isEmpty) {
          return const Center(child: CircularProgressIndicator());
        }
        return RefreshIndicator(
          onRefresh: _controller.refresh,
          child: ListView.builder(
            controller: _scrollController,
            physics: const AlwaysScrollableScrollPhysics(),
            itemCount: _controller.articles.length + 1,
            itemBuilder: (context, index) {
              if (index >= _controller.articles.length) {
                return _buildFooter();
              }
              final article = _controller.articles[index];
              return ListTile(
                title: Text(article.title),
                subtitle: Text(article.summary),
                isThreeLine: true,
              );
            },
          ),
        );
      },
    ),
  );
}

_buildFooter 是一个独立方法，它根据 _controller 的状态返回不同的底部组件：

dart复制Widget _buildFooter() {
  if (_controller.error != null) {
    return Padding(
      padding: const EdgeInsets.symmetric(vertical: 16),
      child: Center(
        child: TextButton(
          onPressed: _controller.loadNextPage,
          child: const Text('加载失败，点击重试'),
        ),
      ),
    );
  }
  if (!_controller.hasMore) {
    return const Padding(
      padding: EdgeInsets.symmetric(vertical: 16),
      child: Center(child: Text('已经到底了')),
    );
  }
  return const Padding(
    padding: EdgeInsets.symmetric(vertical: 16),
    child: Center(child: CircularProgressIndicator()),
  );
}

这三个分支分别对应加载失败、没有更多、正在加载三种状态。只要 Controller 状态管得干净，UI 层的分支判断就是水到渠成的事。很多新手写到这里会把判断塞进 itemBuilder 的 if 里，最后只能 return 一个空 widget，错误提示、重试按钮全都无处安放。把它抽成 _buildFooter 之后，代码逻辑和视觉位置就都对了。

3.5 下拉刷新、空态与错误重试的细节

RefreshIndicator 是 Flutter 自带的下拉刷新组件。有一点要特别注意：如果你列表内容不足一屏，RefreshIndicator 可能无法触发下拉手势。解决办法是给 ListView 设置 physics: AlwaysScrollableScrollPhysics()，我已经在代码里加上了。这个看似不起眼的属性，在数据量少的时候直接决定下拉刷新能不能用。

空态我单独处理了一下。当刷新结束后列表为空，_controller.articles.isEmpty，并且不在 loading 状态时，我会显示一个“暂无数据”的占位图。但在实现上要注意，RefreshIndicator 要求它的 child 必须是一个可滚动的组件，所以空态建议放在 ListView 的 item 里，而不是直接替换 ListView，否则下拉刷新又失效了。这个坑我踩过好几次，特地提醒一下。

错误重试放在底部 footer 里，点击后调用 loadNextPage。这里有一个细节：控制器里我在 _error 不为空时禁止 loadNextPage 继续，所以点击重试前需要先把错误清掉。我这里写的版本是保留当前页重试，也就是“停留在失败现场”，因为服务端可能只是临时网络抖动，重试当前页是最安全的。如果你想从第一页重新加载，也完全可以在重试回调里直接调用 refresh()，看业务场景决定。

4. 性能观察：在 RK3568 这档设备上，分页凭什么会卡

代码跑通只是第一步，分页的最终目标是在目标设备上流畅滚动。这里我聊几个和 OpenHarmony 设备强相关的性能点。说句实话，在上面提到的 RK3568 开发板上，分页列表的性能瓶颈往往跟算法关系不大，更多是渲染和内存层面的问题。与其花时间优化分页算法，不如先看看 item 在 GPU 上每一步都是怎么被画出来的。

4.1 ListView.builder 复用机制与渲染链路差异

Flutter 的 ListView.builder 本身是有复用机制的，它只构建视口附近需要的 item。你在 UI 层感受到的“滑动不流畅”，很多时候不是 item 太多，而是每个 item 的构建成本太高。比如 item 里有图片解码、文本过多、阴影过重，任何一项在 GPU 能力有限的设备上都会被放大。OpenHarmony 开发板的 GPU 能力有限，你在开发机上跑 60fps 不代表板子上也能跑到。

我实测过一个带圆角阴影卡片的分页列表，在 RK3568 的板子上滑动时帧时间明显变长。排查下来，罪魁祸首是 Card 的 elevation 阴影在 Flutter 渲染管线里走了离屏合成，每滚动一帧都要重新合成一次。换成不带阴影的普通 Container 后，帧时间立刻降下来。这不是分页特有的问题，但分页列表最容易踩到，因为 item 的复杂性通常比普通页面高。

4.2 图片加载、内存水位与分页批次大小

分页列表最常见的资源消耗就是图片。每加载一页数据，就要解码一批网络图片。Flutter 的 Image.network 如果你不加以管控，会把解码后的位图留在内存里，即使 item 已经被 ListView 回收。我建议在 OpenHarmony 工程里统一走 cached_network_image 这类缓存方案，同时在 Controller 里以页为单位控制解码数量：每次新页加载时，如果内存水位偏高，优先丢弃屏幕外图片的缓存。

如果你做的是“本地数据库+后端同步”那种场景，还要注意一次从数据库查询返回的数据量。LIMIT 200 和 LIMIT 20 对 OpenHarmony 上 SQLite 的耗时差异可能不大，但构建成 Dart 对象并放入列表后，内存差异就很明显了。我的经验是：移动端分页 pageSize 一般 10 到 20，表格或者瀑布流可以到 30 到 50，超过 50 就要重点检查滚动性能了。

4.3 帧耗时分析方法与工具

OpenHarmony 上的 Flutter 性能调试，工具链比 Android 上保守一些，但基本思路一致。你可以启用 Flutter 的 debugProfileBuildsEnabled 和 debugProfilePaintsEnabled，观察每个 item 的 build 和 paint 耗时。如果某一类 item 的 paint 耗时特别高，优先检查是不是有阴影、模糊、裁剪等重合成操作。DevEco Studio 的 Profiler 也可以看 OpenHarmony 应用的整体 CPU 和 GPU 占用，交叉对照能快速定位瓶颈。

另外一个容易被忽略的指标是 vsync 信号。Flutter for OpenHarmony 在部分设备上如果拿不到稳定的 vsync，即使在空列表上滚动也可能出现不规律的掉帧。你可以通过 onReportTimings 记录单帧耗时，把超过 16ms 的帧次数单独统计。如果所有帧都健康，只有加入分页数据后才卡，那问题还在业务层；如果空列表都卡，那你得先检查 Flutter 引擎和 OpenHarmony 图形栈的适配版本了。

5. 常见问题排查与避坑指南

最后这块是我最想写的，因为很多坑我踩过不止一次。分页问题往往表面看起来都一样，实际上每个案例的根因都可能完全不同，所以你需要一套系统的排查方法。

5.1 触底加载触发不了，先检查这四件事

第一，ScrollController 有没有正确挂到 ListView 上，这个最常见；第二，触发条件里是不是用了 maxScrollExtent - 200，如果列表 item 总数太少，maxScrollExtent 本身就接近 0，触发条件可能永远不满足，这时候可以直接判断 position.pixels >= position.maxScrollExtent，或者增加一个“内容不足一屏就自动加载”的兜底；第三，外层是否有 PageView 或者 SingleChildScrollView 把纵向滚动抢走了，导致 Flutter 列表收不到滚动事件；第四，controller 的 hasMore 是否已经被置为 false，如果之前某一页返回数据不足 pageSize，hasMore 就永久失效了，需要在刷新时重置。

在 OpenHarmony 上我还碰到过一种特殊场景：列表外层是一个平台原生的视图容器，滚动事件没有正确传给 Flutter。这种时候触底加载怎么都不会触发，你就要考虑把原生视图和 Flutter 列表拆开，不让它们在一个滚动区域内混布。

5.2 数据重复、页码错乱与竞态处理

页码错乱我见的太多了。最常见的原因就是上面提到的竞态：旧请求返回覆盖新请求。所以我在 Controller 里加入 _requestSeq，用请求序号来识别过期响应。还有一个细节是：不要在 initState 里同时调用 refresh 和 loadNextPage，也不要允许下拉刷新和触底加载并发执行。我的 Controller 里所有加载入口都通过 loadNextPage 内部的三个条件把并发拦住，refresh 虽然会清空数据，但内部的 _requestSeq 保证旧加载的响应不会污染新列表。

如果你发现列表有重复数据，优先检查数据源本身是不是在下拉刷新和上拉加载时重复返回了同一批数据。很多后端在做分页时，如果客户端翻页速度过快，服务端可能返回同一页。客户端可以在 addAll 之前用 id 建一个 Set 去重，虽然不根治，但至少能让 UI 不至于出现明显重复。

5.3 Flutter for OpenHarmony 构建与运行时的几个坑

这个我必须记一笔。我用社区 ohos 分支构建 Flutter 工程时，遇到过依赖版本不对导致依赖包下载失败的问题，这类问题九成是 Flutter 版本和 ohos 分支版本不匹配造成的，经验做法是锁死 flutter 版本，不要轻易用 flutter upgrade。另外如果你把某个第三方 Flutter 插件直接装进 OpenHarmony 工程，而它没有 ohos 平台实现，运行时会直接报 MissingPluginException。分页列表里如果用到 shared_preferences、cached_network_image 这些插件，一定要确认它们有 ohos 适配版本。

还有一个 ArkUI 和 Flutter 混合场景的问题。Flutter 页面在 OpenHarmony 里默认是被一个 ArkUI 页面承载的，如果你在外部用 ArkUI 的 Navigation 控制整个 App 的跳转，Flutter 页面的生命周期和返回手势可能会跟预期不一样，间接影响列表页的滚动体验。我的建议是，如果不是特殊情况，Flutter 页面内部的导航尽量用 Flutter 自己的 Navigator 来管理，外部容器只负责挂载。

5.4 问题速查表

我把上面的问题整理成一张表，方便你排查时直接对照。

这张表基本覆盖了我自己在开发中遇到的主要问题。你照着定位，大多数情况都能快速找到方向。

我做 Flutter for OpenHarmony 的分页踩了这么一圈，最大的体会是：在端侧生态还没有完全成熟的时候，技术选型和代码结构反而要比在成熟平台上更保守。分页这种看似人尽皆知的功能，一旦把数据层、状态层、UI 层拆得清清楚楚，换到什么样的设备上都不会慌；反过来，图省事把请求和状态全写在 Widget 里，平台一换就手忙脚乱。

最后再分享一个小技巧：如果你在 OpenHarmony 上做分页列表，不妨一开始就把 pageSize 留成可配置项，后续在真机上用不同档位实测列表滚动的帧耗时，找到一个“刚好不卡”的批大小。这个参数不值得提前优化，但值得跑起来之后认真调一调。希望这篇实操笔记能帮到你，如果你也正在折腾 Flutter 在 OpenHarmony 上的分页，遇到了什么新坑，欢迎一起交流。