Уменьшаем размер приложения: проверенные способы / Хабр

Запоминайте все, что пользователь ввел

Во-первых, это сэкономит ему время.

Во-вторых, часто позволяет сократить число кликов (например, запоминание местоположения, личных данных, регулярных покупок)

https://www.youtube.com/watch?v=CWJAyCFZpdE

В-третьих, даст вам ценную информацию для анализа.

Отличным примером здесь служит опять-таки сервис Google Drive. Мгновенное автосохранение документов позволяет вообще не думать о том, что данные надо сохранять.

Или еще хороший пример – Amazon. Амазон постоянно накапливает информацию обо всех действиях (не только покупках) — что вы смотрели, куда ходили и т.д. Это позволяет создать отличную систему рекомендаций, при которой легко доступными оказываются именно те товары, которые вам интересны – «с этим товаром часто покупают» и пр.

Эта статья не касается многих вопросов — специфики е-коммерса, энтерпрайза, web vs mobile, mobile vs планшет, форм, авторизаций, обработки ошибок, а также вопросов, связанных с построением процесса (это уже в случае, когда дизайнер на проекте есть). Если что-то из этого сообществу интересно, то дайте знать.

А вот небольшой список книг, которые могут быть полезны для углубления в тематику.

Для разработчиков:Джеф Раскин. ИнтерфейсАлан Купер. Об интерфейсеBruce Tognazzini. Tog on Interface

Есть еще отличная книга Дженнифер Тидвелл «Разработка пользовательских интерфейсов», но она уже более специализированная.

Для руководителей проектов:Алан Купер. Психбольница в руках пациентов

Для тех, чей мозг нуждается в перезагрузке:Виктор Папанек. Дизайн для реального мираДональд Норман. Дизайн привычных вещей

Ну и главная, на мой взгляд, книжка про то, как создавать хорошие продукты, это биография Стива Джобса, автор Айзексон

Приятной работы над проектами 🙂

Делайте основные функции как можно доступнее и прячьте редкие функции

Согласитесь, проще разобраться в Google Docs, чем в MS Office?

Да, гугл-докс покрывает меньше кейсов, но это 90% самых распространенных кейсов. Да, в 10 случаях из 100 придется заморочится офисом, но в 90 случаях люди будут куда более счастливы. А кому-то эти редкие функции вообше никогда не понадобятся.

Кому нужны редкие функции — и так до них доберутся.

Что дальше?

Я планирую сделать несколько выпусков в этой рубрике. И в каждом выпуске рассматривать несколько приложений (либо от одного производителя, либо одной тематики) и рассказывать, чем в каждом конкретном случае обусловлен большой объем приложений.

Что значат папки

Конечно, в APK можно найти еще много разных файлов (а в папке res – много разных типов ресурсов), но основные здесь перечислены.

«пожиратели» мегабайт

В случае с приложением «Мой МТС» все оказалось просто: больше всего объема уходит на банальную рекламу в виде картинок и видео.

Но бывают и другие «пожиратели» мегабайт:

• Внутренние справочники тех или иных данных. В том же приложении «Мой МТС» справочник тарифов занимает 4,6 Мб.
• Библиотеки. Например, разработчик приложения решил подключить для чатов библиотеку Hyphenate. И не посмотрел, что по умолчанию предлагается вариант с кодеками для голосовых звонков и видеовызовов. В итоге приложение получает в нагрузку несколько десятков мегабайт.
• Графика. Однажды я помогал дизайнеру участвовать в конкурсе компании Samsung. Разрабатываемое приложение представляло собой офлайн-справочник, довольно простой с точки зрения разработки (немного анимаций да простое перелистывание страниц), но очень насыщенный графикой. Было нарисовано больше сотни изображений в разрешении QHD. После одной из промежуточных версий (включавшей в себя далеко не все изображения) стало понятно, что приложение получается слишком большим. И было принято решение ограничить графику разрешением HD. Оценка результата на целевом планшете (Galaxy Tab S) дизайнера устроила, а объем при этом был уменьшен почти в 4 раза.

Самое важное

Как этим будут пользоваться? Это самое важное, что нужно понимать.

Мне нравится определение Джефа Раскина (дизайнера, работавшего в т.ч. над легендарным Apple II и написавшего культовую среди дизайнеров книжку “Интерфейс”), что интерфейс — это способ взаимодействия с продуктом.

То есть — это не внешняя красота в первую очередь, надо четко представить себе, как вашим продуктом будут пользоваться.

