電力の制限：バッテリー消費の改善

電力の制限：バッテリー消費の改善

電力使用量を制限しながら、ユーザがAppをさらに活用できるようにする方法をご確認ください。ご自身のコードに4つの重要な変更を加えて、Appからのバッテリー消費を抑える方法について解説します。さらに、ご利用のAppにダークモードを追加してOLEDディスプレイの利点が得られるようにしたり、セカンダリアニメーションからのフレームレートを監査したり、バックグラウンドデータ処理を制限したり、長時間実行タスクを延期したりする方法を紹介します。

リソース
関連ビデオ

WWDC22
- Push to Talkで音声通信を強化する
WWDC21
- 可変リフレッシュレートディスプレイ向けの最適化
WWDC19
- iOSのダークモードを実装する
- Webコンテンツをダークモードに対応させる
ダウンロード

♪ ♪ こんにちは Vaibhav Gautamです Software Powerチームのエンジニアです Appは一日を通して様々な重要な機能を提供し生活を豊かにしていますしかし代償が伴います：バッテリーの消耗ですそのため Appのバッテリー駆動時間の改善には特に注目すべきですより長くデバイスやAppを使えるようにするためです我々は消費バッテリーを理解するためにシステムコンポーネントを研究していますこの動画では Appのバッテリー寿命を大幅に改善するために我々が特定した 4つの重要なアクションを紹介しますその4つとは Appのダークモードフレームレートの監査バックグラウンド時間の制限 Appの作業の延期です
まずはダークモードについてダークモードは iOS 13で導入されデバイスを暗い表現のプレゼンテーションで構成できますダークモードの個人への効果は知られていますがバッテリー駆動時間にも劇的に影響します
iPhone 13や13 Proのような有機ELディスプレイ搭載のデバイスでは暗いコンテンツは明るいものよりも消費バッテリーが少ないためです有機EL画面では画素ごとに電力を必要とし暗い色ほど少ない電力で画素が点灯できますシステムを構成する部品の中でディスプレイはバッテリー消費の大きな要因の一つです実際一般的な使用例ではディスプレイがバッテリー消耗の主要因になり得ますディスプレイの消費バッテリーに影響する方法の一つがダークモードの採用です私のチームが取り組む Food Truck Appを例に挙げて説明しますこのAppは画面の大半を占める背景色がとても目立ちますダークモードでは背景色がライトモードよりかなり濃くバッテリーの節約に大きく貢献しますこのようなケースでは結果として最大で70% ディスプレイの省電力化が期待できますこれは大きな節約です！画面の輝度が高い場合はさらに高いバッテリー節約効果を発揮しますダークモードを好むユーザーにとってバッテリーの消耗を抑え熱負荷も軽減できる絶好の機会ですまずダークモードを有効にしたときに Appがどのように表示されるかの確認から始めます Appのどのコンポーネントを更新すればシステムの UIに適合するか把握します App構築の際にアピアランス機能を使用することで Xcodeがこれを簡単にします
ライトモードしか対応せず Appの色がハードコードされている場合もあります Xcodeのダイナミックカラーで両方の背景色画像テキストに対応させますシステムが自動的に正しいカラーバリューを使用しモードが変わると更新します
また Appはライトモードとダークモードの代替画像に対応する必要があります Appのダークモード対応について詳しくはWWDC 2019の「iOSのダークモードを実装する」をご覧ください
Appだけでなく Webコンテンツにダークモードを採用する方法も考えておきましょう Safariは Webコンテンツを自動で暗くはしないので Webコンテンツにもダークモードを採用します
Webサイトのスタイルシートにcolor-schemeプロパティを
実装することで Webページのデフォルトのテキストと背景色が現在のシステムの外観や標準的なフォームコントロールスクロールバーと一致しますほかの名前の付いたシステムカラーはライトとダークモードを切り替えて表情を変えますスタイルシートで色が参照される場所ではスタイルシート変数を使いますこれでデバイスがライトとダーク間で切り替わると Webコンテンツの色が更新されます Webページの画像やメディアアセットにも同様に適用しモードごとに異なるバリエーションを用意します Webコンテンツへのダークモードの実装について詳しくは WWDC 2019の「Webコンテンツをダークモードに対応させる」を参照してくださいバッテリー節約の別の方法はフレームレートの監査です ProMotionディスプレイを搭載したデバイスではリフレッシュレートが消費電力に影響しますリフレッシュレートが高いほど消費電力も大きくなり App内のアニメーションのフレームレートがディスプレイのリフレッシュレートを決定します App内のコンテンツすべてに高いフレームレートが必要なわけではないので App内のプライマリコンテンツが必要とするフレームレートを考慮してくださいディスプレイのリフレッシュレートは Appの中で最もフレームレートの高いアニメーションが決定します Appの二次的要素が必要以上に高速に更新され App全体が予想以上にバッテリーを消費している可能性があります
再び Food Truck Appの登場です冒頭では毎秒30フレームでレンダリングしていますトラックの下には「Food Truck」というテキストオーバーレイがあり水平方向にスクロールしますこのセカンダリテキストは毎秒60フレームなので結果画面全体が毎秒60フレームでレンダリングされますテキストアニメーションを 30fpsに変更すれば画面全体が30fpsでレンダリングできるのでバッテリーの消耗を最大20％抑えらえれます素晴らしいですね！ Appのデバッグやフレームレートに関する詳細を得るには Instrumentsを使用します CoreAnimation FPS instrumentで Appのフレームレートが時系列で表示できます主なユーザーシナリオの監査から始めましょうフレームが期待したレートでレンダリングされているかの確認は画面上の二次的要素がプライマリのコンテンツよりも高いフレームレートかどうかで判断します
AppはiOSのCoreAnimationの CADisplayLinkでしばしばカスタムアニメーションやレンダーループを駆動します CADisplayLinkはディスプレイのリフレッシュレートに同期したタイマーでカスタム描画がリフレッシュイベントを認識できるようタイミング情報を渡します AppはCADisplayLink オブジェクトに希望する画面のリフレッシュレートに関するヒントを与えられます CADisplayLinkのpreferred FrameRateRangeを設定し最小最大好みのフレームレートを指定します
ディスプレイリンクはシステムが処理可能なフレームレートに基づいて希望に最も近く利用可能なレートを選択しますレートが提供できない時は指定した範囲内に収めようとしますディスプレイリンクを設定するにはターゲットとセレクタを指定して初期化しますこのセレクタはカスタムアニメーションの実行と次に表示するビデオフレームの計算に使用しますディスプレイリンクが初期化されたら希望のフレームレート範囲を設定しますこの例で好ましいレートは 30ですが 10～60の範囲で扱うことができます最後に現在の実行ループにディスプレイリンクを追加します
Appのバッテリー消費とリフレッシュレートは相関しダイナミックなリフレッシュレートに対応するProMotion ディスプレイを搭載したデバイスには特に重要です InstrumentsでAppのフレームレートを監視し Appをリリースする前に問題の発見ができます最後に CADisplayLinkで Appコンテンツのリフレッシュレートを制限する情報をシステムに渡します
フレームレートの最適化について詳細は WWDC2021の「可変リフレッシュレートディスプレイ向けの最適化」をご覧くださいではバックグラウンドで動作しているAppをパワーダウンさせる方法の説明に移ります誰かがみなさんのAppから別のAppに切り替えたときバックグラウンドでみなさんの Appが実行され続けてバックグラウンド実行APIに依拠することがありますバックグラウンド動作中に Appは位置情報やオーディオなどの共通サービスを使い続ける場合があります長時間実行するとバッテリーの消耗が激しくなるため Appがバックグラウンドでこれらサービスを使う場合は特に注意が必要です！これらのモードを使う際に過剰な消耗を回避する方法を説明します位置情報サービスではデバイスを起こし続けて位置情報を流し続けますユーザーからは見えない Appでもバックグラウンドで位置情報を流し続け過剰にバッテリーを消耗する可能性があります Appのバックグラウンドローケーションセッションの実行時間を必ず確認しましょうセッションが不要になったら Appが stopUpdatingLocation() を呼び出してセッションを停止させることを確認します App開発のさまざまな段階でツールを使ってバックグラウンドで想定外の位置情報の利用がないか調べられます Appのビルドとテスト中に Xcodeのゲージでシステムのエネルギー使用量やバックグラウンドの位置情報の使用量を知ることができますリリース前のAppをテストする際は MetricKitで 1日使用した場合の診断情報が収集できます iOS 16の新機能にコントロールセンターでの位置情報の使用の表示があります Xcodeゲージは CPU 位置情報ネットワーク使用状況などに関する情報を提供します XcodeのゲージはAppの位置情報の使用状況やエネルギーへの影響を時系列で表示しますこのタイムライン表示で位置情報のランタイムが予想される時間に停止するかどうか確認できます Appのテスト時にMetricKit を使用するのも有効です cumulativeBackgroundLocationTime プロパティで Appのバックグラウンドでの位置情報の使用時間を調べます
iOS 16の新機能ではコントロールセンターでユーザーは現在位置情報を使用しているAppを監視できます　上部のテキストをタップすると位置情報を利用している Appの詳細が表示されます外出先で位置情報の使用時間を監視するために使用しますみなさんのAppが表示されたらアクティブな位置情報ストリーミングセッションを持っている指標になります同じ原理をオーディオセッションにも適用できます例えば音楽Appでオーディオプレーヤーを使ってファイルを再生していてそれを止めたとします Appは音の一時停止や停止だけでなくオーディオエンジンがアイドル状態にならないよう一時停止や停止をする必要があります AVAudioEngineクラスの autoShutdownEnabled プロパティを設定しオートシャットダウンモードを使用することをお勧めしますこのモードではオーディオエンジンが一定時間アイドル状態かどうか継続的に監視し検出しますアイドル時にはエンジンがオーディオハードウェアをシャットダウンしますその後いずれかのソースが再びアクティブになればオーディオハードウェアを同時に起動します　これらはすべて内部で行われます watchOSでは強制的に自動シャットダウンモードが動作します使用しないときは節電のため必ずオーディオエンジンを停止してくださいバックグラウンドの実行時間を制限する鍵は終了するときにそれをシステムに伝えるのを忘れないことですバッテリー駆動時間を改善する最後のアクションは作業の延期です 1日で Appはたくさんの異なるタスクやデータを処理することがあります画面上にコンテンツを表示したりユーザーがタップした音声や動画を再生したりとユーザーの動作に即座に対応する必要があります
機械学習タスクや分析のアップロードバックアップなどの作業はそれほど時間に制約されません時間的制約のある作業を充電時などのより良いタイミングで行えばバッテリーを節約しユーザー主導のインタラクティブな作業との競合が避けられますそのために利用できる3つの APIについて説明します BGProcessingTaskは長時間タスクの延期に適します裁量型URLSessionは延期可能なネットワーキングのスケジュールに最適ですまた適切なプッシュの優先順位を活用することでサーバが適切なタイミングでプッシュを配信できます詳しく見ていきましょうまずは BGProcessingTaskから BGProcessingTaskを使うと長時間実行する処理タスクをデバイスの充電中などより良いタイミングに延期しますデータベースのクリーンアップやバックアップの作成機械学習のトレーニングの実行などに最適です利用するには BGProcessing TaskRequest APIでリクエストを作成し App識別子を指定します次に外部電源やネットワークが必要なタスクかどうかなど詳しい情報を入力しますより詳しく情報提供するとシステムはより良い時間帯にタスクをスケジューリングできます　その後システムは適切なタイミングでAppをバックグラウンドで起動して遅延可能な作業の完了のため数分の実行時間を付与します次は裁量型URLSessionですみなさんのAppは一般的なネットワーキングのためにバックグラウンド URLSessionsをすでに使用しているかもしれませんこれは裁量フラグを使うとさらに向上します裁量フラグ付きURLSessionはデバイスがプラグインされ Wi-Fiに接続中であるなど最適なタイミングでのネットワーキング実行のためシステムにオフロードされたネットワーキングトランザクションです裁量フラグはテレメトリ収集やテレビ番組の次の話のダウンロードなどユーザー主導でない長時間稼働のネットワーキングに最適ですまたネットワークがオフロードされたのでネットワークトランザクション完了までの間にAppを実行する必要がありません裁量URLセッションを使用するにはバックグラウンドの URLセッションを設定し isDiscretionaryをtrueに設定します追加情報の入力によってシステムが適切なタイミングでダウンロードを行うように設定できますタイムアウト時間の設定によって永久にダウンロードを試みずバッテリーの消耗を防ぎます
データのアップロードやダウンロードを将来のある時点まで行わない場合は「最も早い開始日」を指定してください最後に予想されるワークロードのサイズを入力するとシステムがダウンロードタスク間でインテリジェントにロードバランスをとります
BGProcessingTaskと裁量型URLSessionで特定の操作の即時性を制御できるのと同様に異なるプッシュ優先度を使うことでプッシュ配信の即時性に影響を与えられますプッシュの優先順位はプッシュをデバイスに配信する緊急性の程度を決めます優先度の高いプッシュの場合サーバはプッシュをすぐにデバイスに送信するためデバイスが起動しバッテリーの消耗を引き起こす可能性があります優先度の低いプッシュの場合サーバはデバイスの起動中や優先度の高いプッシュが届くなど適切なタイミングまでプッシュの送信を遅らせます高優先度プッシュは悪天候警報のような緊急性の高いメッセージに最適です低優先度プッシュは緊急性がなく延期できる受動的な通知に最適ですこれを活用して遅延可能なメッセージ配信を遅らせるとデバイスがスリープから頻繁に起動せずに済むためバッテリーを節約できます低優先度のプッシュを設定はプッシュのペイロードのapns-priority を5に設定するだけですサーバが残りを処理しユーザーはバッテリー寿命の節約に感謝することでしょう最終の考察と次のステップに入りまとめとしましょう Appにダークモードオプションを用意しますユーザーの意図を尊重してバッテリーが節約できますアニメーションを見直しフレームレートを必要な分まで下げる機会を探します小さなアニメーションひとつが大きな効果を発揮しますバックグラウンドの実行時間が終了したらシステムに知らせることで常に監視できます最後に長時間実行するバックグラウンド作業をデバイスの充電時などより良いタイミングに延期しますこれらをすべて実行すれば Appの電力消費が本当に抑えられますご視聴ありがとうございました

