Flutter应用迁移OpenHarmony实战：二手交易App分类筛选模块

最近不止一次被问到一个问题：我手里这套Flutter写的App，到底能不能搬到OpenHarmony上？问的人有做二手交易平台的，有做企业内部工具开发的，也有纯粹想在国产开发板上跑点东西的。我给他们的回答基本都是同一句：能跑，而且思路通了之后，工程量比你想的小得多。这篇文章就以一个二手物品置换App的“分类筛选”功能为例子，完整走一遍Flutter在OpenHarmony上的实战落地过程。从环境搭建到分类导航，从筛选面板到过滤引擎，再到移植过程中真正让我头疼过的坑，都会提到。无论是你正准备把现有Flutter项目适配到OpenHarmony，还是想从零开始做一个支持国产系统的跨端App，都可以照着这条路线走。

先交代一下背景。我做的这个二手物品置换App，核心场景是用户把闲置物品拍照发布，其他用户按分类浏览、按条件筛选，然后线下或邮寄完成置换。业务本身不复杂，但分类筛选是用户每天都要碰的高频入口，必须做得顺手。原本这套代码跑在Android和iOS上，后来因为要覆盖OpenHarmony设备，就顺手做了跨端迁移。整个过程中，分类筛选模块既是业务核心，也是踩坑最多、最能体现Flutter跨端价值的地方，拿它来拆解最合适不过。

1. 为什么把二手置换App的筛选模块迁到OpenHarmony：技术选型逻辑

先说个大前提：OpenHarmony不是“换了个名字的安卓”，它是一个独立的操作系统底座，有自己的软件包格式、自己的应用框架和编译工具链。但好在它保留了标准C/C++和现代Web技术的接入能力，这给Flutter这种自绘引擎跨端移植留了一扇门。社区里已经有人把Flutter引擎移植到了OpenHarmony上，这意味着，我可以在不改动Dart业务代码的前提下，让同一套界面和交互跑在Android、iOS、OpenHarmony三个平台上。

1.1 二手置换场景为什么适合Flutter

二手置换App和那种强依赖系统原生能力的App不太一样。它不需要特别复杂的相机滤镜、不需要激光雷达扫描、也不需要深度的系统设置交互，核心功能就三个：浏览商品列表、按条件筛选、下单沟通。这类业务对UI一致性要求高，列表要能快速滚动，筛选面板要能在各种分辨率下稳定呈现，而这些恰好是Flutter的看家本领。Flutter用Skia自绘渲染引擎直接绘制每一个像素，不依赖系统控件，所以不同平台上的视觉表现基本一致。这对二手交易这种“用户要反复刷商品图”的App来说非常重要，界面统一意味着用户换设备不需要重新适应。

另外，Flutter的Dart语言在数据处理和状态管理上非常顺手。分类筛选这种大量依赖集合操作、条件组合判断的场景，用Dart的集合Api和不可变数据模型写起来很清爽，比在ArkUI里用TypeScript再套一层状态管理要舒服一些，至少对我来说是这样。

1.2 为什么不直接用ArkUI重新写

市面上OpenHarmony原生应用的主流开发方式是用ArkUI，搭配ArkTS语言。这套东西本身也成熟，但如果我重新用ArkUI把整个项目写一遍，等于把Android和iOS的Flutter版本全部推翻重做。人员成本、维护成本、后续功能同步成本都是成倍的。更何况，ArkUI的生态起步晚，社区组件和第三方库远不如Flutter丰富，我需要用的很多筛选组件、图片懒加载库、下拉刷新组件，在ArkUI里找不到现成方案，还得自己封装。

相比之下，Flutter on OpenHarmony的移植方案直接复用现有Flutter代码，筛选模块基本上改改平台相关适配就能跑起来，这也是我选择这条技术路线最核心的原因。

1.3 分类筛选在项目里的定位

在整个App里，分类筛选模块承担了三个职责：给用户提供清晰的商品浏览入口、把海量商品数据快速收敛到用户想要的范围、为后续的服务端查询提供精确的参数。我把它拆成了三块：数据模型层（管理分类树和筛选条件）、界面展示层（分类导航和筛选面板）、状态管理层（整合用户选择并触发过滤逻辑）。后面几节就按这个拆法逐一展开。