Теперь расставьте приоритеты.Выделите 1-2 основные функции и кейса использования и сфокусируйте на них усилия. Если недопилили что-то второстепенное — пользователи с большей вероятностью это простят.

Убирайте лишние клики

Чем меньше действий для достижения цели — тем, как правило, лучше. Например, сделайте список из радиобаттонов вместо комбобокса (если позволяет место), это сократит один клик.

Или — автоматически определяя местоположение пользователя, вы избавляете его от необходимости тратить время на ручной ввод места.

Как только вы начнете думать над тем, что бы еще убрать, как найдете кучу мест, которые можно улучшить.

Чем меньше элементов — тем проще изучить, как приложение работает.Поэтому выбросьте все, что можно, не заставляйте пользователя изучать лишнее.

Формы, ошибки, обратная связь

Из всех best practice самые важные — для форм, обработки ошибок и обратной связи.

Разного рода формы — один из основных способов передачи информации от пользователя к вам. Регистрация, заказы, сообщения — это все формы.Сделать хорошую форму – это обширная и отдельная тема, обсуждение которой уведет нас сильно в сторону. Например, Люк Вроблевски (Luke Wroblevski) написал об этом отдельную книгу.

Людям свойственно ошибаться. Сделайте так, чтобы ошибку было легко исправить.Если исправить ее нельзя, хотя бы предупреждайте об этом с помощью специального сообщения.Как именно делать отмену — отдельный вопрос, и тянет на полноценную тему для отдельной статьи.

Обратная связь при совершении каких-либо действий – еще один важный момент, очень сильно влияющий на восприятие приложения в целом. Если пользователь что-то добавил, отправил, удалил, изменил – сообщите ему об этом. Иначе он будет по сто раз совершать одно и то же действие и недоумевать, почему ничего не происходит.Если данные долго грузятся – повесьте лоадинг, так ваше приложение будет казаться менее тормознутым.

Держите важную информацию на виду

Что есть важная информация?

Та, которая сообщает о состоянии системы и позволяет быстро навигироваться по ней. Обычно это:

1) саммари или корзина

2) быстрый выход в меню и другие части системы,

3) поиск

Удобно это делать панелькой в верхней части интерфейса и замораживать ее при скролле.

Этот прием используют почти все – от Apple и Google, до любого сервиса, который делает кнопку «Выйти» в правом верхнем углу.

Графический контент

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

Кроме того, зачастую в проекты по умолчанию добавляются наборы изображений под различные форм-факторы мобильных устройств, как например @1x, @2x, @3x для iOS приложений. Ниже мы приведем методы, которые использовали в своих приложениях, чтобы разрешить проблему с обилием графического контента. Возможно, какие-то из них вы применяете и сами.

Один из простейших путей — использовать вместо трех масштабов только 3x изображение. Этот способ не назовешь оптимальным, так как на устройствах, ориентированных под 1x и 2x масштабы, такие изображения не всегда будут смотреться приемлемо. Однако за неимением лучшего этим приемом можно неплохо уменьшить размер проекта при огромном количестве графики.

Другой способ завязан на добавлениеи векторных изображений вместо растровых. На iOS мы экспортировали изображения в формат PDF. Зачастую такой файл действительно весит меньше, однако это работает не со всеми изображениями. Загвоздка здесь в том, что в векторная графика может некорректно отображать некоторые маски изображения, делая их абсолютно черными или искажая цвета.

Теперь рассмотрим пример с приложением, имеющим несколько цветовых схем (в простонародье «скин»). Чем больше цветовых схем в приложении, тем сильнее возрастает количество необходимых изображений. Если в изображении используется более одного цвета, то приходится хранить несколько вариантов на каждый скин.

1. выставить Template Image в самом XCode (см. Рис.1);
2. задать шаблонный режим программно

Рис.1. Выставление шаблонного режима изображения в XCode.

UIImage *templateImage = [[UIImage imageNamed:@«Back Chevron»] imageWithRenderingMode:UIImageRenderingModeAlwaysTemplate]; 
[backButton setTintColor:[UIColor blueColor]];

— где UIImageRenderingModeAlwaysTemplate и является шаблонным режимом изображения.

Замена анимационных изображений

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

Другие же, более сложные, требуют отрисовки каждого кадра анимации. Когда мы впервые столкнулись с добавлением анимационного изображения в ходе разработки, то использовали для его реализации один из распространенных способов, а именно анимирование через массив изображений. Выглядело это так:

