タグ: 発達

ハイブリッド開発とネイティブ開発。 2010 年以来、iOS 開発の世界で起こっているジレンマ。そして、デスクトップの世界でも数年前からツール Electron で起こっているジレンマ。ある人が賞賛するように、他の人が批判するように。 Electron は、Web 開発者のあらゆる相乗効果を利用して、アプリケーション (この場合はデスクトップ) の世界に Web 開発者を引き付けるオープンソースコミュニティによる最新の試みです。 GitHub の所有者であり、このライブラリの前身である Microsoft によって掲げられた旗。

しかし、ハイブリッド開発またはネイティブ開発とは何でしょうか?前者では、iOS と Android の両方で最小限の変更で同等に動作するアプリを作成できるのはなぜでしょうか?ネイティブ開発はクロスプラットフォームにできないのでしょうか?ネイティブ開発とは、システムに応じて Apple や Google が作成した、各システムの公式 SDK を使用して行うものだけでしょうか?この物議を醸すトピックを少し掘り下げて、それぞれが何であるかを説明してみましょう。

フレームワークの概念とハイブリッドまたはネイティブ開発

ライブラリまたはフレームワークは、そのコンポーネントを使用してシステム用のアプリを作成できるようにするものです。 iOS の場合、Apple の開発用の公式ライブラリは Cocoa Touch と呼ばれ、いくつかのコンポーネント、いくつかのライブラリが含まれています。UIKit から、サウンド、ネットワーク、システム機能へのアクセスなど、さまざまな機能のためのインターフェースを構築できるようにする他の多くのインターフェースや、もっとたくさん。このライブラリはネイティブです。しかし、それは Apple によって作成された公式のものだからではなく、その構築方法とインターフェースの描画方法によるものです。

共通のイデオロギーで扱われる基本的な概念は、ネイティブ アプリは各システムの公式ライブラリを使用して作られたアプリであるということです。 Cocoa Touch でアプリを作成し、Swift または Objective-C を使用する場合、それは Apple ネイティブになります。 Android SDK で作成し、Kotlin または Java を使用すると、Android にネイティブになります。しかし、これは正確には当てはまりません。私たちは 2 つの基本的な概念を理解する必要があります。1つはアプリのインターフェイスをどのように描画するかということです。もう 1 つは、アプリは最小限の変更で一度に複数のシステムで実行できるかということです。

Unity を使用したビデオ ゲームの例を見てみましょう。このツールを使用してゲームを作成すると、iOS や Android だけでなく、Xbox One、PS4、 Switch だけでなく、PC、Mac、Linux にも対応します。実際には、Unity が行うことは、C++ のバイナリ コードとすべてのシステムの互換性を利用して、開発されたゲームの「パッケージ」を作成することです。このパッケージは、サポートするシステムごとに作成された Unity 独自のライブラリによって読み取られて実行されます。それ。

ただし、実行がネイティブである理由は 2 つあります。1 つは、システムのグラフィック エンジン (プラットフォームまたはデバイスの互換性に応じて、OpenGL ES、Vulkan、または Metal のいずれか) に対して直接実行されるため、もう 1 つは、システム コンポーネントを必要とする呼び出しがリアルタイムに変換されるためです。各システムのネイティブ コンポーネント、つまりその公式ライブラリに対して。 Unity にインターフェイス用のテキスト フィールドを配置すると、これはその呼び出しから各システムの公式ライブラリのネイティブ要素に変換されます。

同じ前提に、たとえば Microsoft の Xamarin ライブラリが存在します。技術的に言えば、ネイティブ アプリを作成します。これは、ユーザー自身の呼び出しをシステムの呼び出しに変換するためです。 Xamarin で許可されるオプションの 1 つは、Xamarin.Forms と呼ばれるライブラリを通じて独自のコンポーネントを使用することです。このタイプの開発はパフォーマンスが良く、有能です。しかし、これには特別な機能もあります。それは、クロスプラットフォーム (非ハイブリッド) アプリを作成することです。 1 つの開発が複数のシステムで動作します。

