HarmonyOS7 ImageFilterEffects 教程:透明度与滤镜效果的界面表达
前言

颜色滤镜和透明度更像是视觉调味料,重点不是堆特效,而是服务页面状态。 这也是我很喜欢拿来讲 ArkUI 的一类例子,因为它足够小,却能把状态、布局和反馈三件事串起来。 这篇更适合边读边对照代码,因为很多细节只有放在页面行为里才看得出来。
这篇我会重点从 动画与反馈设计 这个角度往下讲。不是为了把每个属性都讲一遍,而是帮你建立一个更接近真实开发的阅读顺序:先看页面目标,再看状态流,最后再看样式怎么收口。
适用场景
读这段代码时,先看用户会做什么,再看代码为什么这样写,会顺很多。
把它放进真实项目里看,会更容易理解这个案例的价值。围绕“Image 混合模式与 colorFilter”这件事,页面通常不是孤立存在的,它前面连着输入动作,后面连着结果展示。
这一类写法常见在 相册页、商品卡片、用户头像、内容封面 这些页面里。你只要把示例里的交互换成自己的业务文案,再把静态数据换成真实数据源,骨架基本就够用了。

我读这类示例时有个习惯:先不看属性名,先看“用户碰了哪里,页面发生了什么”。这样更容易抓住重点。
另外一个不能跳过的问题是边界。这个案例要是准备落地,第一时间要检查的通常不是样式,而是 状态字段和展示结果有没有保持同一份数据来源,避免页面看起来“能动”但结果不可信。
实现思路
页面最外层通常先用 Column 把主轴定下来,这一步看起来普通,但它决定了后面所有内容是顺着读,还是碎着看。
如果代码里出现了 Scroll,那基本说明作者已经预判到内容会超过一屏。这种处理很实在,至少不会等页面做长了再返工。
像 Row 这种并排容器,真正的价值不是“能横着排”,而是帮你把对比关系直接摆给用户看。数字、标签、刻度、按钮放在一起时,理解速度会快很多。

