「10年の研究開発の道に立ち、フロントエンドの未来を見つめる」：読後_html/css_WEB-ITnose

以下の内容はただの戯言のようで、実用的な情報もソースコードもありません。これは単に私自身のめちゃくちゃな考えであり、個人的な一方的なものである可能性もあります。 。 。私はまだ実店舗に分類していませんが、でたらめです

フロントエンドに大きな関心を持っているクライアント開発者として、このインタビューを読んだ後、偶然目にしました。フロントエンドをよく知っている初心者ですが、それでも素晴らしいと思います。

10 年間の研究開発の道に立ち、フロントエンドの未来を見つめる

以下は引用元です

混合アプリ開発の長所と短所は何ですか?それが主流になるでしょうか？

Tongmu: ハイブリッド開発は主にダイナミズムの実現と開発コストの節約を目的としていますが、WebView で実行される部分はとにかくネイティブのパフォーマンスとエクスペリエンスを実現するのが困難です。現在の多くのテクノロジーの開発により、実際には WebView が変革され、荷物や歴史的な重荷を取り除こうとしています。 WebView にはどのような歴史的負担があるのか​​と疑問に思う人もいるかもしれません。詳しく見てみましょう:

まず第一に、標準互換性の負担があります。ユニバーサル ブラウザのコアとして、WebView 自体には上位互換性が必要です。たとえば、フレックスボックス レイアウト ブラウザはより効率的にレイアウトできますが、互換性を保つためには、フローティング レイアウト、相対配置レイアウト、さらにはテーブル レイアウトを認識できなければなりません。これらのロジックは非常に複雑に絡み合っており、身体全体に影響を与えます。ここで、新しい WebView をフォークし、フレックスボックス以外のサポートを削除するとします。これにより、レイアウト ロジックの複雑さが大幅に軽減されます。最適化を行わなくても、すでに大幅に高速化されており、状況がより単純になった場合にはフレックスボックスをターゲットにすることもできます。レイアウトは、パフォーマンスを大幅に向上させるために特別に最適化されています。

第二に、ブラウザの内部メカニズムと js 言語の設計には、実際には歴史的な問題があります。たとえば、ブラウザは最初から設計されており、js エンジンと dom エンジンは 2 つの独立したブラック ボックスです。js が dom を呼び出すとき、それぞれの呼び出しにはコンテキストの保存と復元が含まれます。同時に、js excute と dom render は同じスレッドで実行されます。この 2 つの間に呼び出し関係がない場合でも、dom はレンダリングされる前に js が実行されるまで待機する必要があります。これら 2 つの結果として、Web ページは動作中にこれら 2 つのブラック ボックス間を行き来し、さまざまなコンテキストの切り替えや相互の待機が行われるため、フレーム ドロップが避けられません。そこで、jsエンジンとdomエンジンを実行レベルで接続し、rpc呼び出しをローカル呼び出しに変更できれば、大幅に高速化できるでしょう。さらに、複数のコアを有効に活用したり、特定の条件下での js の実行とレンダリングを並列化したり、スタイル解決とレイアウトを並列化したりできれば、新たなパフォーマンスも向上する可能性があります。

繰り返しになりますが、WebView 自体は確かにますます高速になっていますが、OS の制限や一部のデバイスに古い WebView が存在することにより断片化の問題が発生し、これもペースを遅らせています。 iOS の Nitro や WKWebView から UIWebView、Andorid 4.4 以降の Chromium WebView から以前の WebKit WebView など、誰もがよく知っています。

Lao Guo の BeeFramework/Samurai と Alibaba の Birdnest は、最初の 2 つの負担を放棄する一方で、Web 標準のサブセットを採用し、他方では実行のためにすべてをネイティブ ランタイムに取り込みます。 Alibaba Weex は主に最初の負担を軽減します (2 番目の負担は部分的に最適化します)。Mozilla の Servo は主に 2 番目の負担を軽減し、Intel の Crosswalk、WeChat の X5、Alibaba の UCWebView などで 3 番目の負担を軽減します。一定の範囲内で... これらの荷物を取り除くために、誰もがさまざまな解決策を提案しました。

誰もがどの道を歩むとしても、全員が見つけたコンセンサスがあり、それは Web のいくつかの標準に準拠するというものです。なぜなら、Web の技術システムは UI 記述機能と柔軟性の点で非常によく設計されており、関連する開発者を採用するのが簡単だからです。したがって、ハイブリッド開発が、ネイティブで Web 標準を実行し、ランタイムを使用して GUI を記述し、一部のネイティブ機能を呼び出しのためにランタイムにブリッジすることを指す場合、それは永遠のトレンドとなるはずです。

fe に興味のある素人です

私は大学を卒業したばかりの頃にゲームを作っており、半年前には cocos2dx-lua の開発をしていました。この種の純粋な lua スクリプト ダイナミクスはすでに存在していました。ゲーム アプリ全体を更新するためのソリューションである、このスクリプト解釈主導のネイティブ ソリューションは、新卒の私に、探究し学びたいという無限の欲求をすでに与えてくれました。