では、ハイブリッド アプリとは何でしょうか?これは、アプリがネイティブ テクノロジーと、実際にはシステムに直接描画されていない Web ページであるインターフェイスを組み合わせた場合です。したがって、ハイブリッドという言葉が生まれます。 Unity や Xamarin と同様に、変換を通じて各システムのネイティブ コンポーネントを使用できますが、インターフェイスはシステムのグラフィック エンジンのキャンバスに対してではなく、ブラウザ ウィンドウに描画されます。したがって、インターフェースはグラフィカルなシステム命令ではなく、HTML を使用して作成されます。

ハイブリッド ライブラリがマルチプラットフォームであることはハイブリッド ライブラリの特徴ですが、それは互いに何の関係もありません。 iOS 上でのみ動作する iOS 用のハイブリッド ライブラリが存在する可能性があります。それはハイブリッドですが、マルチプラットフォームではありません。

iOS におけるハイブリッドの歴史

2010 年まで、iOS アプリを作成する唯一の方法は Xcode と Objective-C を使用することでした。 iPhone 上でアプリとして実行できるバイナリ コードを生成できる、どのような種類のソリューションであっても、別のソリューションを作成した人は誰もいませんでした。しかしその後、iPad のプレゼンテーションで、スティーブ ジョブズは Adob​​e Flash との戦いを始めました。フラッシュはサポートされていませんでした。 Flash を実行するには、iOS システム管理権限を持つコンピュータ上に仮想マシンを配置する必要がありました。これには 2 つの影響がありました。1 つ目はシステムのパフォーマンスを妨げる (ライブラリが十分に開発されていない場合) 2 つ目は、システムのセキュリティに障害が発生することです。 Flash エンジンを使用すると、iPhone 上で管理者権限を取得し、そのすべてのセキュリティをバイパスできるようになります。このため、Apple は Flash や Java などの仮想マシンを受け入れません。

しかし当時、業界では Flash が大きな比重を占めていたため、Adobe が取り組み、Flash Builder と呼ばれるアプリを開発しました。これにより、Flash で作成されたものをアプリとして iPhone 上で実行できるようになりました。翻訳です。実際には、アプリ内のブラウザーで Flash エンジンを実行するハイブリッド コンテナーです。このことが知られるようになると、スティーブ ジョブズは決定的な決断を下しました。App Store のルールが変更され、Objective-C で開発されていない、Xcode で作成されたアプリのアップロードが禁止されました。しかし、最も重要なことは、公式ライブラリを唯一の選択肢として使用することを強制されたことです。これは 2010 年 4 月に起こり、この規則は夏まで変更されませんでした。 Apple は、Unreal Engine の作成者である Epic Games のおかげで、この制限をひっそりと削除しました。

その理由は説得力のあるものでした。Epic チームは、Adobe が使用していたトリックを使用した、2010 年 9 月の iPod 専用イベントで後に発表された信じられない技術デモを Apple に提示しました。このゲームは Project Sword と呼ばれ、同日に Epic Citadel の技術デモが公開され、数か月後には最初の Infinity Blade ( 現在は消滅しています) になります。ゲームで 3D アクセラレーションを可能にする Stage3D Flash ライブラリに対して Unreal エンジンを技術的に実行するデモ。ブラウザ用の WebGL 3D グラフィックス テクノロジを使用して、ユーザーから隠されたブラウザに対して iOS 上で実行されるエンジン。そのため、Apple は制限を解除する以外に選択肢はありませんでした。ハイブリッド、クロスプラットフォーム開発、およびアプリ内での他のライブラリ (Flash 自体など) の使用は、拒否できない将来への賭けであることを示したばかりだったからです。そこで Apple はそのルールを削除し、それ以来、Apple の公式のものとは別に、iOS 用のアプリを作成できるツールやライブラリが多数登場しました。

ハイブリッドがデスクトップに登場: Electron

