モバイルアプリ開発フレームワークのレイアウトの計算、描画方式の違い

レイアウト計算のエンジンの派閥みたいなのがたまに気になるので、いま認識している範囲で雑に書いておきます。

「俺の愛する○○が入ってないじゃないか」は、僕が知らないかたまたま思いつかなかっただけで、特に意図的に排除したものはありません。

公式のレイアウト計算＋公式の描画

Androidでいえば、Androidを支える技術＜I＞で解説されているような、プラットフォームネイティブなレイアウト計算（measure）と描画（draw）が行われている方式です。

公式のSDKがここに入っているのは当然のこととして、Xamarin Native*1も、普通にLayout XMLやStoryboardでUIを組んだりするので、こちらに入ります。

レイアウト計算は独自の方式で実施しつつ、描画はネイティブ側におまかせする方式です。

このジャンルだと、広く使われていそうなのはFacebookのYogaでしょうか。Flexboxを中心とした、Webの方法論でUIを構築するためのレイアウトエンジンです。

今回調べてみて初めて知ったのですが、Xamarin.Formsも独自のレイアウトエンジンで動いてるっぽいですね。↓の記事を流し読んだだけなので、もしかしたら違うのかもしれませんが。

レイアウト計算も描画も自前で頑張ってる方式です。

公式と言えば公式のJetpack Composeを独自と呼ぶのもアレですが、Canvasにゴリゴリ書いてるみたいです。レイアウト計算について明言しているところは見つかりませんでしたが、ひとまずここに置いてみました。

FlutterやUnityは、独自方式をとっているおかげで、プラットフォーム間やバージョン間での表示差異が出づらいのがいいところです。

クロスプラットフォーム方面は、言語やUIキットの違いが取り沙汰されることが多い感じですが、こうして中を見るとレイアウト計算や描画の方式にも違った特徴があります。

言語やパラダイムが似ているように見えても、プラットフォーム差異やバージョン差異の起こりやすさ、ネイティブUIの取り込みやすさなどで違いがあるので、意識しておくとよさそうです。

エンジンがモバイル向けとして作られているわけではないのであえて書きませんでしたが、CordovaのレンダリングエンジンをWebViewであるとした場合は、「独自のレイアウト計算＋独自の描画」枠です。

*1:Xamarin.Formsを使わない開発方式をこう呼ぶと聞いたことがあるので、この名称を使わせてください