쿠...sal: [컴][안드로이드] 안드로이드 코드 최적화 방법

Android code optimization tips / how to profiling on app / app 프로파일링 / java code optimization / 자바 코드 최적화

본문: Performance Tips( http://developer.android.com/training/articles/perf-tips.html )
의 내용을 대략 옮겨 놓는다. 내용이 부족하거나, 번역이 별로인 내용은 본문을 참고해 주세요.

필요없는 Objects 들은 만들지 말자.

메모리 할당은 언제나 비용이 든다.

너무 많은 메모리를 사용하게 되면, garbage collection 을 주기적으로 호출하게 되며, 결국 뚝뚝 끊기는 현상을 유저에게 경험하게 할 것이다.(android 2.3 에서 도입된 concurrent garbabe collector 가 좀 덜 버벅이게 한다.)

다차수 배열을 1차배열로 만드는게 좀 더 유용하다.(디자인적인 면보다는 성능적인 면을 우선시 한다.)

Integer 보다는 int 가 낫고, 2개의 int 배열이 (int, int) object 의 배열보다 낫다.
(Foo, Bar) 의 배열보다도, Foo[], Bar[] 2개의 배열이 낫다.

short-term temporary object 를 피하자.

virtual 호출보다는 static 호출이 낫다.

object의 method가 object 의 field 에 접근할 필요가 없다면, method 를 static 으로 만들자. Invocation 이 15%~20% 정도 빨라진다.

이건 또 method 가 object의 state 를 변경하지 않는다는 것을 얘기해 주는 좋은 방법이기도 하다.

Constants 를 위해서는 static final 을 사용하자.

static 은 compiler 가 <clinit> 이라는 initializer method 를 만들어서 class 가 처음 사용될 때 사용한다.

이 static 값들이 <clinit>에 의해 만들어 진 후에, 이 static 값을 접근 할 때는 field 를 뒤져서 찾고, 접근해야 한다.

하지만 statci final 을 사용하면 <clinit> 을 만들지 않고, constants는 dex file 에 있는 static field initializer 로 간다. 그리고 접근시에도 integer value 는 그냥 바로 접근하고, string 도 string constant instruction 을 사용한다. 이 string constant instruction 은 field lookup 보다 저렴하다.

note: 이 최적화는 String 과 primitive type에만 적용되는 것이다.

내부에서는 Getters / Setters 를 피하자.

android 에서는 instance field 를 뒤지는 것보다 vitrual method call 이 비싸다.
JIT에서는 7배나 속도 차이가 난다.

ProGuard 를 사용한다면 굳이 신경안써도 된다. ProGuard 가 최적화를 대신 해 준다.

Enhanced for loop 구문을 사용하자.

ArrayList 에서는 직접 작성한(hand-written) counted loop 이 3배정도 빠르다. 하지만 ArrayList 를 제외한 collection 에서는 for-each(enhanced for loop) 의 속도가 for 의 속도와 같다. 그러니 되도록 for-each 를 쓰자.

private inner class 에서 private 에 대한 접근을 하려 한다면 package 를 고려해 보자.

private inner class 에서 private 에 접근할 때는 overhead 가 발생한다.
package access 로 대신할 수 있는 경우라면, package 로 변환을 고려하자.

floating point 를 피하자.

대체로 integer 보다 2배정도 느리다.

되도록 library(이미 작성된 코드) 를 사용하자.

그래야 JIT 가 optimization 할 수 있다.

Native code 는 신중하게 사용하자.

Native code 의 단점

resource 를 관리하기 힘들어진다.

processor 마다 compile 해야 한다.

processor 마다 최적화를 해야 한다.

JIT 가 optimize 를 할 수 없다.

Performace Myths

JIT 이 있는 곳에서는 interface 나 실제 구현한 class 의 호출에 대한 속도차이가 거의 없다.
JIT 가 있다면 field access 는 local access 와 비슷한 cost 를 필요로 할 뿐이다.

측정을 위한 도구

benchmark 만드는 프로그램 Cliper : microbechmarking framework for JAVA
Traceview 는 JIT 를 사용못하기 때문에 주의해서 Traceview data 를 이용해야 한다., Traceview 를 보고 수정한 프로그램이 Traceview 없이 실행했을 때(JIT 를 이용했을때) 느려질 수도 있다.
Traceview profiler How To

Optimizing Layouts

from : Professional Android 4 application development, 2012. 5월. 1
see also : Improving Layout Performance, developer.android.com

layout 을 inflating 하는 비용은 비싸다. 그래서 되도록 여러단계로 되어 있는 layout 을 줄여서 간단하게 만드는 것이 쾌적한 UI 를 위해서 좋다.

쓸데 없이 만들어 놓은 layout 을 없애자. 예를 들면, LinearLayout 안에 여러개의 LinearLayout 으로 만드는 등의 작업을 RelativeLayout 하나로 처리할 수 있다.
그리고 FrameLayout 대신에 <merge> tag 를 통해서 같은 효과를 낼 수도 있다. merge tag 는 include 에 의해 다른 layout 안으로 들어가면 merge 효과가 없어진다.(?)
nested layout 에 제한은 없지만, 10단계가 넘지 않는 것이 좋다.
한 layout 이 View 를 80개이상 가지지 않는 것이 좋다.
ViewStub 을 사용하자. inflate 을 원하는 순간에만 할 수 있다. 그러나 한번 inflate 된 후에는 다시 deflate 이 되지는 않는다.
Eclipse plug-in 인 ADT 에서 제공하는 lint 에서 어느정도의 redundancy 는 알려준다.
lint 가 test 하는 항목 : http://tools.android.com/tips/lint-checks

쿠...sal

[컴][안드로이드] 안드로이드 코드 최적화 방법