NSArray *gif=@[@"frame1",@"frame2",@"frame3",@"frame4",@"frame5", @"frame6",@"frame7",@"frame8",@"frame9",@"frame10"];
NSMutableArray <UIImage *> *images = [[NSMutableArray alloc] init];
for (int i = 0; i < gif.count; i  )
{
        	UIImage *image=[UIImage imageNamed:[gif objectAtIndex:i]];
        	[images addObject:image];
}
imageView.animationImages = images;
imageView.animationDuration = 0.3;
imageView.animationRepeatCount=1;
[imageView startAnimating];

Сначала создается массив с названиями изображений, затем — массив который поочередно пополняется изображениями из названий. Потом у переменной типа UIImageView задаются массив изображений для анимации, продолжительность анимации и количество повторений.

После чего запускается сама анимация. Однако если кадров много и при этом на каждый из них приходится по три масштаба, то для размера приложения это не сулит ничего хорошего. Придя к такому печальному итогу, мы задались поиском способа добавления gif-файла вместо массива картинок.

  (UIImage * _Nullable)animatedImageWithAnimatedGIFData:(NSData * _Nonnull)theData;
  (UIImage * _Nullable)animatedImageWithAnimatedGIFURL:(NSURL * _Nonnull)theURL;

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

Однако gif-файл тоже занимает пространство, поэтому мы старались выполнить все анимации программно. В Audio Editor Tool на стартовом экране у нас проигрывается анимация появления логотипа AUDIO EDITOR побуквенно. Раньше данная анимация была реализована с помощью гифки, но из-за большого разрешения изображения весила она многовато. Поэтому мы решили реализовать ее с помощью CABasicAnimation.

CAGradientLayer *gradient=[CAGradientLayer layer];
gradient.frame=animationLabel.bounds;
gradient.colors = @[(id)[UIColor colorWithWhite:1 alpha:1.0].CGColor,
                    (id)[UIColor clearColor].CGColor];
gradient.startPoint = CGPointMake(0.0, 0.5);
gradient.endPoint = CGPointMake(0.1, 0.5);
animationLabel.layer.mask=gradient;
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(0.99 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
    gradient.colors = @[(id)[UIColor colorWithWhite:1 alpha:1.0].CGColor,
                        (id)[UIColor colorWithWhite:1 alpha:1.0].CGColor];
});
CABasicAnimation *startPoint=[CABasicAnimation animationWithKeyPath:@"startPoint"];
startPoint.fromValue= [NSValue valueWithCGPoint:CGPointMake(0.0, 0.5)];
startPoint.toValue= [NSValue valueWithCGPoint:CGPointMake(1.0, 0.5)];
startPoint.duration = 0.9;
[startPoint setBeginTime:0.1];
startPoint.removedOnCompletion=NO;
CABasicAnimation *endPoint=[CABasicAnimation animationWithKeyPath:@"endPoint"];
endPoint.fromValue= [NSValue valueWithCGPoint:CGPointMake(0.1, 0.5)];
endPoint.toValue= [NSValue valueWithCGPoint:CGPointMake(1.0, 0.5)];
endPoint.duration = 1.0;
[endPoint setBeginTime:0.0];
endPoint.removedOnCompletion=NO;
CAAnimationGroup *group = [CAAnimationGroup animation];
[group setDuration:1.2];
[group setAnimations:[NSArray arrayWithObjects:startPoint, endPoint, nil]];
[ gradient addAnimation:group forKey:nil];

Чтобы логотип у нас появлялся побуквенно, как на гифке, мы использовали градиентную маску, которая со временем смещала начальную позицию прозрачности. Для начала мы создали слой градиента, у которого прозрачный цвет идет практически с самого начала. Потом задали градиент как маску слоя текста логотипа, тем самым делая его прозрачным.

Следующим шагом создали группу анимаций, в которую добавили две анимации. Первая из них смещала начальную позицию градиента, а вторая — конечную, тем самым делая его непрозрачным. Отметим один нюанс: важным шагом было указать в свойстве removeOnCompletion отрицательное значение, иначе анимация была бы удалена по завершению и слой вернулся бы к начальному значению.

Как смотреть

APK представляет собой zip-файл, его можно просто переименовать и распаковать. Или воспользоваться инструментом «Analyze APK» из Android Studio. В этом случае сразу будет виден размер папок, и можно будет понять, что стоит детально проанализировать, а на что можно не обращать внимания.