第 45 篇案例在布局上最值得学的地方,是它没有为了展示组件能力去强行堆内容,而是尽量让每一块区域都有明确职责。这样的代码后面更好拆组件。
完整代码
下面这份代码保留了案例本身的实现思路,但把示例编号替换成了更自然的英文命名。你直接拿去做实验、拆段运行,阅读成本会低很多。
/**
* ImageFilterEffects - Image 混合模式与 colorFilter
*/
import { PRESET_COLORS, generateListItems, PAGE_BG_COLOR, PANEL_BG_COLOR, ACCENT_COLOR, MUTED_TEXT_COLOR } from './types'
@Entry
@Component
struct ImageFilterEffects {
@State isShow: boolean = true
build() {
Column() {
if (this.isShow) {
Scroll() {
Column({ space: 16 }) {
Text('Image 混合模式/colorFilter').fontSize(16).fontColor(ACCENT_COLOR).fontWeight(FontWeight.Bold)
/* 原始图 */
Column() {
Text('原始图像').fontSize(13).fontColor(ACCENT_COLOR).margin({ bottom: 8 })
Column() {
Text('Original Image').fontSize(14).fontColor('#FFFFFF')
}
.width('100%').height(80).backgroundColor('#A0A0A0').borderRadius(8).justifyContent(FlexAlign.Center)
}
.backgroundColor(PANEL_BG_COLOR).padding(12).borderRadius(12)
/* colorFilter 滤镜效果 */
Column() {
Text('colorFilter 颜色滤镜 (概念演示)').fontSize(13).fontColor('#4D96FF').margin({ bottom: 8 })
Row({ space: 8 }) {
Column() { Text('红').fontSize(10).fontColor('#FFF') }
.width(55).height(55).backgroundColor('#FF6B6B66').borderRadius(6).justifyContent(FlexAlign.Center)
Column() { Text('蓝').fontSize(10).fontColor('#FFF') }
.width(55).height(55).backgroundColor('#4D96FF66').borderRadius(6).justifyContent(FlexAlign.Center)
Column() { Text('绿').fontSize(10).fontColor('#FFF') }
.width(55).height(55).backgroundColor('#6BCB7766').borderRadius(6).justifyContent(FlexAlign.Center)
Column() { Text('紫').fontSize(10).fontColor('#FFF') }
.width(55).height(55).backgroundColor('#9B59B666').borderRadius(6).justifyContent(FlexAlign.Center)
}.width('100%').justifyContent(FlexAlign.SpaceEvenly)
Text('colorFilter: [R,G,B,A] 矩阵着色')
.fontSize(11).fontColor(MUTED_TEXT_COLOR).margin({ top: 6 })
}
.backgroundColor('#E8F4FD').padding(12).borderRadius(12)
/* opacity 透明度 */
Column() {
Text('opacity 透明度效果').fontSize(13).fontColor('#FFA500').margin({ bottom: 8 })
Row({ space: 8 }) {
Column() { Text('1.0').fontSize(10).fontColor('#FFF') }
.width(50).height(50).backgroundColor('#FFA500').borderRadius(4).justifyContent(FlexAlign.Center)
Column() { Text('0.7').fontSize(10).fontColor('#FFF') }
.width(50).height(50).backgroundColor('#FFA500').opacity(0.7).borderRadius(4).justifyContent(FlexAlign.Center)
Column() { Text('0.4').fontSize(10).fontColor('#FFF') }
.width(50).height(50).backgroundColor('#FFA500').opacity(0.4).borderRadius(4).justifyContent(FlexAlign.Center)
Column() { Text('0.1').fontSize(10).fontColor('#FFF') }
.width(50).height(50).backgroundColor('#FFA500').opacity(0.1).borderRadius(4).justifyContent(FlexAlign.Center)
}.width('100%').justifyContent(FlexAlign.SpaceEvenly)
}
.backgroundColor('#FFF8E8').padding(12).borderRadius(12)
}.width('100%')
}
}
Text('Image 混合模式')
.fontSize(12).fontColor(MUTED_TEXT_COLOR).margin({ top: 12 })
}
.width('100%').height('100%').backgroundColor(PAGE_BG_COLOR).padding(16)
}
}
逐段读代码
第一处关键代码
@State isShow: boolean = true
这一行先别急着略过,它通常就是页面状态的起点。后面很多显示内容,都会跟着它一起变化。 对图片类页面来说,最好顺手看看它后面有没有连到占位、失败态或者尺寸处理。
第二处关键代码
.width('100%').height(80).backgroundColor('#A0A0A0').borderRadius(8).justifyContent(FlexAlign.Center)
如果说状态决定页面会不会动,那这种写法决定的就是页面动起来以后像不像一个成品。 对图片类页面来说,最好顺手看看它后面有没有连到占位、失败态或者尺寸处理。
第三处关键代码
.backgroundColor(PANEL_BG_COLOR).padding(12).borderRadius(12)
它不一定改变核心逻辑,但会直接影响用户对页面“是否完整”的第一感受。 对图片类页面来说,最好顺手看看它后面有没有连到占位、失败态或者尺寸处理。
容易忽略的细节
这段代码没有刻意堆很多事件,但状态变化的路径依然很清楚:用户操作,数据改动,页面刷新。
对图片类页面来说,交互往往不只是点一下这么简单,还包括加载中、加载失败、尺寸适配这类“非点击型反馈”。
读到交互段时,不妨多问一句:这个结果有没有唯一数据源?很多页面后面难维护,就是从这里埋下的。
一个很实用的改法,是尽早把状态分层:谁负责输入,谁负责展示,谁负责兜底。只要这一步做清楚,后面页面再长,build() 也不至于越来越乱。
再往前走一步
真要把这个案例拿去改业务页面,我会按下面这个顺序动手:
- 把演示用的静态数据替换成真实数据源,别等接口接进来以后再改页面结构。
- 把重复出现的卡片、标题栏、结果区提成小组件,后面加状态会轻松很多。
- 提前补上异常态,比如空值、失败态、禁用态、超范围输入,否则示例一进业务就会露怯。
- 如果是图片页,我会先补齐占位图、失败态和尺寸规范,因为视觉问题一旦放到最后处理,代价通常更高。
这里最容易被忽略的一点,是 状态字段和展示结果有没有保持同一份数据来源,避免页面看起来“能动”但结果不可信。 这个问题。很多示例在静态数据下看不出毛病,一接真实状态就开始暴露问题,所以这一步最好趁早做。
容易被忽略的小地方
有些细节在第一眼看代码时很容易被跳过去,但它们往往决定了页面是不是耐改。
@State不是装饰器样板,它决定了哪些数据变化后会重新驱动画面。- 对于 Image 类页面,我会特别留意文案反馈是不是跟着用户动作一起变化,因为这直接影响页面有没有“会说话”的感觉。
这些东西单看都不复杂,组合在一起,才是一个案例真正的完成度。
写在最后
把这篇读透之后,你再回头看同类控件,会更容易判断哪些是核心参数,哪些只是表面样式。
把这份案例读成“一个可以继续长大的页面骨架”,你后面改业务时会轻松很多。
更多推荐

所有评论(0)