웹/안드로이드에서 위치추적을 사용하기 위해 정리했던 글..

GPS system 도입을 위해 분석했던 자료이며, 정확한 내용이라고 하기에는 많이 부족합니다. 처음 앱/웹에서 gps를 도입하기 위해 간단하게 읽어나가, 검색을 어디부터 시작해야할지 정도의 도움이 되기를 바라며 남기는 글 입니다..

Web/App 위치기반 시스템을 사용하기 위해 우선적으로 현제 GPS시스템을 어떻게 쓸지 분석하기위해 17년 12월부터 한달간 기록된 자료들을 정리하여 제 작성한 글 입니다.

앱 파트에서 GPS 위치정보 기반 시스템은 이미 많은 수준의 기술적 상향들이 있었기 때문에, 그저 끌어 쓸 줄만 알면 됩니다.

하지만 플렛폼과 버전별로 각기 다른 필요 방식이 있기 때문에, 짚고 넘어야 할 사항이 많이 있었습니다.

아이폰의 경우엔 ObjectC 와 Swift로 나뉘어져 있으며, 특히 Swift의 케이스엔 버전별로 코드가 매우 다르다는 이야기를 접했기 때문에, 기존에 내렸던 결론인 아이폰은 적용이 비교적 쉽다는 말은 실제로 알아보기 전 까지는 장담 할 수 없게되었습니다(…)

안드로이드

안드로이드의 경우에도 역시 버전별로 많은 위치기반 수집 방식이 있지만, 크게 2013년 전 후로 기능이 나뉘어져 있습니다.

이전 년도의 기능은, 순수하게 안드로이드 기기를 이용하여, 개발자가 스스로 구현해야 할 파트가 많으며, 덕분에 퍼포먼스 하락 같은 요인이 발생 할 수 있습니다. 하지만 굳이 무거운 라이브러리를 쓰기 싫다면, 이는 좋은 방법 중 하나라고 판단됩니다. (스스로 짜는만큼 확실히 알 수 는 없을태니깐요.)

하지만 이러한 불편함 덕분에, 구글에서 자체적으로 쉽게 사용할 수 있게 되었습니다.

그리고 이를 fusedLocationProvider 를 만들어 API레벨 23 이상의 안드로이드 OS에서 이용이 가능케 되었습니다.

하지만 그 당시 23래벨은 상당히 높았으며, 지금까지도 안드로이드OS 점유율의 대부분은 19버전임을 감안하면, 개발자 입장에서는 고려의 가치가 상당히 낮아집니다.

이러한 이유로 구글은 추가적인 업데이트 배포와 함께, API 10부터 가능하게끔 바꾸었습니다.

 이전버전의 호환을 처리하는 방식은, 제조사에게 펌웨어 업데이트를 요구하는 것이 아닌, Playstore업데이트로 가능하게 만들었습니다.

Api10 유저도 playstore 업데이트만 한다면(앱을 정상적인 루트로 받는행위를 한다면..) 사용할 수 있게 됩니다.

Playstore 의 업데이트로 많은 라이브러리들이 작동이 가능케 되었다고 하니, 이 방면으로 조금 알고있으면 원하는 기능 검색에 조금 더 도움이 될 것 같습니다.

최신버전의 fusedLocation은 권한이 필요로 합니다.

1.    1 .  ACCESS_FINE_LOCATION과

2.    2.   ACCESS_COARSE_LOCATION 인데,

1번의 경우는 통신사/GPS/WIFI를 이용하여 위치정보를 수집할 수 있는 권한이며,

2번의 경우는 WIFI만을 이용한 권한입니다.

fusedLocation의 위치정보 수집방식은 위의 열거된 방식을 통해 빠르고/낮은 오차로 위치를 제공하게 됩니다.

(API 23이상의 버전에서는, Manifest에서권한을 grant하여도 추가적으로, 앱에서 기능을 실행할 때마다 권한을 재승인 해야 합니다. 이를 위해 API버전이 23이상인 경우 추가 permission grant코드가 필요로 합니다. 공식 fusedLocation문서에 존재합니다.)

Manifest단에서 권한을 주었다면, LocationCallback과 LocationRequest를 생성/선언합니다

LocationRequest를 생성하며, 옵션들도 설정이 되며,

FusedLocationClient에서 requestLocationUpdate를 호출합니다.

콜백으로 location업데이트의 성공 실패여부를 리턴하게되고,

이후 필요에 따라 FusedLocationClient의 GetLastLocation메서드롱 좌표를 리턴합니다.

requestLocationUpdate와 getLastLocation의 기능은 비슷해 보였고,

이전버전에서는 getLastLocation만 있었기 때문에, 이부분에서 혼돈이 있었는데,

getLastLocation은 마지막으로 기록된 정보만을 반환하는 반면,

