ネイティブかどうか？ クロスプラットフォーム開発に関する4つの神話

スマートフォンは、猫の写真を消費するためのツールとしてだけでなく、作業ツールとしても、太陽の下でますます多くのスペースを獲得し続けています。 そのため、モバイル開発の需要が高まっています。 一般的に、労力とクールさは、Objective-C / iOS用のSwiftとJava / Android用のKotlinです。 間違いなく、労力とクールさはありますが、クロスプラットフォームフレームワークの使用がネイティブツールと比較してより望ましい多くの現実のシナリオがあります。 詳細はこちら！







注：Hacker誌の記事の完全版の出版物シリーズを継続します。 著者のスペルと句読点が保存されました。



著者に発言権を与えます。



クロスプラットフォームフレームワークが人生のすべての問題を解決するのを待っている開発者もいれば、敵意を持ってそれを認識する開発者もいます。 どちらの「戦争キャンプ」も、どのように、そして何が機能するかについての誤解によって引き起こされる独自の誤解を持っています。 技術的な議論の代わりに感情が使用されるため、これは火に燃料を追加します。



開発者、特に初心者の間でも、クロスプラットフォームモバイルフレームワークについて多くの神話があります。 この記事では、最も人気のあるものを分析します。 しかし、まず、ITブラックジャック全体にお金を提供するビジネスの目を通して、モバイル開発を見てみましょう。

クロスプラットフォームツールを使用する理由

歴史的に、コンピューター市場には常に競争があり、各メーカーはオペレーティングシステムとデバイス用のアプリケーションを開発するための最適なセットのいわゆるネイティブ（ネイティブ）ツールを提供してきました。



ネイティブツール=エコシステムの所有者によって提供されます。



「ネイティブ性」の他のすべての兆候は二次的です-動作とアプリケーションインターフェイス、OS機能へのアクセス、パフォーマンスなど。



さらに、ネイティブツールは、開発言語、受け入れられている規則およびアーキテクチャのレベルだけでなく、オペレーティングシステムおよびライブラリを操作するメカニズムのレベルでも互いに互換性がないことがほとんど常に判明しています。 その結果、同じアルゴリズムとインターフェイスを実装するには、異なるプログラミング言語で複数の環境のアプリケーションを作成し、「プラットフォームごとに1つのコマンド」に基づいてアプリケーションをサポートする必要がありました。 同時に、異なるプラットフォーム上のアプリケーションの機能と外観は、ほぼ常に90％同一です。 楽しみのために、iOSとAndroidのお気に入りのプログラムの実装を比較してください。



2番目の重要なポイントは、チーム内で必要な知識と経験を利用できることです。彼らがそこにいなければ、学ぶには時間がかかります。



これらの両方の問題を解決するために、クロスプラットフォーム開発ツール（モバイルだけでなく）が市場に長く登場し、以下を提供します。



-製品の開発と保守が容易になるように、単一のプログラミング言語で全体的なコードベースを最大化します。

-既存の能力と専門家を使用して、新しいプラットフォームにアプリケーションを実装します。



現在、多くのプログラミング言語（および環境）（およびこれらの言語を知っている専門家）があるため、クロスプラットフォーム開発用のツールがかなりあります。 例として、この地域で人気のあるPhoneGap、Xamarin、React Native、およびQ tに焦点を当てます。







今、あなたは神話について話すことができます。

神話1.マジック

初心者の開発者の心を刺激する最も一般的な神話は、クロスアルゴリズムアプリケーションをネイティブアプリケーションに魔法のように変換するスーパーアルゴリズム（およびそれらを作成したスーパープログラマー）の信念に関連しています。 「JavaScriptコードをSwiftに変換し、Swiftアプリケーションをさらにコンパイルする」という精神に基づいたもの。 クロスプラットフォームツールの開発者自身もこの神話に力を入れており、出力として「ネイティブアプリケーション」を作成することを約束しています。 そして、誰かがここでcしているわけではありませんが、豊かな想像力と基本的なメカニズムの理解不足により、開発者はシャーマニスティックなトリックについて考えるようになります。



クロスプラットフォームソリューションの基礎となる主な原則は、コードを2つの部分に分けることです。

• クロスプラットフォーム 、仮想環境に住んでおり、特別なブリッジを介してターゲットプラットフォームの機能へのアクセスが制限されています。
• Nativeは、アプリケーションの初期化、キーオブジェクトのライフサイクル管理を提供し、システムAPIへのフルアクセスを提供します。

「ネイティブ」の世界と「クロスプラットフォーム」の世界を接続するには、クロスプラットフォームフレームワークの可能性と制限を決定する特別な**ブリッジ**を使用する必要があります。



ブリッジを使用する場合、「世界」間のデータ変換、およびAPI呼び出しとライブラリの変換により、常にパフォーマンスが低下します。



そのため、すべてのクロスプラットフォームアプリケーションにはネイティブパーツが必要です。そうでない場合、オペレーティングシステムは単にそれらを実行できません。 それでは、iOS、Android、およびWindows自体によって提供されるシステムAPIとメカニズムを詳しく見てみましょう。 次の神話に進みます。

