今週末、開発者のローレン・ブリヒター氏は、Mac版Google Chrome、より具体的にはその自動更新メカニズムにより、macOS上のWindowServerプロセスのCPU使用率が常に高くなり、ハイエンドマシンでもmacOSのパフォーマンスが低下していると主張するウェブサイトを公開した。

このウェブサイトには、MacからChromeとそのアップデータを完全に削除してパフォーマンスを回復する方法に関する情報が掲載されており、それを「マルウェア」と呼ぶことさえありました（この言葉はその後削除されました）。多くのユーザーから、この方法は実際に効果があり、Google Chromeをマシンから削除した後、すべてが大幅に高速化したという報告があります。

まず最初に、私はGoogle Chromeのファンではないことをはっきりさせておきます。オンラインで行う作業によってはChromeが必要なのでインストールしていますが、ブラウザはSafariを愛用しています。私が興味を持ったのは、この話の技術的な側面と、ローレンのレポートを読んでいるときに浮かんだいくつかの疑問です。それは、プロセスが実行中にアクティビティモニタから自身を隠すことは可能か？アップデータプロセスはいつ実行され、何をするのか？人々が目にしているこのWindowServerのCPU使用率の原因は、本当にGoogle Chromeアップデータなのか？

プロセスが実行中にアクティビティ モニターから自身を非表示にすることは可能ですか?

この質問に対する明確な答えはありません。私が見つけた唯一の実用的な方法は、システム上で実行中のプロセスを監視し、アクティビティモニタが見つかった場合は、アクティビティモニタに表示されないようにプロセスを終了させることでした。GoogleのKeystoneアップデータがなぜこのようなことをしなければならないのか理解できませんし、バイナリを簡単に静的に分析しても、そのような方法は見つかりませんでした。

アップデータプロセスはいつ実行され、何を行いますか?

GoogleのKeystoneサービスは、Mac上で実行される他のサービス型アプリやプロセスと同様に、launchdプロパティリストを使用してシステムに登録されます。launchdはmacOS上でプロセスを生成するデーモンであり、launchdプロパティリストは基本的に、特定のサービスをどのように扱うべきかをlaunchdに指示する設定ファイルです。

Google Chrome アップデーターの場合、 にある同じバイナリでサポートされている 2 つのサービスを登録します~/Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle/Contents/Resources/GoogleSoftwareUpdateAgent.app/Contents/MacOS/GoogleSoftwareUpdateAgent。

「Keystone User Agent」サービスは秒単位StartIntervalの値に設定されている3623ため、アップデートの確認のために約1時間に1回実行されます。もう1つの「Keystone XPC Service」は、Googleアプリがオンデマンドでアップデートを確認する必要がある場合にのみ起動されます。これらのサービスは無期限に実行されるものではなく、アップデートを確認するため、またはGoogleアプリが通信する必要がある場合にのみ定期的に起動されます。そのため、これらのサービスがWindowServerの速度を低下させるという主張はさらに興味深いものになります。

このアップデータエージェントが何をするのかについては、Hopper を使って関連するバイナリを静的に解析し、基本的なリバースエンジニアリングを行いました。クラッシュレポートがあればアップロードしたり、Chrome などの Google アプリのアップデートを確認したりといった処理を行っているようです。実際に動作している様子をアクティビティモニタで確認したところ、「Google ソフトウェア アップデート」と表示されていました。

この基礎調査は、このソフトウェアが潜在的に悪質な行為を行わないことを証明するものではなく、限られた時間で調査した結果、特に気になる点は見つからなかったというだけのことであることに注意してください。

Google Chrome アップデータが、実際に WindowServer の CPU 使用率が高くなっている原因なのでしょうか?

これが、私がテスト中に答えようとした主な疑問でした。テストは、Core i9プロセッサと16GBのRAMを搭載した2019年モデルの16インチMacBook Proで実施しました。マシンは外部ディスプレイに接続され、テスト中は基本的なバックグラウンドタスク以外のアプリはアクティブに動作していませんでした。また、マシンがスリープ状態にならないように、 Caffeinateを実行したままにしていました。

CPU使用率などのソフトウェアメトリクスを経時的に観察できるInstrumentsを使用して、2つのセッションを記録しました。1つはGoogle Chromeをインストールした状態、もう1つはGoogle Chromeとアップデータサービスをアンインストールした状態です。Instrumentsセッションの最初の30分間を使用して、各シナリオにおけるWindowServerのCPU使用率を測定しました。

上記の比較からわかるように、Chrome がインストールされている場合、WindowServer プロセスはテストウィンドウ中に約50 秒の CPU を使用しました。Chrome とそのアップデータがインストールされていない場合は、約49 秒でした。この差はごくわずか（目に見えるパフォーマンスの問題を引き起こすレベルをはるかに下回る）であるため、これは問題の確証とは考えられません。

それとは別に、1時間に1回実行されるプロセスが、全く関係のないシステムサービスのCPU使用率を高くする、という主張自体が的外れです。WindowServerはmacOSのUIを画面にレンダリングする役割を担っており、CGXUpdateDisplayCALayersのレンダリングというメソッドに時間を費やしています。これは、UIを持たないソフトウェアアップデートチェッカーが行う処理とは全く関係のないタスクです。

なぜ人々は、Mac のパフォーマンスを低下させているのは Chrome のせいだと考えているのでしょうか?

人々がなぜこの問題とその解決策を認識しているのか、いくつか可能性が考えられます。その一つはプラセボ効果です。問題を抱え、誰かが解決策を教えてくれたことを実行すると、まるで問題が解決したように感じるのです。これはコンピューターの世界では想像以上に一般的です。もう一つは確証バイアスです。GoogleとGoogle Chromeが嫌い（私も好きではないので、仲良くなりましょう）なのに、そのソフトウェアに対する自分の認識と一致するストーリーを見て、本能的に信じてしまうのです。

ここで影響している可能性のあるもう1つの要因は、Lorenのウェブサイトの手順では、説明されている手順を実行した後にマシンを再起動するように指示されていますが、Googleのソフトウェアアップデータをアンインストールするためには再起動は不要であるということです。実際、私のテストでは、実行されていないことを確認してから実行launchctl unloadし、launchdのプロパティリストとバイナリをシステムから削除することでアンインストールしました。これは、再起動したばかりのコンピュータは、数週間稼働していたコンピュータよりも常に速く感じるため、テストからその変数を排除する必要があったためです。

それでも Google Chrome が Mac のパフォーマンスを低下させていると感じる場合は、ぜひ削除してください。代わりに Safari をお勧めします。

havebin.com を Google ニュース フィードに追加します。 

FTC: 収益を生み出す自動アフィリエイトリンクを使用しています。詳細はこちら。