2010-04-07 3 views
10

가비지 수집기에서 작업 부하를 줄이기 위해 안드로이드 애플리케이션이 생성 된 객체의 수를 제한해야한다고 들었습니다. 제한된 메모리 사용량으로 추적하기 위해 엄청난 수의 개체를 생성하고 싶지 않을 수도 있습니다. 예를 들어, 기존의 서버 응용 프로그램에서 생성 된 100,000 개의 개체가 몇 초 안에 들리지 않을 수 있습니다.Android GC 성능으로 인해 코딩 스타일이 변경되었는데 어느 정도 거리가 멀었나요?

문제는 내가 이것을 얼마나 멀리 가져야합니까? 필자는 정적 상태에 의존하는 안드로이드 애플리케이션의 수많은 사례를 "속도를 높일 것"이라고 예상했습니다. 수십에서 수 백으로 가비지 수집해야하는 인스턴스의 수를 늘리면 실제로 그 차이가 커지나요? 나는 코딩 스타일을 변경하여 현재 Java-EE 서버가 가지고있는 것과 같이 수십만 개의 객체를 만들었지 만 가비지 수집 대상 객체 수를 줄이기 위해 정적 인 상태에 의존하는 것처럼 보입니다. 이상한.

성능 Android 앱을 제작하기 위해 코딩 스타일을 변경하는 것이 얼마나 필요합니까?

답변

10

"할당 방지"조언은 일반적으로 게임 루프와 관련됩니다. VM은 쓰레기를 수집하기 위해 일시 ​​중지해야하며 게임이 30fps로 애니메이션을 재생하는 동안에는 VM을 원하지 않습니다. 객체를 할당하지 않으면 VM은 가비지를 수집하여 메모리를 비울 필요가 없습니다. 사용자가 볼 수있는 딸꾹질없이 실행해야하는 게임이 있다면 할당을 최소화하거나 없애기 위해 관련 부분의 코드를 변경하는 것을 고려해야합니다.

조리법이나 사진을 담고있는 앱을 만드는 중이라면 걱정할 필요가 없습니다. GC 딸꾹질은 사용자가 쉽게 알아 차릴 수있는 것이 아닙니다.

향후 Dalvik GC (예 : 세대 별 수집)가 개선되면서 문제가 줄어 들었습니다.

+3

필자는 데스크톱이나 서버용으로 작성된 Java 코드가 매우 비효율적이며 많은 양의 오브젝트를 통해 작업량에 비해 스 래시 (thrash) 할 수있는 Java 코드를 자주 발견 할 것이라고 덧붙입니다. 예를 들어 네트워크에서 데이터를 처리 할 때 GC를 계속 발생시키는 네트워킹 코드를 보았습니다. 코드가 이것을 수행하고 있다면 Dalvik이 아니라 모바일 장치에 적합하지 않기 때문에 실제로 최적화해야합니다. 추가 작업은 모두 배터리에서 직접 이루어집니다. – hackbod

+1

실제로 스타일을 얼마나 많이 변경해야하는지에 관해서는, 작동하는 코드를 작성하는 것이 가장 좋습니다 (할당 된 오브젝트를 재사용하는 것에 대해 약간의 생각을 해보았습니다. 광범위하지는 않지만). GC에 대한 압력. 있을 경우, 코드를 프로파일 링하는 메모리를 시작하고 변수 할당 및 삭제를 피할 수있는 장소를 찾으십시오. –

4

저는 정말로 당신이하고있는 일과 코딩 스타일이 무엇인지에 달려 있다고 말하고 싶습니다. 항상 모바일 장치와 프로그램의 하드웨어 제한을 염두에 두어야 할 필요가 있습니다.하지만 앱을 어디에서 실행하든 상관없이이를 인식하는 것이 좋습니다. 실시간으로 또는 게임과 같이 업데이트해야하는 많은 집중적 인 계산을 수행하는 경우 NDK를 사용할 수 있습니다.하지만 정상적인 사용자 중심의 작업을 수행하는 경우에는 그렇게 나쁘지 않습니다. . 내 충고는 검소하기는하지만 최적화 실행에 대한 느낌을 얻을 때까지는 최적화에 대해 너무 걱정하지 않는 것이 좋습니다.