Battery Usage

[pocketcasts]

User report

Just sent a Twitter DM as well but I’m finding the app uses a ton of power. Is this expected? Was surprised to find my new iPhone 13 Pro doesn’t have that much better battery life than my aging iPhone XS, and seems Pocket Casts is the primary culprit.

Additional info

From Chip Snyder:

I spent some time looking onto this and I have a few take-aways for this user.

They're on 7.18.1 and they have 132 podcasts that they subscribe to. Also a few settings that stand out to me:

Auto Download On: yes Auto Download Only on Wifi: yes Auto Download Up Next: yes

They have Auto-Download on but our logs don't provide insight into how many are included in the Auto-Download. We might want to add that to the meta-data if these issues persist. I wasn't familiar with the app "No Cell Coverage" but apparently this is a tool that Apple will use to help boost the signal in low connectivity cases.

Thoughts Given that they have so many podcasts and that they Auto Download I wonder if their battery is being effected by episodes downloading under cellular data. If they're downloading on a cell network (especially a poor cellular network) then they'll definitely have a greater impact on their battery life.

With that bug fixed I'd be interested to see how their battery usage impact changes because they have all of the settings I would encourage them to use. Maybe turn off Auto Download for shows that they don't listen to regularly 🤷 and only download them when added to up next using Auto Download Up Next

---

Other Research

I did some deep diving into this over the last two days so I want to document some of my findings before the week is out.

I pulled up some of our battery stats and found a few interesting cases. Our biggest impact is while in the background which should be expected given the nature of the app.

Average Users	Heavy Users

For our average users our impact is minimal and we shouldn't worry too much IMO. We average about 1.3% of their daily battery usage which is down from the previous release.

Our heavy users use 6.65% on average (this aligns pretty closely to my own use.) Audio is high (2.59%) but that's expected and I haven't found a way to be more efficient there yet. Processing is nearly just as high though.

---

FileLog

I believe a big contributor to the processing impact is due to the FileLog. Each time an event fires a loggable event the process is

• Open the log file
• Seek to the end
• Write the log
• Close

This kind of I/O can be expensive. A few recommendations from Apple:

Minimize data writes. Write to files only when their content has changed, and aggregate changes into a single write whenever possible. Avoid writing out an entire file if only a few bytes have changed. If you frequently change small portions of large files, consider using a database to store the data instead.

While streaming an episode our energy impact is on the high side.

Running the same test with the file log disabled moved us back into the low category.

Batching these events and/or moving them to the DB could also be a viable approach to saving us energy usage. However this needs more validation because it's not a 1 to one comparison given the network calls that happen around these screen shots with various intervals. Which raises that we might be able to batch requests as well.

More info: #4529585-zen