Что такое билд в компьютере

Обновлено: 04.07.2024

Приветствую всех друзья! В прошлой статье были рассмотрены типичные проблемы и способы их решения при работе с кроссплатформенными приложениями, создаваемыми на Unity. Сегодня мы рассмотрим окно создания билда. Билд – это собранная из ресурсов вашего проекта готовая игра, ее конечное представление зависит от платформы, на которую вы его собираете. Например для Android это будет файл с расширением .apk , а для ПК (персонального компьютера) это будет папка с файлами в корне которой будет лежать файл с названием вашей игры и расширением .exe . Но помимо этого также будут рассмотрены такие вещи как уменьшение размера билда, и конвейер создания билда (крайне кратко).

Картинка для привлечения внимания из открытых источников Картинка для привлечения внимания из открытых источников

Окно настройки сборки содержит все настройки и параметры, необходимые для создания билда на различные платформы. Из этого окна можно создать билд разработчика ( development build ) чтобы протестировать ваше приложение, а также сделать финальный билд который можно будет публиковать в магазины приложений. Чтобы настроить параметры билда вашего приложения перейдите в контекстное меню File\Build Settings .

Используйте панель Scenes in Build для управления тем, какие сцены попадут в ваш билд. Просто поставьте галочку напротив сцены, которая должна попасть в билд. В разделе Platform вы можете выбрать на какую платформу вы хотите сделать билд, а также здесь можно настроить параметры билда, например, выбрать метод сжатия данных ( Compression Method ). Ниже я кратко раскрою для чего нужны остальные параметры сверху вниз:

Target Platform – это платформа на которую будет сделан билд
Architecture – как вы знаете существуют 32х разрядные и 64х разрядные процессоры, так вот с помощью этой настройки мы можем выбрать на какую разрядность делать билд
Server Build – при переключении данного чекбокса Unity создаст билд для сервера, который не имеет графики, а также будет использовать платформозависимый определитель UNITY_SERVER для кода. Если мы с такой галочкой сделаем билд для Windows он будет работать как консольное приложение.
Copy PDB files – при включении данного чекбокса Unity при билде на ПК включит в него PDB файлы. Файлы PDB содержат информацию об отладке приложения, которая полезна для отладки, но при этом она увеличивает размер вашего билда.
Create Visual Studio Solution – данный чекбокс при включении создаст файлы решения для вашего проекта, чтобы вы могли создать окончательный исполняемый файл в Visual Studio .
Development Build – данный чекбокс при включении активирует отладку и профилировку в билде. Используйте этот параметр, когда хотите протестировать свое приложение.
Autoconnect Profiler – этот чекбокс можно включить только при включенном Development Build . Когда этот параметр активирован профайлер Unity (о нем еще будет статья, если вкратце то нужен для просмотра и отладки работы приложения) будет автоматически подключаться к билду и профилировать его.
Deep Profiling – этот чекбокс также можно включить только при активном Development Build . Он автоматически подключает глубокую профилировку в профайлере. Эта функция позволяет более глубоко исследовать ваше приложение, но при этом работа всех скриптов и всего приложения будет замедленна.
Script Debugging – этот чекбокс также можно включить только при активном Development Build . Это позволяет вам отлаживать свой код. Эта функция не доступна на WebGL .
Scripts Only Build – Запустите сборку билда чтобы проверить изменились ли скрипты. Для этого проект уже должен быть собран хотя бы один раз.
Compression Method – Выше я уже писал об этом – позволяет выбрать метод компрессии (сжатия) игровых ресурсов.

Для создания билда нажмите на кнопку Build – после чего Unity предложит выбрать место хранения и имя билда (хранить билд в папке Assets нельзя), затем начнется процесс сборки билда. Кнопка Build And Run создаст билд после чего сразу запустит его на платформе (то есть если у вас, например, билд на Android , то телефон должен быть подключен к компьютеру, после того как билд будет собран Unity установит его на устройство).

Важно свести размер файла билда к минимуму, особенно для мобильных устройств, так как обычно магазины приложений для мобильных накладывают ограничения на размер билда. Первым шагом в уменьшении размера является определение того, какие ресурсы вносят в него наибольший вклад, поскольку именно эти ресурсы являются наиболее вероятными кандидатами на оптимизацию. Эта информация доступна в логе редактора сразу после выполнения сборки билда. Перейдите в окно консоли (если оно у вас не открыто, то откройте его по следующему пути в контекстном меню Window\General\Console ), нажмите на небольшой выпадающий список в правом верхнем углу и выберите пункт Open Editor Log .

Журнал редактора показанный выше предоставляет сводку ассетов по категориям, а также показывает какое процентное соотношение по памяти занимает тот или иной тип. После чего он начинает в порядке убывания перечислять от самого большого к самому маленькому ресурсы в игре. Обычно текстуры/звуки/анимации весят много в то время как скрипты/уровни/шейдера мало. Также не забывайте, что все ресурсы игры, хранящиеся в папке Resources (что это за папка, для чего она нужна и как с ней работать я еще опишу в своей будущей статье) будут добавлены в итоговый билд.

Журнал редактора поможет вам определить какие именно ресурсы необходимо оптимизировать или удалить, но перед началом работы вам следует помнить о следующем:

Во время сборки билда Unity кодирует импортированные ресурсы (например, текстуры) в свои внутренние форматы, поэтому для работы выбирайте формат файла, с которым вам удобно работать (например, png ).
Unity удаляет большинство неиспользуемых ресурсов во время сборки, поэтому вы ничего не получите вручную, удалив их из проекта. Единственные ресурсы, которые Unity удалить не может это скрипты и файлы, хранящиеся в папке Resources (потому как Unity не знает какие файлы из этой папки будут использованы вами во время работы игры, а какие нет). Имея это ввиду вы всегда должны держать ресурсы в папке Resources имеющие отношение к самой игре – остальные смело удаляйте. Также можно подумать о замене ассетов (они же ресурсы) из папки Resources на AssetBundles – это означает что такие ассеты будут загружаться динамически, тем самым уменьшая размер билда. О AssetBundles будет отдельная статья.

Предложения по уменьшению размера билда.

Обычно текстуры занимают большую часть размера билда. Первым решением уменьшающим их является компрессия (она настраивается при импорте текстур в инспекторе, как всегда в будущем я напишу подробную статью об этом). Если это не уменьшает размер файла достаточно, попробуйте уменьшить физический размер текстуры (в пикселях). Чтобы сделать это без изменений исходного файла, выберите текстуру в окне проекта и в окне инспектора измените параметр Max Size . Чтобы увидеть, как это выглядит в игре, увеличьте масштаб игрового объекта, который использует эту текстуру, а затем отрегулируйте Max Size , пока он не начнет выглядеть в окне сцены хуже. Изменение параметра Max Size никак не влияет на ваш ассет текстуры, только на его разрешение в игре.

По умолчанию Unity сжимает все текстуры при импорте. Для ускорения рабочего процесса в редакторе перейдите по пути Edit\Preferences и во вкладке General уберите галочку напротив пункта Compress Assets on Import . Все текстуры сжимаются при сборке билда независимо от этого параметра.

Вы также можете сжимать сетки и клипы анимации при импорте (опять же для уменьшения веса итогового билда). Чтобы включить компрессию сетки ( Mesh compression ), выберите в окне проекта необходимую вам сетку, и в окне инспектора установите напротив пункта Mesh compression один из трех параметров: Low, Medium или High . Помните, что сжатие сеток и анимаций вносит в них неточность, поэтому с этими параметрами нужно поэкспериментировать чтобы подобрать нужные для себя значения.

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

При создании билда иногда требуется каким-то образом изменить ход сборки. Например сделать так, чтобы Unity собрал не только билд на ПК, а также добавил установщик к нему. Чтобы сделать это нужно воспользоваться скриптом редактора, используя BuildPipeline.BuildPlayer , он нужен для запуска сборки, а затем запустить код постобработки который вам нужен:

Этот код запускает сборку билда для ПК, а также копирует в конечную папку билда файл Readme.txt из ресурсов игры. Этот код запускает сборку билда для ПК, а также копирует в конечную папку билда файл Readme.txt из ресурсов игры.

Выше самый простой из примеров того как можно сделать свой сборщик билдов. О возможностях BuildPipeline я более подробно расскажу в своих будущих статьях.

На сегодня это все. В следующей статье я расскажу о некоторых известных проблемах и способах их решения в Unity. Спасибо всем, кто дочитал эту статью до конца, подписывайтесь на канал, ставьте лайки, а для тех, у кого появились вопросы - спрашивайте в комментариях! А если вы хотите помочь данному каналу в развитии – делитесь этой статьей с друзьями в социальных сетях!

В этой инструкции будет показано, как узнать мажорный номер установленной системы Windows (например, Windows 7, Windows 8, Windows 10), как узнать версию Windows (Home, Pro и т. д.), а также как узнать номер сборки.

Номер сборки Windows меняется по мере установки обновлений, которые выходят регулярно, причём такие обновления могут приносить значительные изменения в систему, сравнимые с мажорными обновлениями до выхода Windows 10. Поэтому иногда нужно узнать точную версию Windows, с номером билда и релиза.

Что такое номер сборки Windows (build) и что такое номер выпуска Windows (release)

Сейчас, после отказа от идеи сервисных пакетов и обновления мажорной версии Windows (не планируется выпускать новые версии, всё время будет Windows 10), можно запутаться с номерами сборки и номерами версии (релиза). К тому же, номер релиза и номер сборки соответствуют друг другу и изменяются синхронно.

Итак, номер сборки (build) соответствует важным обновлениям Windows и если сравнивать с предыдущими версия данной операционной системы, то номер сборки ближе всего к понятию сервисного пакета.

Поскольку обе эти величины (сборка и версия/релиз) позволяют идентифицировать версию операционной системы, то использовать можно любое из этих значений, главное указать, что именно вы имеете ввиду.

Также Windows различаются изданиями: Home (Домашняя), Professional (Профессиональная), Enterprise или Education (Для образовательных учреждений).

Ещё нужно помнить о типах системы: 64-битная и 32-битная.

Как посмотреть точную версию Windows

Нажмите клавиши Win+i, в открывшемся окне кликните на «Система»:

Пролистните вниз боковое меню и кликните пункт «О системе»:

Опять пролистните чуть вниз и вы увидите Характеристики Windows:

Будет показана дата установки Windows, номер версии и номер сборки.

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

Как увидеть версию Windows в командной строке

Для открытия командной строки (CMD) нажмите кнопки Win+r, введите в окне

В открывшейся командной строке введите и нажмите ENTER:

Пример полученной информации:

10 — означает Windows 10
18362.657 — это номер сборки (build)

Для получения номера версии (релиза, выпуска) выполните команду:

Как открыть окно с версией Windows. Как в меню настроек найти версию Windows

Окно с версией Windows можно найти в настройках как это показано выше, но самый простой вариант, это в командной строке, либо в PowerShell выполнить такую команду:

Откроется следующее окно:

Как увидеть версию Windows в PowerShell

PowerShell — это тоже разновидность командной строки, но более современная, с новыми функциями. Чтобы открыть PowerShell, намжите Win+x и выберите в открывшемся меню «Windows PowerShell».

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

Если вы хотите получить номер выпуска, но выполните команду:

Чтобы в одной строке получить номер сборки и номер выпуска с максимальной детализацией, выполните следующую команду:

Будет выведено что-то вроде:

Ещё одна команда, которая позволяет вывести более полную информацию о версии сборки:

Чтобы узнать тип издания (Домашняя, Профессиональная и т. д.) выполните команду:

Как получить подробную информацию о системе Windows

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

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

загрузить зависимые библиотеки для вашего проекта из сети (репозитория);
скомпилировать классы модуля или всего проекта;
сгенерировать дополнительные файлы: SQL-скрипты, XML-конфиги и т.п.;
удалять/создавать директории и копировать в них указанные файлы;
упаковка скомпилированных классов проекта в архивы различных форматов: zip, rar, rpm, jar, ear, war и др.;
компиляция и запуск модульных тестов (unit-test) вашего проекта с результатами выполнения тестов и расчетом процента покрытия;
установка (deploy) файлов проекта на удаленный сервер;
генерация документации и отчетов.

Путаница

На хабре есть ряд статей о Maven, но, к сожалению, все они находятся в разных хабах, т.к. отдельного хаба для билд систем не существует.
Поэтому, я решил «не быть как все» и выбрать именно общий хаб «Программирование», а не «Java», «Веб-разработка» и др.

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

Я специально начал пост с пояснений и описания возможностей, так как данные системы могут делать сборки не только для «Java» и применимы не только в веб-разработке. Возможности и варианты использования данных систем значительно шире.

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

High-level архитектура

конфигурации
- собственная конфигурация, где хранятся «личные» настройки системы. Например, такие как информация о месте установки или окружении, информация о репозиториях и прочее;
- конфигурация модуля, где описывается место расположения проекта, его зависимости и задачи, которые требуется выполнять для проекта;
- парсер способный «прочитать» конфигурацию самой системы, для её настройки соответствующим образом;
- парсер конфигурации модуля, где некоторыми «понятными человеку» терминами описываются задачи для системы сборки;
На этом общую часть о build-системах закончу и перейду к более конкретным вещам.

