最大のストレージ回収は、ほぼ常に少数の巨大ファイル
スマホがストレージ不足を警告してきたとき、自然な反応は古いスクリーンショットからバースト、そして重複して見えるものへと、手当たり次第に写真を削除し始めることです。正直な作業ですが、肝心なところで効果が出ることは稀です。ストレージ圧迫の真相はよりシンプルで、少し気まずいものです — 圧迫の大半は、少数の異常に大きなファイルにあります。
多くのライブラリは上位が重い
ライブラリをファイルサイズでソートし、上位20項目を見てください。典型的なスマホでは、その20項目が下位5,000項目を合わせたよりも重いです。4K動画、Live Photoのペア、高解像度の文書スキャン、ライブラリに保存されたダウンロードしたミーム — 重量級項目は一度に現れるわけではありませんが、数年かけて静かに積み上がります。
ロングテールが効かない理由
100枚の2 MB画像を削除して200 MBを空けることは生産的に感じます。数学はめったに噛み合いません。次に並ぶ写真も2 MBほどで、それが何千枚もあります。100個の小さな項目をレビューする時間は2つの大きな項目をレビューする時間に匹敵しますが、ストレージへの影響は桁違いです。
静かに最も容量を食う項目
一部の重量級項目は毎日見ないため忘れやすいです。一度きりのイベントのために撮った4K動画、スマホで編集して書き出した動画、スチルと動画の両方を含むLive Photoのペア。これらは大きく、一度見たかもしれず、「すべての写真」リストではサイズを示す形で浮かび上がることはありません。
上から始めて下に進む
意味のある容量を空ける最速の道のりは、サイズ順に並んだリストの上から下に進むことです。上での各決定はインパクトが大きいです — 1タップで数百メガバイトから数ギガバイトを解放できます。50 MB未満の項目に届く頃には、もうこの作業全体の始まりとなった小さな写真の整理に戻っています。
サイズ優先、そして記憶
便利な経験則:ファイルが重く、なぜ重要か思い出せないなら、通常それは削除できます。ファイルが重く、いつ再生するかが分かっているなら、それは残します。判断の枠組みは二択で素早いので、サイズ順にソートされたリストは、区別なく並んだリストの何分の一かで終わります。
ローカルレビュー、システム削除
サイズリストは、ライブラリのローカルメタデータから構築されます。レビューで何かがアップロードされることはありません。すべての削除は引き続きシステム写真ライブラリを介し、明示的な確認を経て行われるので、すでに信頼している保護された削除プロンプトが引き続き管理します。