すべての開発者の夢は、コードを一度書いてどこにでも展開できるようにすることです。これにより、小規模なチームがより信頼性の高い製品を幅広いユーザーに展開できるようになります。残念ながら、基盤となるカーネルやユーザー インターフェイス API が異なる多数のオペレーティング システムがあるため、開発者にとってこれは悪夢となることがよくあります。
通訳言語が不十分な理由
通訳言語 Python 理論上は、クロスプラットフォームのコード展開に最適です。存在するほぼすべてのプラットフォームで利用可能なインタープリタがあります。しかし、いくつかの重要な点で不十分です。まず、知的財産を保護するのが比較的難しいことです。コードはコンパイルされていないため、プレーンテキストで誰でも見ることができます。これには、難読化や シトン コンパイルはデバッグと展開を非常に複雑にします。 Java この問題に悩まされる可能性があります。
エンドユーザーに解釈されたコードを配布する際のもう一つの大きな問題は、インストールサイズです。Pythonインタープリタを配布すると、 ピップ、多くの ピップ パッケージによっては、単純なアプリケーションであっても、ディスク上のコードが簡単に 1 ギガバイトを超えることがあります。 電子 同様の問題を抱えており、全体をバンドルする必要がある Chromium インストールします。その結果、メモリを大量に消費する低品質のアプリが作成されることがよくあります。
最後に、エンドユーザーのマシンでの依存関係管理は、 Python 開発者が配布するコードが特定のパッケージバージョン（たとえば、Tensorflow 2.4.2）に依存している場合、そのパッケージをインストールしようとするインストールスクリプトでバージョンの競合が発生する可能性があります。この時点でスクリプトは、中止するか、ユーザーの既存のパッケージを上書きするかを決定する必要があります。どちらも、ユーザーエクスペリエンスを著しく低下させます。 パイプ これを解決しようとする試みですが、これはユーザーがツールをインストールしており、インストールしたバージョンがインストールスクリプトのバージョンと一致していることを前提としています。これを解決するもう1つの方法は、完全に別の Python ユーザーのマシンにインストールすることもできますが、これは不要なスペースを占有し、信頼性の問題やバージョンの競合から逃れることはできません。さらに、インターネット接続の要件は、セキュリティ上の理由でインターネット アクセスが制限または制限される可能性のある顧客にとって懸念事項です。
コンパイル言語候補
コンパイル言語は、知的財産の保護、インストール サイズの小ささ、依存関係の管理、信頼性などの要件を満たすことができる、インタープリタ言語の代替手段です。以下では、いくつか例を挙げて説明します。
C / C ++
メリット
- 成熟したコンパイラはあらゆるOSで利用可能
- 数十年にわたって文書化されテストされたマルチプラットフォームのライブラリ
- 世界中の開発者によく理解されている
デメリット
- コピーオンライト、オプション、組み込み JSON 解析などの最新の言語機能はサポートされていません。
- 弱い型付けでnull保護なし
- 追加の依存関係がない Unix ベースと Windows ベースのプラットフォーム間で一貫性のない標準ライブラリ
- 標準パッケージマネージャがない
GO
メリット
- 高速コンパイル
- 比較的シンプルな構文
- 静的型付け
デメリット
- ガベージコレクションベースのメモリ管理はパフォーマンスの問題を引き起こす可能性がある
- ジェネリックなし
- より複雑な言語から定型コードを削減するいくつかの機能を省略します。
- オープンソースパッケージやコミュニティの支援が不足しているため、全体的な使いやすさが低下するニッチな言語です。
Rust
メリット
- 厳密な型付け、ジェネリック、パターンなどを備えた最新の言語。
- コンパイル時の「自動」メモリ管理
- 大規模なコミュニティ サポート
デメリット
- 安定した ABI はなく、採用する予定もありません
- 急な学習曲線
- やや複雑 C バインディング、ネイティブ Rust 図書館はギャップを埋められない
Swiftを選択する
スウィフト 当初はAppleプラットフォームのみで動作するように開発されました。2016年にLinuxサポートが追加されました。それ以来、 スウィフト パッケージは両方のオペレーティングシステムと互換性があるように設計されています。2020年にはWindowsのサポートが追加され、主要なオペレーティングシステムXNUMXつへのサポートが完了しました。Qeexoの場合、 スウィフト 全ての条件を満たしています。型安全性、オプション、ジェネリック、便利な標準ライブラリなどの機能を備えた最新の言語であり、クロスプラットフォーム、信頼性、比較的小さなバイナリの生成、知的財産の保護も備えています。さらに、 C コードでは、次のような十分にテストされたクロスプラットフォームライブラリとやり取りするコードを簡単に記述できます。 libusb.
Qeexoの既存のPythonベースのデスクトップクライアントから、純粋にPythonで書かれたものに移行する スウィフト インストーラーのサイズは108MBから18MBに、インストール時間は57秒から13秒に、ディスク容量は830MBから58MBに削減されました。さらに、インストーラーと初回起動時の信頼性が大幅に向上し、インターネット接続の不足、バージョンの競合、不良による依存関係の問題は発生しなくなりました。 Python インストールします。
Swiftを一度書けばどこでも実行できる
堅牢な標準ライブラリのおかげで、ネットワークリクエスト、JSONシリアル化、エラー処理など、アプリケーションに必要な操作の多くは、コードがどのプラットフォームで実行されていても簡単に機能します。ただし、USBデバイス通信やWebSocketサーバーなどの複雑なタスクでは、より複雑な技術が必要でした。 スウィフトシリアル or Vapor 存在しますが、macOSとLinuxでのみサポートされています。 スウィフト Windows上で信頼性の高いWebSocketサーバーやUSBインターフェースコードをゼロから作成しようとするよりも、 スウィフト、フックするのは簡単だった C 図書館など libwebsocket の三脚と libusbシンプルな スウィフト パッケージとモジュールのマップ（例： https://github.com/NobodyNada/Clibwebsockets), スウィフト 静的にリンクされたライブラリや動的にリンクされたライブラリ（Macでは.dylib、Linuxでは.so、Windowsでは.dll）を簡単に取得し、 スウィフト 簡単なモジュールのインポート後に構文を実行します。これらのライブラリはすでにクロスプラットフォームなので、作業はすでに完了しています。ライブラリのビルド スクリプトを全体のコンパイル プロセスに統合するだけで済みます。
これらの技術を使用すると、必要な場所が非常に少なくなります #if os() コード内のチェック。これには、ログの場所のパス、パッケージ ファイル内のコンパイラ フラグのパス、USB パスの検出が含まれます。その他はすべて、すべてのオペレーティング システムで同じように機能します。
クロスプラットフォームSwiftの課題
このブログが公開された時点では、 スウィフト Windowsで利用可能になってまだ1年も経っていない。つまり、Stackoverflowの質問やWindows向けに設計されたライブラリなどのリソースは スウィフト Windowsでは、すべてがゼロから構築され、ドキュメントから発見され、統合されなければなりません。 C 図書館で見つけたり、 スウィフト 言語ソースコード。これは時間の経過とともに改善されるでしょうが、現時点ではクロスプラットフォーム スウィフト プログラミングは初心者にとって少し難しいかもしれません。例えば、 アラモファイア、非常に人気のあるネットワークライブラリ スウィフトは、ごく最近まで Windows も Linux もサポートしていませんでした。Qeexo は、オープンソース ライブラリにパッチを提供して、動作可能な状態にしました。
もう一つの問題は、 スウィフト WindowsでもLinuxでもABIが安定しているとは考えられていません。つまり、すべてのアプリは スウィフト 共有ライブラリを利用できるのではなく、ランタイムでのみ機能します。ライブラリは過度に肥大化していないため、これは大きな懸念事項ではありませんが、それでも考慮すべき事項です。
結局のところ、たとえ スウィフト クロスプラットフォームで動作するには、特別な考慮が必要になることがよくあります。たとえば、関数 睡眠（） の一部ではありません スウィフト 標準ライブラリです。POSIXから来ています。つまり、この関数を使用するコードはWindowsではコンパイルされません。代わりに、ヘルパー関数を使用します。 グランドセントラルディスパッチ スリープ機能をシミュレートするためにセマフォを開発する必要がありました。また、UIライブラリは標準化されていません。macOSは ココア、Windowsは WinUI/WPF、Linuxでは xlib. スウィフト 3つのAPIすべてとやり取りすることができますが、すべてのコードには #if os() チェックとコードはOSごとに異なります。その結果、QeexoはOSの推奨言語で小さなラッパーアプリを書くことにしました。 Swift/C#、そしてクロスプラットフォームを生み出す スウィフト コアをセカンダリ プロセスとして使用します。追加の利点は、ヘルパー アプリがサブプロセスのクラッシュを監視し、シームレスにユーザーに警告できることです。
迅速な未来
活発なコミュニティのおかげで、 スウィフト サーバー上で、そして地球上で最大のテクノロジー企業（Apple）の支援を受けて、クロスプラットフォーム スウィフト 明るい未来が待っている。 SwiftUI 真のクロスプラットフォームUI開発も可能になるかもしれません。 スウィフト Qeexo は、知的財産を保護し、真にクロスプラットフォームな、信頼性が高くコンパクトなアプリを展開できるようになりました。