Конвертирование аудио

В наших приложениях часто используются аудиофайлы формата WAV. В силу своей структуры этот формат занимает много места в проекте. По этой причине было решено сначала полностью заменить в бандле все файлы этого формата на более легковесный M4A, а потом, уже в самом приложении, конвертировать их в WAV.

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

 (void)convertAudio:(NSURL *)url toUrl:(NSURL *)convertedUrl{
    AVAudioFile *audioFile = [[AVAudioFile alloc] initForReading:url error:nil];
    AVAudioPCMBuffer *buffer = [[AVAudioPCMBuffer alloc] initWithPCMFormat:audioFile.processingFormat frameCapacity:(uint32_t)audioFile.length];
    [audioFile readIntoBuffer:buffer error:nil];
    NSDictionary *recordSettings = @{
                                     AVFormatIDKey : @(kAudioFormatLinearPCM),
                                     AVSampleRateKey : @(audioFile.processingFormat.sampleRate),
                                     AVNumberOfChannelsKey : @(audioFile.processingFormat.channelCount),
                                     AVEncoderBitDepthHintKey : @16,
                                     AVEncoderAudioQualityKey : @(AVAudioQualityMedium),
                                     AVLinearPCMIsBigEndianKey: @0,
                                     AVLinearPCMIsFloatKey: @0,
                                     };
    AVAudioFile *writeAudioFile = [[AVAudioFile alloc] initForWriting:convertedUrl settings:recordSettings error:nil];
    [writeAudioFile writeFromBuffer:buffer error:nil];
}

В данном методе берется файл из бандла по url и сохраняется в директорию по convertedUrl. Считываемый файл загружается в буфер и уже оттуда записывается в новый с требуемыми настройками записи. Таким образом, мы используем более стабильный и тяжеловесный WAV после первого запуска, но при этом размер приложения существенно уменьшается на этапе загрузки и установки.

Масштабирование интерфейса в windows — история и проблемы

При покупке современного монитора или ноутбука мы очень часто сталкиваемся с тем, что картинка на экране выглядит мелкой, а если в настройках системы поставить масштаб больше, то некоторые программы начинают «мылиться». Причины такого поведения уходят корнями в бородатые 80ые, когда графические интерфейсы только-только начали появляться, так что начнем с истории возникновения таких параметров как DPI и PPI.

История появления 72 и 96 DPI

Давным-давно, когда Windows 1.0 еще был в разработке, а персональные компьютеры стоили дороже автомобилей, Apple представила миру Macintosh 128K, имеющий 9″ экран с разрешением 512х534 пикселя: на таком экране буква высотой в 72 пикселя выглядела ровно так же, как и буква высотой 1 дюйм на бумаге — так и родился стандарт 72 пикселя на дюйм (PPI — Pixel Per Inch). Тогда же, для связи изображения на экране и на бумаге, был придуман параметр DPI (Dots Per Inch — точек на дюйм), с которым можно столкнуться при сканировании документов или обработке фото. Иными словами параметр PPI — реальный: зная разрешение и диагональ монитора можно без труда узнать, сколько будет пикселей в дюйме, а параметр DPI – виртуальный, введенный лишь для усреднения и унификации при работе с текстом и на экране, и на бумаге. Если PPI монитора совпадает с DPI, под которое рассчитана система, то изображение будет выглядеть так же, как и на листе бумаги. Если PPI будет больше DPI, то картинка на экране будет меньше, чем на бумаге, и наоборот — если PPI меньше DPI то картинка на экране будет больше.

Параметр в 72 DPI был только у Apple, и Microsoft, дабы придумать что-то свое, рассчитали, что экран находится в среднем на 33% дальше, чем лист бумаги, когда мы с него читаем, и поэтому чтобы шрифт на бумаге и экране был одного размера, на экране он должен быть на 33% больше – отсюда и пошел стандарт 96 DPI (72*1.33=96):

Стандарт 96 DPI держится на ПК и до сих пор, хотя в телефонах и планшетах нередки значения в 200, 300 и даже 400 PPI — почему так? Потому что привязка к бумаге всегда была удобной при разработке приложений и выводе текста, к тому же в 80-90ых годах разрешение и размер мониторов росли более-менее пропорционально, и нужды менять стандарт не было. Но в конце 90ых прозвучали первые звоночки — стали появляться мониторы с большим разрешением (до 1600х1200), и при относительно небольших диагоналях PPI получался сильно выше 100. А так как в Windows 95/98 была строгая привязка к 96 DPI то текст на таких мониторах оказывался очень мелким. В прочем исправить этот недостаток было не трудно – ЭЛТ мониторы хорошо умели работать с несколькими разрешениями, и снизив гигантское 1600х1200 до 1024х768 можно было получить крупную и одновременно четкую картинку.

