在这些使用场景中，动态调整线程池大小应该算是最实用的功能了。很多时候，当 Kafka Broker 入站流量（inbound data）激增时，会造成 Broker 端请求积压（Backlog）。有了动态参数，我们就能够动态增加网络线程数和 I/O 线程数，快速消耗一些积压。当突发流量过去后，我们也能将线程数调整回来，减少对资源的浪费。整个过程都不需要重启 Broker。你甚至可以将这套调整线程数的动作，封装进定时任务中，以实现自动扩缩容

Consumer 端还有一个参数，用于控制 Consumer 实际消费能力对 Rebalance 的影响，即 max.poll.interval.ms 参数。它限定了 Consumer 端应用程序两次调用 poll 方法的最大时间间隔。它的默认值是 5 分钟，表示你的 Consumer 程序如果在 5 分钟之内无法消费完 poll 方法返回的消息，那么 Consumer 会主动发起“离开组”的请求，Coordinator 也会开启新一轮 Rebalance。

Implement a custom sharing flowApps can implement a custom sharing flow when UICloudSharingController is unavailable or doesn’t fit their UI. (UICloudSharingController is unavailabe in watchOS. In macOS, the counterpart is NSSharingService with the cloudSharing service.) The sample app performs the following tasks so users can share photos from watchOS:

private func createShare(_ destination: Destination) async { do { let (_, share, _) = try await stack.persistentContainer.share([destination], to: nil) share[CKShare.SystemFieldKey.title] = destination.caption self.share = share } catch { print("Failed to create share") } }

If your app stores data as files and you want those files to sync across devices, you can use iCloud document storage. This storage option gives you granular control over which files to sync. Choosing to store your data as files affords the least control over how your data persists to iCloud, but is relatively simple.

你可以使用通知来简单地表明已发生更改, 而不必依赖单个通知来详细了解单个通知代表什么更改, 然后你可以询问CloudKit自上次询问以来发生了什么更改。在我的示例中, 我通过使用CKFetchRecordZoneChangesOperation和CKServerChangeTokens来做到这一点。可以将更改令牌视为一个书签, 该书签告诉你最近的更改序列发生之前的位置。

// We set shouldSendContentAvailable to true to indicate we want CloudKit // to use silent pushes, which won’t bother the user (and which don’t require // user permission.) let notificationInfo = CKNotificationInfo() notificationInfo.shouldSendContentAvailable = true subscription.notificationInfo = notificationInfo