iOS 11 CPU限制和空闲计时器

Question

On an iPhone SE, after an upgrade to iOS 11.4, I am now seeing a very strange CPU throttling result after about 8-10 seconds. I am using a very simple example app with (Deployment Target set to iOS 10.3) that displays a single view and does a decode operation inside a call to drawInMTKView. The CPU usage is as expected when the app starts (10-15%) but after an 8-10 second window the CPU seems to be massively throttled down so that a frame decode operation that was taking 4-5 ms at full CPU speed then takes 16-17 ms where (CPU usage is about 60%). I attempted to disable any iOS idle timer by toggling the idleTimerDisabled flag, but this seems to have no effect on this. What is interesting is that rotating from Portrait to Landscape will reset this throttling and the decode will operate at full speed again until the 8-10 seconds of inactivity again throttles it down. What could possibly be going on here? I have read that iOS 11 contains some new battery management code, but my device is new and the battery settings in General->Battery indicate that the device is operating at full speed. Is there some other app flag or setting that can disable this throttling?

(full speed)
decode time 5.74 ms
decode time 5.87 ms
decode time 5.37 ms
decode time 5.81 ms
decode time 5.56 ms
decode time 5.97 ms

(after 8-10 second, reduced speed)
decode time 16.65 ms
decode time 16.65 ms
decode time 17.02 ms
decode time 16.49 ms
decode time 16.95 ms
decode time 16.03 ms

Answer 1

This may be relevant to your experience: we found that the act of profiling an app could fool these versions of iOS into downclocking when it was not appropriate. The problem did not occur in release builds not connected to the host PC.

We had an app whose render-loop ran in just under 8ms - well under the ~16ms needed for 60fps gameplay. When connected to the profiler, the target device would detect this and downclock - but the overhead of communicating with the profiler would push the frame time over 16ms, resulting in 30fps gameplay.

We found no solution to this other than recognising that it was happening and taking it into account. When we added additional render load to the app, pushing it past 8ms, the problem went away because the target device no longer downclocked.