2. Flutter for OpenHarmony工程搭建与分类数据模型设计

很多人以为把Flutter项目跑到OpenHarmony上，就是下载一个SDK然后编译打包那么简单。实际做下来，环境配置和工程结构比普通Flutter项目要多花两三天时间。这部分的坑主要在版本对应关系上，建议先花点时间把工具链理顺，不然后面每个编译错误都够你查半天的。

2.1 环境准备：SDK版本与工具链对齐

我使用的方案是社区维护的flutter_flutter和flutter_ohos组合。前者是适配OpenHarmony的Flutter引擎仓库，后者是用于生成OpenHarmony宿主工程的命令行工具。

• 下载适配OpenHarmony的Flutter SDK，解压后放到独立目录，不要和你平时用的Flutter SDK混在一起，两个版本分支不同，混用容易出问题。
• 配置PATH环境变量，让flutter命令指向OpenHarmony适配版本。
• 安装DevEco Studio，这个是OpenHarmony应用的IDE，用来创建宿主工程、编译HAP包、连接开发板调试。
• 确认OpenHarmony SDK版本和Flutter适配版本保持一致，我用的组合是OpenHarmony 4.0 Release配合当时的Flutter稳定适配版。

注意：Flutter on OpenHarmony的版本迭代比较快，不同版本之间API有差异，如果照抄别人的配置发现编译不过，优先查看自己用的Flutter SDK版本和openharmony-sig仓库的适配文档。

配置国内镜像源这一步也很关键，不然依赖下载速度会让你怀疑人生。在环境变量里设置PUB_HOSTED_URL和FLUTTER_STORAGE_BASE_URL指向国内镜像，然后正常执行flutter pub get就能拉取依赖。

2.2 建立OpenHarmony宿主工程

环境配好之后，用flutter_ohos命令行工具在Flutter项目目录下生成OpenHarmony宿主工程：

bash复制flutter create --platforms=ohos my_app

然后进入工程目录，执行flutter pub get同步依赖，再用DevEco Studio打开生成的ohos目录。这里生成的工程结构里，entry模块是应用入口，Flutter引擎跑在entry/src/main/ets/pages/Index.ets的XComponent容器里。简单理解的话，XComponent是一个原生组件承载区，Flutter的UI画面渲染到这个组件里，由OpenHarmony的Ability生命周期驱动。

如果你手里的项目已经有Android/iOS代码，不需要重新创建工程，直接在新版本Flutter SDK下执行flutter-ohos的初始化命令，让它在你现有项目里补一个ohos宿主目录就行。

2.3 分类数据模型：从接口返回的JSON到内存中的树

分类筛选的第一步，是先把后端返回的分类数据变成App里能用的结构。二手置换App的分类是多级树形结构，比如“数码设备 > 手机 > iPhone”、“家用电器 > 厨房电器 > 微波炉”。接口通常返回扁平列表或嵌套JSON，我这边后端返回的是嵌套结构，每个节点包含id、名称、父级id、子节点列表。

我在Dart里定义了两个核心模型：

dart复制class CategoryNode {
  final String id;
  final String name;
  final String parentId;
  final List<CategoryNode> children;
  final int itemCount; // 该分类下的商品数量，用于展示

  CategoryNode({
    required this.id,
    required this.name,
    required this.parentId,
    required this.children,
    this.itemCount = 0,
  });

  bool get isRoot => parentId.isEmpty;
  
  factory CategoryNode.fromJson(Map<String, dynamic> json) {
    return CategoryNode(
      id: json['id'] as String,
      name: json['name'] as String,
      parentId: json['parentId'] as String? ?? '',
      children: (json['children'] as List<dynamic>? ?? [])
          .map((e) => CategoryNode.fromJson(e as Map<String, dynamic>))
          .toList(),
    );
  }
}

筛选条件则用一个独立的模型：

dart复制enum ProductCondition { brandNew, nearlyNew, lightlyUsed, heavilyUsed }

