Monosnapのメモリ使用量が多すぎる?
タスク マネージャーのスクリーンショット1枚では、メモリリークは証明できません。以下の再現可能な手順で、一時的なスパイク、保持されたキャッシュ、別プロセスの影響、そして継続的な増加を切り分けてください。
1. きれいな状態のベースラインを記録する
- 作業を保存して、Windowsを再起動します。
- Monosnapを起動し、5分間は何もキャプチャしません。
- 次のキーでタスク マネージャーを開きます:
Ctrl+Shift+Esc。Microsoftはタスク マネージャーを、プロセスのリソース消費を確認するための標準機能として説明しています。 - Monosnapのバージョン、Windowsのバージョン、モニターの台数、そのプロセスに表示されているメモリの値を記録します。
Microsoft:タスク マネージャーと Windows のシステムツール
2. 同じキャプチャ手順を繰り返す
毎回まったく同じように再現できる手順を決めます。たとえば次のような内容です。
- 注釈なしの範囲キャプチャを10回
- 矢印1本とぼかし1か所を入れた範囲キャプチャを10回
- 短い録画を3本、停止して保存まで完了させる
- クラウドへのアップロードを5回
- 最後の作業のあと、10分間アイドル状態にする
各段階のあとにメモリを記録します。作業中に上がってその後下がる値と、同じサイクルを繰り返すあいだ上がり続けてアイドル時間を置いても落ち着かない値は、まったく別物です。
3. 見るべきメモリの列を確認する
タスク マネージャーの標準の「メモリ」列は手早い比較には便利ですが、それだけで診断が完結するわけではありません。Microsoftのメモリリーク調査ガイドでは、物理的なワーキングセットとコミット済み仮想メモリを区別し、継続的な増加を調べる際はコミットの挙動も確認するよう推奨しています。
Microsoft:アプリケーションとサービスのメモリリーク調査
4. 長時間の計測には Process Explorer か PerfMon を使う
Microsoft Sysinternals Process Explorer は、プロセスのハンドルや読み込み済みDLLなど、より詳しい情報を確認できます。時系列で記録する場合、Microsoftは パフォーマンス モニター を提供しており、値が落ち着くのか増え続けるのかを判断できるだけの時間をかけて計測することを推奨しています。
マシンと作業内容は揃えてください。片方はアプリを起動した直後のアイドル状態、もう片方は録画中、といった比較は避けます。
5. よくある交絡要因を除外する
- Windowsとディスプレイドライバーを更新してから、同じテストを繰り返します。
- DPIが混在した構成でのみ発生する場合は、モニター1台の状態でも試します。
- スクリーンショットのキャプチャと画面録画は分けて検証します。エンコーダーはリソースの挙動が異なります。
- 高い値がMonosnap自体のものか、ブラウザ/WebViewの子プロセス、デスクトップ ウィンドウ マネージャー、あるいは別のアプリのものかを確認します。
- 1回の外れ値だけで判断せず、クリーンな再起動のあとにもう一度同じ手順を繰り返します。
6. 開発元に証拠を送る
役に立つ報告には、アプリのバージョン、Windowsのビルド、モニターとDPIの構成、正確な再現手順、時刻、そして同じメモリ列を時系列で記録したCSVかスクリーンショットが含まれます。「一度すごくメモリを食った」という報告より、はるかに対応につながります。
代替ツールを公平に比較する
問題が続く場合は、Monosnapと並行して別のツールをインストールし、クリーンな再起動のあとに同じ手順を実行してください。MaxisnapはWindows向けの選択肢の1つで、ShareX、Greenshot、Snagitなども候補になります。機能とプランについては、 出典付きのMaxisnapとMonosnapの比較 をご覧ください。パフォーマンスについては、ご自身の計測結果で判断してください。
同じテストをMaxisnapでも実行する
ダウンロードは無料です。ご自身のハードウェアとワークフローで両方を比較し終えるまでは、Monosnapもそのまま残しておいてください。