Combine 系列
- Swift Combine 从入门到精通一
- Swift Combine 发布者订阅者操作者 从入门到精通二
- Swift Combine 管道 从入门到精通三
- Swift Combine 发布者publisher的生命周期 从入门到精通四
- Swift Combine 操作符operations和Subjects发布者的生命周期 从入门到精通五
- Swift Combine 订阅者Subscriber的生命周期 从入门到精通六
- Swift 使用 Combine 进行开发 从入门到精通七
- Swift 使用 Combine 管道和线程进行开发 从入门到精通八
- Swift Combine 使用 sink, assign 创建一个订阅者 从入门到精通九
- Swift Combine 使用 dataTaskPublisher 发起网络请求 从入门到精通十
- Swift Combine 用 Future 来封装异步请求 从入门到精通十一
- Swift Combine 有序的异步操作 从入门到精通十二
- Swift Combine 使用 flatMap 和 catch错误处理 从入门到精通十三
- Swift Combine 网络受限时从备用 URL 请求数据 从入门到精通十四
- Swift Combine 通过用户输入更新声明式 UI 从入门到精通十五
- Swift Combine 级联多个 UI 更新,包括网络请求 从入门到精通十六
- Swift Combine 合并多个管道以更新 UI 元素 从入门到精通十七
- Swift Combine 通过包装基于 delegate 的 API 创建重复发布者 从入门到精通十八
- Swift Combine 响应NotificationCenter 的更新 从入门到精通十九
- Swift Combine 使用 ObservableObject 与 SwiftUI 模型作为发布源 从入门到精通二十
- Swift Combine 使用 XCTestExpectation 测试发布者 从入门到精通二十一
- Swift Combine 使用 PassthroughSubject 测试订阅者 从入门到精通二十二
- Swift Combine 使用从 PassthroughSubject 预定好的发送的事件测试订阅者 从入门到精通二十三
- Swift Combine 使用 print 操作符调试管道 从入门到精通二十四
- Swift Combine 使用 handleEvents 操作符调试管道 从入门到精通二十五
1. 使用调试器调试管道
目的: 强制管道在特定场景或条件下进入调试器。
你可以在管道内的任何操作符的任何闭包内设置一个断点,触发调试器激活以检查数据。 由于 map
操作符经常用于简单的输出类型转换,因此它通常是具有你可以使用的闭包的优秀候选者。 如果你想查看控制消息,那么为 handleEvents
提供的任何闭包添加一个断点,目标实现起来将非常方便。
你还可以使用 breakpoint
操作符触发调试器,这是查看管道中发生情况的一种非常快速和方便的方式。 breakpoint
操作符的行为非常像 handleEvents
,使用一些可选参数,期望返回一个布尔值的闭包,如果返回 true 将会调用调试器。
可选的闭包包括:
receiveSubscription
receiveOutput
receiveCompletion
swift
.breakpoint(receiveSubscription: { subscription in
return false // return true to throw SIGTRAP and invoke the debugger
}, receiveOutput: { value in
return false // return true to throw SIGTRAP and invoke the debugger
}, receiveCompletion: { completion in
return false // return true to throw SIGTRAP and invoke the debugger
})
这允许你提供逻辑来评估正在传递的数据,并且仅在满足特定条件时触发断点。 通过非常活跃的管道会处理大量数据,这将是一个非常有效的工具,在需要调试器时,让调试器处于活动状态,并让其他数据继续移动。
如果你只想在错误条件下进入调试器,则便利的操作符 breakPointOnError
是完美的选择。 它不需要参数或闭包,当任何形式的错误条件通过管道时,它都会调用调试器。
swift
.breakpointOnError()
断点操作符触发的断点位置不在你的代码中,因此访问本地堆栈和信息可能有点棘手。 这确实允许你在极其特定的情况下检查全局应用状态(每当闭包返回
true
时,使用你提供的逻辑),但你可能会发现在闭包中使用常规断点更有效。breakpoint()
和breakpointOnError()
操作符不会立即将你带到闭包的位置,在那里你可以看到可能触发断点的正在传递的数据、抛出的错误或控制信号。 你通常可以在调试窗口内通过堆栈跟踪以查看发布者。当你在操作符的闭包中触发断点时,调试器也会立即获取该闭包的上下文,以便你可以查看/检查正在传递的数据。
参考
https://heckj.github.io/swiftui-notes/index_zh-CN.html