class FilterCondition {
  final String? categoryId;      // 当前选中的叶子分类id
  final RangeValues priceRange;  // 价格区间
  final Set<ProductCondition> conditions; // 成色条件，多选
  final String? region;          // 地区
  final String? tradeType;       // 面交 or 邮寄
  final bool priceSortAsc;       // 是否按价格升序
}

这里有个设计心得：筛选条件不要散落成十几个独立变量，建议打包成一个不可变对象。状态管理里每次修改条件就生成一个新的FilterCondition实例，既方便比较是否发生变化，又能在UI上精准控制哪些位置需要重建。Dart里用copyWith方法实现部分更新，非常顺手。

2.4 数据层接口设计

为了让分类筛选模块不绑定具体后端协议，我加了一层Repository抽象。界面层只依赖Repository接口，不关心数据来自HTTP、本地数据库还是内存缓存。这在OpenHarmony适配阶段非常有用，因为OpenHarmony设备上跑的网络库和Android的OkHttp不是一套体系，我可以在Repository里切换实现，而界面层零改动。

dart复制abstract class CategoryRepository {
  Future<List<CategoryNode>> fetchCategoryTree();
  Future<ProductList> fetchProducts({required FilterCondition condition, int page = 1});
}

HTTP实现用Dio，OpenHarmony适配版的Dio可以用dio_ohos包，兼容性没问题。数据结构解析用json_serializable，减少手写fromJson的工作量。

3. 分类导航双栏布局与筛选面板交互实现

分类筛选界面我参考了主流二手交易App的做法：左栏显示一级分类，右栏显示当前一级分类下的二级分类和商品列表；顶部放一个筛选入口，点击弹出半屏筛选面板。整体布局不复杂，但交互细节非常多。

3.1 左右双栏分类导航

左栏是一个固定宽度的ListView，显示所有一级分类，选中项高亮并联动右栏刷新。

dart复制class CategoryPage extends StatefulWidget {
  @override
  State<CategoryPage> createState() => _CategoryPageState();
}

class _CategoryPageState extends State<CategoryPage> {
  String _selectedCategoryId = '';
  String _selectedSubCategoryId = '';

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Row(
        children: [
          Container(
            width: 96,
            color: const Color(0xFFF5F5F5),
            child: CategoryLeftList(
              selectedId: _selectedCategoryId,
              onSelect: (id) {
                setState(() {
                  _selectedCategoryId = id;
                  _selectedSubCategoryId = '';
                });
              },
            ),
          ),
          Expanded(
            child: ProductGridView(
              categoryId: _selectedSubCategoryId.isNotEmpty
                  ? _selectedSubCategoryId
                  : _selectedCategoryId,
            ),
          ),
        ],
      ),
    );
  }
}

需要注意几个细节。

第一，左栏点击一级分类时，右栏不能直接跳到具体商品，而是应该先展示二级分类导航（也就是子分类的“网格”或“瀑布流”），让用户逐级下钻。这符合二手置换场景的用户心智，用户习惯先看大类再选小类，直接跳到商品列表会让用户失去位置感。

第二，右栏切换分类时，列表要保持在顶部。我给ProductGridView的ScrollController绑定了状态，每次分类变化时执行scrollController.jumpTo(0)，避免出现在类目A看到一半，切到类目B后列表还在中间位置的不自然感。

第三，列表项要加AutomaticKeepAliveClientMixin，保持右栏列表的滚动位置。这个在用户来回切换分类时特别重要，不加的话每次切回来都重新加载图片，体验会非常糟糕。

3.2 筛选面板的动态生成

筛选面板我用了showModalBottomSheet实现，面板内容按筛选条件类型动态生成。价格区间用RangeSlider，成色用ChoiceChip多选，地区用下拉选择器，交易方式用两个单选按钮。所有控件都放在一个可滚动的ListView里，保证小屏设备也能完整展示。

关键点是：筛选面板打开时，要把当前已有的筛选条件回填进去，不能每次打开都是默认值，否则用户之前设置的筛选条件就丢了。我在打开面板时把当前FilterCondition传入，面板里的每个控件初始值都从它读取。

