Jump to content

Новая система сборки Android приложений со значительным приростом скорости ​🔥​


Yaroslav Brovin

3,825 views

Добрый день, уважаемые пользователи FGX Native!

Вот мы и подошли к главной ключевой новинке версии FGX Native 1.15.0.0, а именно речь пойдет о новой системе сборки для Android приложений 🔥. Долгое время мы шли к этому решению и уверены, что данная система сборки является ключевым нововведением для всех будущих релизов FGX Native. Это огромный шаг и потенциал для мобильной разработки на Delphi.

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

Что не так со стандартной системой сборки Delphi для Android приложений?

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

1. Поддержка сторонних Android-библиотек

Это самая важная часть для FGX Native. Мы используем различные сторонние Android библиотеки - Firebase, AdMob, Visio и прочие. Все эти библиотеки в свою очередь используют другие библиотеки, и тд т тп. Каждая библиотека - это не только код, но и ресурсы, изменения необходимые для Android манифеста и тд. Соотвественно, для полноценной поддержки сторонних Android-библиотек требуется не только внедрить исполняемый код, но и так же поставить все ресурсы и слить правки в Android манифесте.

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

Более подробно проблема поддержки Android-библиотек описана в статье про миграцию на AndroidX.

2. Скорость

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

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

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

image.png

  1. Первый столбец содержит время старта (без отладки) проекта с нуля. До этого проект не собирался и нет никаких промежуточных результатов сборки.
  2. Второй столбец указывает время старта (без отладки) проекта после внесения изменения в проект: изменили исходный код и тд.
  3. Третий столбец отвечает за повторный старт (без отладки) приложения без внесения изменений .    

Из этой таблицы хорошо видно, что в среднем на сборку с запуском уходит ~1 минута. Обычный сценарий использования: внес изменений в коде, собрал, запустил, поймал ошибку, опять внес изменений и тд. Грубо говоря, в среднем 60 запусков в день приложения (без отладки) может занимать 1 час рабочего времени! С отладкой цифры становятся еще более угрожающими. Тратится драгоценное время на ожидание, вместо того, чтобы потратить его с пользой.

3. Технологическое отставание от требований Google

Стоит отметить, что Google активно развивает сборку Android приложений, каждый раз выдвигая всё новые и новые требования к полученному приложению:

  • Был APK, на его смену пришел более умный AAB.
  • Новые требования к версии используемых библиотек. Если используемая библиотека старая, то приложение не может быть загружено в маркет или же просто не работать на свежих версиях Android.

Поскольку Delphi самостоятельно реализует систему сборки, то получается состояние вечной гонки, в которой Delphi, к сожалению, всегда в роли догоняющего. Поэтому, как только Google/Apple меняют структуру пакета приложения, вам приходится ждать обновлений Delphi, которые изменят встроенную систему сборки в соответствии с новыми требованиями. С учётом частоты выхода новых версий Delphi это может вылиться в длительное ожидание, а иногда и финансовые затраты, необходимые для приобретения новой версии.

Что нам дает новая система сборки

Учитывая все перечисленные выше минусы встроенной сборки Android приложений, мы пошли по единственному верному на наш взгляд пути, а именно, мы внедрили родную систему сборки, которая используется в Android Studio и которую рекомендует сам Google.

1. Поддержка Android-библиотек

Полноценная поддержка всех Android-библиотек. Теперь перед Delphi разработчиком не будет практических никаких ограничений для использования сторонних библиотек. Мы предлагаем полный цикл интеграции любого стороннего решения в FGX Native приложения под Android:

  1. Вы находите интересуемое решение на Java для Android
  2. Вы добавляете Java библиотеку в FGX Native проект
  3. Вы генерируете заголовочные файлы для Java библиотеки на языке Delphi при помощи нашей утилиты Java2Delphi.

В будущем появится автоматическое скачивания всех зависимостей. Так что вам даже не придется искать файл библиотеки, достаточно будет указать имя библиотеки и её версию. Остальное на себя возьмет FGX Native.

2. Скорость

После внедрения новой системы сборки, мы попросили наших клиентов, повторно протестировать сборку их проектов. Все результаты сведены в таблицу ниже. Из нее наглядно видно, что в целом сборка и запуск  проектов стал быстрее от 2 до 5 раз 🔥(кроме старта с нуля, что обуславливается долгой сборкой главной so-библиотеки приложения, которая целиком и полностью зависит от компилятора и линкера).

image.png

Давайте разберем результаты подробнее.

Старт после изменений

