一、题引

在开始正文前，为了大家能够从本篇博文中，汲取到代码外的东西，即编程思想，我想问问每一个屏幕前的读者，一个问题，那就是：所谓UI，在你看来，可以划分成哪些组成？

二、UI 组成

UI，即 User Interface，译为用户界面，是一个应用提供给用户直接进行查看和操作的内容。
虽然，还不知道大家脑海中对于UI组成，都有什么样的看法？但我这里需要说的是，我认为一个合格的UI，当是由结构、样式和响应有机组合成的，而合格的UI封装也应该就此进行。

UI 实际上就像大家日常生活中居住的房子，一个住起来感到惬意的房间，必然先后经历房壳子和装潢后的房间，这两个截然不同的阶段；在装潢阶段，房间的墙壁或被贴上墙纸、或被刷上墙漆，墙壁上的某些位置上出现的各种插座、开关面板，则是早在搭建房壳子的时候一并完成的，然而它们实际会控制什么样的电器，则是在装潢阶段进行的。

三、UI 封装原则

再问大家一个问题：进行UI公共组件的封装时，是习惯于将结构、样式和响应，杂糅在一起进行封装，还是采用粒度更细化的方式进行呢？

我进行UI封装时，会有一个很明确的行为准则：单一职能原则，一个封装实现体（class或struct），应该只承担粒度从小到大顺序中的某一个职能，比如只负责确定结构、或只负责确定样式。
当然了，前提是所使用的UI开发框架支持相应的粒度抽取。

就鸿蒙应用SDK来说，最新版本的API里，样式已经允许与结构、响应独立，封装在不同的ets文件中，具体如何实现，后文细说；而对于结构和响应，就像造房子一样，墙壁上开关面板的走线管道，只能在墙壁完整造出来前布置好，UI结构封装时必须预留响应的载入通道，通常就是允许传入一个函数。

四、实现 lib_comps

现在，开始对工程里面的 lib_comps 模块进行实现，先看一下该模块下的目录结构：

在 ets 源码目录下，我细分出 components 和 style两个子目录，前者负责UI结构和响应载入通道的封装，后者负责UI样式的封装。

1、封装 UI 样式

进行网页实现的时候，大家经常会用到类似如下的代码：

<div class="container"><p class="normal-text">文本</p>
</div>

html 标签的 class 属性，用于将提前封装在CSS文件中的各种样式进行载入的位置，只有这样，才可能进行样式的独立封装。现在，我可以明确地告诉大家，鸿蒙API 12 之后也能如此进行了：

1.1、attributeModifier 属性

在我看来，该属性是相当重要而有用的，它让鸿蒙 UI 实现的灵活度得到了进一步的增强。

虽然，官方将其解释为“动态设置组件的属性方法”，但我却更愿意将其看待成鸿蒙组件的class属性，因为，在鸿蒙UI实现中，组件样式也是通过属性方法进行设置的，比如下面：

Row(){Text(this.fileName.split(".")[0]).fontSize(25).fontWeight(FontWeight.Regular)Text(this.fileName.split(".")[1]).fontSize(20).fontWeight(FontWeight.Lighter)Text('操作').fontSize(25).fontWeight(FontWeight.Regular).bindMenu(this.OptionMenu())}.width("100%").height("10%").alignItems(VerticalAlign.Center).justifyContent(FlexAlign.SpaceBetween)

那么，传入 attributeModifier 属性里面的自定义AttributeModifier<T>类里面，只设置样式相关的属性，那么，实际上对应的自定义AttributeModifier<T>类就相当是一个css了。

1.2、自定义AttributeModifier<T>类

实现时，要与目标组件的类型相一致，也就是说，如果是要为 column 组件的 attributeModifier 属性赋值，那么泛类型 T 对应的具体类型就是 ColumnAttribute。

通常，应用里面使用的 column 样式不会只有一种，所以，不妨把所有适用于 column 的样式封装，都放在同一份 ets 文件中，从而就有了前面 lib_comps 工程目录结构图里面的 ColumnStyles.ets 文件。

下面，以 RootTopColumn 类为例，讲解如何进行自定义AttributeModifier<T>类的封装：

