Ноутбук на рабочем месте подключается к монитору (опционально двум) кто-то использует сам ноутбук кто-то нет, дело каждого. Кто не хочет сидеть сгорбившись за ноутбуком вполне может этого не делать.
Причина тормозов стартового проекта (в статье ссылка не правильная но из оригинала ее можно взять) вызов функции заблюривания в главном потоке. Стоит делать это в фоне и все начнет летать без применения AsyncDisplayKit'а.
Т.е. по сути тут решается проблема плохой архитектуры за счет подключения тяжеловесной библиотеки.
Есть решения которые позволяют стилизовать даже без написания функций под каждый стиль.
Например в SKStyleKit используется описание стилей в виде JSON файла и в общем случае кода не приходится писать вообще.
Классические структуры из С так себя и ведут, но swift структуры вещь гораздо более сложная. Если в общем то поведение структуры будет сильно зависеть от ее наполнения. Если структура содержит пару примитивов, то тут все хорошо и ожидаемо. Но если структура содержит ссылки на классы то начинается форменная вакханалия, например имеем структуру с X полями которые являются классами, и передаем такую структуру в метод. Был бы это класс мы бы получили вызов retain при входе и вызов release при выходе, но у нас ведь структура поэтому вызов retain/release будет сделан для КАЖДОГО поля. Не спасает дело и то что String в swift структура, на самом деле String будет структурой (в классическом понимание) если это константа объявленная в коде, если нет то String будет оболочкой над классом и соответсвенно помещение такой строки в структуру равноценно помещению туда класса. (похожая ситуация и со swift коллекциями)
Дальше интересней, для структуры генерится больше бинарного и бит кода чем для класса (это связано именно с такой сложной реализацией) что увеличивает размер приложения что в свою очередь уже само по себе его замедляет.
Т.е. по сути эффективное использования структур это то как они использовались в ObjC где структуры содержали 2 — 3 примитива (CGPoint, CGRect и тп)
Но подобные стайлгайды говорят что надо использовать структуры везде где можно, т.к. они не вызывают retain cycle'ов передаются по значению и «защищают» от наследования. В результате на свет рождаются огромные формации с 5+ класс полей, это все накапливается в проекте, начинает подтормаживать дистрибьютив пухнет и когда становится ясно в чем дело менять все как правило уже либо поздно либо трудно.
Надеюсь, что SwiftLint более основан на здравом смысле чем на GitHub's Swift Style Guide, в последнем встречаются реально вредные советы, одно только Prefer structs over classes сколько способно создать проблем в более-менее большом проекте.
Устаревший и низкоуровневый все таки совсем разные вещи, по такой терминологии Macaw тоже устаревший т.к. рисует все методами «устаревшего» Core Graphics API
Перегрузка операторов это то что по возможности стоит избегать, а если и применять то очень сильно подумав (мне, например, известны случаи когда перегруженный оператор + давал разные результаты при перестановке слагаемых)
Ввод новых операторов это то что стоит избегать всегда. Вам может быть и кажется очевидным что такое "°" но поверьте это неизвестно больше никому. Вводя такие операторы вы значительно увеличиваете время на изучения вашего API ради чуть более красивого написания.
Согласен, но этот цикл по идее должен на каждом шаге вызывать next() проверять что следующий элемент существует и выполнять тело цикла если это так. Что совсем не тоже самое по скорости чем уменьшать значение i на 1 и проверять что оно не стало меньше нуля.
Swift современный и крутой. Приходится быть современным, если хочешь перерасти Obj-C. Нужна решимость, чтобы избавиться от этих C-подобных циклов, использующихся с 1972 года. Будем надеяться на лучшее!
Я вот например считаю что перерастать Objective-C не требуется, это не некая устаревшая технология, а отличный инструмент со своими сильными и слабыми сторонами, как и Swift.
Хотя отказ от c-style циклов и инкрементов имеет под собой основу: инкремент в Swift представляет собой чисто синтаксическую возможность и x++ и x += 1 по сути ничем не различаются.
С циклами все более странно, в принципе в классических for циклах нет ничего плохого, но реализованы они в Swift так что
for i in 0 ..< x
работает быстрее чем
for var i = 0; i < x; i++
возможно стоит оптимизировать c-style циклы, а не убирать их из языка. Кроме того, for in не поддерживает декремент.
initialize() и destroy() предназначены для работы с объектами, для основных типов они ничего не делают. Впрочем вы правы, стоит поправить, чтобы не возникало недопонимания.
Да, вы правы если pSize будет иметь время жизни большее чем data то это приведет к чтению освобожденной памяти. Так что применяя указатели нужно быть очень внимательным.
Если имеется ввиду чтение GIF хедера то непосредственно «неуправляемого» массива там нет, есть набор байт который управляется объектом типа NSData, я же описал как с помощью указателей интерпретировать данные из этого массива (в данном случае как строку и структуру с двумя целыми числами)
Верно, как следствие от выравнивания наличие минимального расстояния в массиве структур между структурами которое в общем случаем может не совпадать с размером структуры.
var json: [String: AnyObject]!
<...>
json = try NSJSONSerialization.JSONObj...
Логичная, но медленная конструкция. Лучше использовать:
var json: NSDictonary!
А еще когда открываешь чужой код и видишь там что-то типо <~~ вместо вызова функции с именем дающим хоть какой-то намек на то что она делает испытываешь смешанные чувства.
Я бы сказал что сейчас стоит использовать (и вообще задумываться) о ручной верстке в двух случаях:
1. Когда требуется что-то что нельзя задать в рамках Auto Layout, но с таким я сталкивался всего два раза.
2. Требуется считать раскладку очень быстро, например, множество сложных ячеек в таблице.
Во всех остальных случаях ручная верстка дает больше проблем чем пользы, как правильно заметил автор очень много кода, который потом еще надо и как-то поддерживать.
Т.е. по сути тут решается проблема плохой архитектуры за счет подключения тяжеловесной библиотеки.
Например в SKStyleKit используется описание стилей в виде JSON файла и в общем случае кода не приходится писать вообще.
Дальше интересней, для структуры генерится больше бинарного и бит кода чем для класса (это связано именно с такой сложной реализацией) что увеличивает размер приложения что в свою очередь уже само по себе его замедляет.
Т.е. по сути эффективное использования структур это то как они использовались в ObjC где структуры содержали 2 — 3 примитива (CGPoint, CGRect и тп)
Но подобные стайлгайды говорят что надо использовать структуры везде где можно, т.к. они не вызывают retain cycle'ов передаются по значению и «защищают» от наследования. В результате на свет рождаются огромные формации с 5+ класс полей, это все накапливается в проекте, начинает подтормаживать дистрибьютив пухнет и когда становится ясно в чем дело менять все как правило уже либо поздно либо трудно.
Устаревший и низкоуровневый все таки совсем разные вещи, по такой терминологии Macaw тоже устаревший т.к. рисует все методами «устаревшего» Core Graphics API
Ввод новых операторов это то что стоит избегать всегда. Вам может быть и кажется очевидным что такое "°" но поверьте это неизвестно больше никому. Вводя такие операторы вы значительно увеличиваете время на изучения вашего API ради чуть более красивого написания.
Я вот например считаю что перерастать Objective-C не требуется, это не некая устаревшая технология, а отличный инструмент со своими сильными и слабыми сторонами, как и Swift.
Хотя отказ от c-style циклов и инкрементов имеет под собой основу: инкремент в Swift представляет собой чисто синтаксическую возможность и x++ и x += 1 по сути ничем не различаются.
С циклами все более странно, в принципе в классических for циклах нет ничего плохого, но реализованы они в Swift так что
for i in 0 ..< x
работает быстрее чем
for var i = 0; i < x; i++
возможно стоит оптимизировать c-style циклы, а не убирать их из языка. Кроме того, for in не поддерживает декремент.
Логичная, но медленная конструкция. Лучше использовать:
А еще когда открываешь чужой код и видишь там что-то типо <~~ вместо вызова функции с именем дающим хоть какой-то намек на то что она делает испытываешь смешанные чувства.
И вот так работает быстрее, хотя объяснений у меня этому нет:
1. Когда требуется что-то что нельзя задать в рамках Auto Layout, но с таким я сталкивался всего два раза.
2. Требуется считать раскладку очень быстро, например, множество сложных ячеек в таблице.
Во всех остальных случаях ручная верстка дает больше проблем чем пользы, как правильно заметил автор очень много кода, который потом еще надо и как-то поддерживать.