Думаю, картинка с сарказмом "Imagine a world where you write code once" не совсем уместна, тот же Java, который стал языком разработки Android, шёл под лозунгом "Write once, run everywhere", не знаю, шутили ли по этому поводу 20 лет назад.
Shelf на слуху, сам, для прототипов, обычно использовал связку — Node.js+Express.
В следующем pet-проекте можно будет попробовать, но, думаю, написать статью желаемого уровня и с pet-проекта не получится у меня)
Нативный код сгенерированный компилятором Dart отличается от кода сгенерированного C/C++, в том числе отличается работа с кучей и объектами в памяти, но что касается C/C++, то по нему относительно давно существуют неплохой опыт и инструменты — тот же HexRays или IDA Pro. Т.е. привести к более читабельному для исследования виду нативный код полученный из сишного вполне можно, правда конечно без «красивых» имен переменных и функций.
По Dart, считаю, вопрос лежит не в плоскости «невозможности», а в отсутствии необходимости таких инструментов сейчас. Также нужно учитывать, что сейчас в приложениях полностью синхронного кода начиная от ввода и заканчивая выводом достаточно мало. При «раскрутке» кода от «данных» или указателей и попытке отследить последовательность действий, часто натыкаешься на очереди и асинхронные объекты, которые летают между раздельными потоками, и связь, например, между операцией ввода текста и вывода результата далеко не очевидна, тем более когда в процесс включаются косвенные вызовы и полиморфизм. Здесь, зачастую, уже без отладчика в реальном времени тяжело обойтись.
Но, как сказали, вечная борьба между «добром» и «злом» продолжается))
Еще в начале своего опыта по реверсу, пару десятков лет назад, уже тогда часто встречались программы, которые знали что их будут декомпилировать и ломать отладчиками)) Шифрование, мониторинг наличия отладчика в памяти, попытки заблокировать возможность отладки, заметание следов реального кода при декомпиляции, когда даже ассемблерный код тяжело было получить. Это был просто, как интересный квест))
Спасибо за серию интересных статей о подкапотном пространстве Flutter!
На счет слоя «Framework» SDK — с точки зрения архитектуры, он как две капли воды похож на веб-систему, например: «деревья» webkit — HTML/DOM, HTMLElement, RenderObject/RenderLayer, удивительным образом напоминают структуру фреймворка Flutter — Widget (Immutable Widget, что очень хорошо связано по смыслу с описанием посредством HTML языка), Element, RenderObject/Layer (тут даже названия практически совпадают), не упоминая Skia, который является общим движком для Chrome и Flutter. Что не удивительно, поскольку одну из основных ролей разработке Flutter ведёт, в том числе, Ian Hickson (Hixie) — гуру и активный участник HTML сообщества.
Попытки связать веб и натив как есть (Cordova, Xamarin, RN) с точки зрения текущих возможностей (в сторонке стоит QML который решил зайти с другой стороны) думаю вполне себя зарекомендовали в определенных нишах, но Flutter видится мне как следующий шаг в этом направлении — который похож на трансформацию существующих web технологий основанных на HTML, Javascript, CSS в нечто большее.
P.S. Возможно этот комментарий подходит больше к первой части, но, поскольку я «новобранец» на хабре, возможность оставить есть только здесь.
Думаю, картинка с сарказмом "Imagine a world where you write code once" не совсем уместна, тот же Java, который стал языком разработки Android, шёл под лозунгом "Write once, run everywhere", не знаю, шутили ли по этому поводу 20 лет назад.
В следующем pet-проекте можно будет попробовать, но, думаю, написать статью желаемого уровня и с pet-проекта не получится у меня)
По Dart, считаю, вопрос лежит не в плоскости «невозможности», а в отсутствии необходимости таких инструментов сейчас. Также нужно учитывать, что сейчас в приложениях полностью синхронного кода начиная от ввода и заканчивая выводом достаточно мало. При «раскрутке» кода от «данных» или указателей и попытке отследить последовательность действий, часто натыкаешься на очереди и асинхронные объекты, которые летают между раздельными потоками, и связь, например, между операцией ввода текста и вывода результата далеко не очевидна, тем более когда в процесс включаются косвенные вызовы и полиморфизм. Здесь, зачастую, уже без отладчика в реальном времени тяжело обойтись.
Но, как сказали, вечная борьба между «добром» и «злом» продолжается))
Еще в начале своего опыта по реверсу, пару десятков лет назад, уже тогда часто встречались программы, которые знали что их будут декомпилировать и ломать отладчиками)) Шифрование, мониторинг наличия отладчика в памяти, попытки заблокировать возможность отладки, заметание следов реального кода при декомпиляции, когда даже ассемблерный код тяжело было получить. Это был просто, как интересный квест))
На счет слоя «Framework» SDK — с точки зрения архитектуры, он как две капли воды похож на веб-систему, например: «деревья» webkit — HTML/DOM, HTMLElement, RenderObject/RenderLayer, удивительным образом напоминают структуру фреймворка Flutter — Widget (Immutable Widget, что очень хорошо связано по смыслу с описанием посредством HTML языка), Element, RenderObject/Layer (тут даже названия практически совпадают), не упоминая Skia, который является общим движком для Chrome и Flutter. Что не удивительно, поскольку одну из основных ролей разработке Flutter ведёт, в том числе, Ian Hickson (Hixie) — гуру и активный участник HTML сообщества.
Попытки связать веб и натив как есть (Cordova, Xamarin, RN) с точки зрения текущих возможностей (в сторонке стоит QML который решил зайти с другой стороны) думаю вполне себя зарекомендовали в определенных нишах, но Flutter видится мне как следующий шаг в этом направлении — который похож на трансформацию существующих web технологий основанных на HTML, Javascript, CSS в нечто большее.
P.S. Возможно этот комментарий подходит больше к первой части, но, поскольку я «новобранец» на хабре, возможность оставить есть только здесь.