问题描述
我正在使用的应用在后台监视信标，当检测到信标时，我们便开始对信标进行测距。
此方法一直有效，直到我们在更多设备上进行测试，然后发现在某些设备上关闭屏幕仍会调用jest.spyOn(wrapper.props,'fetchComments')，但CREATE TEMPORARY TABLE IF NOT EXISTS RESULT(
usu_id INT,usu_usuario NVARCHAR(150),usu_nombre NVARCHAR(150),usu_apellido NVARCHAR(150),usu_correo NVARCHAR(150)
);
IF exists(select * from usuario where usu_id = usu_ides) THEN
INSERT INTO RESULT(usu_id,usu_usuario,usu_nombre,usu_apellido,usu_correo)
SELECT usu_id,usu_correo FROM
usuario where usu_id = usu_ides;
SELECT *,1 as sqlcode FROM RESULT;
ELSE
SELECT 0 as sqlcode,'No se encontro el usuario' as sqlmsg ;
END IF;
DROP temporary table RESULT;
将为空。屏幕打开后（通知到达，升起唤醒，轻按以唤醒等），测距就开始正常工作，直到屏幕再次关闭。
在创建测试项目以重现此问题时，我注意到，如果停止监视，则在屏幕关闭时，这些设备上的测距仍然有效。虽然这是一个 a 解决方案，但它不是该解决方案，因为它会在以后引起问题。
有人知道这些设备之间的区别吗？这是硬件问题，是某些操作系统设置吗？
解决方法
经过更多测试后，我发现如果您监视要测距的同一信标，这不是问题。
总结一下，当屏幕关闭时（具有必要的功能）：
- 测距（信标1）✅
- 测距（信标1）和监视（信标2）❌
- 测距（信标1）和监视（信标1和＃2）✅
在某种程度上，这是有道理的，因为监视是由系统完成的，而测距是由应用程序完成的，并且这些过程以某种方式相互作用。
问题仍然是为什么这种行为在设备之间会有所不同。我目前的理论是，它可能与电池的健康状况有关，因此BT芯片可能会受到某种限制，因为大多数无法正常工作的设备的电池健康状况均低于90％。
,您应该通过转到设置->应用程序->应用程序->权限->位置来检查每个设备上的位置权限。确保所有用户都具有“始终”位置访问权限。
如果您已授予“使用中”权限，则如果应用程序不在前台，则测距将停止。屏幕关闭将被视为不在前台。更复杂的是，从iOS 13+开始，还有一个“临时的”始终位置权限，当设置屏幕显示“正在使用时”，它的作用就像您一直授予的权限一样。您可以在这里阅读有关此内容的更多信息：What makes provisional Always authorization provisional?
您也可能发现了某种错误-监视第二个区域应该不会影响第一个区域的范围。但是我可以对优化模块进行错误地编码，如果没有与监视区域相关的信标可见，则会关闭频繁的信标扫描-例如如果您所有受监视的区域都处于“外部”状态。我还可以想象，这种编码不佳的优化与特定的位置权限授予之间可能存在某种关系。