오버드로(Overdraw)란?

단일 프레임에 동일한 픽셀을 두 번이상 그리는 작업을 의미한다. UI 카드는 페인터의 알고리즘(뒤에서 앞으로)으로 그려지기에 사용자에게 보여지지 않는 부분까지 그려진다. 오버드로가 발생하면 GPU 시간을 낭비하여 성능 문제로 나타난다.

공식 문서에 따르면 OS가 최적화되었기 때문에 오버드로는 2015년 google I/O에서 논의되었던 것처럼 크게 중요한 문제가 아니라고 한다.

오버드로가 있는지 어떻게 확인할 수 있을까?

• GPU 오버드로 디버그 도구 : 각 픽셀이 그려지는 횟수를 색상으로 구분하여 표시해주는데, 파랑>초록>분홍>빨강 순으로 오버드로가 많다는 뜻이다. 기기의 개발자 옵션에서 ‘GPU 오버드로 디버그’ 도구를 사용할 수 있다.

• 프로파일 GPU 렌더링 도구 : 프레임당 16ms의 벤치마크(연산성능 수치를 객관적으로 표시하는 것을 의미함)를 기준으로 UI창의 프레임을 렌더링하는 데 걸리는 시간을 히스토그램으로 표시해주는 도구이다. 기기의 개발자 옵션에서 ‘프로필 GPU 렌더링(프로필 HWUI 렌더링)’ 도구를 사용할 수 있다. GPU가 픽셀을 그리느라 성능이 저하되거나 오버로드가 심한 경우를 파악할 수 있다. 자세한 분석 방법은 공식문서의 GPU 렌더링 프로파일로 분석 섹션에서 확인할 수 있다.

오버드로를 줄이는 방법

공식 문서에서는 아래의 방법을 사용하면 오버드로를 줄일 수 있다고 설명한다.

• 레이아웃에서 불필요한 배경 제거하기 : Layout Inspector를 사용하면 레이아웃의 계층 구조를 파악하여 사용자에게 보이지 않는 배경을 제거할 수 있다. 앱의 기본 배경색을 잘 활용하면 배경 위의 모든 컨테이너를 배경 값 없이 사용할 수 있다.
• 뷰 계층 구조의 평면화 : 중첩되는 UI 개체의 수를 줄여 뷰 계층 구조를 최적화하면 성능을 향상시킬 수 있다.
• 투명도 줄이기 : 알파 렌더링(화면에 투명 픽셀을 렌더링하는 것, 즉 투명도를 더하는 것)은 오버드로의 주요 원인이다. 시스템이 기존 픽셀을 그린 다음 올바른 혼합 등식을 얻을 수 있기 때문이다. 투명 애니메이션, 페이드 아웃, 그림자 등의 효과는 모두 어느 정도의 알파 블렌딩을 포함하고 있다. 알파 블렌딩이 성능에 부과하는 비용에 대해서는 숨겨진 투명도 비용에 설명되어 있다. 동일한 시각 효과를 준다면 알파 블렌딩 보다는 불투명한 색상으로 표현하는 것이 성능 비용을 줄일 수 있는 방법이다.

뷰 계층 구조 문제 진단하기

• Systrace : 안드로이드 기기 전체에서 타이밍 정보를 수집/검사하여 레이아웃의 성능 관련 문제가 언제 성능 문제를 일으키는지 확인할 수 있다.
• 프로파일 GPU 렌더링 : 레이아웃 및 측정 단계에서 각 렌더링 프레임에 걸리는 시간을 확인할 수 있다. 이렇게 측정한 데이터를 통해 런타임 성능 문제를 진단할 수 있으며, 해결해야 하는 레이아웃 및 측정 문제가 있는지의 여부, 그 문제의 내용 등을 알 수 있다.
• Lint : 뷰 계층 구조에 있는 비효율성을 판단할 수 있다.
• Layout Inspector : 앱의 뷰 계층 구조를 시각적으로 표현할 수 있다. Layout Inspector에서 제공하는 뷰를 통해 이중 과세로 발생하는 성능 문제도 식별할 수 있다. 또한 중첩된 레이아웃의 딥 체인이나 중첩된 하위 요소가 많은 레이아웃 영역(성능 비용의 또 다른 잠재적 원인)을 쉽게 식별할 수 있다. 참고 : Layout Inspector로 레이아웃 디버깅을 하는 방법

참고 자료

• Google 공식문서 - 오버드로 줄이기
• Google 공식문서 - 성능 및 뷰 계층 구조
• Google 공식문서 - GPU 렌더링 프로파일로 분석

