scrcpy 5.0、GPUデコードでAndroidミラーリングのCPU負荷が約1/10に

Android Studioでアプリをビルドし、実機をUSBでPCにつないでscrcpyで画面を開く。レイアウトの崩れを確認してはコードを直し、また同じ実機をビルドし直す。この確認作業を何度も繰り返しているあいだ、ノートPCのファンはずっと回りっぱなしで、裏で走らせているビルドまでワンテンポ遅くなる。画面を映しているだけなのに、なぜここまでCPUを持っていかれるのか。

この負荷の正体と、それが2026年10月5日にリリースされたscrcpy 5.0でどう変わったのかを見ていく。開発元の説明では、CPU使用率は約1/10になる。

なぜscrcpyは動画再生より重いのか

同じノートPCでYouTubeの4K動画を再生しても、ファンはそこまで激しく回らない。scrcpyで画面を映しているときだけ、なぜこんなに差が出るのか。

scrcpyは、USBまたはWi-Fiで接続したAndroid端末の画面をPCで表示・操作できるコマンドラインツールだ。GitHubで公開されているオープンソースソフトウェアで、Windows・macOS・Linuxに対応する。アプリ開発者が実機でのレイアウト確認に使うだけでなく、QA担当者が複数の実機をまとめて検証する場面でも使われる。サポート担当者が問い合わせ対応で、利用者と同じ画面を見ながら手順を説明するのに使うこともある。

多くの人は意識したことがないはずだが、動画も中身は圧縮されたデータで、画面に映すにはその圧縮を解いて元のピクセルの並びに戻す計算がずっと走っている。この計算が重いからこそ、PCやスマホのGPUには動画再生に特化した専用回路が何年も前から組み込まれてきた。scrcpyがAndroid端末から受け取る映像も、仕組みは同じ圧縮データだ。「戻す」計算をしている点は動画再生と変わらないのに、なぜscrcpyのときだけファンが悲鳴を上げるのか。

GPUに仕事を渡すハードウェアデコード

答えは、その「戻す」処理(デコード)を誰が担当しているかにある。動画の圧縮方式(H.264やH.265など)は、同じパターンの計算を映像の1コマごとに繰り返す処理のかたまりだ。汎用の計算回路であるCPUでこれをソフトウェア的にこなすと、何でもできる代わりに動画の復元だけに最適化されていない分、時間も電力もかかる。PCやスマホのGPUには、この計算専用の回路が組み込まれている。多くの動画プレーヤーは最初からこの回路(ハードウェアデコード)に仕事を任せているので、CPUはほとんど働かずに済む。

scrcpyはこれまで、この処理をCPUの汎用的な計算力だけで行うソフトウェアデコードに頼っていた。GPUの中に専用回路があることと、個々のソフトがその回路へ処理を回す設定になっているかどうかは別の話であり、動画再生とscrcpyの体感差はここから生まれていた。

CPU使用率が約1/10になる理由

scrcpy 5.0の目玉は、このハードウェアデコードがデフォルトで有効になったことだ。窓の杜の記事によれば、開発元の説明としてCPU使用率は約1/10になるという。

約1/10とは、たとえば映像の復元だけでCPU使用率が80%に張り付いていたなら、8%程度まで下がる桁の変化になる。自分がこれまでscrcpyを使うたびに無意識にCPUへ押し付けていた仕事を、PCはとっくに別の場所でもっと効率よくこなす用意ができていた。

自分の環境でも効果は出るのか

恩恵を受けるのにscrcpy側で特別な設定はいらない。GPUの専用回路を呼び出す窓口(API)はOSごとに別物で、scrcpyはそれぞれに合わせて実装している。いずれもv5.0からデフォルトで自動選択される。

OSが違ってもscrcpy側の体験は変わらない。どのAPIを使うかはインストールしたOSで自動的に決まり、使う側が窓口の名前を意識する場面はほとんどない。挙動は--hwdecオプションで切り替えられる。

• auto(デフォルト): 対応していれば自動でハードウェアデコードを使う
• disabled: 従来どおりソフトウェアデコードに固定する
• vaapi / d3d11va / videotoolbox: OSごとのAPIを明示的に指定する

この記事が当てはまるのは、PC側のGPUとドライバがハードウェアデコードに対応している場合に限る。対応していないGPUやドライバでは自動でソフトウェアデコードにフォールバックし、CPU使用率は従来のままになる。対応状況の一覧はscrcpyの公式情報に見当たらない。

自分の環境で効果が出ているかを確かめる方法は難しくない。--hwdec=disabledと--hwdec=autoをそれぞれ起動する。そのたびにタスクマネージャーやアクティビティモニタでCPU使用率を見比べればよい。

Windows ARM64の新しいビルド

scrcpy 5.0では、Windows向けにARM64ネイティブビルドの配布も始まった。窓の杜の記事は、x86版をエミュレーションで動かすより安定性が上がり、消費電力も削減されると伝えている。

Snapdragon搭載のWindows PCでこれまでscrcpyを使っていた人は、x86向けのビルドをエミュレーション経由で動かしていたことになる。エミュレーションは、x86向けに書かれた命令をその場でARM向けに変換しながら実行する仕組みで、変換の分だけ余計な計算が挟まる。ARM64ネイティブビルドはその変換を挟まず、プロセッサが直接理解できる命令で動くため、同じ作業でも負荷が小さくなる。ハードウェアデコードの対応と合わせると、Snapdragon搭載PCでは今回のアップデートで負荷が二重に下がる組み合わせになる。

まとめ

scrcpy 5.0は、映像の復元(デコード)をCPUからGPUへ任せる設定をデフォルトにし、開発元の説明ではミラーリング中のCPU使用率が約1/10になった。特別な設定は要らず、アップデートするだけで恩恵を受けられる。PCのGPUやドライバが対応していない場合は、これまでどおりソフトウェアデコードにフォールバックする。Windows ARM64機では、エミュレーションに頼らないネイティブビルドも新たに選べるようになった。