이 애플리케이션에 대한 접근 방식을 재고해야한다고 생각합니다.앱이 실행될 기기의 특성에 대한 정보가 충분하지 않거나 적합하지 않은 기능 세트를 만들기로 결정한 것 같습니다.
당신은 "앱은 매 n 분마다 위치를 얻습니다"라고 쓰지만 iOS 위치 서비스가 작동하는 방식이 아닙니다. 앱이 포 그라운드에서 실행 중일 때 현재 위치에 대한 위치 서비스를 가끔씩 쿼리하는 것이 좋은 방법입니다. 일시 중지되거나 종료되면 옵션이 아닙니다. 대신 위치 이벤트를 일정 수준의 정확도로 구독해야하며 기기의 위치가 변경되면 앱에 알림이 전송됩니다. 이러한 이벤트를받는 일정에 대한 보장은 없으며 요청한 정확성과 장치가 움직이는 속도에 따라 다릅니다.
또한 위치를 얻는 것은 값 비싼 작업이므로 장치의 배터리가 빨리 소모 될 수 있습니다. 1 시간 또는 2 시간 내에 사용자가 사용할 수있는 배터리 전력으로 불타는 것은 앱을 신속하게 제거하는 좋은 방법입니다. 가능한 경우 최소의 전력 소비로 정확도가 낮은 위치 업데이트를 얻으려면 중요한 위치 변경 서비스를 사용해야합니다. 더 많은 정밀도가 필요한 경우 정의 된 지역에 대해 경계 교차 이벤트를 사용하거나 가능한 한 많이 요청한 정확도를 줄이는 것이 좋습니다.
제한된 시간 내에 작업해야하는 모든 상황에서 앱은 위치 업데이트를 통해 한 번 실행해야합니다. 아마도 서버로 왕복하기에 충분하지 않을 것입니다. 네트워크 연결이 이미 활성화되어 있고 장치의 대기 시간이 짧아지면 일부 시간에는 응답을 얻을 수 있지만 자주 OS에 의해 종료되는 응용 프로그램을 볼 것으로 예상됩니다. 그런 상황이 발생하면 앱을 다시 실행하는 위치 업데이트를 계속 받을지 모르겠습니다.
알림 목록을 다운로드하고 로컬로 표시하는 대신 중요한 위치가 변경된 경우 UDP를 통해 현재 위치를 서버로 보내려는 것이 더 나은 해결책 일 수 있습니다. 그렇게하면 응답을 기다리지 않고 네트워크 요청을 시작할 수 있습니다. 해당 요청 중 일부만 계속 성공할 수 있지만 앱은 종료되지 않습니다. 그런 다음 서버에서 수신 한 위치를 처리하고 필요할 때 푸시 알림을 보낼 수 있습니다.
서버 측 변경을 수행 할 수없는 것으로 알고 있습니다. 이 경우 앱을 실행할 때 인근 지역에 대한 사전 알림을 미리 수행 할 수 있습니다 (백그라운드에서 왕복을 완료하는 경우). 그렇게하면 위치 업데이트를 해당 목록과 비교할 수 있으며 모든 위치 업데이트에서 네트워크 요청을 실행할 필요가 없습니다. 불행히도 현재 제약 조건 하에서 신뢰할 수있는 솔루션을 사용할 수 없기 때문에 여기서 모퉁이로 돌아갈 수 있습니다.
감사합니다. Jonah와 @yeesterbunny. 이제는 문제를 더 잘 이해하고 고객에게 돌아올 수 있다고 생각합니다. – JAC