Но время шло, и на рынок стали поступать мониторы с ЖК-матрицами, и на них четко выводилось только наибольшее поддерживаемое разрешение — снижение разрешения приводило к замыливанию картинки. К тому же в погоне за красивыми цифрами производители выпускали мониторы с разрешением 1280х1024 — то есть соотношение сторон было 5:4, и поэтому при снижении разрешения до 1024х768 (чтобы текст был крупным) не только мылилась картинка, но еще и пропорции нарушались – 1024х768 имеет соотношение сторон 4:3. В общем где-то к середине нулевых стало понятно, что на Windows очень большие проблемы с масштабированием и нужно было что-то менять.

Проблемы с масштабированием интерфейса

В чем же проблема создания общего для системы масштабирования? Проблема в том, что шрифты в программах до сих пор считаются в DPI, а картинки – в пикселях. И окно программы выглядит четко и шрифты не перекрывают картинки только до тех пор, пока выполняются четко заданные создателем программы пропорции между размером текста и картинки. Теперь представим что мы выставили DPI = 150. Что произойдет с окном программы, рассчитанным под «стандартный» DPI=96? Размер шрифта, привязанный к DPI, увеличится в полтора раза, и текст может выйти за пределы отведенного для него места в программе и перекрыть картинки или вообще обрезаться, а картинки останутся все такими же мелкими. Если же окно программы – растровое изображение (то есть представляющее собой сетку пикселей), то при увеличении DPI оно просто растянется и станет нечетким:

В Windows XP Microsoft сделала первые шаги к решению проблемы – система говорит программе при запуске выставленный в ней глобальный DPI и устраняется: как там приложение отмасштабируется не ее дело. В итоге с учетом того, что разработчики приложений уже не один десяток лет писали под четко заданный DPI=96, большинство программ масштабировалось одним из двух способов, описанных выше, хотя появились первые исключения, имеющие в своем арсенале картинки нескольких разрешений и возможность адаптировать размер окна в зависимости от DPI — это в основном программы от Microsoft (браузер IE, офисный пакет и все стандартные приложения).

Масштабирование в Windows Vista, 7 и 8

К середине нулевых в Microsoft поняли, что с масштабированием нужно что-то делать, и придумали универсальный способ, проработавший без особых изменений вплоть до выхода Windows 10 в 2021 году. Он заключался в том, что теперь в системе можно выставить четко заданный глобальный DPI в процентах — за 100% разумеется принят 96 DPI, 125% — 120 DPI, 150% — 144 DPI, 200% — 192 DPI, а так же можно задать собственный DPI. В принципе это охватывало весь зоопарк устройств, начиная от FHD мониторов на 27″ (около 90 PPI) и заканчивая 2К матрицами в 13″ ультрабуках (около 200 PPI). И теперь разработчикам программ нужно всего лишь продублировать картинки в ней в 4 различных DPI, и в зависимости от системного DPI выводить в программе нужную картинку в том или ином разрешении (ну а нужный размер шрифта подтянется из системы) — в таком случае и весь текст достаточно крупный, и картинки четкие. Однако две проблемы все равно оставались:

• Многие «упертые» разработчики упорно писали программы в 96 DPI (или же банально не обновили свои программы под Windows Vista и новее). В таком случае Windows обрабатывает окно программы в 96 DPI, а потом выводит ее на экран как картинку, предварительно увеличив DPI до заданного в системе. Да, разумеется и текст и картинки в таком случае оказываются несколько размазанными, однако пропорции сохранены и работать с такой программой можно, хоть и неприятно.
• Так и не решена проблема с тем, что пользователь может выставить свой DPI — например 110. Тут программы опять работают кто во что горазд: хорошо написанные программы просто «подгоняют» пользовательский DPI под ближайший четко заданный — в данном случае это 120, и работают так, как будто в системе задан DPI=120. Да, окно программы получается чуть меньше или больше желаемого, однако и картинки, и шрифты четкие. Плохо написанные программы ведут себя или так же, как и написанные под 96 DPI — при выводе на экран мылятся шрифты и картинки, или же вообще игнорируют системный DPI и выводятся в 96 — то есть очень мелко.

