Android 영구 소켓 연결 규칙

Question

영구 소켓을 사용하는 Android 기기 용 맞춤 푸시 알림 솔루션에 대한 테스트를 일부 수행했습니다. 내 연구 결과를 공유하고 결과를 확인하고 싶습니다.

간단한 설명
응용 프로그램은 전경 서비스를 실행하고 서버와의 연결을 설정하고 공격적인 핑을 통해 연결 (10 초 간격 @) 유지한다. 연결이 죽은 것으로 감지되면 앱은 무기한으로 다시 연결을 시도합니다. 서버는 이중 채널을 통해 알림을 보냅니다.

시험 1 :

Pinging is done using a timer at 10 second intervals. 
Server sends notification every minute. 
Applications acquires wifi and wake locks. 
Duration : 8 hours 
Battery loss : ~14% 

시험 2 :

Pinging is done using AlarmManager at 10 second intervals. 
Server sends notification every minute. 
Application acquires only a wifilock 
Duration : 8 hours 
Battery loss : ~7% 

가정 : 들어오는 네트워크 패킷이 자동으로 CPU, 웨이크 잠금 따라서 불필요 깨운다. Timer 대신에 AlarmManager를 사용하여 ping을 수행하면 wakelock이 필요 없다는 것을 의미합니다.

배터리가 실제로 배터리를 제거하는 것처럼 보였습니다. 놀랍게도 두 솔루션 중 어느쪽에 대한 공격적인 핑 소리도 예상했던 것만큼 배터리 수명에 영향을 미치지 않았습니다. (우리는 응용 프로그램이 wifilock을 개최하고 같은 기간에 약 4 % ~ 5 %의 배터리 손실을 일으키는 것을 포함하여 다른 많은 테스트를 수행했습니다)

응용 프로그램이 모든 ping 요청을 성공적으로 보낼 수 있었고 들어오는 메시지를 모두 받으면 내 가정이 정확하다고 믿습니다. 그러나 저는 전문가들로부터 확인을 받고 싶습니다.

하나 더 질문 : 응용 프로그램이 들어오는 연결을 수신 대기하는 경우. 이 경우에 wakelock을 잡아야합니다. 맞습니까? 들어오는 연결이 CPU를 깨우지 않습니까? 우리는이 길을 내려 가지 않고 확인하고 싶었습니다.

또한 회사 정책에 위배되는 GCM을 권장하지 않습니다.

감사합니다.

Answer 1

이 질문에 대한 관심과 확인이 없었기 때문에 지금 답변 드리겠습니다. 테스트가 끝난 후 한참이 지났으며 생산 수준의 솔루션이 만들어져 엄격하게 테스트되었습니다. 웨이크 잠금 장치를 제거해도 여전히 배터리를 사용할 수 있었고 핑 요청이 누락되거나 알림이 수신되는 등의 다른 문제가 발견되지 않았으므로 이것이 상기 가정에서받은 유일한 유효성 검사입니다.

추가 유의할 것들 :

• 을 핑 경보에 대한 브로드 캐스트 리시버의 OnReceive 방법, 직접 (새 스레드 또는 의도 산란) 소켓에 호출되지 않은 경우, 당신은 것입니다 ping 요청이 끝날 때까지 대기 잠금을 유지해야합니다. 안드로이드는 OnReceive가 돌아 오기 전까지 만 깨우기 잠금을 유지합니다. 그 후에는 핑이 끝나기 전에 CPU가 잠자기 상태 일 수 있습니다.

• 알림이 중요한 경우 High Performance Wifi Lock을 사용하십시오.

• 해결 방법에 영향을주는 다른 장치 관련 문제가 하나 있었는데 here입니다.

안드로이드 5.1 다음 문제 다 퉜다 업데이트 : Android Issue

업데이트 2

안드로이드 6.0 도즈 모드 주위에 코드 필요 : Doze Mode