なぜハイブリッド アプリが存在するのでしょうか?システム上でネイティブに描画されるインターフェイスではなく、HTML5 を使用してインターフェイスを作成することに何の意味があるのでしょうか?シンプル:世界中のすべての開発者のほぼ 72% が Web 開発者です。したがって、モバイル システム用のアプリを作成するために必要な数の開発者を活用する最も簡単な方法は、開発者がすでに知っていることやその他のものを使ってモバイル アプリを作成できるツールを提供することでした。それはとても簡単です。

しかし、そうすることで、Web ページがどのシステムで表示されても同じに見えるのと同じように、ハイブリッド アプリは、どのシステムで実行されても同じインターフェイスを表示します。ただし、これは各プラットフォームのガイドラインと設計言語を尊重しません。

非常に多くの開発者の相乗効果を活用するこの革命全体は、GitHub のおかげでデスクトップの世界にも翻訳されました。これまで存在しなかったニーズが生み出されたからです。つまり、主にライブ配信サービスを利用できるデスクトップ システム用のマルチプラットフォーム アプリを作成するというニーズが生まれました。クラウド上で。 Slack、Skype、Spotify のように、または Visual Studio Code や Atom などの単一開発のテキスト エディターやコード エディターを作成することもできます。そしてこのために Electron が作成されました。

しかし、電子とは何でしょうか？基本的に、これは Node.js JavaScript 実行層も含む Chromium エンジン (Google Chrome で使用されるエンジン) です。これは GitHub (現在は Microsoft が所有) によって作成され、 Web ページをコンテナー内にカプセル化できるため、ネイティブ デスクトップ アプリではなくネイティブ デスクトップ アプリのように「見える」ことができます。このエンジンは、システム リソースの消費量が多く、パフォーマンスが非効率であるため現在非常に批判されていますが、1 回の開発で比較的迅速にアプリを作成でき、Windows、Linux、または macOS システム上で実行できます。また、ハイブリッド ライブラリとして、いくつかのシステム サービスに接続して、その実行 (各システムのネイティブ コンポーネント) に適切に統合できるようにします。

しかし、これには非常に大きな問題があります。これを想像してみてください。コードを編集しているので Visual Studio Code (現在最も使用されているコード エディタ) を開き、オンラインのチームで作業しているので Slack を開き、音楽を聴いているので Spotify を開きます。知らないうちに3 つの Google Chrome を同時に開いており、リソースとメモリを消費しています。 Google Chrome を開くと、4. Electron アプリは自己完結型であるため、リソースを共有できません。

この事実の範囲を理解したい場合は、実際のケースを見るだけで済みます。Sublime Text のようなテキスト エディターで 4 行の C ファイルを開くには、動作するのに約 40MB のメモリが必要です。 VIM などのテキスト モード エディターを使用すると、わずか 5MB になります。ただし、Visual Studio Code を使用する場合は 349MB が必要になります。クレイジー。

エディターの機能を向上させるプラグインを使用し、XML 形式で 6 MB ファイルを開く場合、VIM は 12 MB のみを使用しますが、Visual Studio Code は 392 MB を使用します。 CPU消費量とは別に。そして、コードをどれだけ最適化しようとしても、問題の核心はエンジンにあるため、あまり役に立ちません。 Node.js を使用してカプセル化された Chromium エンジンを作成し、それを各アプリで個別にロードします。すべては、各プラットフォームでのネイティブ開発を「節約」し、Web 開発者に各システムのテクノロジーのトレーニングを必要とせずにこれらすべてを活用できるようにするためです。

この種の「問題」は通常、エンドユーザーには伝わらず、多くの場合、デスクトップアプリが非常に遅く、多くのリソースを消費するという事実や、アルバムと 4 つの要素を表示するにはオンにする必要があるという事実を Spotify 自体のせいにします。パソコンの専用グラフやCPUが発熱します。しかし実際には、この問題の本当の責任はこのアプリの背後にあるテクノロジーにあるため、Spotify の責任は間接的です。