// Create a display link

func createDisplayLink() {
   let displayLink = CADisplayLink(target: self, selector: #selector(step))

    // Configure your desired refresh rate by calling preferredFrameRateRange
    displayLink.preferredFrameRateRange = CAFrameRateRange(minimum: 10,
                                                           maximum: 60,
                                                           preferred: 30)

// then activate your CADisplayLink by adding it to the main runloop.
    displayLink.add(to: .current, forMode: .defaultRunLoopMode)
}

16:03 - Discretionary URLSession

// Set up background URL session 
let config = URLSessionConfiguration.background(withIdentifier: "com.app.attachments") 
let session = URLSession(configuration: config, delegate: ..., delegateQueue: ...) 

// Set discretionary 
config.isDiscretionary = true

// Set timeout intervals
config.timeoutIntervalForResource = 24 * 60 * 60 
config.timeoutIntervalForRequest = 60 

// Create request and task 
var request = URLRequest(url: url) 
request.addValue("...", forHTTPHeaderField: "...") 
let task = session.downloadTask(with: request) 

// Set time window of two hours
task.earliestBeginDate = Date(timeIntervalSinceNow: 2 * 60 * 60) 

// Set workload size 
task.countOfBytesClientExpectsToSend = 160 
task.countOfBytesClientExpectsToReceive = 4096 

task.resume()

特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。

クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。

リソース

関連ビデオ

WWDC22

WWDC21

WWDC19