Данный замер является самым часто используемым. Вы вносите изменения в проект и запускаете приложение для тестирования и отладки. Практически - это основной сценарий работы разработчика. В целом прирост скорости составляет от 2 до 5 раз на тестируемой выборке проектов 🚀. Важно отметить, что при этом новая система сборки проделывает гораздо большую работу по сравнению со стандартной, даже если брать в расчёт только внедрение дополнительных ресурсов от используемых библиотеки. Количество ресурсов может исчисляться сотнями, и, если добавлять их все через Deployment Manager, то разница в результатах будет еще больше (не в пользу стандартной системы сборки). 

image.png

Повторный старт

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

В этом случае показатели скорости просто ошеломительные. Прирост составляет в ~5 раз на текущей выборке и практически он является постоянной. Если в стандартной системе сборке повторный запуск зависит от количества ресурсов и размера приложения, то для FGX Native это постоянная величина.

image.png

Старт с нуля

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

image.png

3. Технологическое отставание от требований Google

Мы не "изобретаем велосипед" в сборке Android приложений, а берем проверенное официальное решение от Google, которое поддерживается Google. А это значит:

  1. Соответствование всем новым требованиям со стороны Google
  2. Легкое/моментальное обновление системы сборки до последней версии, без необходимости обновления Delphi

Использование

Первая сборка

При первом открытии FGX Native проекта, начиная с 1.15.0.0 автоматически будет выполнена миграция настроек проекта, в рамках которой будет предложено обновить шаблон манифеста Android приложения и файл стилей styles.xml. Если вы не вносили никаких правок, просто подтвердите замену. Если же вы вносили правки, то необходимо перенести их  вручную в правую часть редактора.

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

image.png

При первой сборке FGX Native проекта начиная с 1.15.0.0 в корне проекта автоматически будет создана директория ".android-build". Этот каталог содержит всё необходимое для сборки вашего проекта. Его не нужно добавлять в систему контроля версии, он может быть большого размера, так как там сохраняются промежуточные результаты сборки, при необходимости его можно удалять. Все файлы внутри данной директории являются автогенерируемыми, поэтому не пытайтесь вносить ручные правки, они будут проигнорированы. 

Первая сборка может занять длительное время, так как при ней загружаются с интернета (требуется наличие активного интернет соединения!) все необходимые компоненты сборки. Однако последующие сборки будут проходить намного быстрее. Во время первой сборки среда может визуально "подвисать", это связано с тем, что интеграция с msbuild в IDE не умеет выполняться полностью параллельно.

Ошибки сборки

Если в результате сборки появляется ошибка, то подробную информацию можно найти на нижней вкладке "Output", а не в "Build", как раньше.

Например, все ошибки упаковки на панели "Build" будут сводиться к такой.

image.png

Подробности можно найти на вкладке "Output". По тексту ошибки становится ясно, что в проекте используется TargetApiVersion ниже 33.

image.png

Требования

  1. Для успешной сборки требуется свежая версия Java JDK (не ниже 18). Можно использовать ту, что идет в поставке с Delphi.
  2. Требуется наличие интернета для первой сборки приложения, так как при ней скачиваются необходимые компоненты сборки.
  3. Теперь все FGX Native под Android используют TargetAPILevel = 33. Мы полностью перешли на использование последней версии Android. Поэтому понижать версию теперь нельзя.

Когда планируется релиз?

Поскольку релиз 1.15.0.0 является очень крупным и затрагивает критические важные моменты, мы хотим быть уверены, что он не испортит ваши проекты. Поэтому внедрение будет происходить постепенно. На первом этапе мы отдали некоторым нашим клиентам сборку на предварительное тестирования на больших проектах, получили обратную связь и устраняем найденные недочеты.  Далее на этой неделе мы планируем выпустить экспериментальную версию 1.15.0.0 для широкого круга пользователей. По сути - это полноценная версия и вы сможете опробовать её для перехода на Android 13, сравнить скорость сборки и тд. Однако, если вы столкнетесь с какими-то серьезными проблемами для вашего проекта, вы всегда сможете откатиться на стабильную версию 1.14.6.0. На текущий момент, практически все большие собранные проекты на 1.15.0.0 успешно запускаются и работают.

image.png 

Если при тестировании вы столкнетесь с проблемами, просьба сообщить нам о них, и мы постараемся их оперативно поправить.

Всем спасибо за внимание и хорошей продуктивной недели!

  • Like 14

22 Comments


Recommended Comments

