안녕하세요 극마입니다.
팀원들과 학교어플을 만들면서 파싱관련 문제가 있어 이를 해결했는데
펍에는 관련 글을 못찾아서 여기에 올리게 되었습니다(나중에 제가 까먹을까봐-_-;)
저같은 초보개발자분들은 주의를 해야할듯합니다.
파싱관련 문제인데요
초보분들은 앱제작시 파싱을 하실경우 메인쓰레드(ex. 액티비티의 onCreate, onStart, onResume)에
파싱함수를 불러와 작업하시는 분들이 있는데 진저브래드(2.3)까지는 이게 가능하였습니다.
근데 아이스크림 샌드위치(4.0)부터는 아이에 다른 쓰레드를 만들어서 거기서 작업해줘야합니다.
저같은 경우 프로그래스 다이얼로그를 즐겨쓰는지라 파싱을 항상 다른 쓰레드에서 구현하여 문제가 없었지만
팀원중 2.3에서 작업하다 4.0으로 올리니 파싱이 되던것이 파싱자체가 아이에 되지 않는 문제점을 발견하고
이게 4.0에서만 그렇다는걸 발견후 찾다가 알아내서 이렇게 남깁니다.
요약 : 파싱은 이제 메인쓰레드가 아닌 다른 쓰레드를 만들어 파싱하여야 한다. 아니면 아이스크림 샌드위치는 지원하지 못한다.
여지없이 무한 테스트의 필요성을 느낀 어제였습니다-_-;;
이걸 strict mode라 부르는데 안드로이드 앱의 퀄리티 상승을 위해서 진저브래드에서부터 지원되었고 허니컴부터 강제화하였습니다
xml 파싱뿐만 아니고 기본 http 통신이나 1초이상의 지연이 걸리는 작업은 모두 쓰레드-핸들러로 구현해야합니다
NoBrain말씀처럼 파싱이 아니라 파싱과 연결된 InputStream에 해당하는 것으로 StrictMode에서 걸린거겠죠. 2.3에도 StrictMode는 있지만 3.0 부터는 StrictMode가 Default로 디버깅시 동작하게 되어있더군요.
http://android-developers.blogspot.com/2010/12/new-gingerbread-api-strictmode.html
Disk I/O
Network I/O
가 UI 쓰레드가에서 직접적으로 동작하면 ANR 시켜버리는 무서운 녀석입니다 :)
저도 3.0 어플 처음으로 개발해보다가.... 어라!! 왜 에러나지? 잘 되던건데!! 하던 소스가 있었는데.. 결국... 이 글과 같은 문제더군요..
UI스레드에서는 절대로 네트워크를 이용하는.. 시간을 많이 잡아먹는 작업을 못하게 강제화 시켜 두었더군요..
ANR이 밣생하는것을 방지하고, UI의 최적화를 위한 방편인지.... 구글에서 강제로 설정해 두었더라구요...
뭐.... 사실 그게 올바른 방식이라고 생각하니 저도 나쁘게 보지는 않습니다 ^^ 다만.. 좀 알려주고 강제로 막아버리던지 하지...
이 문제 때문에 저도 팀원들가 한동안 개고생 했던 기억이 떠오르네요 ~~~ ^^
저도 요즘 겪고 있는 문제 입니다. 유독 ICS 에서 ANR 이 잘걸림.. 하기 사이트 통해 내용정리를 했습니다.
KTH 에서 정리를 잘 해주셨더라구요. 참고하세요.
http://dev.paran.com/2012/01/31/android-strict-mode-howto/
헐~
그런문제가 있었군요.
모르면 한참 시간을 헤멜만한 문제군요..
정보감사~