В общем и целом за почти 10 лет с момента выхода Windows Vista разработчики большинства популярных приложений сделали оптимизацию как минимум под 125% масштаб, так что на большинстве современных мониторов с PPI 100-130 можно получить и четкую, и крупную картинку. Да, пользователи ультрабуков с PPI за 200 увы оказываются за бортом — мало кто из создателей программ будет заморачиваться ради 1% пользователей. Так же даже некоторые известные разработчики до сих пор не оптимизировали программы под Hi-DPI: к примеру клиенты Steam, Origin и Uplay до сих пор работают лишь с 96 DPI.

Масштабирование в Windows 10

Майкрософт не был бы Майкрософтом, если бы в Windows 10 не ввел новой алгоритм масштабирования, поломав уже почти 10 лет как существующий и хорошо работающий старый. Новый алгоритм основан на том, чтобы программы выглядели четко и крупно при любом DPI, а не только при 4ех заданных в системе (то есть так же, как и на Android, где на любом устройстве из целого зоопарка моделей программа выглядит нормально). В итоге программа, которая под Windows 8 в масштабе 150% выглядела четко и крупно, на 10ке выглядит так, как будто написана под 96 DPI и растянута системой в полтора раза. Да, разумеется некоторые программы уже адаптированы под новый способ масштабирование — например тот же браузер Google Chrome, ну а для всех других программ есть фикс, который возвращает старый тип масштабирования. Этот фикс — программа под названием XPExplorer, скачать ее можно бесплатно с официального сайта: XPExplorer. Работать с программой просто — нужно ее запустить, поставить галку напротив «Use Windows 8.1 DPI scaling», указать ниже нужный масштаб и добавить программу в автозагрузку:

Если же у Вас стоит масштаб порядка 125% и вы пользуетесь программой, которая умеет работать только с 96 DPI (100%), то можно для нее отключить масштабирование — тогда она будет выводиться в 96 DPI, что будет несколько мелко, но текст и картинки в ней будет четкими. Для этого нужно нажать правой кнопкой мыши по .exe программы, выбрать в выпавшем списке «Свойства», перейти в открывшемся окне во вкладку «Совместимость» и поставить галку напротив «Отключить масштабирование изображения при высоком разрешении экрана», после чего нажать кнопку «Применить»:

В общем и целом ситуация с масштабированием под Windows гораздо печальнее, чем под macOS, где используется всего несколько разрешений и размеров дисплеев, и проблем оптимизировать программы под несколько четко заданных PPI нет. Однако некоторые подвижки Microsoft все же делает, и есть надежда что в будущем Windows будет корректно работать на любом мониторе.

Подгрузка файлов с сервера

Подгрузка файлов с сервера — это то что нужно для приложений со значительным объемом контента. Большое количество пресетов музыки, наборы изображений и многое другое, что сильно увеличивает размер приложения, можно загрузить и позднее. Конечно, загрузка каждого отдельного файла потребовала бы много времени и трафика, поэтому с сервера подгружаются архивы со всем необходимым, а уже в самом приложении они распаковываются и сохраняются в директории приложения. Для разархивирования используется библиотека SSZipArchive (репозиторий библиотеки вы найдете

). Эта библиотека способна как упаковывать файлы в архив, так и распаковывать архивы. Но нас интересует только один метод из основного класса библиотеки:

  (BOOL)unzipFileAtPath:(NSString *)path toDestination:(NSString *)destination
    progressHandler:(void (^)(NSString *entry, unz_file_info zipInfo, long entryNumber, long total))progressHandler
    completionHandler:(void (^)(NSString *path, BOOL succeeded, NSError *error))completionHandler;

Данный метод распаковывает файл из пути path в путь destination, а пока он распаковывается в progressHandler можно совершать какие-либо действия (например, отображение прогресса распаковки), после чего в completionHandler показать, что распаковка благополучно завершилась, либо вывести ошибку при неудаче.

Причина 4: ос телефона заражена вирусом и ошибками

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

Заключение

В конечном счете, если судить по приложению Mix Wave, которое до установки весит ~41 МБ, а после загрузки всех пресетов — 281 МБ, то описанные методы смогли уменьшить размер приложения примерно в семь раз. Результат неплохой, хотя, возможно, существуют и более актуальные способы. Если вы знаете о таких, предлагаем поделиться в комментариях.

UPD: Спасибо Dim0v за дельные замечания о графическом контенте. Приводим их ниже: