이번 글은 글의 형식에 제한받지 않고, 대략적인 정리 형태로 작성해보겠다.
일단, 웹뷰를 사용하다보면 어플리케이션이 갑자기 죽는 경우를 발견할 것이다.
그것도 대책없이 "fatal signal 11"이라는 단순명료한 에러메세지와 함께...
특히, AVD나 Genymotion을 이용하여 테스트를 할때에는 발견되지 않는 에러이다.
이 에러를 해결하기 위해서 다양한 논의가 진행되고 있다.
각각의 사람들은 예상되는 문제를 제기하고, 그에 대한 해결법을 이야기하였다.
나도 이 문제를 해결하기 위해서 수많은 구글링을 통해서 다양한 옵션을 적용해보았다.
그럼, 여러 사람들이 이야기하는 문제점과 각각에 대한 해결법을 생각알아보자.
(물론, 이것은 여러분에게 해결책이 되지 않을 수 있다. 내가 해결한 방법은 맨아래서 다시 이야기하겠다.)
1. 메모리 문제
몇몇 사람들은 웹뷰가 갑자기 죽는 이유를 메모리사용량에 있다고 보았다. 실질적으로 인피니티스크롤을 사용하는 각종 어플리케이션은 수많은 메모리를 잡아먹고 죽는 경우가 많다. 이는 웹뷰뿐만이 아니라 네이티브엡에서도 종종 발생하는 문제이다.
이에 대한 좋은 해결 방법으로는 쓰레드를 나눠서 일을 처리하던지, 메모리 관리를 하는 코드를 적어주는 것이다. 하지만, 나를 포함한 "게으름에 빠진 개발자들"은 메니페스트 파일에서 한 줄을 추가하므로써 이 문제를 회피하려고 한다.
메니페스트 파일의 어플리케이션 부분에 ~android:largeHeap="true"~라는 한 줄의 코드를 작성하면 메모리 문제에서 어느 정도 회피할 수 있게 된다.
...
<application
android:allowBackup="true"
android:icon="@drawable/ic_launcher"
android:label="@string/app_name"
android:largeHeap="true" >
...
하지만, 나의 경우에는 문제를 완화하는 것에 그치고 말았다...
2. 웹뷰의 성능(뷰포트 문제)
몇몇 사람들은 웹뷰의 뷰포트에 문제가 있다고 제시한다. 뷰포트 문제인 경우는 웹뷰안에서 줌인/아웃이 가능할 경우에 발생한다. 모바일 웹을 위한 페이지를 제공하는, 즉 반응형 웹을 제공하는 쪽에서는 발생하지 않을 수도 있는 문제이다.
이에대한 해결방법은 웹뷰를 설정하는 두 줄의 코드를 더 작성하여 웹뷰에 유연성을 더하는 것이다. 몇몇 사람들은 실제로 이것이 문제여서 이를 이용해서 해결한 경우가 많다고 한다.
[WebView Instance].settings.setUseWideViewPort(true);
[WebView Instance].settings.setLoadWidthOverviewMode(true);
하지만, 나의 경우에는 확대 축소같은 기능이 없는 페이지를 로드하기 때문에 도움이 되지 않았다.
3. 포기하라
가장 쓸모없지만 당신이 기획자담당자 또는 상사를 이길 수 있다면 사용하라. 실질적으로 구글링을 하다보면 몇몇 글은 포기하라고 적혀있다. 직접적으로 해석하면 그글은 다음과 같이 적혀있다.
당신은 NDK를 이용해서 JAVA에서 발생하는 Signal 11 문제를 해결할 수 없다.
가장 무책임하면서도 마음 편한 것이 포기하는 것이지만, 대부분의 Signal 11 문제는 문제점을 발견하기 힘들어서 그렇지 해결 가능한 문제가 다수이기 때문에 이 방법은 사용하지 않길 바란다.
4. Hardware Acceleration
이 것을 설명하기 위해서 Hardware Acceleration이라는 것을 간단히 설명하도록 하겠다.
Hardware Acceleration은 안드로이드 3.0(허니컴)부터 적용된 기술로 사용자에게 양질의 슬라이드 퍼포먼스를 적용하기 위해서 적용한 것이다. 실질적으로 3.0이 개발할 당시에는 IOS와의 큰 차이점으로 슬라이드 모션이 불안정하다는 평가를 받고 있었기 때문에 이와 같은 기술이 적용된 것으로 보인다.
Hardware Acceleration이 포함된 버전의 안드로이드를 사용할 경우, 웹뷰를 포함해서 다양한 안드로이드 기능을 사용하다보면 다음과 같은 에러를 발견할때가 있다.
TileRenderer가 발생한 glEndTilingQCOM: 0x502
이 에러는 Game 그래픽 랜더링이나 Hardware Acceleration이 오작동할때 발생한다. 이 에러가 발생한다고 작동하는 어플리케이션이 갑작스럽게 죽지는 않을 것이다. 하지만, 에러가 많이 거듭발생하면서 어플리케이션이 죽는 경우가 있다.
위에서 처음에 언급한 것처럼 Hardware Acceleration은 슬라이드 모션을 향상시키기 위해서 적용됬듯이 슬라이드를 많이할 경우 에러로그가 폭발적으로 누적되면서 꺼지게 되는 것이다.
이를 해결하기 위해서는 슬라이드가 발생하는 위치에서 Hardware Acceleration을 끄고 소프트웨어적으로 움직이게 설정을 바꿔주면된다. 이 설정을 웹뷰에 적용한다면 아래와 같은 코드가 된다.
[WebView Instance].setLayerType(View.LAYER_TYPE_SOFTWARE, null);
이를 이용하면 glEndTilingQCOM 오류가 사라짐과 동시에 갑작스럽게 어플리케이션이 꺼지는 현상도 사라지게 된다. 하지만, 하나 문제점으로 슬라이드 감이 약간 떨어지는 문제가 발생한다.
나는 어플리케이션이 갑자기 꺼져서 사용자에게 주는 불쾌감보다 크지 않을 것이라고 판단하여 이를 적용하여 문제를 해결하였다.
이 글이 LogCat창을 뒤덥는 glEndTilingQCOM 에러로 고생하는 분이나 웹뷰를 사용하는 엡을 개발할 때 갑작스럽게 종료되는 현상을 격는 분에게 도움이 되었으면 한다.