私は、複数のモバイル プラットフォーム向けに開発するための代替手段を探しており、HTML/CSS/JS またはスクリプト言語の代わりにJava をリングア フランカとして使用するCodename Oneを見つけました。
私が見つけられなかったのは、それがどのように機能するかです。iOS と Win7 用のアプリケーションに JVM をバンドルし、Android では Dalvik を使用しますか? ソース コードをネイティブに変換しますか? また、このソース コードにアクセスできますか? 「妥協なし」を約束していることを考えると、他の魔法はありますか? Java に依存しないコーディングを行う際に注意すべき制限事項は何ですか?
先制攻撃: これは Codename One に関する質問であり、どのクロスプラットフォームを選択すべきか、ネイティブに移行すべきか、ウェブに移行すべきかについてではありません。
Codename Oneにはオプションの SaaS アプローチがあるため、アーキテクチャの改善に対応するために、これは将来的に変更される可能性があります (おそらくそうなるでしょう)。Codename One にはオフラインで構築するオプションも用意されていることに注意してください。つまり、そのようなクラウド アーキテクチャを禁止するポリシーを持つ企業は、追加のオーバーヘッド/複雑さで Codename One を引き続き使用できます。また、ビルド サーバーを操作することなく無料で使用できることも意味します。
現在、Android では標準の Java コードがそのまま実行されます。Java 8 構文は、使用時にすべてのプラットフォームで retrolambda を使用して変換されます。これにより、すべての Android バージョンと他のポートとの互換性が確保されます。
iOS コードネーム Oneは、非常に保守的な VM であるParparVMをビルドしてオープンソース化しました。ParparVMは並行 (ノンブロッキング) GC を備えており、完全に Java/C で記述されています。これは事実上、xcode プロジェクトがビルド サーバー上で生成およびコンパイルされることを意味します。そのため、ネイティブ アプリをハンドコーディングしたかのように、Apple による変更に対する「将来の証明」となります。たとえば、iOS ビルドに対する最近の 64 ビットおよびビットコードの変更では、これらの変更に準拠するために ParparVM を変更する必要はありませんでした。
以前、Codename One はXMLVMを使用して非常によく似た方法でネイティブ コードを生成しましたが、XMLVM ソリューションは Codename One のニーズに対して汎用的すぎました。
iOS ビルドは、xcode (公式の Apple ビルド ツール) を使用して、クラウド内の Mac でコンパイルおよび署名されます。これにより、Apple からの現在/将来の変更と互換性があり、開発者は iOS をターゲットにしながら Windows/Linux を使用できます。ParparVM と iOS の互換性について詳しくは、こちらをご覧ください。
以前、Codename One は XMLVM に依存する C# トランスレータを使用して Windows Phone をサポートしていましたが、これは理想的なアプローチではありませんでした。C# に変換される XMLVM バックエンドは、iOS に変換するために以前使用されていたものとは大きく異なることに注意してください。Codename One は、新しい UWP バックエンドほど強力ではなく、 UWP (Universal Windows Platform)に焦点を合わせて前進する Microsoft の目標と一致しないため、その古いバックエンドを廃止することを選択しました。
Windows 10 デスクトップおよびモバイル サポートについては、Codename One は iKVM を使用してUWP (Universal Windows Platform) をターゲットにし、 Codename One github リポジトリで元の iKVM コードへの変更をオープン ソース化しています。
UWP ビルドはクラウド内の Windows 10 マシンで行われるため、開発者はネイティブ Windows アプリをビルドするときに Mac/Linux または古いバージョンの Windows を使用できることに注意してください...
エンタープライズ レベルのサブスクライバーで利用できる JavaScript ビルド ターゲットは、 TeaVMを使用して静的に変換を行います。TeaVM は、かなり精巧な方法でアプリを分割することにより、JavaScript を使用したスレッド化のサポートを提供します。複雑な UI Codename をサポートするために、One は HTML5 Canvas API を使用して、アプリケーションの構築に絶対的な柔軟性を提供します。
デスクトップ ビルドの場合、Codename One は を使用しますjavafxpackager。Mac と Windows マシンの両方がクラウドで利用できるため、プラットフォーム固有の性質はjavafxpackager問題になりません。
Codename One を際立たせているのは、「軽量アーキテクチャ」を使用して UI をすべてのプラットフォームでシームレスに動作させ、ほぼ完全に Java で開発できるようにする UI へのアプローチです。「軽量」ウィジェットの中に「重量」ウィジェットを埋め込む機能によって拡張されます。詳細については、このブログ投稿を参照してください。現時点では、ピアリングがいくつかの改善を受けており、レイヤリングなどのより複雑な使用法がサポートされていることに注意してください。
軽量コンポーネントは完全に Java で記述されているため、開発者はシミュレーターと GUI ビルダーでアプリケーションを正確にプレビューできます。
Codename One は、iOS の OpenGL ES など、ほとんどのプラットフォームのネイティブ ゲーム API を使用して描画することにより、高速なパフォーマンスを実現します。
Codename One の背後にあるコア テクノロジはすべてオープン ソースであり、Codename One 自体によって開発されたもののほとんど ( ParparVM など)だけでなく、完全なライブラリ、プラットフォーム ポート、デザイナー ツール、デバイス スキンなども含まれます。Codename One ソースの使用について詳しくは、こちらを参照してください。
参考までに、この回答の著者である Shai Almog は Codename One の CEO です。
Codename one は、移植性に対して非常にバランスの取れたアプローチを採用しました。実用的なコメントを追加したいと思います。
ユーザー インターフェイス側から見ると、CN1 はすべての UI をプラットフォーム提供のキャンバスに描画します。選択した場合は、プラットフォーム ネイティブのルック アンド フィールを模倣しようとしますが、Swing が「ネイティブ プラットフォームのルック アンド フィール」で得たのと同じくらいの成功を収めています。ケースはあまり正しくないように感じます。
しかし、プラットフォームに依存しないルック アンド フィール (今日の傾向のようなもの) を選択すると、Codenameone のデフォルトのコンポーネント セット セットに制限されることはありません。クロスプラットフォームのルック アンド フィールを備えた Swing と同じです ("メタル」など）。どっちがいい。
言語側から: iOS では、C にコンパイルされた Java であり、手書きの Objective-C に結び付けられます。VM はバンドルされず、ポータビリティ レイヤーのみがバンドルされます。ここで最も重要なのは、java が Objective-C ではなく C にコンパイルされているという事実です。これにより、慣用的な Objective-C コードよりも高速になります。これは、Java が遅い Objective C メッセージのディスパッチではなく、仮想メソッド呼び出し、または多くの場合直接メソッド呼び出しを行うためです。どっちがいい。
また、Dalvik/Art を使用している間は、CN1 に比べてかさばる Android ネイティブ UI を使用しないため、Android では少し速く見えるかもしれません。これにより、動的な UI の作成が実行時に高速化されます。これは良いことです。
CN1 アプローチの最も強力なポイントの 1 つは、ソフトウェアの開発に使用するエミュレーター (デスクトップ JavaFX キャンバス上に実装) です。エミュレーターは、モバイル プラットフォームと同じ UI コードと移植性 API を使用し、選択した IDE をデバッグに使用できます。それはすぐに再起動し、編集-コンパイル-実行サイクルはアンドロイドに比べて非常に持続的です. どっちがいい。
2 番目の非常に強力な点 (主なもの!) は、UI ライブラリのオープンな性質、すべてのネイティブ コード、およびバイトコードから C へのトランスレータです。多少の努力をすれば、彼らのファームで Android/iOS ポートを構築することを避け、製品の特定のリビジョンから解放することができます (ただし、オープン ソースではない、彼らが提供するかなりの数の付加価値サービスから解放することはできません!)。状況によっては、これが良い場合もあれば、そうでない場合もあります。
Codenameone の弱点は、その成熟度が理想的とは言えないことです。つまり、基本的な UI コンポーネントを意図されていない方法で使用すると、簡単に足を踏み入れることができます。また、Java ポータビリティ レイヤーが十分に大きくない (そして穴がある) ため、一部の場所ではネイティブを使用し、他の純粋な Java ライブラリも移植する必要があります。
また、グラフィックス パフォーマンスの現在の状態は最適ではありません。画面に大量のテキストが表示されると、16 ミリ秒の流体アニメーション/再描画時間の制限を簡単に逃してしまいます。これはダブル バッファリングで回避できますが、制限もあります。幸いなことに、両方のメイン プラットフォームでの実装にはまだ最適化の余地があり、改善されることを願っています。
全体として、Codenameone は、いくつかのクラスのアプリケーションのクロスプラットフォーム フレームワークとして優れたニッチを持っています。あなたも彼らのサービスに価値を見出すかもしれません。