Google запустила сайт для разработчиков приложений для ОС Fuchsia Статьи редакции
Экспериментальную операционную систему поддерживает пока небольшое количество устройств.
Google запустила сайт операционной системы Fuchsia («Фуксия»), над которой работает компания. Внимание на это обратило Androidcentral.
На сайте опубликованы документы, которые должны помочь разработчикам приложений в создании продуктов для Fuchsia. Разработка осложняется тем, что система пока работает только на нескольких устройствах — среди них Acer Switch Alpha 12 и Google Pixelbook, отмечает издание.
Документы также содержат подробную информацию о микроядре Zircon, на котором построена Fuchsia. Системы Android и Chrome построены вокруг ядра Linux.
Пользователи GitHub обнаружили часть кода ОС Fuchsia в 2016 году. В начале 2018 года журналисты смогли запустить одну из версий проекта на ноутбуках Pixelbook, а в июле 2018 года Bloomberg рассказало о деталях проекта.
Ну - конечно, гуглу много что есть исправлять в андроиде. Например, систему управления памятью. Сборка мусора - это ж жесть! ARC куда изящнее.
Но! У гугла и так перебор с операционными системами. Хорошо - хромоОС нужна неттопам. Но зачем ещё один андроид? Просто поправьте недостатки андроида!
А то мы сейчас имеет ещё одну достаточно дырявую Windows - но для мобильных. Пора бы сделать выводы.
Вот эппл довольно динамично делает deprecated куски своей операционки. Софт, который работал 5 версий назад может не запустится на текущей версии. Это норм, кмк - срок службы дивайсов не так велик и всегда можно не обновлять / перестать обновлять операционку. Возможно, подобным образом следует трансформироваться андроиду.
А кто говорил, что это еще один андроид? Это как раз будет замена андроида и ХромОС. Они хотят пойти по пути, который выбрал майкрософт и о котором говорил Apple. Единая модульная ОС, которая будет работать на всём от кофеварок до ПК.
Если они хотят реализовать модульную систему по аналогии со следующей версией Windows, то производитель будет брать лишь необходимые модули исходя из типа устройства.
Эмуляция андроид приложений была заявлена, так что переход будет относительно безболезненным.
А что мешает допилить андроид? Зачем нужно делать новую систему с новым ядром и всем-всем? «До основанья, а затем!»
Fuchsia будет менее открытой, как минимум.
Почему? Лицензия вроде норм. Код на гитхабе
Чтоб отвязаться от кучи исков со стороны Oracle связанных с Java?
Там же иски были про api Java - а при сохранении возможности запуска приложений андроида - цель не будет достигнута!
Она будет более открытой, без GPL
Суть не в модульности, а в кросс-платформенности. Модули ядра были еще в 90-е.
У ARC тоже есть недостатки:
1. ARC добавляет накладные расходы на reference/dereference. А последний dereference вообще может занимать прилично времени.
2. У ARC нет дефрагментации памяти.
3. ARC требует или крайне жесткого подхода типа Rust или становится источником потенциальных утечем памяти в связи с циклическими ссылками.
Ну и самое главное: под Андроид можно писать и на С++, вот только что-то желающих полностью писать на С++ не так много.
Накладные расходы на освобождение памяти происходят в понятный и предсказуемый момент времени. Это - основной плюс.
Расходы на управление памятью всегда присутствуют в системах с автоматическим управлением памятью - только вот сборщик мусора включается когда ему хочется. На это сложно повлиять.
И, безусловно, ARC должна поддерживаться компилятором.
Циклические ссылки побеждают разными типами указателей.
В предсказуемый момент это происходит в С++, потому что там есть явный вызов delete. А в языках с ARC заранее трудно сказать когда счетчик ссылок будет 0. Для С++ есть и умные указатели и реализации ARC (даже GC), но писать на нем все равно боль. Точно так же unsafe pointer это боль и источник ошибок.
В целом же ARC имеет меньшие накладные расходы чем GC, но требует большей аккуратности при работе с указателями. С другой стороны в среде iOS разработчиков ходят страшные байки про GC: STW паузы в минуты, потребление памяти на 100500% больше и прочее, что тоже далеко от истины. На современно смартфонном железе GC нормально работает не создавая проблем.
Безусловно, в системах с «ручным» управлением памятью програмист сам указывает момент освобождения памяти. Это максимальная управляемость процессом.
В ARC - память (возможно) освобождается в момент выхода переменной из scope. Это - предсказуемый момент во время выполнения программы. Не так сложно подходить разумно к раздаче указателей и не разбрасывать их бесконтрольно. Осторожность надо проявлять при построении взаимозависимых объектов - тогда нужны слабые ссылки, но это уже не так просто.
А вот GC срабатывает по своей логике, и, иногда, в ненужный момент. Даже на современном железе это видно. Не минуту тупит, но лаги в андроиде ощущаются - особенно если знать когда и куда смотреть (например, переключился с игры на браузер).
Кмк, ARC - разумный и довольно удачный компромисс между сложностью, функциями и скоростью. Мне сложно указать на «более лучшую» систему. С «ручным» управлением памятью сравнивать некорректно.
Не видел тормозов из-за GC на Андроиде года 4 уже. Примерно с момента, как они перешли на ART. В ARC память освобождается не при выходе из скоупа. Она освобюождается, когда объектом перестают владеть, что, в общем случае, происходит в неопределенный момент времени.
Ну - не видели - понятно, что заметить тормоза на современном железе не так просто. Современный телефон мощнее многих ноутбуков пятилетней давности. Но аппараты средней ценовой зоны вполне себе тупят
А насчёт освобождения памяти - эмм. А когда память освобождается то?!
ARC - просто смарт пойнтер. Что в нем изящного? То, что эппл пришлось для его реализации влепить костыль, да еще и имя ему дать - всё, что нужно знать про Objective-C. То, что это уехало кусками в свифт - все, что нужно знать об отношении Apple к разработчикам
И ещё немножко поддержки в языке и компиляторе. С понятным моментом освобождения памяти.
А какую систему автоматического управления памятью вы считаете лучшей? Лучше, чем ARC?
ARC - не система автоматического управления памятью. Она от std::shared_ptr отличается только тем, что для ее реализации нужен костыль в копиляторе, потому что язык, к которому ее прикрутили сбоку, после того как оказалось что писать под айфон модно, поэтому писать будут все - очень бедный. Если тебе на постоянной основе, а не в виде крайне редких исключений, надо разделять strong и weak владение - то это нельзя назвать "автоматическим" управлением.
Ну - какого ни какого, но управления памятью. Точно - не «ручного». О степени автоматичности, наверное, спорить смысла нет - это субъективная оценочная категория.
А насчёт strong/weak - это нужно не все время, а в случае дедлоков и кольцевых ссылок. В целом - это проблемы архитектуры кода, если в нем кольцевые ссылки - это правило, а не исключение. К тому же часть решается пулами - если объекты попали в пул и он освобождается - вроде бы даже с кольцом память отпустится.
Android уже не исправишь, когда кода несколько миллионов строк и сложившийся архитектура то вносить хоть какие то мелкие изменения не реально, ведь если где то внести правку то может в другом месте что то поломаться, со временем ошибки и разные костыли накапливаются до такой степени что систему уже не возможно поддерживать.
Как же на текущий день живы Unix, Linux, Marcos, Windows - системы с не меньшей кодовой базой и куда более давней историей?
Ага только они почти что не меняются кроме графической оболочки, скорости исполнения программ и нового значительного функционала до сих пор нету.
Вы серьёзно щас утверждаете что, например, macOS не менялась?)) иконки новые рисовали.
А что там могло меняться кроме новых иконок, только дизайн и поддержка новых устройств.
Переезд с carbon на cocoa. Появление uikit в дополнение к appkit. Новый metal api для графики. И куча всяких новых -kit. Это то, что сразу вспомнилось. Мелкие потребительские фичи не считаем.
Тут скорее разговор что проще с нуля создать, чем переписать.
Ну - и заодно выкинуть в топку миллионы приложений от разработчиков? Нереалистично.
Да и подход - когда до основанья, а затем - он не очень работает. Неуклонные улучшения с заменой устаревшего, такая вот реновация - мне представляются гораздо лучшей тактикой.
Зачем же выкидывать. Их поддержку анонсировали. А через 5 лет все спокойно перепишут свои приложения под нативную фуксию. Профит
Тогда получится в фуксии будет полный андроид и сама фуксия. Бардак прям.
Что мешает андроид допиливать? Делайте как эппл - отрезайте неудачные куски через 3 мажорных версии. Сначала deprecate warning программистам. Потом warning конечным пользователям. Потом - удаляем фичу.
В том что ахитектурно в андроид с их Activity есть затыки. В том что View слой выделить тяжело. С жизненным циклом в целом проблема. У них даже их модная livedata в потрохах через fragment без отображения реализована. Ну а в остальном, да, хорошая ОС
Ну и как это все мешает реализовать новые механизмы в ОС?
Тот же эппл в macOS (тогда ещё MAC OS) заменил Carbon на Cocoa. А сейчас портирует UIKit в рамках проекта Marzipan (ныне Catalyst) с iOS на macOS.
В рамках той же macOS сначала делали GC, потом делали ARC.
Язык заменили - с objective-c на Swift.
Компилятор принципиально другой прикрутили - llvm.
Довольно кардинальные штуки. Так что - было бы желание!
"Что мешает андроид допиливать?"
Ты наверное ни разу не работал над крупным проектом, где даже мелкое изменение дается с трудом а тут цела ос.
Как все ИТ компании справляются - даже удивительно! Понавыдумывали себе всяких тестирований и методик, и работают. Вообще страх потеряли перед священной кодовой базой!
"Ну - и заодно выкинуть в топку миллионы приложений от разработчиков?"
95% приложений бесполезное ненужное говно.
Я смотрю - вы реалист и практик! ;)