我很好Xcode 8.3.2和SourceKitService正在使用我所有的CPU。我在这里阅读了很多关于stackoverflow的问题，但是我找不到真正的解决方案。SourceKitService在Xcode 8.3.2上吃掉所有CPU
我的尝试：
没有工作。我明白这个问题可能与某些代码有关，但我怎么能发现问题在哪里？我的项目是相当大的...
目前Xcode是不可用的......
感谢您的帮助
SourceKit一贯的CPU和RAM饿了，速度慢，容易死机。 它（用我的经验）Xcode 9更好一点。
一个大问题是，Swift中的很多表达式都有大量的重载。对于工作类型推断，所有这些都必须进行测试。这也是为什么Swift代码的编译时间通常稍长一些的原因。
一旦SourceKit开始处理这些表达式，其他所有内容都必须等待。
您可以通过避免长的表达式使用二进制运营商和map，flatMap链和收藏和序列filter操作尤其是当作为对这样的表达式解析返回类型的时间复杂度是指数帮助SourceKit。
您可以尝试通过声明变量类型（let a: X = expr而不是let a = expr）来减少长型推断时间。根据我的经验，这也有助于关闭链条map,filter和flatMap链（{ param -> Result in ...}而不是{ param in }）。
您可以使用Other Swift Flags构建设置中的-Xfrontend -debug-time-function-bodies标记来获取Xcode中构建报告中每个函数的编译时间，这可以帮助您识别需要很长时间才能由编译器和SourceKit处理的表达式。详细说明可在this blog post中找到。
除此之外，我不知道任何其他解决方案。
我在一个有多个故事板的应用程序中看到过类似的问题，其中，有趣的是，Xcode只有一个故事板有问题。在这个故事板上工作会非常困难，而CPU将会爆满。
我们的解决方案是将故事板分成更小的故事板。这可以通过选择几个场景然后在菜单上选择Editor -> Refactor to Storyboard...轻松完成。
这一变化使人们更容易与新的小故事板工作。
我已经使用了很长一段时间的一个非常好的解决方案是使用Build Time Analyzer for Swift工具来分析我的代码库，并显示所有需要花费大量时间来处理和编译的方法和函数的详细列表。
然后，我会重构必要的文件和声明，并再次测量我的结果。重复此操作，直到您拥有非常快速的编译时间结果。
还有一个nice list与Swift编译时间的建议。
这不是一个真正的“修复”，因为这对那些依赖向他们展示实况问题的人也是不利的。但是如果你去Preferences-> General并关掉“显示实时问题”，那么xcode就像一个兔子在一个凉爽的春日里运行。我更喜欢不必强制退出SourceKit服务。
这至少使XCode再次可用。非常感谢 – schmidiii
谢谢，但我不使用故事板... –
这将取代我的旧故事板成一个只有一个视图控制器的新故事板。更好地测试它，否则我会向社区报告。 –