简介
Swift Macro 在 Swift 5.9 版本中正式引入,且需配合 Xcode 15 使用。Swift Macro 作为一种新的设计方法,致力于帮开发者降低编写重复代码的繁琐,以更为简洁优雅的方式去实现。
在 OC 中,有大家熟知的宏 #define,但是在 Swift 5.9之前我们无法像使用 OC 一样去定义宏,在 Swift 中没有这种宏的概念,只能通过静态方法去模拟宏从而达到目的。
OC 宏的实现原理是纯文本的替换,在编译之前通过预处理器帮我们对标记了 #define 的表达式进行展开替换,但是纯文本替换会产生一系列问题,比如 命名冲突,类型检查,调试问题等。
#define SQUARE(x) x * x
// ❌ 展开后逻辑不符
int a = 5;
int result = SQUARE(a + 1); // 结果为 5 + 1 * 5 + 1 = 11
// ❌ 缺少类型检查
int result = SQUARE("BiliBili") // 结果为 BiliBili * BiliBili
和 OC 的不同之处在于 Swift Macro 选择在编译时进行展开以及替换,一方面是可以在编译时进行类型安全检查,另一方面更大程度的提高了宏编译对开发者的反馈力度,宏的调试和错误都可以被开发者所感知。
相对于传统的预编译,编译时 Swift Macro 具有感知上下文的能力,对上下文的理解,从而可以产生更多样化的代码扩展和逻辑处理。
例如通过 Swift Macro 构造一个宏:为某个类自动生成 Int32 类型 的 age 成员并赋值
public macro DefaultAge(_ age: Int32)
@DefaultAge(12.0)
class Test {}
当我们将 Double 类型的参数 12.0 传入 宏里,在编译展开阶段就会报错,此时编译器会把错误抛出,并视为编译错误
class Test {
var age: Int32 = ❌
// Cannot convert value of type 'Double' to specified type 'Int32'
}
Swift Macro 是在 Swift 语言特性的基础上设计出来的产物,编译时对宏进行有效性的检查,可以让开发者在 Swift 宏使用过程中,更容易的发现错误,更方便的进行调试。
原理
Swift Macro 大部分是外部宏类型 #externalMacro,它不由当前程序执行,而是在沙盒的某个独立应用程序内,交由 Compiler Plug-in 去处理宏的展开和替换。
以 @DefaultAge 为例,宏的声明分为两个部分,角色声明和方法声明。方法声明则固定通过 macro 和 #externalMacro 关键词去修饰,而角色定义可以分为很多种,后续会展开介绍。
// 宏的角色定义
@attached(member, names: arbitrary)
// 宏的方法定义
public macro DefaultAge(_ age: Int32) = #externalMacro(
module: "宏实现的模块",
type: "宏实现的类型"
)
因为宏是通过 Package 去管理的,所以这里的 module 也就是包的模块名,而 type 则是当前宏实现的具体类型。
外部宏的展开进程是独立的,在一个安全的沙盒环境下进行,与外界的其它信息进行隔绝。在编译器执行 和 Swift 宏有关的代码时,编译器会调用宏的实现来展开宏。下面从 @DefaultAge 的定义到展开,大概阐述整个过程。
Test 类添加 @DefaultAge
@DefaultAge(12)
class Test {
var name: String = "BiliBili"
}
1.编译器读取当前类,并拿到内存中转化的 AST 语法树,当前 AST 仅有一个成员 name
ClassDecl
-- MemberBlock
-- MemberBlockItemList
-- MemberBlockItem
-- name (String) == "BiliBili
2.将上述AST 传入宏的作用域,发送给编译器插件 Compiler Plug-in (只会传 AST,不包含其它代码)
3.编译器插件通过宏的声明,去宏的模块内找到该宏的实现,获取当前宏返回的AST,且在这个展开过程中,编译器会去检查 age 的有效性,比如类型是否正确等
public struct DefaultAgeMacro: MemberMacro {
public static func expansion(of node: AttributeSyntax,
providingMembersOf declaration: some DeclGroupSyntax,
conformingTo protocols: [TypeSyntax],
in context: some MacroExpansionContext) throws -> [DeclSyntax] {
var res: DeclSyntax?
let name = node.arguments?.firstToken(viewMode: .sourceAccurate)?.text
if let name {
res = """
var age: Int32 = \(raw: name)
"""
}
return [res].compactMap { $0 }
}
}
// 通过字符串字面量语法创建并返回的包含 age 的成员声明,得到 age 的 AST
// 最终这个AST对应的代码是:var age: Int32 = 12
4. 编译器拿到新增的 AST后,将其添加到原始 AST 中,最终生成新的语法树
ClassDecl
-- MemberBlock
-- MemberBlockItemList
-- MemberBlockItem
-- name (String) == "BiliBili"
-- MemberBlockItem
-- age (Int) == 12
5. 编译器插件将新的语法树序列化后插入到源码中,参与后续编译
过程图示:
经历过这样一个简短的过程,可以得出几个结论:
1. Swift Macro 的运行作用域是封闭的,隔绝外界无关信息,避免双向信息的交流和获取,禁止在宏内部做出一些对外界干扰的行为
2. Swift Macro 对代码原环境的上下文感知是有限的,只感知和宏有关的 AST,我们无法对原始的 AST 做出修改和删除,从而印证了 Swift Macro 是一个增量的行为
3. Swift Macro 会在宏的展开阶段对代码进行有效性检查,保证宏的正确性和可预测性
类别
在对宏的有了一个初步的认识后,了解一下宏的各个角色定义有什么不同。Swift 宏分为目前分为两类,独立宏和绑定宏。
独立宏
独立宏以 # 开头,创建一个表达式或者声明。独立宏类似平常开发中的纯函数,这里独立的意思是不需要感知外部环境的上下文,仅仅靠它自己就可以独立运行。
独立宏又细分为表达式宏和声明宏。
1.1 @freestanding(expression)
表达式宏:定义一个可以在表达式上下文中使用的宏,通常返回一个表达式或者值,类似系统中的 #function。使用方式一般是以字符串插值嵌入到某个表达式中,生成新的表达式,并作为表达式的一部分参与运算。
打印当前函数信息
@freestanding(expression)
public macro function()
func logInfo(function: String = #function, lineNum: UInt = #line) {}
1.2 @freestanding(declaration)
声明宏:定义一个可以在声明上下文中任何地方使用的宏,和表达式宏不同的是,它返回的是一个完整的声明,且永远不会产生值。类似系统中的 #warning,它还可以为我们声明整个类,枚举,属性等。
警告声明
@freestanding(declaration)
public macro warning(_ message: String) -> ()
#warning("插入一句警告")
生成一个方法
@freestanding(declaration)
macro LogFuction() = #externalMacro(module: "Macro", type: "LogFuction")
// 原代码
class Test {
@LogFuction
}
// 展开后
class Test {
func log() {
print("log info")
}
}
在日常开发中,我们经常会使用到色值转换,通过 ColorWithXXX 获得一个色值
func ColorWithString(_ hexString: String) -> Color
func ColorWithHex(_ hex: UInt) -> Color
但是从设计稿复制黏贴并不能保证色值的正确性,这就可能会造成运行时的崩溃。那么此时独立宏就有了用武之地,我们可以在宏的实现内部加入色值的校验。
16进制色值正则校验
@freestanding(expression)
public macro Color(_ value: UInt) -> Color
public struct Color: ExpressionMacro {
public static func expansion(
of node: some FreestandingMacroExpansionSyntax,
in context: some MacroExpansionContext
) -> ExprSyntax {
// 正则判断
// 1.正确 return color
// 2.错误 throw error
}
}
#Color(FFFFFF) // true
#Color(123456) // ❌ invalid color value
这样我们就可以在编译时抛出异常,避免因为少了一个字符而引发的cs。
绑定宏
以 @ 开头,和独立宏不同的点在于,它为我们提供了扩展 Swift 代码的能力,基于参数上不同角色的转换为我们创建或者扩展声明。比如可以对一个类,新增方法,新增属性,新增协议等
2.1 @attached(peer)
attached(peer) 是在原方法的作用层级上,对原有方法的增强,比如函数的重载。日常开发中,我们会在某些性能监控场景计算函数耗时,在方法前后记录当前时间戳计算差值。那么 attached(peer) 就可以提供overloaded 的能力,在原有方法的基础上,为我们自动生成一个新的方法。
函数的重载
@attached(peer, names: overloaded)
public macro NeedAPM() = #externalMacro(module: "Macro", type: "NeedAPM")
public static func expansion(of node: AttributeSyntax,
providingPeersOf declaration: some DeclSyntaxProtocol,
in context: some MacroExpansionContext) throws -> [SwiftSyntax.DeclSyntax] {
guard let functionDecl = declaration.as(FunctionDeclSyntax.self) else {
fatalError("非函数类型")
}
var functionSyntax: FunctionDeclSyntax?
if let body = functionDecl.body {
functionDecl = """
func \(functionDecl.name)(_ needApm: Bool) {
if needApm {
// 记录开始时间
}
\(body.statements)
if needApm {
// 记录结束时间 数据处理
}
}
"""
}
return [functionSyntax].compactMap { $0 }
}
// 原代码
class Test {
@NeedAPM
func test() {}
}
@NeedAPM 宏代码展开
class Test {
@NeedAPM
func test() {}
func test(_ needApm: Bool)
}
如此一来,宏会帮我扩展出一个新的方法 func test(_ needApm: Bool),使用场景就由开发者决定。
2.2 @attached(accessor)
@attached(accessor)是对属性访问器的扩展,主要为某个属性扩展 setter,getter,didSet,willSet方法。可以把存储属性变成计算属性,通过 _Property 去接收;还可以通过这种方法去自己管理 Strcut / Class 的 Copy on Write,用来提升内存效率。
@attached(accessor, names: named(set), named(get))
public macro NameMacro() = #externalMacro(module: "Macro", type: "NameMacro")
public static func expansion(of node: AttributeSyntax,
providingAccessorsOf declaration: some DeclSyntaxProtocol,
in context: some MacroExpansionContext) throws -> [AccessorDeclSyntax] {
return [
"""
set {
_\(identifier) = newValue
}
""",
"""
get {
return _\(identifier)
}
"""
]
}
// 原代码
class Test {
private var _name: String = ""
@NameMacro
var name: String
}
@NameMacro 宏代码展开
class Test {
private var _name: String = ""
@NameMacro
var name: String {
set {
_name = newValue
}
get {
return _name
}
}
}
又或者通过该宏来达到类似 PropertyWrapper 的能力,对某个属性进行 UserDefault 的存取,那么只需在 accessor 的 set,get 中添加 UserDefault 的能力。
public macro UserDefault() = #externalMacro(module: "Macro", type: "UserDefault")
# 原代码
class UserDefaultManager {
@UserDefault
var name: String
}
@UserDefault 宏代码展开后
class UserDefaultManager {
@UserDefault
var name: String {
set {
UserDefaults.standard.set(newValue, forKey: "name")
}
get {
return UserDefaults.standard.object(forKey: "name") as? String ?? ""
}
}
}
2.3 @attached(memberAttribute)
对类 / 结构体 / 枚举等所有成员添加属性扩展
随着 UserDefaultManager 的成员日益增加,UserDefaultManager 就会变得臃肿起来
class UserDefaultManager {
@UserDefault
var name: String
@UserDefault
var title: String
@UserDefault
.....
}
而 @attached(memberAttribute) 就可以帮我们解决这个问题,由于宏的特性,在展开的时候是递归展开的。也就意味着,我们对 UserDefaultManager 实现 memberAttribute 宏,就可以让内部的成员实现 @UserDefault 宏。
@UserDefaultDefine
class UserDefaultManager {
var name: String
var title: String
}
@UserDefaultDefine 第一层展开后
@UserDefaultDefine
class UserDefaultManager {
@UserDefault
var name: String
@UserDefault
var title: String
}
@UserDefaultDefine 第二层展开后
@UserDefaultDefine
class UserDefaultManager {
@UserDefault
var name: String {
set {
UserDefaults.standard.set(newValue, forKey: "name")
}
get {
return UserDefaults.standard.object(forKey: "name") as? String ?? ""
}
}
@UserDefault
var title: String {
set {
UserDefaults.standard.set(newValue, forKey: "title")
}
get {
return UserDefaults.standard.object(forKey: "title") as? String ?? ""
}
}
}
2.4 @attached(member)
对类 / 结构体 / 枚举等 添加成员或者方法,如开头 @DefaultAge 所示。
2.5 @attached(extension, conformances)
@attached(extension, conformances:xxxProtocol)是以 extension 的形式去遵循某个协议。日常开发中判断2个实例是否相等 ,需要遵守 Equatable 协议,添加成员的判断,conformances 宏可以帮我们省去这些操作。
public macro Equatable() = #externalMacro(module: "Macro", type: "EquatableMacro")
public struct EquatableMacro: ExtensionMacro {
public static func expansion(of node: AttributeSyntax, attachedTo declaration: some DeclGroupSyntax, providingExtensionsOf type: some TypeSyntaxProtocol, conformingTo protocols: [TypeSyntax], in context: some MacroExpansionContext) throws -> [ExtensionDeclSyntax] {
var conditions: [ExprSyntax] = []
// 遍历成员,找到属性
// VariableDeclSyntax 代表变量的 let / var 声明节点
for member in declaration.memberBlock.members {
if let varDecl = member.decl.as(VariableDeclSyntax.self) {
for binding in varDecl.bindings {
if let identifier = binding.pattern.as(IdentifierPatternSyntax.self) {
let propName = identifier.identifier.text
conditions.append("lhs.\(raw: propName) == rhs.\(raw: propName)")
}
}
}
}
// 拼接成员,得到 "==" 的判断表达式
var conditionString = ""
for (index, condition) in conditions.enumerated() {
if index > 0 {
conditionString += " && "
}
conditionString += condition.description
}
return [try ExtensionDeclSyntax("extension \(type.trimmed): Equatable { static func ==(lhs: \(type.trimmed), rhs: \(type.trimmed)) -> Bool { return \(raw: conditionString)}}")]
}
}
# 原代码
@EquatableMacro
class Test {
var name: String = ""
}
@EquatableMacro 宏代码展开后
@EquatableMacro
class Test {
var name: String = ""
}
extension Test: Equatable {
static func == (lhs: Test, rhs: Test) -> Bool {
return lhs.name == rhs.name
}
}
上面简述了一些不同宏的基础用法,但是想要应用在项目内,还需要结合实际场景。不难看出,Swift Macro 的构造相对来说是比较麻烦的,我们需要按照 AST 的结构去拆解,编写代码,包括宏的单元测试。
不过我们需要透过繁琐的过程看到本质,宏的本质就是将繁琐的代码简化,在编译时帮助我们自动去生成或者补齐代码。虽然写宏的过程是比较痛苦的,但是在@出宏的那一刻就会被延迟满足。
Swift宏 应用
模块化场景下的应用
目前在大会员中心业务下维护的 番剧影视 和 大会员收银台 都采用了 MVVP的模块化架构,那么模块化的东西势必会产生一些模块化的模版。每次新增模块,就不得不把一些模版化的代码 CV 过来修改,虽然不复杂,但是不想写。
以模块声明为例,我们需要单个模块内绑定模块的视图,模块的逻辑,以及一些模块固定的成员。
protocol BiliModule: AnyObject {
associatedtype ModuleView: BiliModuleView
associatedtype ModulePresenter: BiliModulePresenter
static var moduleIdentifier: BiliModuleIdentifier { get }
var view: ModuleView? { get set }
var presenter: ModulePresenter { get }
var moduleSize: CGSize { get }
...
}
那么新增一个 TAB 模块,就需要遵循 BiliModule,并实现以下代码:
class TabModule: BiliModule {
typealias ModuleView = TabView
typealias ModulePresenter = TabPresenter
static var moduleIdentifier: BiliModuleIdentifier {
.TAB
}
var view: TabView?
var presenter: TabPresenter
required init(context: BiliContext, data: BiliModuleInfo) {
self.presenter = TabPresenter(context: context, data: data)
}
}
同上,在逻辑层 Presenter 和 视图层 View 都需要进行模版化的绑定。CV 的工作量并不大,但是需要人眼去纠错,因为很容易漏改某个地方。所以尝试用 Swift Macro 来简化模版代码,让开发重心更倾向于业务。
于是用到了 @attached(extension, conformances):自动遵循 BiliModule 协议@attached(member):自动生成模版属性和方法
@attached(member, names: arbitrary)
@attached(extension, conformances: BiliModule)
public macro BiliModuleDefine<P, V>(_ presenter: P, _ view: V, _ type: BiliModuleIdentifier)
public struct BiliModuleMacro: MemberMacro {
public static func expansion(of node: AttributeSyntax, providingMembersOf declaration: some DeclGroupSyntax, conformingTo protocols: [TypeSyntax], in context: some MacroExpansionContext) throws -> [DeclSyntax] {
guard let _ = declaration.as(ClassDeclSyntax.self) else {
throw ClassMacroError.onlyApplicableToClass
}
// 获取参数列表 arguments
guard case .argumentList(let arguments) = node.arguments else {
throw ClassMacroError.noArguments
}
// 获取 arguments 参数类型
let viewType = arguments.compactMap { $0.expression.as(DeclReferenceExprSyntax.self) }.last?.baseName.text ?? ""
let moduleViewDecl = """
typealias ModuleView = \(TypeSyntax(stringLiteral: viewType))
var view: \(TypeSyntax(stringLiteral: viewType))?
"""
...
...
// 生成 init 方法
let initDecl = """
required init(context: BiliContext, data: BiliModuleInfo) {
self.presenter = \(TypeSyntax(stringLiteral: xxx))(context: context, data: data)
}
"""
}
}
// 遵循 BiliModule
extension BiliModuleMacro: ExtensionMacro {
public static func expansion(of node: AttributeSyntax, attachedTo declaration: some DeclGroupSyntax, providingExtensionsOf type: some TypeSyntaxProtocol, conformingTo protocols: [TypeSyntax], in context: some MacroExpansionContext) throws -> [ExtensionDeclSyntax] {
let extensionDecl = try ExtensionDeclSyntax("extension \(type.trimmed): BiliModule {}")
return [extensionDecl]
}
}
最后,得到了下面这样一句话模块声明
@BiliModuleDefine(TabPresenter, TabView, .TAB)
class TabModule {}
当然了并非所有的模版定义都是一层不变的,这需要建立在一套固有的模版准则上,对样板内部的静态代码进行抽离。在大会员收银台的业务场景,可以轻轻敲下 @BiliModuleDefine,快速的构造一个模块声明,来聚焦业务逻辑的开发。为了不写模版,不得不为这个模版新写一个模版。
曝光场景下的应用
曝光在各个平台都有自己的实现方案,在大会员中心你想要曝光某个 ListView,你需要实现曝光 4 要素。
1. 注册曝光容器(Container),该容器视图需要 遵循 BiliExposureContainer 容器协议,以 ColletionView 为例。
// 容器视图
class ExposureCollectionView: UICollectionView, BiliExposureContainer {
// 容器标记位
var exposureCheckFlag: Int32 = 0
var exposureContext: BiliExposureContext = BiliExposureContext()
public func visibleExposureTargets() -> [UIView]? {
return self.visibleCells
}
}
2. 曝光对象(Target), 负责控制曝光的属性(曝光区域,是否重复曝光等),需要遵守 BiliExposureTarget 协议
class ExposeData: NSObject, BiliExposureTarget {
// 曝光标记位
var exposureCheckFlag: Int32 = 0
// 曝光比例 (0 - 100%)
var exposurePercent: Int32 = 100
// 是否重复曝光
var repeatExposure: Bool = false
var name: String = ""
}
3. 曝光视图(View),真正曝光的区域遵循 BiliExposureRegion 协议
4. 曝光回调(Report ), 表该视图成功曝光,实现 BiliExposureReporter 协议
class ExsoureCell: UICollectionViewCell, BiliExposureRegion, BiliExposureReporter {
// 3.1 曝光对象
private var data: ExposeData?
// 3.2 返回曝光对象
func exposureTarget() -> BiliExposureTarget? {
return data
}
// 4.1 曝光成功
func reportExposure(with context: BiliExposureContext?) -> Bool {
// 此处埋点上报
return true
}
}
这是没有嵌套滚动视图下的情况,如果 Cell 内部又嵌套了其它的滚动视图,那么整个曝光流程,在不熟悉的情况下,会让你手忙脚乱。所以想通过宏让刚接触的人可以快速上手,不用过多关心曝光组件,减少认知成本,同时也避免协议满天飞。
整个流程可以精简为3个步骤:
-
第一步:标记曝光容器
@ExposureContainer:标记曝光容器
@ExposureView: 标记需要被曝光的视图 (非必须,可选)
情况A:该曝光视图是 ListView
@ExposureContainer
class ExposureCollectionView: UICollectionView {}
@ExposureContainer 宏代码展开后
@ExposureContainer
class ExposureCollectionView: UICollectionView, BiliExposureContainer {
func visibleExposureTargets() -> [UIView]? {
return self.visibleCells
}
}
情况B:该曝光视图是常规 View(视图内多个元素需要曝光),需配合 @ExposureView 使用。其中 collectionView 和 headerView 都需要曝光检测。
@ExposureContainer
class ExposureView: UIView {
@ExposureView
var collectionView: UICollectionView
@ExposureView
var headerView: UIView
}
@ExposureContainer 宏代码展开后
@ExposureContainer
class ExposureView: UIView, BiliExposureContainer {
@ExposureView
var collectionView: UICollectionView
@ExposureView
var headerView: UIView
// 生成 Targets方法,并添加标记了 @ExposureView 的View
func visibleExposureTargets() -> [UIView]? {
var views: [UIView] = []
views.append(headerView)
views.append(contentsOf: collectionView.visibleCells)
return views
}
}
-
第二步:设置曝光参数
@ExposureTarget(_ percent: Int32, _ repeat: Bool ),通过 @attached(member) 生成成员。
@ExposureTarget(100, true)
class ExposeData: NSObject {}
@ExposureTarget(100, true) 宏代码展开后
@ExposureTarget(100, true)
class ExposeData: NSObject {
var exposureCheckFlag: Int32 = 0
var exposurePercent: Int32 = 100
var repeatExposure: Bool = true
}
-
第三步:标记曝光视图
@ExposureRegion:需要曝光的具体视图,接收曝光回调,@ExposureTargetMember:标记需要被返回的曝光的对象实例。
真正需要被曝光的视图在当前场景下是 UICollectionViewCell,而其内部的exposureData 用来提供曝光配置给 Cell。
@ExposureRegion 和 @ExposureTargetMember 需绑定使用
@ExposureRegion
class VipCollectionViewCell: UICollectionViewCell {
@ExposureTargetMember
var exposureData: ExposureData?
}
@ExposureRegion 宏代码展开后
@ExposureRegion
class VipCollectionViewCell: UICollectionViewCell, BiliExposureRegion {
@ExposureTargetMember
var exposureData: ExposureData?
func exposureTarget() -> BiliExposureTarget? {
return exposureData
}
}
其中 @ExposureTargetMember 和 @ExposureView 是通过 @Peer 宏来进行标记,从而确定哪些成员是需要被找到的,Peer 宏内并无任何实现,以 @ExposureView 举例:
@attached(peer)
public macro ExposureView() = #externalMacro(module: "ExposurePlugin", type: "ExposureViewMacro")
public struct ExposureViewMacro: PeerMacro {
public static func expansion(
of node: SwiftSyntax.AttributeSyntax,
providingPeersOf declaration: some SwiftSyntax.DeclSyntaxProtocol,
in context: some SwiftSyntaxMacros.MacroExpansionContext
) throws -> [SwiftSyntax.DeclSyntax] {
return []
}
}
// 在 ExposureContainer 实现中配合使用
public struct ExposureContainer: MemberMacro {
public static func expansion(of node: AttributeSyntax, providingMembersOf declaration: some DeclGroupSyntax, conformingTo protocols: [TypeSyntax], in context: some MacroExpansionContext) throws -> [DeclSyntax] {
// 遍历成员寻找是否存在 ExposureView 标识符
var propertyString: String = ""
declaration.memberBlock.members.forEach { item in
let variableDecl = item.decl.as(VariableDeclSyntax.self)?.attributes.first
let identifier = variableDecl?.as(AttributeSyntax.self)?.attributeName.as(IdentifierTypeSyntax.self)?.name.text
if let identifier, identifier == "ExposureView" {
let binding = item.decl.as(VariableDeclSyntax.self)?.bindings.first
let typeName = binding?.typeAnnotation?.as(TypeAnnotationSyntax.self)?.type
if let propertyName = binding?.pattern.as(IdentifierPatternSyntax.self)?.identifier.text {
// 记录当前成员名称
propertyString += "\(propertyName),"
}
}
}
}
}
那么对上面的代码进行宏简化,在 List VC 就得到了下代码
class ExposureVC {
private lazy var collectionView: ExposureCollectionView = {
return ExposureCollectionView()
}()
func viewDidload() {
super.viewDidload()
BiliExposer.registerContainer(collectionView, containerDelegate: self, context: exposureContext)
}
}
// 标记曝光容器
@ExposureContainer
class ExposureCollectionView: UICollectionView {}
// 标记曝光对象
@ExposureTarget(100)
class ExposeData: NSObject {
var name: String = ""
}
// 标记曝光视图
@ExposureRegion
class ExsoureCell: UICollectionViewCell, BiliExposureReporter {
// 标记曝光对象
@ExposureTargetMember
private var data: ExposeData?
func reportExposure(with context: BiliExposureContext?) -> Bool {
// 此处埋点上报
return true
}
}
# reportExposure 是使用者的动态上报行为,没有对其进行宏处理
整个流程翻译成图:
在曝光的接入流程上,使用者只需要明确自己需要标记宏的位置即可,无需感知什么角色需要遵守什么协议,将曝光流程职责化在具体的某个点上,让曝光的接入变得更为轻量化。
小结
以上两个场景应用,模块宏是为了解决模块化通用模版定义的繁琐, 曝光宏是为了降低整个曝光体系接入的复杂度,本质上都是让 Swift Macro 帮助我们减少重复样板代码的编写,提供快速接入的能力。接入 Swift Macro 给我的感受是它可以玩出很多花样,不仅增加了代码的趣味性,也增加的代码的可读性,降低了维护成本。目前对宏的理解和应用或存在瑕疵,后续会对宏继续探索,更大化的增强宏的实用性。有同学对代码实现有更好的建议也可以提出,一起交流进步。
-End-
作者丨 tit