• Секреты скорости Swift

    • Translation
    С момента анонса языка Swift скорость была ключевым элементом маркетинга. Еще бы – она упоминается в самом названии языка (swift, англ. — «быстрый»). Было заявлено, что он быстрее динамических языков наподобие Python и Javascript, потенциально быстрее Objective C, а в некоторых случаях даже быстрее, чем C! Но как именно они это сделали?

    Спекуляции


    Несмотря на то, что сам язык предоставляет огромные возможности для оптимизации, у нынешней версии компилятора с этим не все в порядке, и получить хоть какие-то успехи в тестах производительности стоило мне немало сил. В основном это происходит из-за того, что компилятор генерирует массу излишних действий retain-release. Думаю, что это быстро поправят в следующих версиях, но пока мне придется говорить о том, благодаря чему Swift может быть потенциально быстрее Objective C в будущем.

    Более быстрая диспетчеризация методов


    Как известно, каждый раз, когда мы вызываем метод в Objective C, компилятор транслирует его в вызов функции objc_msgSend, которая занимается поиском и вызовом нужного метода в рантайме. Она получает селектор метода и объект, в таблицах методов которого производится поиск непосредственного куска кода, который будет обрабатывать этот вызов. Функция работает очень быстро, но зачастую делает куда больше работы, чем действительно нужно.

    Передача сообщений удобна тем, что компилятор не делает никаких предположений относительно того, какой объект попадется ему в рантайме. Это может быть экземпляр типа выражения, дочерний класс, или вообще абсолютно другой класс. Компилятор можно обмануть, и все будет работать как положено.

    С другой стороны, в 99.999% случаев вы не будете врать компилятору. Когда объект объявлен как NSView *, это либо непосредственно NSView, либо дочерний класс. Динамическая диспетчеризация необходима, а вот настоящая пересылка сообщений практически не нужна, но природа Objective C заставляет всегда использовать самый «дорогой» вид вызовов.
    Читать дальше →
  • Ускорение компиляции в Xcode на swift

    С ростом проекта, скорость компиляции проекта замедляется. Особенно это заметно становится, когда тестируешь программу, делая параллельно небольшие изменения в программе.

    Сначала давайте узнаем как долго компилируется проект до наших улучшений. ЧТобы это сделать надо в терминале ввести

    defaults write com.apple.dt.Xcode ShowBuildOperationDuration -bool YES

    Для этого нужно зайти в раздел Product зажать alt и нажать Clean Build Folder, а потом собрать проект заново. Мой проект компилируется 81 секунду. Посмотрим какой результат будет после улучшения.



    Нам, в первую очередь, стоит узнать какие места приводят к замедлению компиляции. По умолчанию Xcode не показывает предупреждения, где проблема, но мы можем это исправить.
    Самые «тяжелые» места большие функции и проверка типов. Поэтому нам нужно вписать эти две строчки в раздел Build Settings -> Other Swift Flags -> Debug

    -Xfrontend -warn-long-function-bodies=100
    -Xfrontend -warn-long-expression-type-checking=100

    (здесь у нас стоит 100мс время компиляции, мы можем поставить любое число)

    Наглядный рисунок


    Пример моего рабочего проекта



    У меня есть участок который занимает 13778 ms, скорее всего у вас не будет такого, но из-за специфики проекта у меня такие участки есть. Так как там построено бинарное дерево для OCR.
    Из-за глубокой вложенности друг в друга и определения типа только в самом начале, перед знаком равенства, компилятору требуется много времени понять какой перед ним тип. (Дерево занимает 30 строк, вот его часть)
    Читать дальше →
    • +15
    • 5.6k
    • 6
  • The Processing of Unrecoverable Errors in Swift

    • Tutorial

    Preface


    This article is an example of how we can do research into Swift Standard Library functions behavior building our knowledge not only on the Library documentation but also on its source code.


    Unrecoverable Errors


    All events which programmers call "errors" can be separated into two types.


    • Events caused by external factors such as a network connection failure.
    • Events caused by a programmer's mistake such as reaching a switch operator case which should be unreachable.
    Read more →
  • Core Data в деталях

      Недавно я начала работать над большим проектом с использованием Core Data. Обычное дело, что люди на проектах меняются, опыт теряется, а нюансы забываются. Углубить всех в изучение конкретного фреймворка невозможно — у всех полно своих рабочих проблем. Поэтому я подготовила небольшую презентацию, из тех пунктов, которые считаю важными или недостаточно освещенными в туториалах. Делюсь со всеми и надеюсь, что это поможет писать эффективный код и не делать ошибок. Предполагается, что вы уже немного в теме.

      Начну с банального.

      Core Data – это фреймворк, который управляет и хранит данные в приложении. Можно рассматривать Core Data, как оболочку над физическим реляционным хранилищем, представляющую данные в виде объектов, при этом сама Core Data не является базой данных.

      Объекты Core Data


      image
      Читать дальше →
      • +7
      • 34.5k
      • 6
    • Memory Management: ARC vs MRC в iOS

        Как работает Automatic Reference Counter в iOS? На самом деле эту тему мне было легче понять после того, как я познакомился с Manual Reference Counter. Это очень простая статья, которая помогает базово понять как работает управление памятью в iOS.

        Для управления памятью в iOS есть несколько инструментов:

        Читать далее
      • Отключение профиля DEP и MDM на Mac OS Big Sur

        Решение с обходом DEP и MDM блокировки на Mac OS Catalina достаточно простое и без труда находится в интернете. С Big Sur все намного сложнее. В новой операционной системе реализован новый механизм защиты целостности системы. Поэтому весь алгоритм действий усложнился.

        Читать далее
      • Контроль соблюдения контракта API — ограничения или возможности

          Из этой статьи вы узнаете, какие преимущества предоставляет контроль контракта API, что можно и нужно контролировать и как организовать процедуры контроля для исключения негативного влияния на производство.

          Когда в 1825 году Англия первыми из всех запустила железнодорожное сообщение между городами, мир еще жил по солнечному времени, ориентируясь на полдень – момент верхней кульминации солнца. Фактическая разница во времени между городами в одной географической полосе могла достигать 30 минут. Отсутствовала синхронизация.

          Поезд, который отправлялся из Лондона в 12:00 по местному времени и должен был прибыть в Бристоль в 13:00, по местному времени прибывал в 13:30. Для местных жителей и пассажиров поезда это не было критичным явлением, но для компании-перевозчика, которая строит бизнес вокруг расписаний, планировать работу с каждым новым маршрутом становилось дорогим удовольствием. К стандартным проблемам, как опоздания, сбои в работе или аварии, прибавилась еще одна – каждый новый маршрут кратно увеличивал затраты на перевозку.

          В итоге ввели специальный стандарт времени – железнодорожное время. Синхронизировали часы в каждом городе, где проходят пути. Решение было сложным и непопулярным среди жителей городов, но в итоге в 1880 году новый стандарт обрел правовой статус.
          Читать дальше →
        • Туториал по AsyncDisplayKit 2.0 (Texture): Начало работы

          • Translation
          • Tutorial


          «Искусство – это все, что вы можете сделать хорошо. Все, что вы можете сделать качественно» (Robert M. Pirsig).


          От переводчика:
          С появлением autoLayout создавать интерфейс iOS-приложения стало намного проще и быстрее. Вам больше не нужно думать о подгонке размеров под определенные устройства, autoLayout сделает это за вас. Вычисление происходит на основе констрейнтов относительно ближайших элементов. Чем больше таких зависимостей, тем дольше будет строиться autoLayout, и это основная проблема всех приложений с сложным интерфейсом.
          Использование AsyncDisplayKit позволит вам на порядок уменьшить объем работ, выполняемых в основном потоке, и реализовать сложные интерфейсы с минимальным количеством кода. Ребята из Raywenderlich сделали подробный и наглядный туториал по работе с ним. Надеюсь, что перевод статьи поможет вам ещё быстрее освоить этот фреймворк.
          Читать дальше →
          • +12
          • 10.2k
          • 2
        • Библиотека для работы с iOS-пермишенами, от идеи до релиза (часть 1)

            • Каĸ унаследовать Swift-ĸласс не целиĸом, а лишь то в нём, что тебе нужно?

            • Каĸ позволить юзеру твоей CocoaPods- или Carthage-библиотеĸи ĸомпилировать лишь те её части, что он действительно использует?

            • Каĸ раздербанить ресурсы iOS, чтобы достать оттуда ĸонĸретные системные иĸонĸи и лоĸализованные строĸи?

            • Каĸ поддержать completion blocks даже там, где это не предусмотрено дефолтным API системных разрешений?

            Читать полностью
          • Mobx — управление состоянием вашего приложения

            • Translation

            MobX это простое, опробованное в бою решение для управления состоянием вашего приложения. Этот туториал научит вас основным концептам MobX. MobX это автономная библиотека, но большинство используют ее в связке с React и этот туториал будет сфокусирован на этой комбинации.


            Основная идея


            Состояние (state ориг.) это сердце каждого приложения и нет более быстрого способа создания забагованого, неуправляемого приложения, как отсутствие консистентности состояния. Или состояние, которое несогласованно с локальными переменными вокруг. Поэтому множество решений по управлению состоянием пытаются ограничить способы, которыми можно его изменять, например сделать состояние неизменяемым. Но это порождает новые проблемы, данные нуждаются в нормализации, нет гарантии ссылочной целостности и становится почти невозможно использовать такие мощные концепты как прототипы(prototypes ориг.).


            MobX позволяет сделать управление состоянием вновь простым, вернувшись к корню проблемы: он делает невозможным инконсистентность состояния. Стратегия достижения этого довольно проста: убедится что, все что может быть вынуто из состояния, будет вынуто. Автоматически.

            Читать дальше →
          • Секрет формы иконок iOS: это сквиркл? Разбор

              Давайте сыграем в игру. У нас есть два ряда знакомых всем пользователям iOS-иконок. На первый взгляд иконки сверху и снизу одинаковые. Но это не так. В одном ряду вы видите настоящие иконки, а в другом подделку.





              Можете ли вы определить, где какие? Не торопитесь, посмотрите внимательно? Ну что, выбрали?

              Настоящие иконки находятся сверху. Думаю многие из вас заметили, что с нижними иконками что-то не так. По какой-то причине их форма выглядят неаккуратно, будто где-то был отрезан лишний пиксель. Почему так происходит?

              Дело в том, что поддельные иконки по форме — это квадраты с закруглёнными углами, ну и прямоугольник если говорить о серой подложке.

              Но! В интерфейсе iOS нет ни одного квадрата с закруглёнными углами. Все элементы в iOS, это не квадраты и прямоугольники — это суперэллипсы!

              Сегодня мы поговорим про секреты в дизайнах продуктов Apple. Что такое суперэллипс? В чём магия формы иконок? И почему HomePod — это суперяйцо.



              Читать дальше →
            • Парадигмы программирования. Data Driven vs Domain Driven

              Информационные технологии развиваются семимильными шагами, появляются новые устройства, платформы, операционные системы, и вместе с этим растет спектр задач, который приходится решать разработчикам. Но, не все так плохо — на помощь программистам спешат новые средства разработки, ide’шки, новые языки программирования, методологии и т.д. Один только список парадигм программирования впечатляет, а с учетом современных мультипарадигменных ЯП (например, C#) резонно встает вопрос: «Как с этим всем быть? Что выбрать?».

              Попробуем немного разобраться.
              Читать дальше →
            • Многопоточность (concurrency) в Swift 3. GCD и Dispatch Queues

                Надо сказать, что многопоточность (сoncurrency) в iOS всегда входит в вопросы, задаваемые на интервью разработчикам iOS приложений, а также в число топ ошибок, которые делают программисты при разработке iOS приложений. Поэтому так важно владеть этим инструментом в совершенстве.
                Итак, у вас есть приложение, оно работает на main thread (главном потоке), который отвечает за выполнение кода, отображающего ваш пользовательский интерфейс (UI). Как только вы начинаете добавлять к вашему приложению такие «затратные по времени» куски кода, как загрузка данных из сети или обработка изображений на main thread (главном потоке), то работа вашего UI начинает сильно замедляться и даже может привести к полному его «замораживанию».



                Как можно изменить архитектуру приложения, чтобы таких проблем не возникало? В этом случае на помощь приходит многопоточность (сoncurrency), которая позволяет одновременно выполнять две или более независимые задачи (tasks): вычисления, загрузку данных из сети или с диска, обработку изображений и т.д.
                Читать дальше →
              • Сложные отображения коллекций в iOS: проблемы и решения на примере ленты ВКонтакте

                  Привет! Меня зовут Саша, я iOS-разработчик в команде, которая делает ленту ВКонтакте. Сейчас расскажу, как мы оптимизируем отображение интерфейса и обходим связанные с этим проблемы.
                  Думаю, вы представляете, что такое лента VK. Это экран, где можно просматривать разнообразный контент: тексты, статичные картинки, анимированные гифки, встраиваемые элементы (видео и музыку). Всё это должно отображаться плавно, отсюда высокие требования к производительности решений.


                  Теперь посмотрим, какие существуют стандартные подходы к работе с отображениями и какие ограничения или преимущества следует учитывать.


                  Если вы больше любите слушать, чем читать, видеозапись доклада есть вот тут.


                  Читать дальше →
                • Создание зашифрованного диска с «двойным» дном с помощью Veracrypt

                  • Tutorial


                  VeraCrypt — свободный форк TrueCrypt используемый для сквозного шифрования в Windows, Mac OSX и Linux, и позволяет шифровать системный диск, отдельный внутренний или внешний диск или создавать виртуальные диски с использованием файлов-контейнеров.

                  В этой статье мы рассмотрим интересную возможность VeraCrypt для создания зашифрованного диска со скрытым разделом, этот метод, также называемый методом «двусмысленного шифрования», обеспечивает возможность правдоподобного отрицания наличия второго тома, т.к. не обладая нужным паролем, доказать существование скрытого тома не представляется возможным.
                  Читать дальше →