神話2.ネイティブ！

そのため、仮想環境に存在し、フレームワークインフラストラクチャとブリッジを介してオペレーティングシステムとやり取りするアプリケーションのクロスプラットフォーム部分があります。



すべてのオペレーティングシステム：iOS、Android、およびWindows UWP-次のサブシステム（システムAPIのセット）へのアクセスを提供します。

• WebView（アプリケーションに組み込まれたWebブラウザー）は、PhoneGapに基づくハイブリッドアプリケーションで使用され、実際にはローカルWebサイトのランタイムとして機能します。
• JavaScriptエンジンはReact Nativeおよびその類似物で使用され、JSコードを迅速に実行し、ネイティブとJSの間でデータを交換します。
• OpenGL ES（またはDirectX）は、インターフェイスをレンダリングするために、Qt / QMLまたは同等のゲームエンジンとアプリケーションで使用されます。
• UIサブシステムは、アプリケーションのネイティブユーザーインターフェイスを担当します。これは、React NativeおよびXamarinに関連しています。

クロスプラットフォームアプリケーションにはネイティブ部分があり、「ネイティブ」アプリケーションと同じシステムAPIへのフルアクセスがあります。 違いは、システムメソッド呼び出しがブリッジとフレームワークインフラストラクチャを通過することです。



WebView-アプリケーションは、1ページのWebサイトに似たWebブラウザーで動作します。 ネイティブコントロール（ボタン、リストなど）へのアクセスはなく、すべてがHTML / CSS / JavaScriptに基づいています。 一方、Web開発者は水中の魚のように感じるでしょう。



iOSでは同様のメカニズムがバージョン7.0でのみ追加されたため、 JavaScriptエンジンは比較的最近人気があります。 これらの機能のうち、JavaScriptとネイティブ環境間で転送される複雑なデータ構造のJSONでのシリアル化の必要性を考慮する価値があります。 このようなソリューションのクラスを簡単に説明すると、JavaScript環境では、ネイティブアプリケーションを制御するJSコードが実行されます。



OpenGL ESおよびDirectXは低レベルのサブシステムであり、ゲームや、たとえばQt / QMLでユーザーインターフェイスをレンダリングするために使用されます。 つまり、OpenGL / DirectXを使用する場合、開発者自身がネイティブのものにしか見えないコントロールとアニメーションを描画します。 一方、それは非常に高いパフォーマンスを備えた低レベルのサブシステムであるため、クロスプラットフォームゲームエンジンでも使用されています。



すべてのクロスプラットフォームアプリケーションにはネイティブ部分があるため、システムAPIへの「ネイティブ」アプリケーションと同じフルアクセスが潜在的にあります。 クロスプラットフォームアプリケーションも、ネイティブツールによってネイティブインストールパッケージにアセンブルおよびパッケージ化されます。 重要な質問は、クロスプラットフォーム部分とネイティブの間の相互作用がどのように編成されるかです。 たとえば、WebView内またはOpen GL ES / DirectXを使用すると、完全にネイティブなルックアンドフィールのユーザーインターフェイスを作成する方法はありませんが、同時にGPS、プッシュ通知、およびその他の機能に完全にアクセスできます。 JavaScriptまたはC＃のコードは、ネイティブアプリケーションとその動作を非常に自由に制御でき、完全にネイティブなルックアンドフィールを提供します。



要約すると、はい、使用されている開発ツール（Apple、Google以外）の観点からは「ネイティブではありません」。 しかし、アプリケーションはシステムAPIへのアクセスに関して完全にネイティブであり、完全にネイティブの外観と動作を提供できます。 そして、私たちは次の神話に向かっています。

神話3.松葉杖の松葉杖

ネイティブAPIはデフォルトでは松葉杖とは見なされません（異なる意見がありますが）ため、すべてのdigりはクロスプラットフォームの部分を対象としています。 明らかに、ランタイム環境（WebView、JavaScriptエンジン、Monoなど）も松葉杖と呼ぶのは困難です-長い歴史を持つ成熟した成熟したソリューションです。



松葉杖は、クロスプラットフォーム部分がネイティブ部分と統合する方法と呼ばれているようです。 さまざまなフレームワークがどのように機能するかをよりよく理解するために、PhoneGap、Xamarin、Qt、およびReact Nativeの例を使用して、クロスプラットフォーム部分とネイティブ部分をリンクするために使用されるオペレーティングシステムメカニズムを調べます。



PhoneGapから始めます。 以下は、このフレームワークに基づいたトップレベルのアプリケーションアーキテクチャです。







PhoneGapアプリケーションは、実際には、WebViewを唯一のUIコントロールとして表示するネイティブアプリケーションです。 ネイティブ部分との相互作用があるのは彼を通してです。 iOS、Android、およびWindows UWPのすべての標準WebViewは、JSプロパティおよびメソッドのネイティブハンドラーを追加する機能をサポートしています。 同時に、JSコードは独自の隔離された環境に存在し、ネイティブ部分については何も知りません。必要なJSメソッドをプルするか、必要なJSプロパティを変更するだけです。 すべてが標準のWebベースのDOM内にあり、そこにネイティブ実装に関連する新しい要素が単純に追加されます。