dart复制showModalBottomSheet(
  context: context,
  isScrollControlled: true,
  shape: const RoundedRectangleBorder(
    borderRadius: BorderRadius.vertical(top: Radius.circular(16)),
  ),
  builder: (context) {
    return FilterPanel(
      initialCondition: _currentCondition,
      onApply: (newCondition) {
        setState(() {
          _currentCondition = newCondition;
        });
        _loadProducts();
      },
    );
  },
);

筛选面板内部的确定按钮，需要把用户选择的各项条件组装成新的FilterCondition实例，然后通过回调传给父页面。这里不要直接在面板里修改全局状态，而是让面板做一个纯UI组件，返回用户选择结果，由页面统筹处理，逻辑更清晰。

3.3 二手商品场景特有的筛选维度

除了常规的价格区间，二手商品还有一个非常关键的筛选维度：成色。二手交易里，用户对商品的折旧程度极其敏感，同样一台手机，“几乎全新”和“明显使用痕迹”可能差出一倍价格。所以成色筛选不能简单地用下拉框，我用的是多选标签，允许用户同时选择“几乎全新”和“轻微使用”，在过滤时取并集。这比单选更符合实际搜索习惯，用户往往愿意接受两个相邻成色的商品。

另外一个维度是交易方式：面交还是邮寄。这个在很多二手App里会被忽略，但实际上它直接影响用户筛选的决策。面交适合同城，邮寄适合跨城，如果用户没有明确偏好，就不该默认过滤掉某一种。我的做法是交易方式作为可选筛选，不选时返回全部，选了才过滤。

3.4 空状态与加载状态的交互处理

筛选结果为空是分类筛选模块必须面对的场景。用户设置了很严苛的条件，比如“500元以内 + 几乎全新的苹果手机 + XX区面交”，结果很可能一条数据都没有。这时候界面要优雅地提示，不能白屏。

我的方案是在商品列表组件里内置空状态视图：一张插画、一段说明文字、一个“清除筛选条件”按钮。按钮点击后直接重置所有筛选条件并重新加载数据。这个交互虽然简单，但能把用户从死胡同里拉回来，转化率很可观。

加载状态用常见的骨架屏方案，列表首屏显示灰色占位块，数据回来后再渲染真实图片和文字。Flutter里可以用shimmer库实现骨架屏效果，但注意OpenHarmony适配版本可能不支持这个库，需要确认依赖兼容性。如果不行就自己用AnimatedContainer写一个简单闪烁效果，成本很低。

4. 筛选状态管理与过滤引擎的完整实现

分类筛选的界面只是表象，真正决定用户体验的是背后的状态管理和过滤逻辑。这一节把这两部分拆开讲透，也是整个项目里最核心的代码设计。

4.1 用ChangeNotifier + Provider管理筛选状态

我选择Provider而不是Riverpod，不是因为Riverpod不好，而是因为项目里已有的代码都基于Provider，团队熟悉度高，迁移成本为零。在这个项目里，筛选状态是全局共享的，分类页、筛选面板、商品列表都需要访问，用ChangeNotifier加Provider可以很自然地把状态提升到页面级别。

dart复制class FilterViewModel extends ChangeNotifier {
  FilterCondition _condition = FilterCondition();
  FilterCondition get condition => _condition;

  bool _isLoading = false;
  bool get isLoading => _isLoading;

  List<Product> _products = [];
  List<Product> get products => _products;

  void updateCondition(FilterCondition newCondition) {
    _condition = newCondition;
    notifyListeners();
  }

  void resetCondition() {
    _condition = FilterCondition();
    notifyListeners();
  }

  Future<void> loadProducts() async {
    _isLoading = true;
    notifyListeners();
    
    try {
      final result = await _repository.fetchProducts(condition: _condition);
      _products = result.items;
    } finally {
      _isLoading = false;
      notifyListeners();
    }
  }
}

这里有个细节：loadProducts里的notifyListeners()在最开始和最后各调用一次，是为了让UI能及时切换到加载状态和完成状态。如果你在加载过程中不通知UI，用户在点击筛选确定后，界面会有半秒到一秒的“卡住不动”感，体验非常差。

4.2 本地过滤与远端查询的选择

