手数の多かったサイクル数などのチェックが簡単になります.
※価格は記事執筆時のものです. 現在の価格はApp Storeから確認ください.
レビュー時のiOSバージョン : iOS14.2
スポンサーリンク
ダウンロード
使い方
設定アプリを開き, 「プライバシー」→「解析および改善」をタップします.
「解析データ」をタップし,
log-aggregated-xxxx-xx-~
という項をタップします.
もし「iPhone解析を共有」のスイッチがオフの状態なら, このデータログが作成されません.
スイッチをオンにして一日待ってから再試行してください.
なおこのデータはどういう基準かわかりませんが画像のように当日を含め過去7日分あればもっと多いときもあります.
log-aggregated-xxxx-xx-~の画面右上にある共有アイコンをタップし, ダウンロードしたショートカットレシピを選択します.
すると画像のようにログのファイル名に続いて
- CycleCount:サイクル数
- design_capcity:購入時のバッテリー最大容量
- raw_max_capacity:ログを取った日のバッテリー最大容量
- battery.health:上記2つを元にしたバッテリー寿命
が表示されます.
battery.healthは設定アプリの「バッテリー」→「バッテリーの寿命」にある数字と必ずしも一致しません.
以降はもうちょっと具体的な話や蛇足のようなものです.
サイクル数と寿命
iPhoneをはじめとして多くの電子機器に使われているリチウムイオンバッテリーの寿命は, 主にサイクル数によって決まります.
少なくともAppleの言う「サイクル数」は, バッテリーを100%分使ったら1カウントとして数えます.
充電した回数ではありません.
iPhoneのバッテリーは、フル充電サイクルを500回繰り返した時に、本来の容量の最大80パーセントを維持できるように設計されています。
support.apple
なので公式で指摘している「500回」とは充電回数でなく「充電サイクル数」です.
よって現在この回数がどれぐらいか…がiPhoneの劣化を示す指標の一つとして我々は知っておきたい情報です.
また劣化の別の指標として「バッテリーの最大容量」があります.
例えば購入時3000mAhのiPhoneを買ったとして, ある時最大容量が1500mAhであったとすると, この状態で満充電してもその量は1500mAhです.
なので購入時のバッテリー100%とその後の100%は一致せず, 基本的には少ない値となります.
最大容量が減れば当然それだけ使える時間が減り, 充電する頻度が増えるのでサイクル数もどんどん増えます.
「フル充電したのにすぐに減っていく」のは最大容量が減っていることが一因なわけです.
過去にこれらが分かるcoconutBatteryというアプリがありましたが今はストアから削除され, 端末に残した状態でも起動しないのでお手上げだったんですよね…
解析データから見る
確実なのは先日紹介した, 解析データから確認する方法です.
毎日朝9時過ぎに新しい情報(前日なんでしょうね)が追加され, そのファイルの中にサイクル数やバッテリーの最大容量を含む情報が入っています.
しかしファイルを開いた画面ではキーワード検索はおろかテキストを全選択できないので, 地道にテキストを選択してコピーし, メモ帳などに貼り付けてやっと検索…というのが前回の結果でした.
今回はそれをショートカットを使って取り出そう…というわけです.
うまく行かないうまく行かない…とあれこれ試行錯誤したら「名前を設定」アクションを使うことでテキストとして取り込むことができました.
中身はplist形式なのでショートカット内で辞書化できます, ただ先頭にあるタイムスタンプを含んだ状態だとダメだったので取り除いています.
拡張子はともかく名前が「A」になっていますが今回は特に意味はありません, BでもCでもhogeでもいいです.
今回必要な情報が入っている3つのキー
com.apple.ioreport.BatteryCycleCount
com.apple.power.battery.design_capacity
com.apple.power.battery.raw_max_capacity
が全体の辞書におけるキーの一つである"ADScalars"の中に入っていることは確認済みだったので, それぞれ掘り下げるだけでした.
項目によってはアプリの起動回数や充電回数(挿入した回数,抜いた回数)など色々あります, 今回の3項目は全体のほんの一部です.
また別の日と比べるとログの順番や項目の有無に違いがあります, その日によって何を使ったか, 何をしたか…が違うので項目の有無についてはまだ分かりますが順番が違ったりするのは意外でした(今回はそれで問題が生じるわけではないですが).
〆
複数の解析ログでちゃんと取得できることを確認していますが例外があるかもしれません(流石にないとは思いますが).
解析データのページまで移動するのが地味に面倒なんですよね, 特にlog-aggregated-~までに他のログが結構あったりするのでうっかり飛びすぎてしまうことも.