export class RootTopColumn implements AttributeModifier<ColumnAttribute> {private columnColor: ResourceColor;constructor(columnColor: ResourceColor) {this.columnColor = columnColor;}applyNormalAttribute(instance: ColumnAttribute): void {instance.width("100%").height("100%").backgroundColor(this.columnColor).alignItems(HorizontalAlign.Center).justifyContent(FlexAlign.Start)}applyPressedAttribute(instance: ColumnAttribute): void {}applyFocusedAttribute(instance: ColumnAttribute): void {}applyDisabledAttribute(instance: ColumnAttribute): void {}applySelectedAttribute(instance: ColumnAttribute): void {}}

首先，自定义AttributeModifier<T>类和普通类一样，可以定义字段并通过构造函数进行初始化或赋值；其次，可以一次性封装5种不同的样式，用以针对组件的普通状态、按下状态、获焦状态、不可用状态和选择状态，不同的状态样式由各自对应的 applyXXXXAttribute 方法实现，这些方法统一接受一个 T 类型参数，对于 Column 组件来说，就是 ColumnAttribute；最后，在具体渲染时调用哪一个 applyXXXXAttribute 方法，由 UI 渲染引擎自行判断，开发者无需关心。

实现每个具体的 applyXXXXAttribute 方法时，可以从样式的如下几方面进行：

• 尺寸：width 属性和 height 属性
• 颜色：背景色 backgroundColor 属性，前景色foregroundColor属性
• 对齐方式：alignItem 属性和 justifyContent 属性
• 边距：外边距 margin 属性和内边距 padding 属性
• 边框：boder 属性

当然了，鸿蒙 UI 组件支持的样式属性绝不止这些，只不过上面这些是比较常用的，基本足够应付大多数UI实现所需的样式了。

当对应的 自定义AttributeModifier<T>类，需要用在最外层的容器上，那么尺寸就应该是与屏幕尺寸相同，这里的 RootTopColumn 就是这样的，所以，我才会在 applyNormalAttribute 函数中，将尺寸都设置为百分百；同时，因为预期布局方式是水平居中、垂直局始，所以，只剩下背景色需要通过类构造函数进行传入。

2、封装 UI 组件

由于，鸿蒙API中，UI 结构和响应，没办法彻底解耦，所以，结构和响应就没有按照彻底独立的方式进行封装，而是直接上升到组件维度进行封装。

在组件中，按钮和对话框应该算得上是使用频率很高的组件了，所以，有必要为此封装相应的公共组件，以黑色背景的按钮来说，可以用类似如下的代码进行封装：

@Component
export struct BlackBtn {private buttonWidth: Length = "75%"private buttonHeight: Length = 55@Prop @Require text: ResourceStr = ""private textSize: uiltin">string | uiltin">number | Resource = 20private action?: () => void = () => {}private btnStyle: BlackButton = new BlackButton(this.buttonWidth, this.buttonHeight)build() {Button() {Text(this.text).WhiteText(this.textSize)}.attributeModifier(this.btnStyle).onClick(this.action)}
}

在鸿蒙UI中，所有的组件都是用注解了 Component 的 struct 体承担实现，并且该 struct 体中必须实现 build 方法，具体的 UI 内容实现放在 build 方法里，build 方法里不允许使用非UI表达式，除了少数允许的条件表达式外的一切逻辑表达式，都不允许直接放在 build 方法体里面。

由于注解了 Component 的 struct 体，跟类一样，允许从外部传入参数，所以，具体的内容和样式参数，都可以从外部传入；当然了，也可以为它们都设置初始化值；如果某个属性值必须要外部传入，可以在相应的字段前用 Require 注解。

对话框的封装，也是差不多的形式：

从上面的代码可以看出，封装UI组件的时候，可以根据内容的多寡，决定是否继续划分出更小的组件。

五、总结

受限于篇幅，我这里并没有将 lib_comps 模块的全部实现代码贴出来，大家不妨前往lib_comps仓库，查看具体的实现代码。

总而言之，在封装UI的时候，应当在遵循单一职能的基础上，按粒度从小到大的形式进行内容拆分和实现，一块砖一块砖地码，万里长城才能码得稳、码得好！