筛选逻辑存在两种实现方式：本地过滤和服务端查询。两种我都用过，这里直接说结论。

本地过滤适合数据量小（几千条以内）且初次加载已全量拉取的场景。我一开始为了省事，把所有商品一次性拉下来，然后在内存里做过滤。这种方式的好处是响应快，用户拖动价格滑块时能实时看到商品数量变化，交互非常顺手。缺点是数据量一上来就完蛋，而且App启动时全量拉取数据流量消耗大。

服务端查询适合数据量大、需要分页加载的场景。用户点击筛选确定后，App把筛选条件作为请求参数发给后端，后端在数据库层面做过滤，返回当前页的数据。这种方式能应对百万级商品数据，但每次筛选都需要网络请求，会有一小段等待时间。

我最终采用的是混合方案：首次进入分类页，请求当前分类下的商品id列表和简要信息，量不大；本地维护一个商品缓存，过滤时先在缓存里筛，筛不到结果再请求服务端。这样既保证日常使用流畅，又不会因为数据量膨胀而崩溃。分类筛选模块在二手App里的数据规模通常在万级左右，本地过滤完全够用，但设计一定要预留服务端查询的接口，不然业务量上来之后重构成本很高。

4.3 过滤引擎的条件组合逻辑

过滤引擎是整个模块的核心，我把所有筛选条件的判断逻辑收敛到一个纯函数里，方便单元测试：

dart复制bool matchesFilter(Product product, FilterCondition condition) {
  // 分类判断：商品属于选中分类或其子分类
  if (condition.categoryId != null && !product.categoryIds.contains(condition.categoryId)) {
    return false;
  }
  
  // 价格判断
  if (condition.priceRange.start > product.price || condition.priceRange.end < product.price) {
    return false;
  }

  // 成色判断：多选为并集
  if (condition.conditions.isNotEmpty && !condition.conditions.contains(product.condition)) {
    return false;
  }

  // 地区判断
  if (condition.region != null && condition.region != product.region) {
    return false;
  }

  // 交易方式判断
  if (condition.tradeType != null && condition.tradeType != product.tradeType) {
    return false;
  }

  return true;
}

几个判断条件的顺序也讲究。我先判断分类，因为它是最粗粒度的过滤条件，能最快排除掉绝大多数不相关的商品；然后判断价格，这也是高区分度条件；最后判断成色、地区、交易方式这些细粒度条件。虽然在这个函数里顺序对性能影响很小，但如果过滤对象是几千条甚至上万条数据，先判断粗粒度条件能明显减少无效比较次数。

另一个值得说的细节是分类匹配。我传入的categoryId如果是二级分类，那么商品的分类必须包含该id；如果是一级分类，那商品分类包含该一级分类下的任意子分类都算匹配。所以在Product模型里，我用的是List<String> categoryIds，存的是商品从根节点到叶子节点的完整分类路径，这样匹配逻辑就变得非常简单，不需要每次实时遍历分类树判断归属。

4.4 分类树内存遍历与子分类折叠

页面加载时，分类树会一次性从接口拿到。二级分类页需要展示当前一级分类下的所有二级分类，如果二级分类还有三级分类，则需要展示三级分类的入口。这里我实现了一个内存遍历方法，根据当前选中一级分类找到所有子孙分类id，并构建展示数据：

dart复制List<CategoryNode> getChildrenByParentId(String parentId) {
  final result = <CategoryNode>[];
  for (final node in _categoryTree) {
    if (node.parentId == parentId) {
      result.add(node);
    }
  }
  return result;
}

Set<String> collectSubtreeIds(String categoryId) {
  final result = <String>{};
  
  void traverse(CategoryNode node) {
    result.add(node.id);
    for (final child in node.children) {
      traverse(child);
    }
  }
  
  traverse(_findNode(categoryId));
  return result;
}

collectSubtreeIds这个方法的返回值正好给过滤引擎用，把选中的一级分类id展开成所有子孙id集合，然后判断商品分类id是否和这个集合有交集。这样即使用户选中的是顶层分类，也能正确匹配到底层商品。

5. 移植到OpenHarmony的适配记录：插件、权限与编译坑

