关于-[RBSAssertion setInvalidationHandler:]断言失败致应用崩溃的咨询

先把你的崩溃日志贴出来方便参考：

2019-08-09 13:49:36.946141+0300 xxx[2861:1427995] *** Assertion failure in -[RBSAssertion setInvalidationHandler:], /BuildRoot/Library/Caches/com.apple.xbs/Sources/RunningBoardServices/RunningBoard-223.0.2/RunningBoardServices/RBSAssertion.m:189
2019-08-09 13:49:51.091952+0300 xxx[2861:1427995] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'can only call before acquisition'
*** First throw call stack: (0x186ccadf8 0x1869f40a4 0x186bcd7f8 0x1870016d4 0x1897db49c 0x1897dadec 0x1063858ac 0x106386c88 0x10638fe44 0x106399b88 0x1869e8fa8 0x1869ebae4)
libc++abi.dylib: terminating with uncaught exception of type NSException

问题本质 #

这个崩溃的核心原因非常明确：你在已经获取（acquire）了RBSAssertion实例之后，尝试调用它的setInvalidationHandler:方法，但系统的RBSAssertion规则要求这个方法只能在断言被获取之前调用，违反这个规则就会触发系统断言检查失败，进而导致App崩溃。

解决步骤 #

根据问题本质，你可以按以下方向排查和修复：

• 调整调用顺序：找到代码中调用-[RBSAssertion acquireWithError:]（或其他获取断言的方法）的位置，确保setInvalidationHandler:的调用严格在它之前。比如把设置handler的代码移到断言初始化完成后、获取操作执行前的位置。
• 排查异步时序问题：如果代码里有异步逻辑（比如后台线程任务、网络请求回调），要确认设置handler的操作不会在断言已经被获取之后执行。举个例子，如果是在某个completion block里设置handler，要确保这个block在断言获取前就被触发执行。
• 避免复用断言实例：如果代码存在复用同一个RBSAssertion实例的情况，注意一旦这个实例被获取过，就不能再修改它的invalidationHandler了。如果需要重新设置handler，应该创建新的RBSAssertion实例，先设置handler再执行获取操作。
• 检查第三方依赖：如果这个RBSAssertion是由第三方库（比如后台任务管理、权限相关的SDK）创建的，那可能是库内部的时序bug。你可以检查库的最新版本，看看是否有修复该问题的更新，或者查阅库的官方文档确认正确的使用姿势。

你提到上周也出现过这个崩溃，说明这是一个有复现性的问题，按照上面的步骤重点排查代码的调用时序，应该能快速定位并解决问题。

内容的提问来源于stack exchange，提问作者Anton Tropashko