requestLocationUpdate는 fusedLocationClient에서 위치정보를 업데이트 하라고 시키는 역할 입니다.

즉, reuqestLocationUpdate를 호출하지 않으면, getLastLocation을 몇 번이고 호출해도 값은 바꾸여지지 않습니다.

이전버전까지는 requestLocationUpdate를 실행하면 즉각적으로 안드로이드에게 현제 위치를 업데이트 요청을 시켰으나, 이는 개발자의 관리 부주의로 불필요하게 많이 호출하여, 배터리 소모를 유발하는 문제가 있었습니다. 

이를 방지하고자 새로운 fusedLocationClient는 업데이트 주기를 설정하여, 주기가 돼야만 실제로 requestLocationUpdate를 실행하며, 주기가 되지 않았을 때 위치업데이트를 요청하면, 그냥 getLastLocation을 호출하여, 개발자의 실수로 battery drain현상을 방지하게 되었습니다.

해당 설정 값들은 LocationRequest를 생성할 때 사용되는,

setInterval과 setFastestInterval, setPriory로 설정됩니다. 

(이 값은 앱 실행 도중 변경이 가능합니다.)

이 값들을 이용해서 Interval시간을 주기로 업데이트를 자동적으로 하게 되는데,

수동적으로 현제위치를 업데이트 시킬 필요가 있을 때,

(역시 상기와 같은 이유로 battery 낭비를 위해 안전장치로) 

fastestInterval의 값을 설정하게 되는데, 이 fastestInterval에 명시된 시간이 지난 뒤, 수동으로 gps업데이트 요청을 할 때에는, 그 요청을 응해준다는 의미입니다.

이 값으로 자동 업데이트 간격을 정의해 놓고, 수동 요청 시 과도한 요청을 막으면서 유연하게 대처 할 수 있습니다.

Priority는 GPS위치 추적 기능을 얼마만큼 정밀하게 사용하는가에 대한 세팅입니다.

값은 no  / Balance / high 가 있으며,

No의 경우에는 직접적으로 위치정보를 업데이트 하지 않고, 타 앱이나 서비스에서 가지고 있던, 최종 값을 가져온다는 의미입니다. 앱을 구동하다 보면, 여러 앱 혹은 서비스에서 GPS정보를 얻어오게 되는데, 굳이 이미 가져온 정보가 있음에도 불구하고, 다시한번 fusedLocation을 쓰지 않게 하기 위한 기능입니다.  

당연하게도 정확도는 위치정보를 얻어오는 앱/서비스에 따라 다를것 이며, 배터리 소모량도 없습니다.

Balance 의 경우에는 GPS를 사용하지 않으며, 오차는 20~미터 정도입니다. 결과를 리턴하는대에까지 시간이 30초 정도까지도 소요되었으며, 단일 앱 구동시 테스트 장비에서는 배터리가 9시간을 버텼습니다.

Power의 경우에는 15미터~ 정도까지도 나왔습니다. 요청의 리턴은 거의 항상 20초 내에 작동했습니다. 구동시 테스트장비는 balance의 배터리 소모량의 반도 못 미쳤습니다.

장비의 성능과 배터리에 따라 다르기 때문에, 이 수치는 절대적이지 않으며, 다른 블로그나 android에서 소개하는 페이지에 정확한 수치가 공개 되어있습니다.

여기서 Priority를 설정한다 한들, gps혹은 3/4G, wifi를 끄게 되면 기능을 이용하지 않습니다.

필드테스트를 거치지 않았으나, 실험실 주변에서의 위치측위 결과, balance는 준수한 성능과 지리를 불러왔기 때문에, 정밀한 수준의 위치 추적이 필요치 않는 상황에서는 balance 로 세팅이 옳은 것으로 보입니다.

테스트 당시에 앱은 소멸을 지시한 코드가 없었으며, 백그라운드로 자동적으로 넘어가 작업을 수행함을 확인했기 때문에, 불필요시 메모리 할당 해제를 반드시 해야 할 것 같습니다.

웹

웹의 경우는 앱과는 달리 위치측위 방식은 인터넷 밖에 없습니다.

js단에서 이미 깔끔하기 그지없는 라이브러리까지 다 준비 되어있어, 적용에 무리가 전혀 없었습니다.

오차는 이동중에는 역시 오차가 넓으나(km수준까지도), 동일한 위치에서 동일한 이더넷일 경우에는 정밀하게 측위 되었습니다.

다만, http환경에서는 위치추적기술을 사용하지 못하게 되어있습니다.

Localhost일 경우에는 개발용으로 문제가 없으나, 정식 서비스를 위해서는 서버를 https로 만들어야만 합니다.

또, 웹 특성상 미지원 브라우저가 존재합니다.(그리고 이게 아마 모든 브라우저가 하나의 표준을 따르기 전까진 제가 죽을때까지 웹을 공부하면서 느낄 고통이겠지요)