这一节是踩坑重灾区。Flutter代码本身在OpenHarmony上兼容性还不错，真正出问题的几乎都是插件和工程配置。我把实际遇到的几个典型问题列出来，给大家做个参考。

5.1 图片加载与缓存插件的适配

二手交易App的商品列表离不开网络图片加载。Flutter里最常用的图片加载方案是cached_network_image加flutter_cache_manager。但我在OpenHarmony上运行时发现，这两个库的底层依赖了Android的图片解码能力和文件路径处理，OpenHarmony上不一定完全兼容。

我采用的替代方案是：网络请求用Dio下载图片字节流，然后用Image.memory直接渲染。图片缓存逻辑自己写一个简单的LRU内存缓存，磁盘缓存暂时不做，因为二手App的商品图片热度比较集中，内存缓存命中率很高，足够支撑日常浏览。

dart复制class ImageCacheService {
  static final Map<String, Uint8List> _cache = {};
  
  static Future<Uint8List> load(String url) async {
    if (_cache.containsKey(url)) return _cache[url]!;
    final response = await Dio().get<List<int>>(
      url,
      options: Options(responseType: ResponseType.bytes),
    );
    final bytes = Uint8List.fromList(response.data!);
    _cache[url] = bytes;
    return bytes;
  }
}

如果图片很多，建议加缓存淘汰策略，不然内存容易被撑爆。这个临时方案后期可以替换成适配OpenHarmony的图片库，但现阶段稳定优先。

5.2 权限声明与文件访问

OpenHarmony的权限模型和Android不同，不能直接使用Android的Manifest声明。需要在ohos/entry/src/main/module.json5里声明权限。我踩过的坑是，App访问网络图片时发现图片加载不出来，检查半天发现是ohos.permission.INTERNET权限没声明。

json5复制{
  "module": {
    "name": "entry",
    "requestPermissions": [
      {
        "name": "ohos.permission.INTERNET"
      }
    ]
  }
}

注意：module.json5里的权限名称是OpenHarmony自己的格式，不是Android的android.permission.INTERNET，复制粘贴时要小心。除此之外，如果涉及到读取本地相册，还需要声明ohos.permission.READ_IMAGEVIDEO，但这个在我们这次的筛选功能里用不到，就不展开说了。

5.3 Gradle与SDK版本对齐

OpenHarmony工程的编译走的是DevEco Studio自带的构建工具链，和Android的Gradle构建不完全一样，但命名很相似，容易混淆。我遇到的报错是failed to find target OpenHarmony，排查后发现是DevEco Studio配置的OpenHarmony SDK版本和工程build-profile.json5里声明的compileSdkVersion不一致。

解决办法是打开DevEco Studio的SDK Manager，安装和工程要求一致的SDK版本，然后修改build-profile.json5里的版本号对齐。还有个容易忽略的点：DevEco Studio会自带一个Node.js运行时，如果系统里装了其他版本Node，可能导致构建脚本执行异常。建议使用DevEco Studio自带的Node，不要额外配置。

5.4 真机调试与开发板运行

OpenHarmony适配版Flutter在真机上的调试方式，和Flutter传统方式稍有不同。不能用flutter run直接启动，而是先编译出HAP包，安装到开发板或设备上，然后通过DevEco Studio的调试工具连接。

bash复制flutter build hap --debug

这条命令执行后，会在ohos/entry/build/default/outputs/default目录下生成HAP包。然后用DevEco Studio打开工程，连接设备，点击Run按钮安装并启动。

有一点需要注意：HAP包安装到开发板之后，Flutter UI首次加载可能会有几秒钟的白屏，这是Flutter引擎初始化的正常过程，不是卡死。如果白屏时间过长，就需要检查是否是图片加载或网络请求阻塞了UI线程。

5.5 条件导入处理桥接差异

因为OpenHarmony上还缺少一些Flutter原生插件的适配版本，我在项目里用了条件导入的方式，把平台相关代码隔离起来。具体做法是：在Dart层定义一个通用的接口，接口的两个实现分别针对OpenHarmony和其他平台，通过import 'xxx_ohos.dart' if (dart.library.ohos) 'xxx_ohos.dart' else 'xxx_other.dart'的写法切换。不过实测下来，OpenHarmony对于dart.library.ohos这个条件的识别还算顺畅，写的时候多验证一下即可。

