Xcode 6带有Swift超慢速打字和自动完成功能

11 回答

• 2

  通常，将缓存文件夹（DerivedData）移动到SSD驱动器（特别是在我的情况下 - 连接到thunderbolt出口的外部存储器）已经大大提高了我的Xcode性能 . 编译时间和应用程序周围的一般想知道快了大约10倍..还将整个git文件夹移动到SSD，这大大提高了git性能 .

  回复于 2024-04-28T15:08:51+08:00
• 5

  直到XCode 7.2才痛苦 .

  Apple在XCode 7.3中修复它，现在它就像一个魅力 . 它的速度超快，功能强大，因为它似乎有点像文件的模糊搜索：你不必实际输入方法/属性的确切开头，它就会出现在命题列表中 .

  回复于 2024-04-28T15:08:51+08:00
• 81

  折叠所有方法有点帮助 .

  命令-alt-shift-left arrow将起到作用......

  折叠/展开当前方法或结构使用：

  折叠：命令 - alt-左箭头

  展开：命令alt-right箭头

  回复于 2024-04-28T15:08:51+08:00
• 12

  • 退出Xcode并重新启动Mac不是必需的，但首选 .

  • 删除〜/ Library / Developer / Xcode / DerivedData文件夹的 content

  • 删除 content ~ / Library / Caches / com.apple.dt.Xcode

  这是暂时的解决方案，但效果很好 .

  使用脚本编辑器app在脚本下方 .

  tell application "Terminal"
      do script "rm -frd ~/Library/Developer/Xcode/DerivedData/*"
      do script "rm -frd ~/Library/Caches/com.apple.dt.Xcode/*"
  end tell
  

  或者，您可以为终端创建一个别名，如下所示：

  alias xcodeclean="rm -frd ~/Library/Developer/Xcode/DerivedData/* && rm -frd ~/Library/Caches/com.apple.dt.Xcode/*"
  

  您可以将其添加到 ~/.bash_profile ，然后每次要清除这两个文件夹时在命令行上键入 xcodeclean .

  回复于 2024-04-28T15:08:51+08:00
• 1

  在键入一些“简单”代码时，我也经历了100％的CPU . 一些小技巧可以通过构造代码的方式使swift-parser更快 .

  不要在字符串中使用“”concatinator . 对我来说，这很快就会触发缓慢 . 每个新的“”都会使解析器进行爬行，并且每次在函数体中的某处添加新的char时都必须重新解析代码 .

  代替：

  var str = "This" + String(myArray.count) + " is " + String(someVar)
  

  使用模板语法，在swift中解析效率似乎更高效：

  var str = "This \(myArray.count) is \(someVar)"
  

  这种方式我基本上没有限制strlen与内联变量“\（*）” .

  如果你有计算，使用/ * - 然后将它们分成更小的部分 .

  代替：

  var result = pi * 2 * radius
  

  使用：

  var result  = pi * 2
      result *= radius
  

  它可能看起来效率较低，但快速解析器的速度要快得多 . 如果某些公式必须进行多次操作，即使它们在数学上是正确的，也不会编译 .

  如果你有一些复杂的计算，那么把它放在一个函数中 . 这样解析器可以解析一次，并且不必在每次更改函数体中的内容时重新解析它 .

  因为如果你的函数体中有一个计算，那么如果类型，语法等仍然正确，那么swift解析器每次都会检查它 . 如果一条线在计算之上变化，则计算/公式中的某些变量可能已更改 . 如果你将它放在一个外部函数中，那么它将被验证一次，并且swift很高兴它将是正确的并且不会不断地重新解析它，这导致高CPU使用率 .

  这样，我在每次按键时从100％到达低CPU同时输入 . 例如，在函数体中内联的这3行可以使swiftparser爬行 .

  let fullPath =  "\(NSHomeDirectory())/Library/Preferences/com.apple.spaces.plist"
  let spacesData  = NSDictionary(contentsOfFile: fullPath )! // as Dictionary<String, AnyObject>
  let spaces : AnyObject   = spacesData["SpacesDisplayConfiguration"]!["Management Data"]!!["Monitors"]!![0]["Spaces"]!! 
  
  println ( spaces )
  

  但如果我把它放在一个函数中并稍后调用它，swiftparser会更快

  // some crazy typecasting here to silence the parser
  // Autodetect of Type from Plist is very rudimentary, 
  // so you have to teach swift your types
  // i hope this will get improved in swift in future
  // would be much easier if one had a xpath filter with
  // spacesData.getxpath( "SpacesDisplayConfiguration/Management Data/Monitors/0/Spaces" ) as Array<*> 
  // and xcode could detect type from the plist automatically
  // maybe somebody can show me a more efficient way to do it
  // again to make it nice for the swift parser, many vars and small statements
  func getSpacesDataFromPlist() -> Array<Dictionary<String, AnyObject>> {
    let fullPath =  "\(NSHomeDirectory())/Library/Preferences/com.apple.spaces.plist"
  
    let spacesData  = NSDictionary(contentsOfFile: fullPath )!    as Dictionary<String, AnyObject>
    let sdconfig    = spacesData["SpacesDisplayConfiguration"]    as Dictionary<String, AnyObject>
    let mandata     = sdconfig["Management Data"]                 as Dictionary<String, AnyObject> 
    let monitors    = mandata["Monitors"]                         as Array<Dictionary<String, AnyObject>> 
    let monitor     = monitors[0]                                 as Dictionary<String, AnyObject>
    let spaces      = monitor["Spaces"]                           as Array<Dictionary<String, AnyObject>>
  
    return spaces
  }
  
  func awakeFromNib() {
    ....
    ... typing here ...
  
    let spaces = self.getSpacesDataFromPlist()
    println( spaces) 
  }
  

  Swift和XCode 6.1仍然非常错误，但如果你遵循这些简单的技巧，编辑代码将再次被接受 . 我更喜欢快速，因为它摆脱.h文件并使用更清晰的语法 . 还有许多类型转换需要像“myVar as AnyObject”，但与复杂的objective-c项目结构和语法相比，这是更小的邪恶 .

  还有另一种体验，我尝试了SpriteKit，使用起来很有趣，但是如果你不需要以60fps的恒定重绘效果它非常有效 . 如果你的“精灵”经常不改变，那么使用旧的CALayers对CPU来说要好得多 . 如果你没有更改图层的.contents，那么CPU基本上是空闲的，但是如果你有一个在后台运行的SpriteKit应用程序，那么其他应用程序中的videoplayback可能会因为60fps的硬限制更新循环而开始出现断断续续的情况 .

  有时xcode在编译时显示奇怪的错误，然后它有助于进入菜单“Product> Clean”并再次编译它，似乎是缓存的错误实现 .

  在另一个stackoverflow帖子here中提到了另一种在xcode卡住你的代码时改进解析的好方法 . 基本上，您将.swift文件中的所有内容复制到外部编辑器中，然后通过功能将其复制回来，看看您的瓶颈在哪里 . 这实际上帮助我获得了xcode在我的项目疯狂100％CPU后再次合理的速度 . 在复制你的代码时，你可以重构它并尝试保持你的函数体简短，函数/公式化/表达式简单（或分成几行） .

  回复于 2024-04-28T15:08:51+08:00
