，V2 写 @ComponentAppear：同一个生命周期的两种写法)
起因搜状态管理的教程有的示例用State有的用ComponentV2配Local。写法差别不小看起来像两个流派。翻 SDK 才发现不是两个流派是两代并存的体系。而且同一个功能在两代里的实现形态都不一样。一、两代组件基类文件ets/component/common.d.ts。declareconstComponentV2:ClassDecorator((options:ComponentOptions)ClassDecorator);// 第 307 行declareclassCustomComponentV2extendsBaseCustomComponent{// 第 24495 行ComponentV2是类装饰器配的基类是CustomComponentV2。而 V1 那套用的是Component配CustomComponent。两套基类不是继承关系是并行存在的。用Component声明的组件和用ComponentV2声明的组件装饰器体系不互通。二、生命周期一边是方法一边是装饰器这是我觉得差别最大的地方。同一个ets/component/common.d.ts里V1 的生命周期是这样aboutToAppear?():void;// 第 24543 行aboutToDisappear?():void;// 第 24556 行它们是组件基类上的可选方法。你在组件里写一个同名函数框架就调它。而 V2 的生命周期在另一个文件里形态完全变了。ets/api/ohos.arkui.StateManagement.d.tsexportdeclareconstComponentInit:MethodDecorator;// 第 1130 行exportdeclareconstComponentAppear:MethodDecorator;// 第 1144 行exportdeclareconstComponentBuilt:MethodDecorator;// 第 1157 行exportdeclareconstComponentReuse:MethodDecorator;// 第 1177 行exportdeclareconstComponentRecycle:MethodDecorator;// 第 1191 行exportdeclareconstComponentActive:MethodDecorator;// 第 1201 行exportdeclareconstComponentInactive:MethodDecorator;// 第 1211 行exportdeclareconstComponentDisappear:MethodDecorator;// 第 1223 行八个全是MethodDecorator方法装饰器。对照着看V1写aboutToAppear() { ... }靠同名被调用V2写ComponentAppear myInit() { ... }靠装饰器标记方法这不是命名变化是机制变化。方法名随便起靠装饰器认而 V1 里名字必须对。混用的后果是静默的你在ComponentV2组件里写aboutToAppear()它就是个普通方法框架不会调它。不报错只是永远不执行。三、这八个装饰器版本还不齐把它们的since排一下API 23ComponentInit1128 行、ComponentAppear1142 行、ComponentBuilt1155 行、ComponentReuse1175 行、ComponentRecycle1189 行、ComponentDisappear1221 行API 26.0.0ComponentActive1199 行、ComponentInactive1209 行同一组里的八个六个是 API 23两个是 API 26.0.0。Active和Inactive是后来补上的。这两个对应的是组件进入前台/后台这类交互状态变化比单纯的显隐更细。如果你的最低支持版本低于 26.0.0这两个装饰器用不了得退回用别的方式监听。顺带一提同一文件里CustomComponentContext第 1234 行也是API 26.0.0和这两个装饰器一批。四、全局存储也在两个文件里V1 的全局存储类在ets/component/common_ts_ets_api.d.tsdeclareclassAppStorage{// 第 29 行declareclassPersistentStorage{// 第 861 行declareclassLocalStorage{// 第 1011 行V2 的在ets/api/ohos.arkui.StateManagement.d.tsexportdeclareclassAppStorageV2{// 第 125 行since 12exportdeclareclassPersistenceV2extendsAppStorageV2{// 第 247 行since 12注意 V2 那两个的类名里直接带了V2后缀。PersistenceV2还extends AppStorageV2V2 的两者之间是有继承关系的而 V1 的PersistentStorage和AppStorage是两个独立的类。这一点值得留意如果你按 V1 的直觉去理解 V2会以为PersistenceV2是独立的持久化类。实际上它是AppStorageV2的子类能力上有继承叠加。另外PersistenceV2的注释里有个字段值得看第 183 行的PersistenceErrorCallback类型exportdeclaretypePersistenceErrorCallback(key:string,reason:quota|serialization|unknown,message:string,oldValue?:string)void;持久化失败时的回调reason是有限的三个字面量配额、序列化、未知。它没写成枚举而是写成字符串字面量联合类型这是同一套声明文件里的又一种表达方式。五、引用传递也换了形态V1 里父子组件传引用用Link这类装饰器。V2 里换成了两个类第 697 行和第 721 行都是since 20exportdeclareclassBindingT{// 第 697 行exportdeclareclassMutableBindingT{// 第 721 行从装饰器变成了类。Binding和MutableBinding的差别在可变性前者只读绑定后者可写。这和第二节的生命周期变化是同一个方向V2 把 V1 里靠装饰器和约定完成的机制换成了有类型的对象和装饰器标记的组合。MutableBinding存在这件事本身就说明设计上区分了只读引用和可写引用V1 的Link是后一种V2 把它拆成了两个。六、为什么不能混着用把三处对照串起来看混用的风险就清楚了生命周期V1 靠同名方法V2 靠装饰器。在 V2 组件里写 V1 的方法名编译通过、运行不执行存储AppStorage和AppStorageV2是两个类方法签名不保证一致引用传递Link和BindingT是两种机制类型系统不会提示你用错了哪一代三处错误都不会报错只会行为不对。这是这套 API 最容易踩的地方也和这个系列前面几篇的结论一致两代并存的东西混用往往不报错。几处和常见理解不一样的地方状态管理有两代体系V1 配CustomComponentV2 配CustomComponentV2common.d.ts 第 24495 行两套基类并行生命周期形态变了V1 是组件方法aboutToAppear()第 24543 行V2 是八个方法装饰器ComponentAppear等第 1144 行起V2 的八个生命周期装饰器版本不齐六个 API 23ComponentActiveComponentInactive是 API 26.0.0全局存储分布在两个文件里V1 在common_ts_ets_api.d.tsV2 在ohos.arkui.StateManagement.d.tsV2 的类名带V2后缀PersistenceV2继承自AppStorageV2而 V1 的PersistentStorage和AppStorage是两个独立类引用传递从装饰器变成了类BindingT与MutableBindingTAPI 20 起混用不报错三处对照里任何一处用错都是编译通过、行为不对选状态管理方案之前先做一件事确认你参考的示例属于哪一代以及你的最低支持版本够不够。V2 的一部分能力要到 API 26.0.0用了就抬高了门槛。补充说明本篇没有跑通截图。手边没有真机模拟器也没有跑通组件渲染链路所以文中只做声明层面的核对每个结论都标了行号可以自行打开对照。涉及运行期表现的地方我按声明文件与注释原文转述没有替官方补充结论。本系列其他文章我把 HarmonyOS 的折叠屏 API 翻了一遍10 个折叠状态你大概只处理了 3 个我读了 HarmonyOS 的断点声明有 5 个档位高度断点算的其实是宽高比画中画起不来的三种原因设备支持、设置开关、窗口可见是三件事悬浮窗有 6 个状态第 5 个叫在悬浮球里窗口舞台的两套生命周期枚举4 个成员同名其中 2 个的值不一样打点 API 分两代API 8 的老三件套API 19 的新五件套线程优先级有三个枚举HIGH 在其中两个里是 0在另一个里是 2泄漏监测的阈值分前后台前台默认 5后台默认 1
