AztecEditor-iOS 基于 UITextView 提供了一个性能良好的用户界面组件。Android 端有对应的 SDK。 它由两个主要部分组成： TextView：用户界面组件，用于呈现和编

我正在参加「掘金·启航计划」 相比JSONSerialization，Codable十分不灵活，几乎所有和 JSONSerialization 有关的字典都是 [String：Any] 类型的，把它变

我正在参加「掘金·启航计划」 这种背压机制 (Backpressure)，可以让我们指定合适的背压策略，来控制可接收的值的上限，防止出现上游的发布速度超过下游消费速度的问题。

Subscriber在订阅上游Publisher时，Combine要求`Publisher.output`和`Subscriber.input`的类型一致，同时也要求所接受的Failure的类型一致，

只要理解了这三个核心概念，你就可以很好的使用Combine，所以从这个角度来说，我们可以将Combine简单的理解为下面的形式： Combine = Publishers + Operators +

你可以使用Combine为给定的事件创建单个处理链，而不用实现多个委托或者闭包回调。处理链的每个部分都是一个Combine操作符，用来对从上一步接收到的元素执行不同的操作。

理解异步代码中的事件流，对于初学者来说一直是一个挑战。在Combine的上下文中尤其如此，因为事件流中的操作符链可能不会立即发出事件。

例如，throttle(for:scheduler:latest:) 操作符就不会发出接收到的任何事件，要了解这个过程中发生了什么，就需要借助Combine提供的一些操作符来进行调试，以帮助我们解决遇到的困难。

Print

当你不确定流中发生的事件时，首先可以考虑使用print(_:to:)操作符来进行打印操作，它是一个passthrough publisher，可以打印大量事件流信息，帮助我们了解事件传输过程中发生了什么，比如用它来了解事件流的生命周期。

let subscription = (1 ... 3).publisher
    .print("publisher")
    .sink { _ in }

控制台会输出流中发生的事件：

publisher: receive subscription: (1...3)
publisher: request unlimited
publisher: receive value: (1)
publisher: receive value: (2)
publisher: receive value: (3)
publisher: receive finished

print(_:to:)还接受一个 TextOutputStream 对象，我们可以使用它来重定向字符串并打印出来。通过自定义的TextOutputStream，在日志中添加信息，例如当前日期和时间等。

例子：

class TimeLogger: TextOutputStream {
    private var previous = Date()
    private let formatter = NumberFormatter()
    
    init() {
        formatter.maximumFractionDigits = 5
        formatter.minimumFractionDigits = 5
    }
    
    func write(_ string: String) {
        let trimmed = string.trimmingCharacters(in: .whitespacesAndNewlines)
        guard !trimmed.isEmpty else {
            return
        }
        
        let now = Date()
        print("+\(formatter.string(for: now.timeIntervalSince(previous))!)s: \(string)")
        previous = now
    }
}

使用：

let subscription = (1 ... 3).publisher
    .print("publisher", to: TimeLogger())
    .sink { _ in }

handleEvents

除了打印事件信息之外，使用handleEvents(receiveSubscription:receiveOutput:receiveCompletion:receiveCancel:receiveRequest:)对特定事件进行操作也很有用，它不会直接影响下游其他publisher，但会产生类似于修改外部变量的效果。所以可以称其为“执行副作用”。

handleEvents可以让你拦截一个publisher生命周期内的任何事件，并且可以在每一步对它们进行操作。

想象一下，你正在跟踪的publisher必须执行网络请求，然后发出一些数据。但当你运行它时，却怎么也收不到数据，比如下面的代码就是如此，

let request = URLSession.shared.dataTaskPublisher(for: URL(string: "https://kodeco.com/")!)

request.sink(receiveCompletion: { completion in
    print("Sink received completion: \(completion)")
}) { data, _ in
    print("Sink received data: \(data)")
}

运行之后，控制台没有任何输出。你是否能发现这段代码存在的问题呢？

如果问题你没找到，那么就可以使用 handleEvents来跟踪并查找问题所在。