ハイブリッドよりネイティブの方が良い

クロスプラットフォーム アプリは、ライブラリによって良くも悪くもなります。そこでの 2 つの大きな勝者は、Xamarin と Flutter です。 1 つは Microsoft 製、もう 1 つは Google 製です。ここでの問題は、Web サイトにインターフェイスを配置するために、より多くのリソースを消費し、システムの設計言語やその使いやすさに適応しないハイブリッドであることです。速度が遅く、次のような変更に正しく適応するのが困難です。ノッチとその安全地帯。

さらに、HTML5、CSS、および JavaScript インタプリタに基づくインターフェイスを備えたハイブリッド アプリには、悪用されるとシステムを危険にさらすセキュリティ上の欠陥が存在する可能性が高くなります。実際、Electron にはこれまで、当社の機器への完全なアクセスを可能にする脆弱性が悪用されることを可能にするいくつかのバグ (すでに解決済み) がありました。そして、これらの失敗の 1 つは、各アプリが個別にエンジンを更新することを意味します。

戦略的な決定に関係なく、システムに固執するほど (ネイティブ ライブラリと公式ライブラリを使用するほど)、アプリが消費するリソースが減り、アプリの効率が向上し、より使いやすくなるということは、開発業界全体が知っています。時間がかかる場合もありますが (場合によって異なります)、品質ははるかに高くなります。

ハイブリッド ライブラリを使用するということは、Facebook のようなシステム用のより重いアプリを使用することを意味します。Facebook は、Facebook 自体が作成したハイブリッド ライブラリである React Native で開発されており、これが、このアプリがデータ消費量の点でモンスターである理由の 1 つです。リソース、メモリ、またはストレージ。生成したキャッシュも削除しない、まったく最適化されていないアプリ。幸いなことに、専門家の傾向としては、最終的にはコスト削減を約束したハイブリッド テクノロジではそれほどコストは下がらず、製品の最終的な品質は Android や iOS のネイティブ開発とは程遠いことに、日々ますます気づいています。

しかし、それに反対するすべての証拠があるにもかかわらず、Web ページのようなインターフェイスを作成することが最善であると主張する開発者が依然として大勢います (私の意見では)。はるかに簡単かつ迅速です。そうです、彼らは正しいのです。しかし、効率も低くなり、最終的な結果はさらに悪くなります。そして、プラットフォームの変更を維持するためです。彼らは、現在、アプリをシステムにインストールする必要をなくすことを目的とした PWA (またはプログレッシブ Web アプリ) と呼ばれる新しいトレンドが存在していると確信しています。アプリを Web ブラウザ上で直接実行できるため、企業がユーザーにアプリをインストールしてもらうために App Store にアクセスしなければならないというトラクションの問題が解消されます。しかし、これはすべてのシステム コンポーネントに Web ページへのアクセスを許可することを意味します。喜んでやらせていただけますか？もちろん私ではありません。

30 年以上の経験、Apple 環境で 10 年以上の経験を持つ開発者としての私の経験と私の意見では、ハイブリッド開発は開発自体にとって大きな障害です。そして私の意見では、コスト削減が「約束された」粗悪な製品よりも高品質の製品の方が優れています（これは慎重に分析する必要があります）。アプリは多くのサービスの未来であり現在であり、ユーザーに最高のエクスペリエンスを提供する以上に優れたものはありません。ユーザーに最高のエクスペリエンスを提供する必要があるのに、アプリ内に存在するサービスがコストを削減し、品質を低下させようとするハイブリッド テクノロジを使用しているということは、私には決して理解できません。

幸いなことに、Apple はすでに MacOS へのマジパンの導入を発表しています。これにより、iOS 開発者は、Mac 上でも同様に動作する公式 Cocoa Touch ライブラリを使用してネイティブに作成された iOS アプリに確実に影響を与えるでしょう。このタイプのアプリのみを受け入れます。他には何もありません。しかし、マジパンについてはまた別の日に詳しくお話します。