Очумелые ручки: фреймворк для создания мобильных приложений

Пописываю, на досуге, фреймворк для мобильной разработки. Альтернативу React-Native, Xamarin и прочим. Пока что just for fun.
Было бы интересно обсуждать эту тему и делиться процессом со всеми, кому это интересно.
Общение, надеюсь, будет подзадоривать и я не заброшу проект.

Пишу на Haxe. haxe.org

Главное отличие моего фреймворка — это полная нативность, никаких виртуальных машин. Со значительно меньшим потреблением памяти и более высокой производительностью. Для Android остается доступна Instant App функция. Также, что немаловажно, есть доступ к нативным библиотекам.
------------

Последнее обновление:
dou.ua/...​rums/topic/25601/#1500791

------------

История обновлений:
1) Завел Haxe под андроид: i.imgur.com/zuKIoUH.gif
2) Первый прототип разметки, андроид: dou.ua/...​rums/topic/25601/#1457839
3) Сделал коллбеки из натива в Haxe: dou.ua/...​rums/topic/25601/#1470568
4) Завел туллчейн для iOS: dou.ua/...​rums/topic/25601/#1500791

Обновления по проекту буду писать в комментариях.
Такие дела.

P.S. Делитесь идеями, расскажите, чего вам не хватает для комфортной разработки под телефоны. Давайте пилить этот велик вместе ;)

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Разобрался до конца и запилил все необходимые туллчейны для сборки под айос:
i.imgur.com/xnc2MU1.gifv

Из неудобного: сначала комилится хакс, потом С++. В одном окне. Из-за этого, иногда не очень удобно читать ошибки компиляции. Надо будет подумать, как это упростить.

Следующие планы: перенести то, что я уже сделал для андроида: позиционирование элементов на экране и коллбеки из нативного интерфейса в хакс.
А потом запилить демку какую-то, уровня Hello World, сравнить с React Native и Flutter по перформансу и потреблению памяти. Хотя я уже знаю результаты :) Но нужны пруфы.

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

Времени на самом деле очень мало :) По выходным, по чуть-чуть как-то делаю. Это интересно и увлекает. Иначе, я бы лучше побухал :)

А були ще якісь альтернативи окрім Haxe?

Я думал этот топик никто не читает :D
Я не зовсім зрозумів питання. Альтернативи обраній мові для розробки фреймворку?

Так, які ще мови могли вибрати для цього? Може залишилась таблиця конвертації між мовами програмування?

Мій вибір був зроблений через свій досвід з Haxe, я добре розумію як він співпрацює з C++ та Java. Тож маю розуміння як його використати.
Говорячи про альтернативи... Можливо це Kotlin, бо він вміє в Android. Але інфраструктура для нативу під iOS там ще досить сира. І в цілому Haxe to С++\C стоїть на декілька сходинок вище за Kotlin.
Деякі «нативні» мови хоч і можна заюзати під iOS і Android, але там знадобиться JNI під андроідом, який стане оверхедом для звичайних UI програм. Інші ж потребують віртуальні машини (c#, js або java на ios (хоча здається, що VM для Java на iOS вже прикрили, але це не точно, не цікавився)).

Сделал коллбеки: i.imgur.com/jJM5Inm.gif
Коллбеки можно задавать как в разметке, так и руками в коде.
Если в разметке будет опечатка с именем коллбека, то такой код не скомпилится.

Заодно, добавил чуть более удобное логирование:
i.imgur.com/OkRNdJ7.png

Пока что у меня в закрытом репозитории. Хочу сначала сделать все коровые фичи и определиться с архитектурой, прежде чем открывать все.

Сделал супер-черновой вариант обертки над нативным UI. Пока только андроид.
Вот гифка с комментами: i.imgur.com/C2BvnVH.gif
Писать гифки я пока не наловчился :P

Подробнее о том, что на гифке.
В общем, пока что основным элементом на экране будет некая сцена. У сцены будет свой layout (макет), который можно будет задавать сразу в коде в виде обычной xml.
Ко всем элементам макета, будет прямой доступ из класса сцены. При этом они вываливаются в виде автодополнения, а код инициализации и биндинга элементов из нативной вьюхи генерируется на лету. Еще, думаю, сделаю коллбеки, чтобы можно было всякие onClick события задавать через xml.

Из минусов. Пока что нужно прыгать в Android Studio, если хочется посмотреть визуально на результат. Пока не решил, как с этим быть. Может быть придется написать плагин к VSCode, который будет рендерить layout вместо AS и Xcode... Но отложу решение этой проблемы на потом.

Не, там C++. Смартфон може вистрілити з кишені в ногу юзеру :-)

Знаю его, конечно. Лично еще не тестировал, но реализация там вроде как хорошая. Хоть это и гибрид. Но в любом случае, рынку нужны альтернативы :) Посмотрим, что из этого выйдет.

Гібрид чого? У них там теж нативний код, причому рендер компонент вони переписали руками: можна матеріал запускать на айфонах.
Я думаю, чого не вистачає на ринку — так це фреймворка для кросплатформених простих ігор. Єдина пристойна штука що знаходив — це Corona. Але там луа з усіма наслідками.

Гибрид, в смысле, что логика там пишется на Dart, транслируется в JS и выполняется в рантайме JS. И выполняется в рантайме в DartVM. Aka RN. А компоненты нативные, да.
i.imgur.com/1wFDyXa.png

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

Очень много их, на самом деле :) От движков до фреймворков.

Гибрид, в смысле, что логика там пишется на Dart, транслируется в JS и выполняется в рантайме JS.

нет.

Так ты пиши, что там, а не просто: «нет» :)

у дарта есть трансляторы как в жаппоскрип так и в плюсы
но, сами компоненты флаттера написаны на плюсах

Там чуть выше я скриншот вставил.

i.imgur.com/1wFDyXa.png

С JS промахнулся, не знал. Но логика, в любом случае, там в DartVM крутится, а не на плюсах. А компоненты нативные, да.
Иначе, у них бы не было hot reload’a, т.к. Objective-C\C++ компилится значительно дольше.

фреймворка для кросплатформених простих ігор

Cocos2D?

Из более простых, чтобы не на плюсах — MonoGame (C#), кроссплатформенный клон XNA.
Если не полениться выучить Haxe, то там есть OpenFL (нативный порт Flash API) под все платформы. Прост как 5 копеек. Есть еще Kha (более низкоуровневый, ака SDL). HeapsIO, Armory, но это уже движки.

Я думаю, чого не вистачає на ринку — так це фреймворка для кросплатформених простих ігор. Єдина пристойна штука що знаходив — це Corona.

как бы есть не только корона. Есть еще Love2D (есть порты под все популярные платформы, в т.ч. и под ведроиды с яблофонами), Gideros Mobile (причем можно не только под мобилки, но и под винду как минимум). Monogame (вроде как тоже под все популярные платформы можно, правда для мобильных игр там нужен ксамарин со всеми вытекающими), LibGDX (на этом наверное только по iOS низзя, ибо java).

Але там луа з усіма наслідками.

Чем не угодила Lua?

Какие проблемы ионика (почему ионика, когда мы говорим о cordova), рн, xamarin и прочих фреймвоков решает еще один новый? Без єтой информации пользоваться не станут имхо.

В отличии от вышеназыванных, этот фреймворк полностью нативный. Со всеми вытекающими: потребление памяти, производительность и тд.

Есть такие. www.appcelerator.com/...​app-development-products
Без аналитики и саппорта — бесплатно

и как у них жабаскрип превращается в бинарник?

Доки нужно читаь. У нас коллега на таком писал свои проекты. Очень рекомендует.

я люблю саморазвиваться, но не настолько

Никак не превращается. Лежит в виде ресурсов приложения и выполняется с помощью JavaScriptCore на iOS, а вот что они используют на Android — нужно копаться в доках. RN тащат за собой свежую версию V8, не исключено, что эти товарищи делают то же самое.

так какое же оно нахрен нативное? тот же реакт натив вид сбоку

«Маркетинг, сэр!» :)

Посмотрю их.
Но ведь хорошо, когда есть альтернатива? Веб-хостингов, например, тоже много :)
Вопрос в реализации и удобстве. К тому же, у меня будет MIT лицензия, если что-то получится.

UPD. Выше правильно было замечено, что это гибрид, а не натив. Опять мимикрируют.

Но ведь хорошо, когда есть альтернатива?

Хороший вопрос.

Разве это не очевидно, что если написано: «убийца» RN, то имеется ввиду альтернатива RN? :)
Ну, я убрал, раз не нравится. Добавил немного больше инфы.

Подумай еще об интеграции С++ для андроида — это для тех частей, что в андроидовском API нет

А о каких именно функциях речь? А то я NDK, кроме как для OpenGL, никогда не использовал. В целом, надо подумать, конечно.

Сделай где рекламные статьи, может еще народа подключится тебе помогать (необязательно местные галерные гребцы, но какие иностранцы, они такое любят).

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

На мобилках оно нужно в довольно редких случаях, и, ЧСХ, как правило, в этих же самых случаях критична производительность / потребление памяти, что в ряде случаев автоматически вычёркивает Haxe.

производительность / потребление памяти, что в ряде случаев автоматически вычёркивает Haxe.

It depends, на самом деле. Если мы, например, оборачиваем хаксом какую-то C++ библиотеку, или C++ апи, то оверхед будет околонулевой или, даже, совсем нулевой. Буквально на этих выходных, ради фана, тестировал батчинг DirectXTK, на вручную написанном С++ бенчмарке получил 320к прыгающих спрайтов при стабильных 60 фпс. Потом сбиндил это все в хакс, написал такой же бенчмарк (используя хаксовые структуры) на хаксе и получил точно такую же цифру, абсолютно не потеряв в стабильности.
Да и вообще, в хаксе много хитростей для оптимизации. К тому же, всегда можно написать высоконагруженный алгоритм на С++ и вставить его как untyped код напрямую в хакс.

всегда можно написать высоконагруженный алгоритм на С++ и вставить его как untyped код напрямую в хакс.

Так а какой тогда профит от хакса? В тех примерах, которые я видел, и где использование NDK было оправдано, именно «высоконагруженные алгоритмы» и использовались

Ой, я даже не знаю, как тут сформулировать ответ :) Столько нюансов.
Ну, если мы, например, пишем андроид приложение на Java и хотим заменить хаксом NDK код, чтобы не писать на С++ 500 строчек кода, то да, профита не будет и смысла в этом, наверное, нет.

Но если отойти от этой ситуации в сторону и представить, что мы пишем приложение полностью на хаксе, не важно под какую платформу, вместо того, чтобы писать его на С++, то в таком случае профит есть. Потому что если и будет такой боттлнек, что хакс не справляется, то это, навреное, совсем небольшой кусочек кода, относительно всего проекта.
В случае с untyped кодом, очень удобно скармливать из Haxe в С++ всякие штуки, типа массивов, строк, любых переменных текущего класса и тд и тп, без какого-либо оверхеда. Для пущего удобства хакс дает инжектить С++ код отдельно в генерируемый хедер, отдельно в .cpp, отдельно в функции, инлайнить его и тд.
Но ты, наверное, это знаешь, в Sigma же юзаете хакс, насколько мне известно :)

мы пишем приложение полностью на хаксе, не важно под какую платформу, вместо того, чтобы писать его на С++, то в таком случае профит есть.

Я не настолько хорошо в курсе нюансов взаимодействия Haxe и мобильных платформ, поэтому, задам, возможно, глупый вопрос применительно к Android — как будет выглядеть взаимодействие с ART и его сборщиком мусора в этом случае? Когда идёт взаимодействие с NDK, там всё понятно — честный «плюсовый» код с ручным управлением памяти. Но вся UI прослойка Андроида и многие высокоуровневые API написаны на Java.

в Sigma же юзаете хакс, насколько мне известно

Да, юзаем, но, насколько я знаю, не для мобайла, и стыковки с C++ кодом у нас нет.

Но вся UI прослойка Андроида и многие высокоуровневые API написаны на Java.

да пишите уже на кьют и не партесь

Нет уж, спасибо, сами на таком пишите :)

да мы и пишем. не на жабе же писать в самом деле

взаимодействие с ART
Но вся UI прослойка Андроида и многие высокоуровневые API написаны на Java.

Речь про то, как дергатать Java функции? Через JNI. Вот, я года два-три назад делал: i.imgur.com/pvPdae9.jpg
На фоне NativeActivity, (NDK, Haxe->C++, OpenGL) и Java библиотека Google Places во всплывающем окне работающая через JNI.

Но тут вот в чем дело, если нужно работать плотно с UI и библиотеками Java, то лучше использовать Haxe -> Java трансляцию, что я и делаю на данном этапе. Иначе JNI станет диким оверхедом.

В 99% случаев, чтобы писать под андроид на Haxe, достаточно Haxe->Java трансляции.

если нужно работать плотно с UI и библиотеками Java, то лучше использовать Haxe -> Java трансляцию

А насколько реально одну часть Haxe кода в одном и том же проекте транслировать в Java, а другую — в C++?

Вполне реально, такое часто используется. Все решается через hxml файлы сборки, директивы препроцессора или, например, макросы: конкретное решение зависит от конкретной ситуации.

не нужная.

Как раз очень нужная, ибо является одним из ключевых selling points конкурентов (кроме Xamarin, и то, там Xamarin Forms есть именно для этой цели).

Из текущего описания, скорее, сказал бы, что это альтернатива Xamarin, но никак не RN / Flutter. RN / Flutter, кроме возможности писать на едином языке, предоставляют ещё и единую кросс-платформенную абстракцию для взаимодействия с мобильными ОС.
Собственно, Cordova и иже с ней — тоже, но ещё более изолированную вследствие использования WebKit как основы.

Все верно, сейчас да, скорее Xamarin напоминает.
Вообще, я думал так и оставить архитектуру, но в последствии решил, что один общий UI, все же, куда проще для пользователя. Так что двигаюсь в эту сторону теперь.

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

А як бути з різними дизайн патернами для різних платформ?

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

Підписатись на коментарі