request.handleEvents(receiveSubscription: { _ in
    print("请求开始了")
}, receiveOutput: { _ in
    print("请求到数据了")
}, receiveCancel: {
    print("请求取消了")
}).sink(receiveCompletion: { completion in
    print("Sink received completion: \(completion)")
}, receiveValue: { data, _ in
    print("Sink received data: \(data)")
})

再次执行，可以看到打印：

请求开始了
请求取消了

因为Subscriber 返回的是一个AnyCancellable 对象，如果不持有这个对象，那么它会马上被取消（释放），这里的问题就是没有持有 Cancellable 对象，导致publisher被提前释放了, 修改代码:

let subscription = request.handleEvents(receiveSubscription: { _ in
    print("请求开始了")
}, receiveOutput: { _ in
    print("请求到数据了")
}, receiveCancel: {
    print("请求取消了")
}).sink(receiveCompletion: { completion in
    print("Sink received completion: \(completion)")
}, receiveValue: { data, _ in
    print("Sink received data: \(data)")
})

再次运行，打印如下：

请求开始了
请求到数据了
Sink received data: 266785 bytes
Sink received completion: finished

终极大招

当你用尽浑身解数也无法找到问题所在时，“万不得已”操作符是帮助你解决问题的终极方案。

简单的“万不得已”操作符： breakpointOnError() 。 顾名思义，使用此运算符时，如果任何上游publisher发出错误，Xcode 将中断调试器，让你从堆栈中找出publisher出错的原因和位置。

完整的变体是 breakpoint(receiveSubscription:receiveOutput:receiveCompletion:) 。 它允许你拦截所有事件并根据具体情况决定是否要暂停调试器。比如，只有当某些值通过publisher时才可以中断：

.breakpoint(receiveOutput: { value in
    value > 10 && value < 15
})

假设上游publisher发出整数值，但值 11 到 14 永远不会发生，就可以将断点配置为仅在这种情况下中断，以进行检查。 你还可以有条件地中断订阅和完成时间，但不能像 handleEvents 运算符那样拦截取消。

总结

以上我们已经介绍了几种Combine的调试方法，下面做一个简单的总结：

• 使用print操作符跟踪publisher的生命周期
• 创建自定义的TextOutputStream来输出需要的调试信息
• 使用handleEvents操作符拦截生命周期事件，并执行操作
• 使用breakpointOnError和breakpoint操作符来中断特定事件

参考

Combine: Asynchronous Programming with Swift

持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第1天 LLDB 是高性能的程序调试器,默认集成在 XCode 中，支持 C 语言、Objective-C 语言和 C++语言程序

我正在参加「掘金·启航计划」 属性包装 propertyWrapper（属性包装器）是 Swift 语言特性，它允许我们定义一个自定义类型，该类型包含了 setter 和 getter，我们可以在需要

使用过其他 IDE 的同学应该知道，大多数都集成了终端，而 Xcode 却没有。当我们要对一个项目执行命令行时，总要将项目拖到终端窗口中，这样很不方便。那如何使用 Xcode 一键启动终端并 cd 到当前项目目录呢？这篇文章就来介绍一种方案。

新建脚本文件：

编辑脚本文件：

#!/usr/bin/env bash 
open -a iTerm "`pwd`"

脚本文件默认没有执行权限，启动终端，使用命令行

chmod +x <脚本路径>

赋予脚本权限。

在 Xcode → Preferences → Behaviors 中添加自定义 Open Terminal 选项，设置脚本路径及惯用快捷键

完成之后就可以在 Xcode中通过快捷键一键调起终端并 cd 到项目目录。

配置起来很简单，使用起来很划算哦😏

如果曾对 iOS 中的 ViewController 有过接触，那就很容易理解生命周期在 UI 绘制中的重要作用。Flutter 中也存在生命周期，它的回调方法都体现在 State 中，源码参考。

Flutter 的生命周期分为页面（Widget）和 APP 两块。理解Flutter生命周期， 对写出一个合理的 Widget 和一个健壮的 APP 至关重要。

页面的生命周期

以 StatefulWidget 为例，来看一下 Flutter 页面的生命周期是怎样的。 Widget 的生命周期大体上可以分为三个阶段：

1. 初始化