Today I Learned

이펙티브 자바 아이템 13. clone 재정의는 주의해서 진행하라.

• clone 재정의에는 아래와 같은 문제점들이 있다.
  • clone은 Object의 protected 메서드이며 Cloneable에는 아무런 메서드가 없다. 하지만 Cloneable은 clone 동작 방식을 결정한다. clone을 구현하고 싶다면 Cloneable 인터페이스를 상속하여 구현해야만 하며 그렇지 않으면 CloneNotSupportedException이 발생한다.
  • clone 메서드의 일반 규약은 허술하다. clone 메서드가 super.clone이 아닌 생성자를 호출해 얻은 인스턴스를 반환해도 컴파일러 오류는 나지 않는다. 하지만 이 클래스의 하위 클래스에서 super.clone을 호출한다면 잘못된 클래스의 객체가 만들어져 결국 하위 클래스의 clone 메서드가 제대로 동작하지 않게 된다.
• 따라서 Cloneable을 구현하는 모든 클래스는 clone을 재정의해야 한다. 접근 제한자는 public으로, 반환 타입은 클래스 자신으로 변경하고 이 clone 메서드는 가장 먼저 super.clone을 호출한 후 필요한 필드를 전부 적절히 수정하도록 한다. 하지만 이는 너무 복잡하다.
• 더 나은 해결책으로 복사 생성자와 복사 팩터리를 이용하는 것을 권장한다. 복사 생성자와 복사 팩터리의 장점은 언어모순적이고 위험한 객체 생성 메커니즘(생성자를 쓰지 않는 방식)을 사용하지 않으며, 엉성하게 문서화된 규약에 기대지 않고, 정상적인 final 필드 용법과도 충돌하지 않으며, 불필요한 검사 예외를 던지지 않고, 형변환도 필요하지 않다. 또한, 복사 생성자와 복사 팩터리는 해당 클래스가 구현한 ‘인터페이스’ 타입의 인스턴스를 인수로 받을 수 있다. 이러한 인터페이스 기반 복사 생성자와 복사 팩터리의 정확한 이름은 변환 생성자(conversion constructor)와 변환 팩터리(conversion factory)이다. 이를 이용하면 클라이언트는 원본의 구현 타입에 얽매이지 않고 복제본의 타입을 직접 선택할 수 있다.
• 그렇다면 코틀린에서는 clone이 어떻게 사용될까? 코틀린 공식 문서를 보니 아래와 같이 나와있다.

• 정리해보면, clone 재정의가 꼭 필요한 경우가 아니라면 아래와 같은 복사 생성자나 복사 팩터리 방식으로 객체를 복사하자. (예외적으로 배열의 clone은 안정적으로 원본 배열을 반환하므로 배열 복제시에는 배열의 clone 메서드를 사용하는 것을 권장한다.)

// 코드 13-7 복사 생성자
public Yum(Yum yum) { ... };


// 코드 13-8 복사 팩터리
public static Yum newInstance(Yum yum) { ... };

Today I Learned

• honeycomb 이전의 안드로이드에서는 액션바가 없고 메뉴 버튼이라는 것이 있었음. 하지만 디자인적으로 너무 많은 기능을 하나에 담고 있다고 판단되어 honeycomb 부터는 액티비티 상단에 액션바라는 것을 추가하여 그 안에 여러가지 메뉴를 넣을 수 있도록 함.

• URL과 Uri의 차이?

  • URL은 Uniform Resource Locator의 약자이며 URI는 Uniform Resource Identifier의 약자이다. URI는 해당 리소스의 identifier이고 URL은 해당 리소스에 접근할 수 있는 locator이다. URL은 URI에 포함되는 개념인데 URL은 리소스 자체의 위치를 의미하지만 URI는 해당 리소스의 위치일수도 있고 식별자일 수도 있는 것이다.
  • 출처 1
  • 출처 2

