web-dev-qa-db-ja.com

HTML5とJSアプリがネイティブアプリと同じように機能しない理由は何ですか?

私の理解から、

  • HTMLはマークアップ言語であり、XAML、XIB、およびAndroidが使用するものやその他のネイティブUI開発フレームワーク)のコンテンツも同様です。
  • JavaScriptは、イベント処理、クライアント側の検証などのさまざまなフレームワークでC#、Java、Objective-C、またはC++が行うことを含むクライアント側のスクリプトを処理するためにJavaScriptと一緒に使用されるプログラミング言語です。
  • Senchaのようなフォームフレームワークで利用可能なMVC/MVVMパターンがありますAngularなど。
  • 他のフレームワークと同様に、sqliteとキー値ストアの両方の形式のlocalStorageがあり、不足しているほとんどすべてのAPI仕様があります。
  • ネイティブUIフレームワークがUIをレンダリングする必要がある場合は常に、同様のマークアップを解析してUIをレンダリングする必要があります。

質問の内訳

  • HTMLとJS自体で同じことをやめるのは何ですか?
  • Webコントロールまたはブラウザーをレイヤーとして使用する代わりに、なぜHTML(CSSと共に)とJSを同じように実行できないのですか?
  • レイヤーがあったとしても、.netランタイムやJVMは、C++、Cが使用されていない他のケースでもそうです。
  • では、DalvikのようなAndroidの場合を考えてみましょう。(Canvi't Chromiumが(dalvikとNDKとともに)別のオプションである理由です)ここで、HTMLは次のように動作しますAndroidマークアップは動作し、JavaScriptは何をするために使用されますか= Javaしますか?

だから問題は、

現在の実装はそれほど良くない場合でも、理論的には、HTML5ベースのアプリケーションを他のモバイル用のネイティブアプリと同じように機能させることは可能ですか?

9

HTML5アプリのポスターボーイであるLinkedInは2013年の初めにネイティブになりました。 VentureBeatでのインタビュー で、理由を説明しています。

これはあなたの質問に最も関連する部分だと思います:

プラサド氏によると、パフォーマンスの問題が原因でクラッシュが発生したり、アプリの実行が遅くなったりすることはありません。彼が言ったことは、モバイルWeb用のHTML5にはまだ明るい未来があることを示しています。ただし、開発者がそれをサポートするツールを作成する用意がある場合に限ります。

...

非常に欠けているものがいくつかあります。 1つはツールサポートです。実際に機能するデバッガー、メモリが不足している場所を通知するパフォーマンスツールがあります。 AndroidとiOSを見ると、本番環境で問題が発生したときに多くの詳細情報を提供するツールを構築することに焦点を当てている2つの大企業があります。モバイルWeb側では、これらのデスクトップツールをモバイルデバイスで機能させることは非常に困難です。2つ目の大きな問題は、操作性、ランタイム診断情報です。今でも、HTML5を構築するときは、クライアント側のアプリとして構築しています。 -サーバーアーキテクチャ…その操作性は、大量のユーザーに配布されたときに情報を提供しますが、それをサポートする優れたツールもそれほど多くありません。

[Prasadは、問題をすばやく解決するためのdevおよびopsツールが「存在しない」ことにも言及しました。]

これら2つが存在しないため、人々はネイティブにフォールバックしています。 HTML5の準備が整っていないわけではありません。エコシステムがそれをサポートしていないということです。 …ツールはありますが、最初の段階です。人々は基本を理解しているだけです。

11
vartec

Javascript標準ライブラリの欠如は恐ろしい阻害剤です。いくつか挙げると、jQuery、Dojo、YUIなどの優れたフレームワークがありますが、それらはすべてプレゼンテーション層とXHRにのみ焦点を当てています。

構成可能なロギング、暗号化ツール、グラフアルゴリズム、UUIDジェネレーター、マップ、セット、ツリー、テンプレート、依存関係管理、日付操作、ローカリゼーション/国際化、マトリックス操作、依存関係注入、ユニットテスト、マップ削減、XML処理が必要ですか? JVMまたは.NET言語にとっては些細なこと-Javascriptでは、多くの場合、独自の実装をロールバックする必要があります。

5
Maros Urbanec

Javascriptが遅い理由の1つは、型安全性が完全に欠如していることです。どの変数も、いつでもどのタイプでもかまいません。また、ほとんどの操作はvalidであり、さまざまなタイプがありますが、semantics。簡単な用語

a += b;

abは数値または文字列になる可能性があるため、インタプリタにとってはそれほど簡単ではありません。両方が数値の場合、それは算術加算です。両方が文字列の場合、これは文字列の連結です。 1つが文字列で1つが数値の場合、文字列の連結を実行する前に数値をフォーマットする必要があります。これらは完全に異なる操作であり、引数の解釈を変える必要があります。

abのタイプに応じて、aのタイプは、以前のタイプに関係なく、整数、倍精度、または文字列になります。

JSの変数はいつでも型を変更できるため、インタープリターは、この命令が呼び出されるたびに型の評価を回避して、誤った操作を回避します。これには追加のCPUサイクルが必要です。

最適化をはるかに困難にする他の機能は、スパース配列またはガベージコレクションと、いつでも起動できるイベントハンドラーです。

asm.js を見てください。これはJavaScriptのサブセットであり、一部のJS機能(特に動的型付け)を取り除くことで、はるかに優れた最適化を可能にします。

2
Philipp