• createState

     //这个方法是必须重写的      
     @override
     _LifecycleWidgetState createState() => _LifecycleWidgetState();

当构建一个 StatefulWidget 时这个方法会被首先调用，而且这个方法是必须要重写的。

• initState

@override
  void initState() {
  super.initState();
}

这个方法调用发生在 createState之后，是除构造方法之外，调用的第一个方法，它的作用类似于 Android 的 onCreate()和 iOS 的 viewDidLoad()。这个方法中通常会做一些初始化工作，比如 channel 的初始化、监听器的初始化等。 与 dispose() 相对应。

2. 状态改变

• didChangeDependencies

  @override
    void didChangeDependencies() {
      super.didChangeDependencies();
    }
  

  这个方法要求必须要调用父类的方法super.didChangeDependencies，当依赖的 State 的对象改变时会调用。

  1. 在第一次构建 Widget 时，在 initState()之后立即调用此方法。
  2. 如果 StatefulWidgets 依赖于 InhertedWidget，那么当当前 State 所依赖 InheritedWidget 中的变量改变时会再次调用它。

• build

@override
  Widget build(BuildContext context) {
      return Container();
  }

是一个必须实现的方法，在这里实现要呈现的页面内容。它会在didChangeDependencies()之后立即调用，另外当调用 setState() 后也会再次调用这个方法

• didUpdateWidget

@override
void didUpdateWidget(covariant LifecycleWidget oldWidget) {
     super.didUpdateWidget(oldWidget);
}

调用 setState 将 Widget 的状态改变时 didUpdateWidget 会被调用，Flutter 会创建一个新的 Widget 来绑定这个 State，并在这个方法中传递旧的 Widget ，因此如果想比对新旧 Widget 并且对 State 做一些调整，可以使用它。

另外如果某些 Widget 上涉及到 controller 的变更，那么一定要在这个回调方法中移除旧的 controller 并创建新的 controller 监听。

3. 销毁

• deactivate

  @override
    void deactivate() {
      super.deactivate();
    }
  

  这个方法不常用，它会在组件被移除时调用，而且是在dispose 调用之前

• dispose

  @override
    void dispose() {
      super.dispose();
    }
  

  与 initState() 对应。

  组件销毁时调用，通常该方法中执行一些释放资源的工作，如监听器的移除，channel 的销毁等，相当于 iOS 的 dealloc。方法参考

App 的生命周期

App 中会有比如从前台切入到后台再从后台切回到前台的场景，在 iOS 中这些生命周期都可以在 AppDelegate 中被体现，那么 Flutter 中我们该如何处理这些场景？对于 App 级别的生命周期与上述 Widget 生命周期相比，稍有不同。

源码参考

如果想监听 App 的生命周期需要使用 WidgetsBinding 来监听 WidgetsBindingObserver，WidgetsBindingObserver是一个 Widgets 绑定观察器，通过它来监听应用的生命周期，使用混入的方式绑定观察器，并且需要在 dispose 回调方法中移除这个监听。

重写 didChangeAppLifecycleState ，当生命周期发生变化的时候会回调这个方法，

class _LifecycleAPPState extends State<LifecycleAPP>
    with WidgetsBindingObserver {
@override
  void initState() {
    //添加监听
    WidgetsBinding.instance!.addObserver(this);
    super.initState();
  }

  @override
  Widget build(BuildContext context) {
    return Container();
  }

  @override
  void didChangeAppLifecycleState(AppLifecycleState state) {
    super.didChangeAppLifecycleState(state);
print(state);
  }

  @override
  void dispose() {
// 移除监听
    WidgetsBinding.instance!.removeObserver(this);
    super.dispose();
  }
}

Flutter 封装了一个枚举 AppLifecycleState 来描述 APP 的生命周期：

enum AppLifecycleState {
  resumed, // 进入前台
  inactive, // app 处于非活跃状态，并且未接收到用户输入的时候调用。比如接听来电
  paused,// 进入后台
  detached, // app 仍寄存在Flutter引擎上，但与原生平台分离
}

我们可以拿到这个 state 在 didChangeAppLifecycleState()来做一些我们需要的处理逻辑。