• 안드로이드 APK가 설치될 때, 각 APK는 고유한 Linux user ID를 부여받는다. 개개의 애플리케이션은 안드로이드 런타임의 인스턴스 내에서 실행되며 따라서 각각의 애플리케이션은 완전히 sandboxed된다. 이로 인해 이 애플리케이션의 파일, 프로새스, 기타 리소스들은 다른 앱에서 접근할 수 없다. 이러한 sandboxing 접근은 기본적으로 그 어떤 애플리케이션도 민감한 데이터에 접근하거나 다른 앱/OS/사용자에게 좋지 않은 영향을 줄 수 있는 동작을 할 수 없도록 보장한다. 예를 들면 인터넷에 접근하거나, 사용자의 위치를 가져오거나, 연락처 정보를 가져오거나 수정하는 일 등이다.

  안드로이드에서는 위와 같이 민감한 작업을 매번 할 때마다 사용자에게 허락을 구하는 방식보다는 앱의 manifest에서 필요한 permission을 선언하도록 한다. 애플리케이션에서 필요한 permission들의 목록은 이곳에서 확인할 수 있다.

  그렇다면 왜 애초에 모든 항목에 대한 허가를 구하고 편하게 개발하면 안되는가? 마시멜로 이전 버전의 안드로이드에서는 사용자가 앱을 처음 시작할 때 개발자가 요청하는 모든 permission의 리스트를 나열하여 보여주는 다이얼로그를 보게 되어있었다. 하지만 이게 사용자한테는 버거운(overwhelming) 경험일 수도 있어서 안드로이드 6.0(마시멜로) 부터는 permission dialog를 보여주지 않고도 많은 permission을 받을 수 있게 되었고 민감한 정보들은 앱이 실행중일 때 허가를 받도록 하게 되어있다. 따라서 최소한의 permission을 요구하는 것을 권장하며 permission을 요구해야 하는 작업이라면 다른 방식으로 우회해보는 것도 하나의 방법이 될 수 있다. 시스템 앱을 중개자로 사용하여 수행할 수 있는 작업들이 있는데 예를 들면 사용자의 카메라에 접근하는 것을 직접적으로 요청하기보다는 시스템의 카메라 앱을 바로 실행하여 사진을 찍을 수 있도록 할 수 있다.

• sandbox란? 외부로부터 들어온 프로그램이 보호된 영역에서 동작하여 시스템이 부정하게 조작되는 것을 막는 보안 형태이다.

Today I Learned

• 프래그먼트를 중첩할 때 add()를 사용하여 중첩하면, 분명 화면에는 새로운 프래그먼트가 나타나는 것 같은데 아래의 프래그먼트 이벤트가 감지되어 에러가 나는 경우가 있다. 원인은 기본 프래그먼트의 속성이 투명으로 되어있어서 그렇다(찾아보자). 이럴 때 새롭게 추가한 프래그먼트에 onclickable=true와 onfocusable=true를 추가하면 새로운 프래그먼트가 이벤트를 받아 아래의 프래그먼트에 이벤트가 가지 않는다.

• 프래그먼트 트랜잭션에서 add()와 replace()의 차이는 무엇일까. add()를 호출하면 기존의 프래그먼트가 소멸되지 않지만 replace()를 호출하면 기존의 프래그먼트가 소멸된다. 즉 기존 프래그먼트를 유지하고 위에 중첩하느냐, 기존 프래그먼트를 소멸하고 새로운 프래그먼트를 갈아 끼우느냐의 차이다. 나는 처음에 당연히 사용하지 않는 자원은 없애는게 좋다고 생각해서 replace()를 자주 사용했는데 그게 아니었다. 다시 사용할 가능성이 크다면 그대로 두는 비용보다 새로 생성하는 비용이 더 높기 때문에 add()를 해 주는 것이 맞다.

• onCreateOptionsMenu()는 단 한 번 호출되고, onPrepareOptionsMenu()는 매번 menu가 open될 때마다 호출된다. 공식문서의 onCreateOptionsMenu() 설명에 아래와 같이 나와있다.

  This is only called once, the first time the options menu is displayed. To update the menu every time it is displayed, see onPrepareOptionsMenu(Menu).

Today I Leaned

• 변수명을 지을 때 ...flag라는 이름은 이것이 무엇을 하는지 아무런 단서도 제공하지 않기 때문에 좋지 않다. 대신 is..., has..., 동사원형...등의 방식을 이용하자. 노수진님 블로그에 Bool 변수 네이밍에 대해 잘 정리된 글이 있다.
• 오래 전 수정한 코드를 볼 때 일부만 보지 말고 전체적으로 내가 왜 그런 코드를 작성했는지 다시 생각해보자. 오늘 몇달 전에 풀리퀘를 보냈던 코드를 수정할 일이 있었는데, 삭제된 코드 양이 많아서 일부만 보고 왜 안되나 생각하다가 결국은 전체를 다시 보고 나서야 실마리를 찾았다. 다음부터는 꼭 전체적으로 확인하자.