• 1

  自从Xcode 4以来，自动完成功能被破坏 . 在Apple决定修复这个2岁的bug之前，唯一的解决方案是在XCode的首选项上完成代码完成 OFF （下图中的第一个选项） .

  您可以在需要时通过键入 CTRL space 或 ESC 继续享受手动完成 .

  对于100％的案例，这是唯一有效的解决方案 .

  

  我最近发现的另一件事是：如果你在Xcode上使用插件，那就不要了 . 全部删除它们 . 他们使问题变得更糟 .

  回复于 2024-04-28T15:08:51+08:00
• 2

  你在使用Spotify吗？我在2009年中期的iMac（2.66Ghz）上安装了Yosemite GM与Xcode 6.1 GM有同样的问题 . 我发现一个名为“SpotifyWebHelper”的过程总是标记为红色，因为没有响应，所以我禁用了“从网络开始”选项spotify，现在Xcode似乎运行得更好 .

  回复于 2024-04-28T15:08:51+08:00
• 10

  即使在Xcode 6.3中我也遇到了同样的问题

  • 超慢自动填充

  • 超慢索引

  • swift和SourceKitService的CPU使用量巨大

  • SourceKitService使用大量内存

  所有这一切都发生在相对较小的项目中 . 我尝试了所有可以找到的修复：

  • 删除〜/ Library / Developer / Xcode / DerivedData / *

  • 删除〜/ Library / Caches / com.apple.dt.Xcode / *

  • 从代码中删除所有"+"字符串组合

  • 删除了所有可疑字典声明

  这些都没有真正帮助我的项目 .

  实际解决了我的问题是：

  • 将每个类的每一端都放在自己的文件中

  • 将每个扩展名放在自己的文件中（Class ExtName.swift）

  • 将"out of class swift methods"放在自己的文件中

  现在我的CPU使用率接近零，内存使用率低，并且完成速度非常快 .

  回复于 2024-04-28T15:08:51+08:00
• 1

  我发现通常会发生在你：

  • 在单个语句中有长表达式（参见this answer）

  • 在单个表达式中混合多个自定义运算符

  第二种情况似乎是在最新的xcode版本中修复的 . 示例：我定义了2个自定义运算符<&&>和<||>，并在 a <&&> b <&&> c <||> d 等表达式中使用 . 分割成多行解决了这个问题：

  let r1 = a <&&> b
  let r2 = r1 <&&> c
  let r3 = r2 <||> d
  

  我希望您的案件由上述2中的一个涵盖......请在案例中发表评论

  回复于 2024-04-28T15:08:51+08:00
• 2

  SourceKitService 在处理代码中的注释时也有点笨拙， embedded comments 也放慢了速度 .

  所以，如果你有能力删除像这样的大量嵌入式评论：

  /*
   * comment 
      /*
       * embedded comment
       */
   */
  

  这肯定也有帮助 .

  ---

  NOTE: 在我的情况下，我的Xcode 7.3.1（7D1014）实际上阻止了我输入任何字母，当文件有大约700行注释与嵌入的注释 . 最初我从那个 .swift 文件中删除了该块，Xcode又重新活了起来 . 我尝试通过删除嵌入式注释来逐个添加我的注释，它仍然比平常慢，但如果没有嵌入注释，它会显示出更好的性能 .

  回复于 2024-04-28T15:08:51+08:00
• 2

  我遇到了同样的问题，其中打字在一个特定的类中滞后，结果证明了这一点

  /* Long multiline comments */

  正在减慢打字速度 .

  回复于 2024-04-28T15:08:51+08:00