ローカルにMacBook Pro、リモートにMac miniを使って、Google リモートデスクトップ *1 をやってみました。

データ利用量は1時間で460MB

実際にはテザリングで利用することを想定していますが、テストとしてWi-Fiネットワーク内で1時間、試してみました。アクティビティモニタでデータの転送量を確認してみると、462.8MBでした。

10時間ぶっ続けで使用したら4.6GB近くデータを利用することになりますが、先日のテザリングで23GB使ってしまった *2 のに比べればたいしたことありません。

レチナをやめればもう少しデータ量は減る？

リモート側もローカル側もレチナ環境（HiDPI）だったので、表示は抜群にキレイでした。ただ、リモート側は2560px × 1440px（HiDPI｜実際には倍の5120px × 2880px）でずっと送信し続けていたことになります。データの節約を意識するならば、レチナをやめて *3 普通の2560px × 1440pxで作業すれば面積比1/4でもっとデータの使用量は少なかった *4 でしょう。今度試してみます *5 。

追記：リモート側の画面解像度を半分にした（HiDPIを止めた）ところ、2時間で399.4MBと、半分以下になりました。10時間で2GBです。さすがに1/4にはなりませんでしたが実用性は高いです。

⌘キーがあってもそれなりに不便

前回、Chromebookでリモートデスクトップを試した時 *6 はローカル側のキーボードに「⌘」がなく、キーボード操作が全く実用になりませんでした。今回は両方ともMacなので、キーの不足はありません。

ですが、ローカルマシンとリモートマシンでキー信号の取り合いになり、それなりに不便な状況がありました。

アプリケーションの主なショートカットキーの操作はきちんと機能します。⌘＋S、⌘＋C、⌘＋X、⌘＋Vなど……。
Karabiner-Elementsによる入力モードの変更ができませんでした。ローカルマシン側の切り替えとして機能します）。
リモートマシン側の入力モードの切り替えは（使用しているIMの「かわせみ3」の機能）「caps lockのオン／オフ」で行いました。
⌘＋tabを使った、アプリケーションの切り替えはローカル側が反応してしまいます。

ですが、致命的な不具合はありませんでした。

追記：その後使い続けたところ、下記のようなことにも気づきました。

ローカル側のトラックパッドの操作（ピンチ拡大など）はリモート側がマウスのみなので操作できませんでした。リモート側にトラックパッドがあったとして意図通りに機能するかは不明です。
Adobeアプリで拡大（⌘＋スペースバー｜虫眼鏡モード）の操作ができませんでした。これはけっこうつらい。ショートカットによる拡大（⌘＋2など）で対応しました。