GoogleのFlutterで作られたアプリはCPUサイクルを無駄に消費する可能性があります。このウェブ界の巨人は、この問題に対してどのような対策を講じるつもりでしょうか。

Google の Flutter クロスプラットフォーム アプリ フレームワークには、思考の問題があるようです。特定の状況では、Flutter デスクトップ アプリが過剰な処理能力を消費します。

どれくらいが多すぎるのでしょうか？ネイティブmacOSアプリのようなカーソルの点滅を再現するためだけに、CPU使用率を6～10%高くしてみてください。これは、Flutterデスクトップアプリのサポートがアルファ段階だった2019年に報告されたCPU使用率100%と比べると改善されています。

これはモバイルデバイスでは致命的な問題となるでしょう。モバイルデバイスでは、バッテリー切れでスマートフォンの画面が真っ暗になるようなアプリはユーザーが許容しないからです。しかし、Flutterが成熟するにつれて、エネルギー効率の悪さはある程度懸念されるようになってはいましたが、最近のFlutterのAndroidおよびiOSビルドでは、エネルギー効率の悪さはそれほど大きな問題ではありませんでした。モバイルデバイスにおけるFlutter開発者にとってより切迫した問題は、シェーダーコンパイルによって生じる遅延、いわゆる「ジャンク」の削減です。

デスクトップ アプリ、特にプラグイン デバイスの場合、メモリと CPU をかなり自由に使用する多くの Electron ベースのアプリの継続的な贅沢なライフスタイルから推測できるように、過剰なリソース消費は開発者/ユーザーの利便性とのトレードオフとして許容されることがよくあります。

しかし、Flutter のセールスポイントの 1 つは、Electron フレームワークや同様のクロスプラットフォーム テクノロジよりも小型でパフォーマンスの高いアプリを提供できる可能性があることです。

Flutterは、Android、iOS、Windows、macOS、Linux、ウェブ、そして組み込みデバイスで動作するアプリを単一のコードベースから作成するためのツールセットを開発者に提供します。Flutterは、C/C++で記述されたグラフィックレンダリングエンジンであるSkiaを高度に活用することでこれを実現しています。Skiaは、ネイティブプラットフォームのインターフェースライブラリに依存せず、デバイスのCPUまたはGPUを使用してアプリのインターフェースを独自に描画します。

しかし、Flutterは合成を独立して処理するため、リソースを最適化したコードを書くという課題が増大しています。ネイティブライブラリの使用を避けているため、ネイティブプラットフォームコードで得られる効率性の一部が失われています。

Flutter の場合、点滅カーソルの CPU 使用率は 1 年以上にわたって GitHub の問題として公開されています。

2020年8月時点で、GoogleのシニアソフトウェアエンジニアであるKaushik Iska氏は、Flutterは期待通りに動作しており、Flutterチームは後日改善を検討する可能性があると述べています。

その時期はまだ到来していませんが、近いうちにそうなる兆候があります。Googleの広報担当者はThe Registerに対し、「Flutterのデスクトップサポートはまだ開発中であり、パフォーマンスを判断するのは時期尚早です」と述べています。

実際、デスクトップ版 Flutter はまだベータ ソフトウェアとして指定されており、Google のエンジニアが時間をかけてパフォーマンスを改善してきたという証拠は十分にあります。

また、カーソルの問題は他のシナリオではリソースの使用状況を反映しておらず、Flutter チームはいずれこの問題を修正または軽減する予定であるとも伝えられました。

しかし、リエンジニアリングはFlutterのカーソル負荷の軽減だけにとどまりません。Linuxビルドではメモリ使用量が過剰になるという報告もあり、FlutterをIoTシナリオに適したものにするには、この点も修正する必要があります。また、Flutterはアニメーション化されたウィジェットを画面の変更部分だけでなく、全体的に再描画する傾向がありますが、これも近いうちに改善される可能性があります。

すべてを統括する単一のフレームワークを作成するのは簡単ではありません。しかし、ネイティブオペレーティングシステムのコードを書くのも同様に簡単ではありません。®