Да, это атавизм давних времён, но на удивление всё ещё часто встречается в различных проектах студий от мала до велика, причём не только в легаси контексте. А ещё иногда это всё-таки удобнее чем Addressables или бандлы, например при использовании внутри пакетов - не тянет лишних зависимостей и полностью инкапсулировано.
В общем случае с вами согласен - если есть возможность отказаться от использования Resources - лучше так и поступить.
Правильные настройки качества и сжатия звуков довольно важный аспект оптимизации проекта в котором планируется богатое звуковое сопровождение. В таких проектах это один из тех пунктов оптимизации, что следует учитывать на уровне процессов, например организовав шаблонные настройки сжатия для звуков разного типа (музыка, sfx, речь и т.п.). Это поможет не только снизить вес билда, но и поспособствует более рациональному использованию ресурсов CPU, I/O и RAM в рантайме. Есть неплохая статья с разумными выводами относительно настроек импорта звуков.
Существенно снизить объем билда можно срезав неиспользуемые варианты шейдеров, особенно когда вам заранее известен спектр железа под которым будет работать проект. Выше есть комментарий на эту тему со ссылкой на соответствующий пост в блоге Unity.
А ещё есть настройка алгоритма сжатия билда: Compression Method, прямо в Build Settings. На некоторых проектах и платформах выбор правильного алгоритма сжатия может снизить вес крайне существенно ценой увеличения времени запуска и чтения упакованных ресурсов (порой совсем незначительного).
Часто в Sprite Atlas'ах оказываются неиспользуемые текстуры бесполезно раздувая их размеры и количество, за этим стоит поглядывать.
Стоит упомянуть классику с неверным использованием папок Resources, когда в них лежат ассеты, не подгружаемые в рантайме через Resources.* API. Это касается и вложенных папок.
Для анализа Build Report у Unity есть пакет Build Report Inspector, с ним может быть поудобнее.
Я знаю, что 5.3 ещё бэтка, но я также знаю, что вовсю готовится 5.3.0f1, т.е. не долго 5.3 в бэте оставаться осталось.
И я ещё раз повторю, что не призываю собирать рабочие проекты под IL2CPP Android, я лишь отмечаю, что работа по IL2CPP постоянно идёт, появляется поддержка новых платформ, фиксятся тонны багов и т.д.
Потому не упомянуть IL2CPP в статье в контексте защиты кода как-то неправильно.
вскрыть как консервную банку билд под Windows не составит труда…
статья пока что более чем актуальна
Я и не говорил, что статья неактуальна. Я отмечал, что она неполноценна и автор много полезных моментов в ней не отметил.
Кстати, всё описанное в статье никак не помешает вскрыть билд под Windows как консервную банку.
Даже раздел касательно защиты кода довольно таки скуп. Если уж использовать обфускаторы, то что-то посерьёзнее и посвежее, например Eazfuscator последних версий, или свой билд ConfuserEx.
статья публиковалась 2 месяца назад, или тогда IL2CPP под android тоже был нормальным по вашему?
2 месяца назад был IL2CPP iOS, IL2CPP WebGL, и уже был IL2CPP Android, не важно в каком состоянии, важно что к тому моменту уже было очевидно, что IL2CPP продолжает своё «наступление» и его нельзя игнорировать.
Официальный релиз стабильной версии WebGL обещают к 5.4 версии.
Ну так отлично же! Хотя как вам наверняка известно, это не мешает многим разработчикам запускать проекты под WebGL уже сейчас.
Стабильно, если сравнивать с первой публичной бэтой.
Я и не говорил, что он работает идеально и его можно смело использовать в продакшене. Но если сравнить то, что было в первой бэтке и то что есть сейчас — разница очень существенная.
Да и 5.2.2 может не содержать последнюю версию IL2CPP под дроид, её надо в 5.3 тестировать для объективных результатов.
p.s скрин IL2CPP под webGL (ей богу не нашел)
WebGL билдится только через IL2CPP, что вы не нашли — не понятно.
IL2CPP пока доступен не на всех платформах, но развитие и добавление поддержки новых платформ не стоит на месте.
Бэта под Андроид уже весьма стабильна (если сравнивать с первой публичной бэтой), что лишь прибавляет уверенности в том, что вскоре мы увидим IL2CPP и на других платформах.
Стоило бы упомянуть, что уже сейчас вполне можно применять IL2CPP как отличное средство защиты от просмотра и редактирования вашего кода.
Копаться в в коде, который хоть и предназначен для VM, но уже всё-таки нативный — то ещё «удовольствие» по сравнению с простым и доступным ковырянием IL.
IL2CPP пока доступен не на всех платформах, но развитие и добавление поддержки новых платформ не стоит на месте.
Кроме того, читеры ещё много чем увлекаются, применяют Speed Hack'и, Wall Hack'и, инжектят свои managed сборки прямо в Unity приложения и добавляют в вашу игру свои OnGUI менюшки, и это лишь малая часть.
Я бы для декомпиляции IL рекомендовал использовать dnSpy, форк ILSpy от известного 0xd4d (автор Confuser, de4dot и многих других полезных продуктов).
Там много полезных вещей для реверсера — отладка, редактирование без пересборки, более устойчивая к обфускации dnLib (вместо Mono.Cecil) и т.д.
Ещё раз спасибо за ответ, я попробую использовать одну задачу со всеми нужными мне источниками, интересно насколько это будет удобно.
На счёт инжекта инкремента в полную копию — интересный момент. Получается, если я выставлю «Keep restore points for the last days ...» в значение 1 и установлю периодичность повтора операции — Daily at 1:00, то есть раз в день, то в итоге я увижу одну полную копию и один инкремент, который будет инжектиться в полную копию перед \ после создания следующего инкремента?
В данный момент у меня на самом деле 3 цели для резервирования:
— система — хотелось бы резервировать раз в сутки
— часто меняющиеся данные — хотелось бы резервировать 2 раза в сутки
— редко меняющиеся (раз в несколько месяцев), но объёмистые данные (более 350 гб) — нужно резервировать вручную, после их очередного изменения — хотелось бы иметь «профиль», в котором всё настроено, чтобы в нужный момент просто выбрать этот профиль и запустить бэкап
Если я всё это буду в рамках одной задачи бэкапить 2 раза в сутки, то боюсь много времени и ресурсов в холостую будет уходить на проверку — что менялось, а что нет, чтобы в инкремент только изменённое попадало…
Или нет? =)
И да, хотелось бы не держать всё в одном огромном файле, а иметь отдельные файлы для каждого бэкапа — отдельный файл для системы, отдельный для важных часто меняющихся данных и отдельный для большого бэкапа редко меняющихся файлов.
Если вы ещё собираете user feedback, то вот мои 2 копейки.
1. Очень не хватает возможности создания нескольких разных задач — хотя бы 2 штуки — отдельно для системы и отдельно для данных, ну просто очень было бы полезно и здорово, тогда ваш продукт с лихвой мог бы заменить многим акронисы и иже с ним.
Ведь это основной use case для домашнего пользователя- периодически резервировать систему и какие-нибудь фотографии \ рабочие документы.
2. Очень хотелось бы иметь побольше настроек в плане качества сжатия. Я был бы рад выбрать LZMA2 с максимальным сжатием для бэкапа системы и оставить zlib с минимальным сжатием или вообще без сжатия для фотографий и видео (контент, который уже особо некуда сжимать).
А так — в верном направлении движетесь, программка выходит отличная!
Интересный продукт у вас, получается, однако!
Я заметил, что вы используете сжатие, и тут же возникла пара вопросов:
— какой алгоритм сжатия вы применяете?
— планируется ли внедрение сжатия с поддержкой многопоточности?
Нам с вами — да, но среднестатистическому хитрому китайцу (как показывает практика) — нет. Он ещё и демку эту продавать будет заодно, где-нибудь на локальных китайских ресурсах.
Да, это атавизм давних времён, но на удивление всё ещё часто встречается в различных проектах студий от мала до велика, причём не только в легаси контексте. А ещё иногда это всё-таки удобнее чем Addressables или бандлы, например при использовании внутри пакетов - не тянет лишних зависимостей и полностью инкапсулировано.
В общем случае с вами согласен - если есть возможность отказаться от использования Resources - лучше так и поступить.
Спасибо за статью, мои 6 копеек в копилку:
Правильные настройки качества и сжатия звуков довольно важный аспект оптимизации проекта в котором планируется богатое звуковое сопровождение. В таких проектах это один из тех пунктов оптимизации, что следует учитывать на уровне процессов, например организовав шаблонные настройки сжатия для звуков разного типа (музыка, sfx, речь и т.п.). Это поможет не только снизить вес билда, но и поспособствует более рациональному использованию ресурсов CPU, I/O и RAM в рантайме. Есть неплохая статья с разумными выводами относительно настроек импорта звуков.
Существенно снизить объем билда можно срезав неиспользуемые варианты шейдеров, особенно когда вам заранее известен спектр железа под которым будет работать проект. Выше есть комментарий на эту тему со ссылкой на соответствующий пост в блоге Unity.
А ещё есть настройка алгоритма сжатия билда: Compression Method, прямо в Build Settings. На некоторых проектах и платформах выбор правильного алгоритма сжатия может снизить вес крайне существенно ценой увеличения времени запуска и чтения упакованных ресурсов (порой совсем незначительного).
Часто в Sprite Atlas'ах оказываются неиспользуемые текстуры бесполезно раздувая их размеры и количество, за этим стоит поглядывать.
Стоит упомянуть классику с неверным использованием папок Resources, когда в них лежат ассеты, не подгружаемые в рантайме через Resources.* API. Это касается и вложенных папок.
Для анализа Build Report у Unity есть пакет Build Report Inspector, с ним может быть поудобнее.
Недавние достижения в этой области от OpenAI, это поинтереснее Copilot:
https://twitter.com/OpenAI/status/1425185923478679552?s=19
https://twitter.com/brianpeiris/status/1426358750684880896?s=19
И я ещё раз повторю, что не призываю собирать рабочие проекты под IL2CPP Android, я лишь отмечаю, что работа по IL2CPP постоянно идёт, появляется поддержка новых платформ, фиксятся тонны багов и т.д.
Потому не упомянуть IL2CPP в статье в контексте защиты кода как-то неправильно.
Я и не говорил, что статья неактуальна. Я отмечал, что она неполноценна и автор много полезных моментов в ней не отметил.
Кстати, всё описанное в статье никак не помешает вскрыть билд под Windows как консервную банку.
Даже раздел касательно защиты кода довольно таки скуп. Если уж использовать обфускаторы, то что-то посерьёзнее и посвежее, например Eazfuscator последних версий, или свой билд ConfuserEx.
2 месяца назад был IL2CPP iOS, IL2CPP WebGL, и уже был IL2CPP Android, не важно в каком состоянии, важно что к тому моменту уже было очевидно, что IL2CPP продолжает своё «наступление» и его нельзя игнорировать.
Ну так отлично же! Хотя как вам наверняка известно, это не мешает многим разработчикам запускать проекты под WebGL уже сейчас.
Я и не говорил, что он работает идеально и его можно смело использовать в продакшене. Но если сравнить то, что было в первой бэтке и то что есть сейчас — разница очень существенная.
Да и 5.2.2 может не содержать последнюю версию IL2CPP под дроид, её надо в 5.3 тестировать для объективных результатов.
WebGL билдится только через IL2CPP, что вы не нашли — не понятно.
Бэта под Андроид уже весьма стабильна (если сравнивать с первой публичной бэтой), что лишь прибавляет уверенности в том, что вскоре мы увидим IL2CPP и на других платформах.
Стоило бы упомянуть, что уже сейчас вполне можно применять IL2CPP как отличное средство защиты от просмотра и редактирования вашего кода.
Копаться в в коде, который хоть и предназначен для VM, но уже всё-таки нативный — то ещё «удовольствие» по сравнению с простым и доступным ковырянием IL.
IL2CPP пока доступен не на всех платформах, но развитие и добавление поддержки новых платформ не стоит на месте.
Кроме того, читеры ещё много чем увлекаются, применяют Speed Hack'и, Wall Hack'и, инжектят свои managed сборки прямо в Unity приложения и добавляют в вашу игру свои OnGUI менюшки, и это лишь малая часть.
Я был бы рад помочь, если у вас ещё есть по нему вопросы.
Там много полезных вещей для реверсера — отладка, редактирование без пересборки, более устойчивая к обфускации dnLib (вместо Mono.Cecil) и т.д.
На счёт инжекта инкремента в полную копию — интересный момент. Получается, если я выставлю «Keep restore points for the last days ...» в значение 1 и установлю периодичность повтора операции — Daily at 1:00, то есть раз в день, то в итоге я увижу одну полную копию и один инкремент, который будет инжектиться в полную копию перед \ после создания следующего инкремента?
— система — хотелось бы резервировать раз в сутки
— часто меняющиеся данные — хотелось бы резервировать 2 раза в сутки
— редко меняющиеся (раз в несколько месяцев), но объёмистые данные (более 350 гб) — нужно резервировать вручную, после их очередного изменения — хотелось бы иметь «профиль», в котором всё настроено, чтобы в нужный момент просто выбрать этот профиль и запустить бэкап
Если я всё это буду в рамках одной задачи бэкапить 2 раза в сутки, то боюсь много времени и ресурсов в холостую будет уходить на проверку — что менялось, а что нет, чтобы в инкремент только изменённое попадало…
Или нет? =)
И да, хотелось бы не держать всё в одном огромном файле, а иметь отдельные файлы для каждого бэкапа — отдельный файл для системы, отдельный для важных часто меняющихся данных и отдельный для большого бэкапа редко меняющихся файлов.
Если вы ещё собираете user feedback, то вот мои 2 копейки.
1. Очень не хватает возможности создания нескольких разных задач — хотя бы 2 штуки — отдельно для системы и отдельно для данных, ну просто очень было бы полезно и здорово, тогда ваш продукт с лихвой мог бы заменить многим акронисы и иже с ним.
Ведь это основной use case для домашнего пользователя- периодически резервировать систему и какие-нибудь фотографии \ рабочие документы.
2. Очень хотелось бы иметь побольше настроек в плане качества сжатия. Я был бы рад выбрать LZMA2 с максимальным сжатием для бэкапа системы и оставить zlib с минимальным сжатием или вообще без сжатия для фотографий и видео (контент, который уже особо некуда сжимать).
А так — в верном направлении движетесь, программка выходит отличная!
Я заметил, что вы используете сжатие, и тут же возникла пара вопросов:
— какой алгоритм сжатия вы применяете?
— планируется ли внедрение сжатия с поддержкой многопоточности?
Спасибо!