やかんです。
前回記事でreactについてリポジトリを読み始めました。
reactはブラウザ(と一部サーバー)で動作します。だから、最終的にはhtml, css, jsなのでまずブラウザから理解するのが近道ではって思いました。なので、ブラウザについて理解を試みます。
あとシンプルに今ブラウザについて理解したい欲が強い
web.devという神
googleが運営している、ブラウザについてのアプリケーションです。こういうメディア系いいですよね、、そしてブラウザというwebがあり続ける限り存続するであろう対象について押さえに行ってるあたり、参考にしたいです。
How browser work
こちらの記事です↓
https://web.dev/articles/howbrowserswork#Parsing_general
これを読んでいきます。
High-level infrastructure
- The user interface
- The browser engine
- The rendering engine
- Networking
- UI backend
- Javascript interpreter
- Data storage
user interfaceはそのまま。アドレスバーとかのブラウザのUI。browser engineはUIからのアクションとその下のrendering engineの間を取り持つ。コンパイラ的なやつってこと?rendering engineは、htmlとかpdfとかを解析して、画面に描画する。Networkingは読んで字の如くだけど、OSのAPI呼んでるんかな?UI backendはよくわからん。Data storageはこれもOSのAPI読んでるんだよな?
rendering engine
- IEはTrident
- FirefoxはGecko
- safariはWebkit
- ChromeとOperaはBlink
Webkitはオープンソースのrendering engine。Linux用のエンジンとして始まったらしい。
https://github.com/WebKit/WebKit
↑webkitはjs, html, c++がかなりの割合占めてるな。webkitについては後述。
基本的な流れとしては、
- parsing html to construct the dom tree
- render tree construction
- layout of the render tree
- painting the render tree
それぞれの流れについて見ていく。
まず、parsing html to construct the dom tree。
これは、ブラウザがHTMLを解析してDOMツリーを構築する作業。HTMLをチャンクに分割して、トークナイザ(htmlの解析はトークンという最小単位で扱われる e.g. div)して、HTMLの階層構造を反映した親子関係を持つツリーを形成する。このとき面白いのが、scriptタグが見つかると、DOMツリーの構築作業をストップし、scriptタグで囲まれた部分をダウンロードして実行する。
次に、render tree construction。これは、DOMツリーとCSSOMツリーを統合して、HTMLの階層構造とCSSのスタイルが統合されたレンダーツリーを構築する作業。CSSOMツリーとは、styleタグやlinkタグを解析してスタイルについて形成されたツリーのこと。CSSOMとは、CSS Object Modelの略。ここでめっちゃおもろいのが、displayがnoneに指定されると、レンダーツリーにそのDOM要素が含まれないということ。これがhiddenとnoneの違い。
次に、layout of the render tree。これは、レンダーツリーをもとにして各要素の位置とサイズを計算する作業。例えば、widthとかの値に%が指定されていると、親要素の値に依存する、など。この作業はめっちゃむずそうで今のところ全くのブラックボックスだ。このとき、DOMやCSSOMに変更が発生するとこの計算作業を再度実行する必要があり、パフォーマンスに影響するらしい、、これはどういうことかというと、appendchildなどがこれに相当する。描画後にDOMツリーが変更されると、それに伴いレンダーツリーも変更が必要になる。これはDOMツリーの変更の例だが、CSSOMツリーについてもウィンドウ幅が変更された場合、相対的値でスタイルを指定している部分についてはCSSOMツリーの変更が生じる。どちらにせよ、DOMツリーあるいはCSSOMツリーの少なくとも一方が変更されるとレンダーツリーの変更が余儀なくされ、その結果
最後に、painting the render tree。これは、レンダーツリーをもとにウィンドウに諸々描画する作業。これこそ、マジでどうなってるのかわからん。
Networking
- ユーザーがURLを入力
- OSのDNSリゾルバを使用してドメインに対応するIPを取得(つまり、ブラウザがOSのAPIをコールしてるってこと)
- OSのソケットAPIを通じてIPに対応するサーバーに接続
- なんらかの手法で暗号化を実現する
- レスポンス取得
これは、ソケットについての理解があるとスムーズかも。試みる。OSの授業で勉強したな。。ソケットはファイルディスクリプタの1種であるという理解に基づくと、
- sokcetの作成:OSから開いているファイルディスクリプタ番号を取得。以降、ソケットはこの番号を通じて使用される。
- connect:3 way handshake
- データ送信:1の手順でソケットをファイルとして扱う準備が整っているので、ファイルとしてソケットを扱い、そこにwriteするとデータが送信される。
- 受信:readする。
↑write, readあたりの解像度がまだ低いけど、OSがよしなになんかしてくれてるんだな、程度の理解で先に進もう。
webkitとは。
↑web browser engineと説明されているが、ブラウザのコンポーネント的にはrendering engineに相当する。
すごいな、consoleってこんなに種類あったんだ。。
https://webkit.org/web-inspector/console-object-api
では、reactの再レンダリングとは。
まず、reactは仮想DOMを作り、これを用いて間接的にブラウザのDOMに作用するという戦略をとっている。いわゆる「差分検出」のロジックで、仮にブラウザのDOMツリーに変更が生じる場合でも、「うまいことやって」、レンダーツリーの更新を最小限に抑える。レンダーツリーの更新が最小限だから、再レイアウトも最小限。その結果、再ペイントも最小限という話らしい。だから、発端となるのは「レンーツリーの更新を最小限に抑える」ということだろう。
また、小技として、複数のstateの更新があった場合、バッチ更新を適用するのもレンダリングコストに関する効率化の一例。
めも
- ブラウザは、ユーザー数がめっちゃ多いソフトウェア。webを利用するためにはほぼ必須と言っていい。
- ブラウザがやっているのは
- サーバーへのリクエスト
- 「ウィンドウ」への描画
- ブラウザで表示できるのはhtmlだけじゃなくて、pdfとかも表示できる。
まだまだ読み終わってないですが、今回はここまで!最後までお読みいただき、ありがとうございます!