Все понятно, Google рулит. Со временем мы превращаемся из Delphi разработчиков в java-программистов на языке Opjeсt Pascal.

Например, я пришел в разработку Android из Windows десктопа, где все просто и понятно, где windows натив - это значит машинный код в командах архитектуры x86, который выполняется процессором напрямую, без всяких там оберток, wrapper и VM, можешь даже ASM код внедрять прямо в код delphi, если очень сильно хочется.

А тут, я читаю у Ярослава про "натив" на Android и недоумеваю, какой тут может быть натив, если весь код в андроид выполняется исключительно на java виртуальной машине. Dalvik, кажется, называется, но суть от этого не меняется - это JVM - виртуальная машина. Значит мы имеем дело с неким байт-кодом, в который компилируется наше delphi приложение с java-библиотеками или без оных, но это же не натив, это именно промежуточный байт-код, выполняемый виртуальной машиной Dalvik. 

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

Link to comment
  • Administrators
23 минуты назад, Benten сказал:

Все понятно, Google рулит.

Не совсем так. Выбор решения зависит от целесообразности, обычно выраженная в требуемых финансовых средств. Если у компании есть большой штат сотрудников, которые могут заниматься системой сборкой, развивать и поддерживать, то почему бы и не делать свою. Но когда есть проверенное, рабочее решение. То зачем нам заниматься созданием своего велосипеда, когда есть Google с тысячами сотрудников, которые этим занимаются и поддерживают актуальность. Можно потратить это время на что-то более ценное для пользователей. В данном случае, Embarcadero судя по релизам не хватает средств для расширенной поддержки билд системы. Поэтому мы выбираем Gradle, как гарантированно рабочее, стабильное решение, не зависимое от версии Delphi. 

Со временем мы превращаемся из Delphi разработчиков в java-программистов на языке Opjeсt Pascal.

Сложно представить любой язык без использования стороннего API. Вас же не удивляет, что на VCL вы используете WinAPI на Delphi, а не на С++ или C? Использование WinAPI в Delphi не делает из вас C++ разработчика 🙂 

Обратите внимание, что на FGX Native вы пишите кроссплатформенный код на Delphi и вы можете ограничиться только этим. И мы занимаемся постепенным расширением его, чтобы гарантировать работу на iOS и Android. С другой стороны у вас есть возможность использовать все возможности операционной системы по полной, как с WinAPI. В итоге вам выбирать, что использовать. Если вам надо решить задачу, то какая разница какого типа код вы вызываете? Так что больше возможностей, больше возможности продукта.

Цитата

Например, я пришел в разработку Android из Windows десктопа, где все просто и понятно, где windows натив - это значит машинный код в командах архитектуры x86, который выполняется процессором напрямую, без всяких там оберток, wrapper и VM, можешь даже ASM код внедрять прямо в код delphi, если очень сильно хочется.

Так и в Android почти так. Есть Байт-код, а есть ваш натив - машинный код в командах архитектуры ARM, который так же выполняется напрямую. Обертки - это внутренний механизм для возможности взаимодействия нативного кода с JVM. Которая в конечном итоге так же выражается в виде байткода, который в конечном счете через JIT компиляцию выражается в нативных инструкциях процессора. Я думаю, вы это понимаете.

А так есть архитектура Андроид приложения, разработанная Google, и поэтому хочешь не хочешь, а ее надо придерживаться или приложения не будет.

Цитата

А тут, я читаю у Ярослава про "натив" на Android и недоумеваю, какой тут может быть натив, если весь код в андроид выполняется исключительно на java виртуальной машине. Dalvik, кажется, называется, но суть от этого не меняется - это JVM - виртуальная машина. Значит мы имеем дело с неким байт-кодом, в который компилируется наше delphi приложение с java-библиотеками или без оных, но это же не натив, это именно промежуточный байт-код, выполняемый виртуальной машиной Dalvik. 

Все верно. У слова "натив" есть несколько смыслов:

  1. Натив - как последовательность инструкций, выполняемых напрямую на процессоре.
  2. Натив - как использующее родное API для операционной системы/приложения. Даже если это и байт код.

С этой точки зрения. FGX Native является и тем и другим. FGX Native использует напрямую Android API (представляющее собой байт код) и взаимодействует с JMV, но с другой стороны код вашего приложения является по большей части инструкциями к процессору. 

23 минуты назад, Benten сказал:

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

Так же верно. Андроид приложение - это стартовый байт код, которые загружает нативный код и передает ему управление (если мы говорим про FGX Native или FMX).

  • Like 1
