问题描述
在我们的Android应用中，我们具有UI组件和核心C ++ 11模块.线程正在基于std::chrono::system_clock::time_point运行，如下所示:
In our Android app, we have UI component and core C++11 module. A thread is running based on std::chrono::system_clock::time_point, such as below:
while(this->m_ConditionVariable.wait_until(lock, this->m_Object.to_time_point())
== std::cv_status::no_timeout)
{
// ... handle any notify() or arbitrary sleep breaks
}
Execute(); // <--- not being called consistently
现在，我们正在测试1分钟time_point.如果正在使用该应用程序，则会按预期方式调用Execute().但是，如果应用程序移至后台或什至屏幕被锁定，则Execute() -s的行为将不一致.
有时，它可能每分钟正常工作15分钟，此后将在2分钟，3分钟或10分钟而不是固定的1分钟后调用.通过调试，我们检查了所提供的time_point是否正确.
Now, we are testing with 1 minute time_point. If the app is in use, then the Execute() is invoked as expected. However, if the app is moved to background or if even the screen is locked, then the Execute()-s behavior is not consistent.
Sometimes, it may work properly every minute for 15 mins and after that it will be invoked after 2 minutes or 3 minutes or 10 minutes, instead of fixed 1 minute. Using debugs, we checked that, the time_point supplied is proper.
假设如果我们在调试模式下(使用Android Studio)运行该应用程序，那么即使在后台和屏幕锁定模式下，该应用程序也能正常工作.
Suppose if we run the app in debug mode (using Android Studio) then it works fine even in background and screen locked mode.
Android在后台运行的应用程序是否具有线程优先级?
Does Android have any threading priority for the app running in background?
更新1 :基本上，后台线程正在收集位置信息.我碰到下面的问题，这表明在Android中，当手机被锁定时，线程执行被暂停.我会坚持那个问题吗?
当屏幕进入睡眠状态时，应用似乎停止工作
Update 1: Basically the background thread is collecting location information. I came across below question, which suggests that in Android, when the phone is locked, the thread execution is halted. Am I stuck to that problem?
App seems to stop working when the screen goes to sleep
更新2 :部分唤醒锁定，效果很好.但是不确定这是否是一个好的解决方案.如果那是唯一的方法，那么我将赞赏如何最佳使用它的策略.
Update 2: With partial Wake lock, it works fine. But not sure if that's a good solution. If that's the only way, then I would appreciate strategy for how to use it optimally.
更新3 :如果我将wait()替换为较小的sleep()，那么即使没有任何Android唤醒锁，它也可以正常工作.但是，我们尚未对此进行回归测试.
Update 3: If I replace wait() with smaller sleep(), then it works fine even without any Android wake lock. However we are yet to do regressive testing on it.
推荐答案
当设备处于空闲状态时，CPU将停止并且任何正在运行的线程都将暂停(C ++或Java).如果由于某种原因唤醒了您的C ++线程，它将再次开始工作，因此出现了随机行为:其他应用或服务可能会不时地唤醒设备.
When the device is idle, the CPU is stopped and any thread running is paused (C++ or Java). If it wakes up for any reason your C++ thread will start working again, hence the random behavior: Other apps or services might wake-up the device every now and then.
在您的情况下，可以添加部分唤醒锁，但这将防止CPU进入空闲状态，这会导致电池消耗.如果您不在乎，则可以使用这种方法，如果电池寿命很成问题，您可以使用Java警报API定期唤醒设备.然后，Java API可以通过JNI调用C ++代码.
Adding a partial wake lock works in your case but that will prevent the CPU from going idle, which will cause some battery drain. If you don't care you can use this approach, if battery live is an issue, you can use the Java alarm API to wake up the device on a regular basis. Then the java API can call the C++ code through JNI.
用于重复警报的Android文档: https://developer.android.com/training/scheduling/alarms.html
Android documentation for repeated alarms: https://developer.android.com/training/scheduling/alarms.html
对于更新3，使用小的睡眠而不是wait()，我怀疑在线程运行时android不会进入空闲模式，也许它等待一个小的超时而没有任何线程处于活动状态，然后才进入空闲状态.这种方法对电池的消耗与唤醒锁具有相同的效果.
For the update 3, using a small sleep rather than wait(), I suspect android is not going in idle mode while a thread is running, maybe it waits for a small timeout without any thread active before it goes idle. This approach will have the same effect on the battery drain than the wake lock.
这篇关于Android:如果屏幕锁定或在后台运行，C ++线程不会唤醒.使用应用程式时运作良好的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！