6. 筛选模块在OpenHarmony设备上的实测表现与优化

代码写完之后，真正的考验才刚刚开始。我把这个二手置换App跑在了一块RK3568开发板上，这块开发板在中低端配置里比较有代表性。如果它跑得流畅，那大多数OpenHarmony设备问题都不大。

6.1 滚动性能与帧率表现

RK3568的GPU性能不算强，跑Flutter自绘引擎时，商品列表快速滑动偶尔会出现掉帧。我的优化策略是：

• 图片使用Image.memory渲染后，配合cacheWidth参数，将图片解码精度限制在屏幕宽度的两倍以内，减少GPU上传压力。
• 列表项用const构造函数，减少不必要的Widget重建。
• 使用itemExtent固定列表项高度，让Flutter的布局算法跳过自动测量，直接使用固定高度，这能显著提升长列表的滚动流畅度。
• 减少setState的调用范围，切换筛选条件时只更新商品列表部分，不重建整个页面。

优化之后，快速滑动列表的帧率稳定在50帧以上，对开发板来说已经能接受，真机上更顺滑。

6.2 筛选面板弹出动画的掉帧问题

筛选面板弹出时，我用了showModalBottomSheet默认的动画效果。在开发板上测试时发现，如果当前页面商品列表里有很多高清图片，面板弹出动画会卡顿。原因是动画过程中，底层列表还在重新渲染，GPU负载过高。

解决办法是给商品列表外层套一个RepaintBoundary，把列表区域隔离成独立的绘制层。面板弹出动画时，底层列表不会重新绘制，只需要合成一次画面，动画帧率立刻提升。

dart复制RepaintBoundary(
  child: ProductGridView(products: viewModel.products),
)

这个优化非常简单，但对低端设备的体验提升非常明显，强烈建议加上。

6.3 内存占用与图片缓存策略

开发板内存有限，如果商品列表图片全部加载到内存里，很容易触发OOM。我实现的ImageCacheService用了一个简单的访问计数淘汰策略：每张图片被访问时计数加一，缓存总大小超过阈值后，优先淘汰计数最低的图片。这样既保证了热图片的命中率，又限制了总内存占用。

实测在连续浏览100多个商品、加载了几百张图片后，内存占用稳定在120MB以内，对开发板来说完全合理。

7. 分类筛选模块的可复用经验与后续扩展方向

整个项目做下来，我最大的感受是：Flutter for OpenHarmony这条路已经能走了，但还不算成熟，需要开发者自己带一份“探路心态”。分类筛选这个模块的代码结构，现在可以原样复用到其他OpenHarmony项目里，包括分类树构建、筛选条件模型、过滤引擎、筛选面板这四块，都可以单独抽取成组件库。

后续我想做这几个扩展：

第一是筛选条件的持久化。用户在二手App里经常有固定的筛选习惯，比如只看本城市的邮寄商品、只看某个价格区间、只看某个成色等级。把最近一次使用的筛选条件存到本地，下次打开App自动恢复，能减少用户的重复操作。

第二是价格排序的混合策略。目前是按价格排序或按发布时间排序，后续可以尝试“综合排序”，即同时考虑价格合理性、发布时间新鲜度和成色维度，让排序结果更符合用户预期。

第三是服务端筛选的分页优化。当数据量超过本地缓存能力的上限时，需要把筛选逻辑完全搬到服务端。接口参数已经预留好了，直接传FilterCondition对应的查询参数就行，这块后续只需要补充一个网络请求层，不用改动UI。

最后再分享一个实操上的体会：在写分类筛选这类功能时，先把数据模型定义清楚，再写界面，最后写过滤逻辑，顺序不要乱。我第一版是先写界面再补模型，结果发现界面字段和接口数据结构对不上，来回改了好几轮。后来把FilterCondition、CategoryNode这类模型固定下来，所有代码围绕模型写，开发效率立刻上来了。这套方法论不管是在Flutter、原生Android还是OpenHarmony的ArkUI里，都是通用的。