Link to comment
13 часов назад, Yaroslav Brovin сказал:
  • Натив - как последовательность инструкций, выполняемых напрямую на процессоре.
  • Натив - как использующее родное API для операционной системы/приложения. Даже если это и байт код.

Ярослав, спасибо.

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

И еще маленькое уточнение - получается, что android API - это полностью байткод под JVM, и не является нативом процессора. Т.е., по сути, android API - это натив JVM. Я правильно понимаю?

А JVM, в свою очередь  общается с процессорным нативом посредством JNI (Java Native Interface). Верно?

Edited by Benten
Link to comment
  • Administrators
В 02.11.2022 в 11:36, Benten сказал:

И еще маленькое уточнение - получается, что android API - это полностью байткод под JVM, и не является нативом процессора. Т.е., по сути, android API - это натив JVM. Я правильно понимаю?

Не совсем. API - это просто набор публичных интерфейсов для использования на любой операционной системы. Реализация API может быть разной. В Android есть как минимуму две:

  1. Реализация через Байт код. Этот набор API находится в Android SDK.
  2. Реализация через нативный код (инструкции процессора). Этот набор объявлен в Android NDK.

В реализации FGX Native под Андроид мы используем и NDK и SDK (по большей части). Если с работой с NDK все довольно просто. Нужно написать заголовочные файлы для С-headers. То с использованием байт кода из делфи не все так просто. Для этих целей используется JNI. 

Цитата

А JVM, в свою очередь  общается с процессорным нативом посредством JNI (Java Native Interface). Верно?

Нет. JVM выполняет байт код в виртуальной машине. Но по скольку байт код и Java существует не первый десяток. То за это время уже давно существуют всякого рода оптимизации. Одна из них - это JIT-компиляция. Это компиляция байткода в машинный код во время выполнения байт-кода. 

А JNI - это API для работы с JVM из нативного кода. А именно JNI позволяет осуществлять использование Java объектов из нативного кода (где нет сборщика мусора и тд). 

  • Like 1
Link to comment

Добрый день!

Для новой версии FGX-Native теперь таки минимальная версия Java 18?  C Java 8 работать уже не будет?

И да, 18 версия считается устаревшей. Использовать 19-ю последнюю или 17-ю LTS ?

img-2022-12-23-15-43-07.png

Link to comment
  • Administrators

Здравствуйте

В 23.12.2022 в 14:45, Benten сказал:

И да, 18 версия считается устаревшей. Использовать 19-ю последнюю или 17-ю LTS ?

19ая Java в настоящий момент не поддерживается, но будет добавлена со временем. 

Вы можете использовать как 17 версию (LTS), так и 18ю.

В 23.12.2022 в 14:45, Benten сказал:

C Java 8 работать уже не будет?

Мы не тестировали конкретно на 8ой версии, но в целом должно работать. 
У вас есть необходимость использовать старые версии Java?

 

Link to comment
2 минуты назад, Viktor Akselrod сказал:

У вас есть необходимость использовать старые версии Java?

Спасибо, уже поставил 18-ю версию Java. Использовать 8-ю версию большого смысла нет.

Link to comment

Всем добрый день, поделитесь пожалуйста кто может своими ощущениями от быстодействия сборки и деплоя с запуском, какое железо было бы оптимально ?

У меня тестовая площадка была следующей: старенький Мас (>10 лет) с родным старым HDD как хост, в нем VirtualBox с Win10 - для попробовать/пощупать конечно сошло, но для реальной работы ~ 3-5 минут до запуска простого демо конечно треш полный... с обычным старым проектом на ХE2 вообще полное отсутствие проблем с быстродействием

Собирать еще что-то на новом железе и работать на зоопарке не очень конечно хочется, кто-то пробовал например конфигурацию SSD на хосте + VirtualBox или только реальное железо использовать для мобильной разработки ?

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

Edited by Михаил Басов
Link to comment
  • Administrators

Добрый вечер,

12 минут назад, Михаил Басов сказал:

но для реальной работы ~ 3-5 минут до запуска простого демо конечно треш полный... с обычным старым проектом на ХE2 вообще полное отсутствие проблем с быстродействием

Только первый запуск выполняется долго. Последующие должны выполняться на порядок быстрее. Уточните, у вас каждый запуск одного и того же проекта занимает 3-5 минут?

Link to comment

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

Edited by Михаил Басов
Link to comment
  • Administrators
7 минут назад, Михаил Басов сказал:

Да, каждый,

Это очень странно...  Проверьте тогда без виртуалки и дайте знать.

