iOS 11 CPU节流和空闲计时器 [英] iOS 11 CPU throttling and idle timer

查看:68
本文介绍了iOS 11 CPU节流和空闲计时器的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在iPhone SE上,升级到iOS 11.4后,大约8到10秒后,我现在看到非常奇怪的CPU节流结果.我正在使用一个非常简单的示例应用程序(部署目标设置为iOS 10.3),该应用程序显示单个视图并在对drawInMTKView的调用内进行解码操作.应用启动时的CPU使用率符合预期(10-15%),但是在8-10秒的窗口后,CPU似乎被大量调低,因此帧解码操作在全CPU速度下要花费4-5毫秒,然后需要16-17毫秒(其中CPU使用率约为60%).我试图通过切换idleTimerDisabled标志来禁用任何iOS空闲计时器,但这似乎对此没有影响.有趣的是,从纵向"旋转到横向"将重置此限制,并且解码将再次以全速运行,直到8-10秒钟的不活动状态再次将其抑制.这可能是怎么回事?我已经了解到iOS 11包含一些新的电池管理代码,但是我的设备是新设备,并且常规"->电池"中的电池设置指示设备正在全速运行.还有其他一些应用标志或设置可以禁用此限制吗?

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

推荐答案

这可能与您的经验有关:我们发现,对应用进行性能分析的行为可能会在不合适的时候使这些版本的iOS陷入降频.在未连接到主机PC的发行版本中未发生此问题.

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.

我们有一个应用程序,其渲染循环的运行时间不到8毫秒-远低于60 fps游戏时间所需的〜16毫秒.当连接到探查器时,目标设备将检测到该情况并降低时钟频率-但是与探查器进行通信的开销会将帧时间推到16ms以上,从而导致30fps的游戏玩法.

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.

除了发现正在发生的问题并加以考虑之外,我们没有找到其他解决方案.当我们向应用程序添加额外的渲染负载并将其拖到8ms以上时,问题就消失了,因为目标设备不再降频了.

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.

这篇关于iOS 11 CPU节流和空闲计时器的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