Я також відчував 100% + процесор під час введення «простого» коду. Деякі невеликі хитрощі, щоб зробити швидший аналіз синтаксичним процесом при структуруванні коду.
Не використовуйте конфінатор "+" у рядках. Для мене це викликає повільність дуже швидко. Кожен новий "+" приводить аналізатор до сканування, і він повинен перепаковувати код щоразу, коли ви додаєте нову значку десь у своєму функціональному тілі.
Замість:
var str = "This" + String(myArray.count) + " is " + String(someVar)
Використовуйте синтаксис шаблону, який здається набагато ефективнішим для швидкого розбору:
var str = "This \(myArray.count) is \(someVar)"
Таким чином, я в основному не помічаю обмеження в strlen з вбудованими параметрами "\ (*)".
Якщо у вас є обчислення, в яких використовується + / * - тоді розділіть їх на менші частини.
Замість:
var result = pi * 2 * radius
використання:
var result = pi * 2
result *= radius
Це може виглядати менш ефективно, але швидкий аналізатор набагато швидше. Деякі формули не збираються, якщо вони мають багато операцій, навіть якщо вони математично правильні.
Якщо у вас є складні обчислення, то покладіть їх у функцію. Таким чином, аналізатор може проаналізувати його один раз, і не потрібно його повторно аналізувати кожного разу, коли ви щось змінюєте у своєму функціональному тілі.
Тому що якщо у вас є функція обчислення в тілі функції, то якимось чином швидкий аналізатор перевіряє його щоразу, якщо типи, синтаксис тощо все ще є правильними. Якщо рядок змінюється вище обчислення, то деякі значення у вашому обчисленні / формулі можуть бути змінені. Якщо ви помістите його у зовнішню функцію, вона буде перевірена один раз, і швидкий радий, що вона буде правильною і не перезаписує її постійно, що спричиняє високе використання процесора.
Таким чином я отримав від 100% на кожне натискання клавіш на низький процесор під час набору тексту. Наприклад, ці 3 лінії, розміщені в рядку у вашому функціональному тілі, можуть привести швидкого парзатора до сканування.
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 як AnyObject", але це менше зло в порівнянні зі складною структурою та синтаксисом проекту target-c.
Також інший досвід, я спробував SpriteKit, який цікаво використовувати, але він досить неефективний, якщо вам не потрібно постійне перефарбовування в 60 кадрів в секунду. Використання старих CALayers набагато краще для процесора, якщо ваші "спрайти" не так часто змінюються. Якщо ви не змінюєте .contents шарів, тоді процесор в основному не працює, але якщо у вас програма SpriteKit працює у фоновому режимі, то відтворення відеозапису в інших додатках може почати заїкатися через жорсткий цикл оновлення 60 кадрів в секунду.
Іноді xcode показує дивні помилки під час компіляції, тоді це допомагає зайти в меню "Product> Clean" та скомпілювати його знову, здається, є помилковою реалізацією кешу.
Ще один чудовий спосіб поліпшити синтаксичний аналіз, коли xcode застрягає з вашим кодом, згадується в іншій публікації stackoverflow тут . В основному ви копіюєте весь вміст із .swift-файлу у зовнішній редактор, а потім за допомогою функції скопіюйте його назад і побачите, де знаходиться вузьке місце. Це фактично допомогло мені знову отримати xcode до розумної швидкості, після того, як мій проект зійшов з розуму зі 100% процесором. під час копіювання вашого коду назад, ви можете перефактурувати його та спробувати забезпечити прості функції (формули / формули / вирази) простими (або розділеними на кілька рядків).