次に、React Nativeを検討します。







React Nativeでアプリケーションを作成する場合、開発者はほとんどの場合、Objective-C、Java、またはC＃でネイティブ部分を実装する必要があり、ネイティブアプリケーションの管理はJavaScriptから行われます。 実際、JavaScriptエンジンは、個別に利用可能なWebView要素です。 PhoneGapの場合と同様に、相互作用は同じJSブリッジを経由します。 ただし、React Nativeでは、JSコードはWeb DOMツリーではなく、ネイティブアプリケーションを制御します。



iOSの制限のため（JITを実装する方法はありません）、JavaScriptコードはオンザフライで解釈され、コンパイルされないことに注意してください。 一般に、これは実際のアプリケーションのパフォーマンスには特に影響しませんが、覚えておく価値があります。



Xamarin.Forms（Windows UWPをサポート）はそれらのアドオンであるため、今度は古典的なXamarin.iOSとXamarin.Androidを見てみましょう。







XamarinはMonoライブラリを使用してターゲットオペレーティングシステムと対話します。これにより、[P / Invoke]メカニズム（https://en.wikipedia.org/wiki/Platform_Invocation_Services）を使用してネイティブコードを呼び出すことができます。 また、iOS / AndroidのネイティブAPIとの通信にも使用されます。 つまり、すべてのパブリックネイティブAPIメソッドに対して、C＃のラッパーが作成され、次にシステムAPIが呼び出されます。 したがって、XamarinアプリケーションからすべてのシステムAPIにアクセスできます。



そして最後に、経験豊富な開発者から多くの質問があるので、Qtを検討してください。







Qtは「それ自体」のものであり、これにはプラス面と制限があります。 Qtライブラリは、すべてのオペレーティングシステムが備えているC ++システムAPIに接続するだけです。 ユーザーインターフェイスのレンダリングには低レベルのメカニズムが使用されますが、ネイティブスタイリングをサポートするグラフィックエンジンが使用されます。 同時に、Androidでは、特別なブリッジ（JNIブリッジ）を介してJava APIにアクセスする必要があります。また、Windows UWPでは、Open GL ESからDirectX呼び出しコンバーターを使用します。





要約すると、すべてのクロスプラットフォームフレームワークは、オペレーティングシステムの標準ネイティブ機能を使用し、成熟しており、IT業界の巨人の支援を受けて経験豊富なチームとオープンソースコミュニティによって作成されます。 そして最後に、最も「強い」議論の時が来ました。

神話4.ゆっくり

クロスプラットフォームフレームワークに関する議論で人々が好む重要な切り札は、生産性が低いことです。 繰り返しますが、何を比較し、どのオウムを数えるかによって異なります。



クロスプラットフォームアプリケーションの機能は、ブリッジで接続された2つの世界が並行して存在することを思い出してください。

• PhoneGap：HTML / JSおよびネイティブJava / Objective-C / C＃;
• React Native：JSおよびNative Java / Objective-C / C＃;
• Xamarin：MonoおよびNative Java / Objective-C;
• Qt：C ++およびネイティブJava / Objective-C。

したがって、パフォーマンスを比較するときは、作業の速度を考慮する必要があります。

• クロスプラットフォーム部分。
• ネイティブ部分;
• 橋。

たとえば、ネイティブと迅速なパフォーマンスを反応させるなどの検索エンジンを入力すると、多くの異なるテストを見ることができます。また、多くのテストでは、クロスプラットフォームコードからのUIのアクティブな操作など、ブリッジをアクティブに使用するとパフォーマンスが急激に低下することに注目しています。 Xamarinの場合、状況は同じように見えます。クロスプラットフォーム部分は非常に高速で、データ処理のネイティブ部分に匹敵しますが、ブリッジを使用すると、パフォーマンスが低下する場合があります。 Qtは通常、C ++レベルで動作しますが、それ自体は高速です。 PhoneGapに基づいたソリューションを検討する場合、パフォーマンスはWebViewに大きく依存しますが、JavaScriptコードのUIを積極的に変更したり、科学的な計算を行ったりしないでください。



ゆっくり？ はい。ブリッジを介したオペレーティングシステムとの不適切な相互作用により、パフォーマンスが低下する可能性があります。 ただし、クロスプラットフォームの世界自体はネイティブのものと同じくらい高速です。

おわりに

今日は、人気のあるクロスプラットフォームモバイルフレームワークの設計に注目し、それらを取り巻く基本的な神話について議論しました。



接続して、コメントに質問を書いてください！

著者について

ヴャチェスラフ・チェルニコフ -開発部長、 ビンウェル 過去には、Nokia ChampionおよびQt認定スペシャリストの1人であり、現在はXamarinおよびAzureプラットフォームのスペシャリストです。 彼は2005年にモバイル分野に参入し、2008年からモバイルアプリケーションを開発しています。Symbian、Maemo、Meego、Windows Mobileから始め、その後iOS、Android、Windows Phoneに切り替えました。



Mediumブログで Vyacheslavの記事を読むこともできます。



これはハッカー誌の記事の完全バージョンであることを思い出します。