Сколько времени занимает запуск FMX приложения?

Link to comment
9 минут назад, Yaroslav Brovin сказал:

Это очень странно...  Проверьте тогда без виртуалки и дайте знать.

Сколько времени занимает запуск FMX приложения?

FMX не пробовал, уже ставлю на железку все с нуля, как будет результат - все подробно опишу

Кстати обратил внимание что на виртуалке при деплое на телефон доступ к диску просто "в полку" на протяжении нескольких минут

Edited by Михаил Басов
Link to comment
  • Administrators

Надо сравнивать с FMX. Сборка, запуск и отладка в принципе в делфи не шустрая. Она не сравниваться по скорости с Android Studio.

Link to comment
12 минут назад, Yaroslav Brovin сказал:

Надо сравнивать с FMX. Сборка, запуск и отладка в принципе в делфи не шустрая. Она не сравниваться по скорости с Android Studio.

Ок, понял

Link to comment

Итак первые результаты скорострельности по верхам :

Конфигурация (в общем так себе, "я слепила из того что было") - H110 Chipset /Intel Pentium G4500 3.50 GHz / SSD KINGSTON SV300S37A240G 240,0 GB / 3ГБ RAM

Тест SSD:

[Read]
  SEQ    1MiB (Q=  8, T= 1):   194.361 MB/s [    185.4 IOPS] < 42835.02 us>
  SEQ    1MiB (Q=  1, T= 1):   176.105 MB/s [    167.9 IOPS] <  5944.80 us>
  RND    4KiB (Q= 32, T= 1):   163.024 MB/s [  39800.8 IOPS] <   803.05 us>
  RND    4KiB (Q=  1, T= 1):    24.910 MB/s [   6081.5 IOPS] <   164.08 us>

[Write]
  SEQ    1MiB (Q=  8, T= 1):   115.922 MB/s [    110.6 IOPS] < 71567.32 us>
  SEQ    1MiB (Q=  1, T= 1):   113.324 MB/s [    108.1 IOPS] <  9241.09 us>
  RND    4KiB (Q= 32, T= 1):   119.410 MB/s [  29152.8 IOPS] <  1096.09 us>
  RND    4KiB (Q=  1, T= 1):   105.506 MB/s [  25758.3 IOPS] <    38.59 us>

Компиляция и деплой проекта HabitBuilder:

                           Первый раз                           Повторно с изменением unit

Compile                    25 сек                                             24 сек

Deploy                      49 сек                                             12 сек

Run on IDE                12 сек                                             10 сек

Run on device          16 сек                                             14 сек

ЗЫ Подумал ..... и не понял как сравнивать с FMX .... ну проекты то будут разные и заморачиваться влом если честно, мне бы библиотеку освоить для начала

Link to comment

Проблему с нестандартными путями для бинарников в версии 1.15.3.0 решили, за что крайне вам признателен. А можно ли как-то и .android-build убрать из корня проекта?

Link to comment
  • Administrators
6 hours ago, sebekin said:

А можно ли как-то и .android-build убрать из корня проекта?

Здравствуйте. 
Убрать куда и для какой цели?
Опишите поподробнее ваш кейс.

Link to comment

Здравствуйте.
Убрать, например, туда же, ку да и бинарники, то-есть DCC_DcuOutput и DCC_ExeOutput. У меня все промежуточные файлы такого рода располагаются по пути C:\Developer\Temp...
Зачем я это делаю? Наверное по привычке. Не люблю, когда рядом с проектом лежат промежуточные файлы, да и моему самопальному резирвированию это немного мешает...
Значит пока нельзя для .android-build изменить путь?

Link to comment
  • Administrators
8 hours ago, sebekin said:

Значит пока нельзя для .android-build изменить путь?

 В настоящий момент такой возможности нет.

Link to comment
  • Administrators
17 часов назад, sebekin сказал:

Убрать, например, туда же, ку да и бинарники, то-есть DCC_DcuOutput и DCC_ExeOutput.

.android-build - это общие скрипты на все конфигурации. Она используется для сборки и релиза и отладочной версии и AAB. Поэтому если размещать такую папку согласно конфигурации приведет к дублированию этого каталога для каждой конфигурации.

Link to comment


 

7 часов назад, Yaroslav Brovin сказал:
.android-build - это общие скрипты на все конфигурации. Она используется для сборки и релиза и отладочной версии и AAB. Поэтому если размещать такую папку согласно конфигурации приведет к дублированию этого каталога для каждой конфигурации.

 

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

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...