Maven

Так как переписывать то, что написали другие было бы неправильно, поэтому приведу перечень статей по теме, которые уже есть на хабре о Maven и где описано конкретно об этой системе — что это, как работает и на каких принципах основана.
- Maven — зачем? — вводная статья о Maven, где описано как устроена конфигурация модуля/проекта, жизненный цикл сборки.
- Apache Maven — основы — терминология, установка, сборка, создание проекта из архетипа, полезные ссылки
- Maven — автоматизация сборки проекта — более детальное описание жизненного цикла сборки, описание настроек диплоя (deploy), на примере установки для Tomcat сервера.
- Создание своих архетипов и каталогов в Maven — для людей уже «в теме» и желающих создавать свои архетипы, если по каким-то причинам не хватает существующих. Процесс описан довольно детально.
Заключение

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

Версия программы состоит из 4х чисел 1.2.3.4.
Первое число (1) - версия, с ним всё понятно;
Последнее билд (4) - это когда производится перекомпиляция всех частей;

второе число (2)- младшая версия;
третье число(3) - релиз;

вопрос
существуют ли правила ведения этой нумерации?
например, выходит сбрасывается билд или инкрементируется версия и т.п.?

и ещё - существуют Альфа, Бетта версии, релиз кандидаты и т.п.
как-нибудь это всё завязано на нумерацию?

Версия программы состоит из 4х чисел 1.2.3.4.
Первое число (1) - версия, с ним всё понятно;
Последнее билд (4) - это когда производится перекомпиляция всех частей;

второе число (2)- младшая версия;
третье число(3) - релиз;

вопрос
существуют ли правила ведения этой нумерации?
например, выходит сбрасывается билд или инкрементируется версия и т.п.?

и ещё - существуют Альфа, Бетта версии, релиз кандидаты и т.п.
как-нибудь это всё завязано на нумерацию?

например, выходит сбрасывается билд или инкрементируется версия и т.п.?

и ещё - существуют Альфа, Бетта версии, релиз кандидаты и т.п.
как-нибудь это всё завязано на нумерацию?

Я искал эту информацию и видел и в этой конференции трактовки этих понятий, но они все разняться и противоречат друг другу.

// Version information for an assembly consists of the following four values:
//
// Major Version
// Minor Version
// Build Number
// Revision
//
// You can specify all the values or you can default the Revision and Build Numbers
// by using the '*' as shown below:

версии, как видишь, начинаются с 1.0, хотя очень часто ведут с 0.1. Номер билда ведётся с самого начала и не сбрасывается. Вот как там считают ревизию - фиг знает, возможно, это число сохранений файлов проекта (типичный пример - 1.0.2378.26839).

Постоянен смысл только первых двух.

свои пять монет.
Более того, ведение версионности сильно зависит от способа хранения-ведения сырцов.

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

способ хранения сырцов, в свою очередь, сильно завазян на методику работы с багами при отладке, способы оптимизации работ связанных по исправлению ошибок и введению нового функционала в исходники. И далее - способ организации всего процесса разработки.

я для себя тоже принял некоторую логику наименований версий, но страдал комплексом ущербности, из за того, что не понимал как это надо:)

мои программы (я использую билдер), имеют нумерацию простую:
номер версии мажор+минор, билд инкрементируется самой средой при вызове "Build", на релиз я забил:)
и ручками в окошке "О программе. " прописываю альфа или бета. Но это чиста что в случае глюка сказать "Но ведь это АЛЬФА версия":)

Но я не пишу шареваре, мои пользователи обходчики с ноутами, которым нужна одна большая кнопка "Прочитать":)

Я правильно Вас понимаю, что Вы предлагаете лазить по системе хранения кода и искать злополучный билд ?

Вы, похоже не внимательно читали, что я написал выше. А именно, если у Вас физически нет ПОВТОРНЫХ точек ОБЪЕДИНЕНИЯ различных веточек - то сквозной билд мягко говоря не в тему.

получается, что билд 2 идентифицирует версию 2.1.1; билд 4 идентифицирует версию 3.1.1; билд 5 идентифицирует версию 1.1.1 . Я правильно Вас понял ?

Читайте также: