【Day11】开源鸿蒙复盘（2）

参考链接

前言

如果 Day1-6 是把地基打好，那 Day7-10 就是开始盖房子：从 Flutter 自定义组件入门，到跨端封装思路的统一，再到鸿蒙侧复杂业务组件（仿知乎日报轮播 Banner）的完整落地。

这一部分的学习重点是**"组件工程化能力"**：你不只会拼 UI，而是能封装、复用、跨端一致、可维护。

1. Flutter 自定义组件封装基础（Day7-10 1）

1.1 StatelessWidget：无状态组件

无状态组件适合纯展示、无内部可变数据的场景，比如通用按钮、空状态页、标题栏。

基本范式：构造函数参数化 + build 返回组合后的 UI。

复制代码

class CustomButton extends StatelessWidget { final String text; final VoidCallback onPressed; const CustomButton({required this.text, required this.onPressed}); @override Widget build(BuildContext context) { return ElevatedButton( onPressed: onPressed, child: Text(text), ); } }

封装要点：

结构稳定：按钮的布局、颜色、圆角不随业务各写一遍
可变点参数化：文本/回调作为参数传入
复用成本低：业务里一行调用即可

1.2 StatefulWidget：有状态组件

当组件内部需要管理状态（计数器、表单输入、动画展开/收起）时使用 StatefulWidget。

复制代码

class CounterWidget extends StatefulWidget { @override State<CounterWidget> createState() => _CounterWidgetState(); } class _CounterWidgetState extends State<CounterWidget> { int _count = 0; void _increment() { setState(() => _count++); } @override Widget build(BuildContext context) { return Column( children: [ Text("count=$_count"), ElevatedButton(onPressed: _increment, child: Text("add")), ], ); } }

理解关键：

状态放在 State 类里
setState 是唯一的 UI 更新入口
StatefulWidget 本体只负责"创建状态"

1.3 child vs children：新手高频错误

Flutter 的 build 只能 return 一个 Widget 。

想返回多个子控件，必须放在支持 children 的多子容器中：

复制代码

return Column( children: [ Text("A"), Text("B"), ], );

速记法：

child：只能放一个孩子（Container/Center/Padding）
children：可以放多个（Row/Column/ListView）

很多布局报错其实都来自这里。

2. ArkUI 与 Flutter 封装对齐（Day7-10 2）

2.1 ArkUI 组件封装风格

鸿蒙 ArkUI 是声明式 UI：

@Component 声明组件
@Prop 定义外部输入属性
@State 定义内部状态
build 描述 UI

这和 Flutter 一样，本质都是"状态驱动界面"，只是语法不同。

2.2 Flutter 封装风格

Flutter 用 Stateless/Stateful + Widget 组合实现同样的思想：

组件结构稳定
可变部分参数化
事件通过回调透出
主题通过 Theme 系统统一

3. 跨端组件库的工程方法论（本阶段最值钱的结论）

文章通过对比两端封装方式，提炼了跨平台统一的三条方法：

抽象共性接口

用一层抽象定义共性能力（参数、回调、状态含义）。

业务层只依赖接口，不要散落平台判断，否则维护地狱。
平台分流实现

真正差异化的部分放在实现层，通过 Platform 判断或条件编译分支解决。
避免高频跨端桥接

高频交互、动画、手势逻辑尽量留在平台侧，Flutter 侧保持轻 UI。

这对性能和体验影响巨大。

image_cropper 插件鸿蒙化就是标准流程：抽象能力 → 鸿蒙侧补齐实现 → 签名/构建验证。

4.1 为什么选 PageSlider

在 OpenHarmony 里，轮播/翻页的基础组件就是 PageSlider：

自带左右滑动分页能力
Provider 提供页面数据
Controller 可控制跳页、自动切页

非常适合封装 Banner。

4.2 数据模型先行

轮播图数据一般包含图片和标题（也可以扩展副标题、跳转链接）。

复制代码

public class BannerItem { private String imageUrl; private String title; // getter/setter }

先有模型再写 UI，后期扩展字段不会撞墙。

4.3 封装 BannerComponent

核心套路是"固定结构 + 数据注入 + 内部管理逻辑"：

BannerComponent 继承 DirectionalLayout
内部持有 PageSlider 和 dataList
对外开放 setData(List<BannerItem>)
setData 后 initBanner 绑定 Adapter

这样业务层只关心传数据，不关心轮播内部怎么实现。

4.4 自动轮播

用定时任务每 3 秒切换下一页：

current + 1
% size 做循环

并注意：页面不可见时停止轮播，避免耗电和后台无意义刷新。

4.5 指示器（圆点）

底部居中放一排点：

用布局动态生成点数
onPageChanged 时刷新选中态

效果就很接近知乎日报的 Banner 体验。

4.6 点击事件

给每一页注册点击监听，通过 position 回调到外部做跳转或埋点。

4.7 性能优化

文章强调了四点高价值实践：

图片缓存（减少重复请求）
不可见即停轮播
Adapter 复用 item view
网络图压缩/缩略

这些都是"轮播组件能否上生产"的关键。

5. 总结

Day7-10 完成了三层能力升级：

Flutter 侧：从"写页面"升级到"写组件库"
跨端侧：从"分别写两套 UI"升级到"接口抽象 + 分端实现"
鸿蒙侧：从"会用基础组件"升级到"能封装复杂业务组件并稳定运行"

当你掌握了这套路径，后续无论做列表卡片、导航栏、表单控件、或者插件鸿蒙化，都可以按同样套路快速落地。

【Day11】开源鸿蒙复盘（2）

前言

1. Flutter 自定义组件封装基础（Day7-10 1）

1.1 StatelessWidget：无状态组件

1.2 StatefulWidget：有状态组件

1.3 child vs children：新手高频错误

2. ArkUI 与 Flutter 封装对齐（Day7-10 2）

2.1 ArkUI 组件封装风格

2.2 Flutter 封装风格

3. 跨端组件库的工程方法论（本阶段最值钱的结论）

4. 鸿蒙端 Banner 轮播（仿知乎日报首页）实战（Day7-10 3）

4.1 为什么选 PageSlider

4.2 数据模型先行

4.3 封装 BannerComponent

4.4 自动轮播

4.5 指示器（圆点）

4.6 点击事件

4.7 性能优化

5. 总结