その後、仕事上の理由で、私は植字に関連した作業をするようになりました。私たちのテキスト植字エンジンは、UI 記述ファイルの JSON を解析するものと非常によく似ていることがわかりました。 (HTML、CSSに似た内容) データ構造(domツリーに似たもの)を生成し、次に組版計算(フレックスボックスに似たもの)を実行し、レンダリング構造(レンダーツリーに似たもの)を生成して、レンダリングします。

その後、JSPatch と React-Native に出会いました。これらは動的更新という目的を達成できるように見えますが、深く考えると、多くのアイデアが完全につながっていることがわかります

。

• ネイティブを駆動するスクリプト (C++ ネイティブ、ネイティブ プラットフォーム ネイティブ、ランタイム ダイナミック ネイティブ)
• インターフェイス記述言語の構成レイアウトとレンダリング

この動的ハイブリッド ソリューションに非常に興味があったため、ネイティブを駆動するスクリプトを使用することにしました。 html+css駆動のレイアウトレンダリングが実装されており、知識欲も旺盛で、フロントエンドにも強い興味があります

H5開発とネイティブ開発が対立したり対立したりするとは決して思っていないのですが、この2つは何でしょうか？引用文の最後の段落で述べられているように、誰がその仕事を争うのかという問題については、ネイティブとウェブは調和した状態にあるべきだと思います。

4 つ目の荷物

私は FE についてまだよく知りませんが、クライアントの観点からこの問題を見て、私自身の考えがあり、それが正しいかどうかはわかりませんが、いくつかの考えがあることを心から願っています。専門家に修正を手伝ってもらうと同時に、FE での私の知識不足を補えるように最善を尽くします

ハイブリッドの話に戻りますが、先ほど述べた 3 つの問題に加えて、マスターさん、4つ目の荷物があると思います。rpcはjsとdomの間に存在するだけでなく、Web環境とネイティブ環境の間にもプロトコル通信が存在します。

ハイブリッドであるため、na の実行環境と js の実行環境は完全に独立した 2 つの環境です。同じアプリ内にありますが、2 つはそれほどスムーズではありません。と呼ばれ、すべてブリッジに依存します

webview に依存するハイブリッド JSbridge 設計に基づいています
cocos2dx-lua は、半自動的に生成された tolua++ の lua/C++ ブリッジ設計に依存しています
JavaScriptCore のブリッジング API に基づいた JSbridge 設計

橋 デザインや通話プランは異なりますが、この橋を渡るには諸経費や費用がかかるため、気軽に呼ぶことはできません。この負担を軽減したい場合は、可能なレイアウト操作と論理操作を最初に Web 環境内に配置する必要があります。

cocos2dx-lua と React-native を比較すると、cocos2d-x は動的更新の目標を達成するためにスクリプト駆動ネイティブを使用しますが、実際に欠けているのは、UI 記述言語の完全なセットのレイアウト機能です。最初のバゲッジが完全に欠落しているため、LuaEngine (JSEngine に類似) と Native のコンテキストを頻繁に切り替え、Lua を使用して Na レイアウト コード スキームを使用してインターフェイスを記述する必要があります。 4 つ目の問題は、私が述べた問題です (もはや、スクリプトと dom の間の切り替えではなく、スクリプトとネイティブの間の頻繁な切り替えです)。

しかし、cocos2dx には特別な機能があり、lua 言語の C カーネル インタプリタの動作効率と C/C++ 言語のネイティブ部分との類似性のおかげで、このコストは通常​​の 2D シンプル UI ゲームよりも高くなります。開発に関しては、現時点ではボトルネックはありませんが、COC のように同じ画面上に複数のアームがあり、それぞれが独立した AI 計算を行う状況に遭遇すると、困難になります (ゲーム チームが遭遇したケース)。以前はありましたが、具体的な状況はまだ少し複雑です、あまり良くありません、それはすべて 4 番目のバゲッジのせいです)

記事で述べたように、一方では、react-native は最初のバゲッジの最適化を開始しました、そして 2 つ目も React.js の virturl dom の特性に基づいて最適化しました。荷物、およびレイアウト操作が js 層で処理されるため、前述した 4 つ目の荷物のプレッシャーが軽減されます

私は少しだけ持っていますフロントエンドの知識が正しいかどうかはわかりませんが、最近フロントエンドを学ぶときに、知識のギャップを埋めたいと思っています。また、フロントエンドのクラスメートから指導を受けることを願っています

Hyrid は確かに引用文にあるとおりだと思います。標準の WebView がパフォーマンスやネイティブの固有のハードウェア デバイスのニーズを満たせない場合は、Web 標準を参照して、結局のところ、Web 標準は柔軟性の点で非常に多くのテストを経験しており、クライアントがカーネル戦略の一部を変更し、荷物を取り除き、最適化を目指して努力することができます。現在のモバイルデバイスのパフォーマンスに適応し、ダイナミクスを考慮したエクスペリエンスは、クライアントとフロントエンドが完全に調和したハイブリッドです

上記の内容は単なる話のように感じられ、あまり実用的ではありません。情報は、ソースコードはなく、私自身の乱雑なアイデアだけです。 。 。私はまだレンガ作りに分類していませんが、でたらめです