Как стать автором
Обновить

Комментарии 10

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

  1. Лучше использовать git, нежели облако (это не только делает твою работу удобнее, но и повышает твой авторитет среди разработчиков)

  2. Давать доступ ко всему и сразу - плохое решение, даже для тестирование. Правильным путём будет реализовать

  3. Не стоит заворачивать каждый из пунктов

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

  5. Если же у тебя не велосипед - стоит обосновать почему он не велосипед и какие преимущества он имеет перед другими решениями


Благодарю, что не обошли стороной данную статью и не поленились дать советы! Однако, хочу сказать:
1. git у меня на данный момент не работает без vpn. Возможно, его блокирует провайдер...
2. Я стремился к удобству для тех, кто, возможно, хочет использовать это в своих проектах, поэтому и решил выложить все исходники.
3. Мне показалось это удобным... Что ж, в будущем постараюсь не злоупотреблять сворачиванием)
4. Я тщательно ознакомился с существующими решениями перед публикацией, так как искал что-то подобное для своего проекта и не нашёл.
5. Это не велосипед, так как вызова методов без создания словаря я не встречал.

  1. Какой именно git? Есть github.com/, gitlab.com, bitbucket.org и ещё множество других сайтов, предоставляющих системы контроля версий

  2. Тут не про доступ исходников, а про доступ к кодовой части. Один из принципов ООП - инкапсуляция, т.е. защита от доступ "извне". У тебя же всё и сразу можно вызывать

  3. Посмотри как оформлены другие статьи. Сворачивание используется в основном для скрытия "необязательной информации". В итоге выглядит, словно вся статья "необязательна"

  4. (и п.5 в т.ч.) Так стоит привести пример найденных альтернативных решений и перечислить их недостатки перед твоим решением.

Без словоря невозможно будет вызвать метод в кейсе, когда билдится на бэке il2cpp и нужные методы и классы урезаются билдером, т.к. на il2cpp это aot компиляция. Единственный способ защитить от урезания (стрипинга) кода, это link конфигурация ручная.

На il2cpp сейчас билдится iOS (обязательно) и Android (не обязательно), но юнитеки со временем планируют полностью отказаться от Mono (JIT) компилятора

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

Воистину, забыл про него

Спасибо за пояснение! Я использовал Mono компиляцию, поэтому не знал о поведении консоли при il2cpp компиляции. Рад, что нашёлся человек, способный дополнить статью! ;)

А где можно прочитать об отказе от jit? Я точно читал на форуме что есть в идеях отказ от mono в пользу microsoft'овского рантайма для поддержки последних стандартов, но прям что бы от jit... Я тогда unity вообще уважать перестану. Выкиньте уже тогда c# и отдавайте наружу c++ хидеры, а для писателей онлайн казино и три в ряд наверните сверху свой скриптовый язык. Вот зачем насиловать c# своим il2cpp, burst, кривым рантаймом, фиговым пекедж-менеджером...

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации