Как работает Codename One?
Я ищу альтернативы для разработки для нескольких мобильных платформ и нашел Codename One, который использует Java в качестве lingua franca вместо HTML/CSS/JS или языков сценариев.
Что я не смог найти, так это как это работает. Это связывает JVM с приложением для iOS и Win7, и использует Dalvik в Android? Переводит ли он исходный код на нативный, и есть ли у нас доступ к этому исходному коду? Есть ли другая магия, учитывая, что они обещают "нет компромисса"? Какие ограничения я должен знать при кодировании независимой Java?
Упреждающий удар: это вопрос о Codename One, а не о том, какую кроссплатформенность мне выбрать, или я должен перейти на нативный, или если я должен перейти в Интернет.
2 ответа
Codename One использует подход, основанный на SaaS, так что это может (и, вероятно, изменится) в будущем, чтобы приспособиться к улучшенным архитектурам. Обратите внимание, что Codename One также предоставляет возможность строить в автономном режиме, что означает, что корпорации, имеющие политики, запрещающие такие облачные архитектуры, могут по-прежнему использовать Codename One с некоторыми дополнительными издержками / сложностью.
В настоящее время на Android стандартный код Java выполняется как есть. Синтаксис Java 8 транслируется с использованием retrolambda для всех платформ при его использовании. Это позволяет ему быть совместимым со всеми версиями Android, а также с другими портами.
На iOS Codename One построен и открыт исходный код ParparVM, который является очень консервативной виртуальной машиной. ParparVM имеет одновременный (не блокирующий) GC и полностью написан на Java/C. Это фактически означает, что проект xcode генерируется и компилируется на серверах сборки так эффективно, как если бы вы вручную кодировали нативное приложение и, таким образом, "на будущее" для изменений, сделанных Apple. Например, с недавними изменениями в 64-битных и битовых кодах в сборках iOS ParparVM не нуждался в изменениях, чтобы соответствовать этим изменениям.
В прошлом Codename One использовала XMLVM для генерации собственного кода очень похожим образом, но решение XMLVM было слишком общим для нужд Codename One.
Сборки iOS компилируются и подписываются на Mac в облаке с использованием xcode (официальный инструмент сборки Apple). Это делает их совместимыми с текущими / будущими изменениями от Apple и позволяет разработчикам использовать Windows/Linux, ориентируясь на iOS. Подробнее о совместимости ParparVM с iOS вы можете прочитать здесь.
В прошлом Codename One поддерживал Windows Phone с использованием переводчика C#, который полагался на XMLVM, но это не был идеальный подход. Обратите внимание, что серверная часть XMLVM, которая транслируется на C#, очень отличается от той, которая ранее использовалась для трансляции на iOS. Codename One предпочел прекратить работу этого старого бэкэнда, так как он не был таким мощным, как новый бэкэнд UWP, и не соответствует целям Microsoft, продвигающимся вперед и сфокусированным на UWP (универсальной платформе Windows).
Для поддержки настольных компьютеров и мобильных устройств Windows 10 Codename One использует iKVM для целевого использования UWP (универсальная платформа Windows) и имеет открытые источники изменений исходного кода iKVM в репозитории Codename One github.
Обратите внимание, что сборки UWP выполняются на облачных машинах Windows 10, что позволяет разработчикам использовать Mac/Linux или более старые версии Windows при создании собственных приложений Windows...
Цели сборки JavaScript, доступные для подписчиков уровня предприятия, используют TeaVM для статического перевода. TeaVM обеспечивает поддержку потоков с использованием JavaScript, разбивая приложение довольно сложным способом. Для поддержки сложного пользовательского интерфейса Codename One используется HTML5 Canvas API, который обеспечивает абсолютную гибкость при создании приложений.
Для настольных сборок Codename One использует javafxpackager Поскольку компьютеры Mac и Windows доступны в облаке, характер платформы зависит от javafxpackager не проблема.
Что выделяет Codename One, так это тот подход, который он применяет к пользовательскому интерфейсу, когда он использует "облегченную архитектуру", чтобы пользовательский интерфейс мог беспрепятственно работать на всех платформах и разрабатываться почти полностью на Java. Он дополняется возможностью встраивать "тяжеловесные" виджеты на место среди "легких". Вы можете узнать больше об этом в этом блоге. Обратите внимание, что в настоящее время пиринг претерпевает некоторые улучшения и теперь поддерживает более сложные способы использования, такие как наслоение.
Облегченный компонент написан полностью на Java, что позволяет разработчикам точно просматривать приложение в симуляторах и построителе GUI.
Codename One достигает высокой производительности, рисуя, используя родной игровой API большинства платформ, например OpenGL ES на iOS.
Все основные технологии Codename One - все с открытым исходным кодом, в том числе большая часть материалов, разработанных самим Codename One, например ParparVM, а также полная библиотека, порты платформы, инструмент конструктора, оболочки устройств и т. Д. Вы можете узнать больше об использовании источников Codename One здесь.
К вашему сведению, Шай Альмог, автор этого ответа, является генеральным директором Codename One.
Под кодовым названием один использовался очень сбалансированный подход к переносимости. Я хотел бы добавить прагматичный комментарий.
Со стороны пользовательского интерфейса CN1 действительно рисует весь свой интерфейс на предоставленном платформой холсте. Он пытается имитировать нативный внешний вид платформы, если вы выбираете его, но имеет такой же успех, как и Swing с его "нативным внешним видом платформы", потому что нативная платформа постоянно меняется, а "родной l&f" всегда отсутствует позади и в большинстве дела кажутся не совсем правильными.
Но, если вы выбираете независимый от платформы внешний вид (который является тенденцией сегодня), вы не будете ограничены каким-либо набором компонентов Codename one по умолчанию: это похоже на Swing с его кроссплатформенным внешним видом (" Металл "и т. Д.). И это хорошо.
Со стороны языка: на iOS это Java-компилируется в C, который затем привязывается к рукописному Objective-C, и он не связывает VM, только слой переносимости. Наиболее важным здесь является тот факт, что java компилируется в C, а не в Objective-C, что делает его быстрее, чем идиоматический код Objective-C, потому что он выполняет виртуальные или, чаще, прямые вызовы методов вместо медленной отправки сообщений Objective C. И это хорошо.
Это также может показаться немного быстрее на Android, потому что, используя Dalvik/Art, он не использует собственный пользовательский интерфейс Android, который является громоздким по сравнению с CN1. Это может ускорить создание динамического пользовательского интерфейса во время выполнения, и это хорошо.
Одной из сильных сторон подхода CN1 является его эмулятор (реализованный на рабочем столе JavaFX canvas), который вы используете для разработки программного обеспечения. Эмулятор использует тот же код пользовательского интерфейса и API переносимости, что и на мобильных платформах, и позволяет использовать IDE по своему выбору для отладки. Он перезапускается быстро, и цикл edit-compile-run очень устойчив по сравнению с Android. И это хорошо.
Вторым очень сильным моментом (главным!) Является открытость их библиотеки пользовательского интерфейса, всего нативного кода и переводчика байт-кода в Си. Если вы потратите некоторые усилия, вы можете избежать создания портов Android/iOS на их фермах и отвлечься от их конкретного пересмотра продукта (но не от нескольких дополнительных услуг, которые они предлагают, которые не являются открытым исходным кодом!). В зависимости от вашей ситуации, это может (или не может!) Быть весьма полезным для вас!
Слабым местом коденамеона является его менее чем идеальная зрелость, что означает, что вы можете легко выстрелить себе в ногу, используя базовые компоненты пользовательского интерфейса, если вы будете использовать их так, как они не предназначены для использования. Также это означает, что его уровень переносимости Java не достаточно велик (и содержит дыры), чтобы удовлетворить потребности каждого, и вам, возможно, придется использовать native в некоторых местах, а также портировать другие чистые библиотеки Java.
Кроме того, текущее состояние графической производительности является неоптимальным; если вы получаете кучу текста на экране, вы легко пропустите ограничение времени анимации / перерисовки 16 мсек, это можно обойти с помощью двойной буферизации, но оно также имеет свои ограничения. К счастью, есть возможность оптимизировать реализацию на обеих основных платформах, надеюсь, они улучшат ее.
В целом, Codenameone имеет хорошую нишу в качестве кроссплатформенного фреймворка для нескольких классов приложений; Вы также можете найти ценность в их услугах.