멋쟁이들은 계절이나 분위기에 따라 다양한 색의 옷으로 스스로를 표현합니다. 아름다운 자연도 계절에 따라 완전 다른 모습으로 우리의 눈을 사로잡습니다.

최근 Android, iOS에 많은 화제가 되고 있는 다크 모드(Dark Mode)도 비슷합니다. 모드에 따라 하나의 앱이 밝고, 어두운 두 가지 모습을 자유자재로 오갑니다.

안드로이드에서는 테마(Theme)를 이용해서 이를 구현할 수 있습니다. 계절에 따라 모습이 바뀌는 자연을 생각하면 테마는 계절이라고 생각할 수도 있고, 기분에 따라 옷의 컬러를 선택하는 사람에겐 기분이 테마가 될 수 있습니다.

안드로이드의 다크 모드라는 것도 결국은 시스템이 ‘다크 모드(Dark mode)’일 때 이에 맞는 미리 만들어둔 테마를 적용시켜주는 것에 불과합니다.

아래 이미지는 안드로이드 공식 페이지에서 테마에 대해 설명하는 이미지입니다. 동일한 액티비티에 서로 다른 테마를 적용한 모습으로, 테마에 따라 액티비티가 완전히 다른 느낌으로 변하는 모습을 볼 수 있죠.

그럼 이번 포스팅에서는 테마에 따라 다양한 모습으로 변신하는 앱을 어떻게 만들 수 있는지에 대해 이야기하도록 하겠습니다.

테마의 선언과 구성

앞에서 테마에 대해 개념적으로 설명을 드렸지만 우리는 개발자이니 좀 개발자의 관점에서 테마를 살펴보도록 하겠습니다. 테마는 아래와 같이 res/values/style.xml에 선언합니다. 여기서 파일 명은 원하는 대로 작성하셔도 됩니다.

1
2
3
4
5
6
7
8

<resources>
    <style name="AppTheme" parent="Theme.MaterialComponents.DayNight.NoActionBar">
        <item name="colorPrimary">@color/colorPrimary</item>
        <item name="colorPrimaryDark">@color/colorPrimaryDark</item>
        <item name="colorAccent">@color/colorAccent</item>
        <item name="colorImagePlaceHolder">@color/GR80</item>
    </style>
</resources>

일단 기본적으로 테마는 키, 값의 쌍으로 이루어진 맵과 같이 생각할 수 있습니다.

더 위에 style 태그를 보면 마치 클래스 처럼 parent를 통해 다른 테마를 상속 받을 수도 있습니다. 위의 예에서는 AppTheme이라는 테마가 Theme.MaterialComponents.DayNight.NoActionBar라는 테마를 상속받아 선언되고 있습니다. 다른 테마를 상속 받으면 새로 정의한 테마는 parent 테마의 모든 속성을 동일하게 갖게되고 기존의 속성을 오버라이드할 수 있습니다.

<style name="AppTheme" parent="Theme.MaterialComponents.DayNight.NoActionBar">

이제 가장 중요한 내용입니다.

테마에 있는 속성들은 컬러와 같은 디자인 리소스에 의미있는 이름을 붙인 것 입니다. 예를 들어 위에 colorAccent은 안드로이드의 뷰가 가진 속성이 아닙니다. 그리고 colorAccent는 이름에서 보이듯이 이름에서 어떤 특정 색을 표현하지 않고 ‘강조를 나타내는 색’이라는 의미를 더 강조하고 있습니다.

즉 테마에 따라 colorAccent를 다르게 적용할 수 있음을 표현하는 것입니다. 꼭 인터페이스와 구현체의 관계와 비슷합니다. colorAccent라는 속성(인터페이스)은 서로 다른 테마(구현체)에서 다른 컬러로 표현될 수 있는 것입니다.

머티리얼 디자인에 포함된 주요 테마 속성

테마는 내가 직접 정의해서 사용할 수도 있고 안드로이드 플랫폼에 정의되어 바로 사용할 수 있는 것들도 있습니다. 아래 이미지는 롤리팝과 함께 머티리얼 디자인이 소개되면서 많이 쓰인 이미지입니다.

위에 보이는 colorPrimary, textColorPrimary, colorPrimaryDark, windowBackground, navigationBarColor와 같은 속성들은 머티리얼 테마(Material Theme)에 미리 정의된 것으로 보시는 것처럼 시스템 UI에 미리 사용되고 있고 앱에서 얼마든지 이를 재정의(Override)해서 사용이 가능합니다. 즉 앱에서 사용하는 테마에서 colorPrimaryDark를 노란색으로 적용하면 위에 위에 그림에 있는 상태바(Status bar)의 색은 노란색으로 변경될 것입니다.

그렇다면 이게 어떻게 가능할까요? 바로 안드로이드도 플랫폼에서 상태바의 색상에 특정 컬러를 하드코딩 한게 아니라 colorPrimaryDark라는 테마의 속성을 참조하도록 해두었기 때문입니다.

아래는 머티리얼 테마를 상속받아서 앱에서 직접 사용할 테마를 AppTheme라는 이름으로 선언해서 사용하는 예입니다. 아래 예에서 android:windowBackground나 android:windowActivityTransitions와 같은 속성은 안드로이드 프레임워크에 있는 테마이고, colorPrimary, colorPrimaryDark, colorAccent는 머티리얼 테마에 선언된 속성입니다.

그리고 마지막에 있는 colorImagePlaceHolder는 제가 직접 만든 속성입니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<resources>
    <style name="AppTheme" parent="Theme.MaterialComponents.DayNight.NoActionBar">
        // Attributes from material theme
        <item name="colorPrimary">@color/colorPrimary</item>
        <item name="colorPrimaryDark">@color/colorPrimaryDark</item>
        <item name="colorAccent">@color/colorAccent</item>

        // Attributes from android framework
        <item name="android:windowBackground">#ffffff</item>
        <item name="android:windowActivityTransitions">true</item>

        // Attributes that I've defined
        <item name="colorImagePlaceHolder">@color/GR80</item>
    </style>
</resources>

colorImagePlaceHolder와 같이 기존에 없는 속성을 선언하고 싶으면 res/values/values.xml 파일에 아래와 같은 방식으로 선언하면됩니다. 보시면 좌측에 속성이 가질 리소스 포맷을 적고 name에 사용할 속성 명을 적어주면 됩니다.

1
2
3
4
5
6

<resources>
    <attr format="color" name="colorImagePlaceHolder"/>
    <attr format="color" name="colorDivider"/>
    <attr format="color" name="mildBackgroundColor"/>
    ...
</resources>

테마에 적용된 값을 사용하기

자 이제 테마의 개념부터, 종류, 선언하는 방법까지 알아봤으니 어떻게 사용하는지를 알아봅시다. 테마를 사용하는 가장 기본적인 방법은 ?attr/[attributeName] 을 사용하는겁니다. 구체적으로 아래와 같이 사용할 수 있습니다.

1
2
3
4
5
6

<androidx.appcompat.widget.Toolbar
        android:id="@+id/toolbar"
        style="@style/Toolbar"
        app:titleTextColor="?attr/titleTextColor"
        app:titleTextAppearance="@style/ToolbarTitle"
        tools:title="Toolbar" />

툴바의 텍스트 컬러를 지정하는 부분을 보시면 아래처럼 ?attr을 사용하고 있죠.

?attr/titleTextColor

?attr은 테마에서 attr 뒤에 있는 속성 이름으로 값을 찾아오라는 의미입니다. 예를 들어 위의 예에서는 현재 나에게 적용된 테마에서 titleTextColor라는 이름으로 정되된 컬러값을 가져오라는 뜻입니다.

앱에 현재 LightTheme과 DarkTheme가 있다고 합시다. 현재 이 툴바가 LightTheme를 적용받고 있고 LightTheme에 titleTextColor가 흰색이라면 툴바의 텍스트는 흰색이 될 것이고, DarkTheme를 적용받고 있고 여기에 titleTextColor가 검정이라면 툴바의 텍스트는 검정이 됩니다.

결국 테마를 통해 화면의 모습을 다이나믹하게 변경하는 것은 내가 변경하고자 하는 UI 요소의 컬러를 최대한 ?attr을 이용해서 테마의 속성을 간접 참조(indirect reference)로 설정하고, 사용자의 선택이나, 환경에 따라 테마를 변경하는 것입니다. (이 포스팅 전체에서 가장 중요한 내용인거 같네요.)

테마의 적용

그렇다면 위의 예에서 저 툴바에 적용되는 테마는 어떻게 결정 될까요? 테마는 컨텍스트에 적용이 됩니다. 자 그럼 안드로이드 플랫폼에서 컨텍스트를 갖는게 어떤게 있을까요? View, ViewGroup, Activity, Application 등이 있겠죠. 테마는 컨텍스트에 적용이 되기 때문에 여기에 모두 적용이 됩니다.

또한 테마는 범위를 갖는데 상위레벨에 적용한 테마는 하위 레벨까지 모두 적용이 되고 하위레벨에 적용된 테마가 상위레벨에 적용된 테마에 우선해서 적용됩니다.

1. 어플리케이션 레벨로 적용하기
   androidManifest.xml

   1 2 3 4 5 6 7 8

   <manifest ...> <application ... android:theme="@style/AppTheme"> ... </application> </manifest>

2. 액티비티에 적용하기
   androidManifest.xml

   1 2 3 4 5 6 7 8 9 10 11

   <manifest ...> <application ...> <activity ... android:theme="@style/SplashTheme"> </activity> ... </application> </manifest>

3. 뷰그룹 및 뷰에 적용하기

   1 2 3 4 5 6 7 8 9 10 11

   <LinearLayout ... android:theme="@style/Theme.MaterialComponents.Light"> <TextView ... /> <TextView ... android:theme="@style/ThemeOverlay.MaterialComponents.Dark" /> </LinearLayout>

xml에서 각 테마는 android:theme를 통해 적용이 가능하고 적용하고자 하는 범위에 따라 androidManifest.xml의 application 태그나, activity 태그 또는 레이아웃 파일에서 각 뷰그룹 또는 뷰에 적용이 가능합니다.

코드에서 테마에 정의된 속성 값 읽어오기

앞서 테마는 컨테스트에 적용이 된다고 이야기했습니다. 그럼 테마에 엮여있는 특정 속성의 값을 코드에서 가져오려면 어떻게 할까요?
(xml이였다면 ?attr/[attributeName]을 썼겠죠)

아래는 컨텍스트에 엮여있는 컬러값을 가져오는 예제입니다.

1
2
3
4
5
6
7
8

@ColorInt
fun Context.getThemeColor(@AttrRes themeAttrId: Int): Int {
    return obtainStyledAttributes(
            intArrayOf(themeAttrId)
    ).use {
        it.getColor(0, Color.TRANSPARENT)
    }
}

현재 액티비티의 테마에 있는 colorPrimary를 가져오려면 액티비티 내에서 getThemeColor(R.attr.colorPrimary)와 같이 할 수 있을 것이고 특정 뷰그룹에 적용된 테마에 대한 컬러를 가져오려면 targetViewGroup.getContext().getThemeColor(R.attr.colorPrimary)와 같이 사용할 수 있겠죠.

테마의 사용

자 그럼 위에서 알아본 테마의 개념이 어떤식으로 사용될 수 있을까요? 아래의 UI를 예로 들어 봅시다. 이 앱의 처음 디자인은 좌측의 밝은 색 위주의 디자인이였는데 어떤 과정을 거쳐서 우측과 같이 어두운 테마를 적용할 수 있었을까요?

이를 위해서는 아래와 같은 단계를 밟아가면 됩니다.

1. 테마에 따라 색상이 변하는 부분과 변치 않을 부분을 나눠봅니다.
2. UI에서 컬러가 하드코딩 되어있는 부분을 찾고 테마의 어떤 속성을 사용할지 결정합니다. 이때는 이미 시스템에 정의된 테마의 속성을 사용할지, 새로운 속성을 만들지 결정합니다.
3. 새로운 테마를 만들고 이 테마에서 변화를 줄 속성을 오버라이드합니다.
4. UI에서 변경이 필요한 부분의 컬러를 테마의 속성을 참조하도록 ?attr/을 이용하여 변경합니다.

테마에 따라 색상이 변하는 부분과 변치 않을 부분을 나눠보기

위의 예제에서 변하는 부분과 변치 않는 부분을 나눠봤습니다.

변하는 것

• 화면의 배경
• 툴바의 배경
• 쿨바의 텍스트
• 리스트 내의 카드 배경
• 리스트 내의 카드 텍스트
• 바텀네비게이션 배경
• 바컴네비게이션 아이콘
• 탭레이아웃 배경

변하지 않는 것

• 탭레이아웃 인디케이터 및 선택된 탭의 텍스트
• 리스트 내 카드의 재생시간 뱃지

변하는 부분과 변치 않는 부분을 나눴으면 각각에 어떤 테마의 속성을 사용할 수 있을까요? 모두 새로 선언해도 되지만 이미 선언돼있는 다양한 속성들이 있으니 이것들을 먼저 확인해봅니다.

아래 링크에는 머티리얼 디자인 시스템에 이미 선언돼있는 다양한 속성들에 대한 설명이 있습니다.

Android Styling: Common Theme Attributes

이 글에서는 컬러에 대한 내용을 주로 다루고 있으니 몇 가지 컬러 관련 속성을 보겠습니다.

• ?attr/colorPrimary : 앱의 메인 브랜딩 컬러
• ?attr/colorSecondary : 앱의 세컨 브랜딩 컬러로 주로 메인 브랜딩 컬러를 보완하는 좀 더 밝은 색상으로 사용
• ?attr/colorOn[Primary, Secondary, Surface etc] : 각 컬러에 대한 대비를 이루는 색입니다. 예를 들어 배경에 ?attr/colorPrimary를 쓰고, 여기위에 다른 UI 컴포넌트를 올릴 때 colorOnPrimary를 사용하면 이 컴포넌트를 좀 더 눈에 띄게 강조 할 수 있겠죠.
• ?attr/colorSurface : 카드(cards), 시트(sheets), 메뉴(menues)와 같은 컴포넌트의 표면 색을 나타냅니다.
• ?attr/colorBackground : 스크린의 백그라운드 색
• ?attr/colorError : 에러를 표시할 때 사용할 색

아래 이미지는 material.io 페이지에 있는 The baseline Material color theme로, 위의 컬러를 보통 어떤식으로 선택하는지에 대한 예시를 보여주고 있습니다. 참고로 material.io 페이지에 가면 대비가 되는 색을 선택하거나, 위에 있는 머티리얼 테마에 사용되는 속성값들을 어떤 식으로 결정하면 좋을지에 대한 가이드와 툴이 잘 나와있습니다.

다시 아래 목록으로 돌아와서 위에 있는 속성들을 참고하면 저는 아래와 같이 테마의 속성을 정의할 수 있을거 같습니다. 이걸 바탕으로 각 UI 컴포넌트에 하드코딩 되어있던 컬러를 ?attr를 이용해서 바꿔줍니다.

이제 위의 속성들을 각 테마에 따라 정의합니다.

밝은 테마

1
2
3
4
5
6
7

<style name="LightTheme" parent="Theme.MaterialComponents.DayNight.NoActionBar">
        <item name="colorSurface">@android:color/white</item>
        <item name="backgroundColor">@android:color/white</item>
        <item name="android:windowBackground">@color/gray_bg</item>
        <item name="titleTextColor">@android:color/black</item>
        ...
</style>    

어두운 테마

1
2
3
4
5
6
7

<style name="DarkTheme" parent="Theme.MaterialComponents.DayNight.NoActionBar">
        <item name="colorSurface">@color/gray_900</item>
        <item name="backgroundColor">@android:color/black</item>
        <item name="android:windowBackground">@android:color/black</item>
        <item name="titleTextColor">@android:color/white</item>
        ...
</style>

이제 감이 오시나요? 위의 속성들을 재정의 하는 테마를 추가하기만 하면 이제 얼마든지 분위기가 확 다른 앱을 만들 준비가 된 것이죠.

그럼 이제 이런 테마를 어떻게 적용하면 될까요? 아까 위에 기술 했던대로 activity 또는 application 단위로 androidManifest의 android:theme 태그를 이용해 정의하면 됩니다. 이걸 동적으로 하고 싶다구요? 그럼 간단히 테마를 선택할 수 있는 다이얼로그를 하나 만들고 테마를 선택하면 이걸 Preference 같은 곳에 저장하고, 액티비티가 시작 시 setContentView 이전에 테마를 설정해주면 됩니다.

1
2
3
4
5
6
7
8
9
10
11
12

override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        val userSelectedPref = getThemeFromPref()
        when(userSelectedPref) {
            "light" -> setTheme(R.style.LightTheme)
            "pink" -> setTheme(R.style.PinkTheme)
            "dark" -> setTheme(R.style.DarkTheme)
            else -> setTheme(R.style.LightTheme)
        }
        setContentView(R.layout.activity_main)
        ...
}

테마는 뷰가 인플레이트 되기 전에 설정이 되고 인플레이트 후에는 변경해도 UI에 업데이트가 반영이 되지 않기때문에 setOntentView 이전에 해주어야합니다.

다크 모드

그럼 다크모드는 뭘까요? 다크모드는 안드로이드 9에서부터 지원되는 시스템 설정입니다. 즉 앱이 아니라 안드로이드 시스템에서 설정 가능한 모드입니다. 앱에서 다크모드를 지한한다는 것은, 사용자가 시스템의 다크모드를 적용하면 이에 따른 어두운 테마를 만들어 두었다가 이게 적용되도록 해주면 됩니다. 간단하죠?

이 부분은 이 글의 내용을 이해했다면 간단히 적용이 가능하지만 이 글에서 다루면 너무 길어질 것 같아서 다음 포스팅에서 따로 다루도록 하겠습니다.

마무리

저는 디자인과는 좀 거리가 있어보이는 개발자입니다. 노트북이 들어간 백팩과 체크무늬 셔츠가 가장 편안합니다. 하지만 그럼에도 제가 만든 앱은 어디서나 돋보였으면 좋겠고 보기에 좋았으면 좋겠습니다. 또한 저는 잘 다듬어진 디자인은 그 자체로 유저에게 큰 가치를 준다고 생각합니다. 이 글을 보신 분들도 테마를 이용해서 보다 다양한 느낌의 앱을 앱을 만드는데 도움이 되셨으면 합니다.

참고

테마에 관련된 글들은 주로 안드로이드 엔지니어인 Nick Butcher의 유튜브 영상과 미디엄 글을 많이 참고했습니다. 또한 material.io에 있는 페이지들도 개발자에게 디자인과 관련된 컴포넌트나 개념을 잡는데 도움이 많이 되었습니다.

마지막으로 안드로이드의 테마를 이야기하면 항상 스타일(Style)에 대한 이야기를 보통 함께 합니다. 이 둘은 상당히 비슷하면서 다른데 개인적으로는 두개를 같이 다루면 오히려 개념을 잡는데 헷갈리기 때문에 스타일에 대한 이야기는 최대한 배제하였습니다. 하지만 테마를 이해했다면 스타일에 대한 부분도 꼭 짚고 넘어가면 좋을 것 같습니다.

• Dark theme
• Styles and Themes
• Material io
• Android Styling: Themes vs Styles
• Android Styling: Common Theme Attributes
• Android Styling: Prefer Theme Attribute
• Android Styling: Themes Overlay

안드로이드 앱을 사용해봤거나 개발해봤다면 누구나 한번씩은 ANR 다이얼로그나 버벅거림, 혹은 크래시로 앱이 비정상 종료되는 상황을 겪어봤을 겁니다. 이런 현상들은 사용자에게 안좋은 경험을 주고 심한 경우 앱을 지워버리게 만드는 요인이 되기도 합니다. 반대로 빠르고 부드러운 앱은 사용자에게 좋은 인상을 줍니다.

그렇다면 빠르고 크래시 없는 앱을 개발하기 위해서는 어떻게 해야할까요?

여러가지가 있겠지만 가장 중요한 것 중 하나는 안드로이드의 프로세스와 쓰레드를 잘 이해하고, 올바르게 다루는 것일 겁니다.

이번 글에서는 안드로이드의 프로세스와 쓰레드의 개념에 대해 정리하고 이를 다룰 때 주의할 점에 대해 다루도록 하겠습니다.

1. 안드로이드 앱의 실행과 프로세스

안드로이드는 리눅스 기반의 OS입니다. 리눅스 커널위에 라이브러리와 런타임이 있고 그 위에 어플리케이션 프레임워크가 존재합니다. 안드로이드 앱 개발자는 어플리케이션 프레임워크에서 제공하는 컴포넌트와 이를 사용하기 위한 API를 이용해서 안드로이드 앱을 개발합니다.

안드로이드 앱은 앱 컴포넌트를 통해 실행됩니다. 앱 컴포넌트는 액티비티, 서비스, 컨텐츠 프로바이더, 브로드캐스트 리시버 이렇게 네 가지입니다. 앱 컴포넌트 중 하나를 실행 시켰는데 이미 실행 중인 컴포넌트가 있으면 안드로이드 시스템은 해당 컴포넌트를 기존 프로세스 내에서 실행 시키고, 없는 경우 새 리눅스 프로세스를 생성하고 여기서 컴포넌트를 실행 시킵니다.

1.1. 앱의 실행 경로

가장 기본적인 실행 경로는 안드로이드 런쳐, 즉 홈 화면이나 앱 메뉴에서 앱 아이콘을 클릭해서 실행 시키는 방법이 있습니다. 이 경우 앱은 AndroidManifest.xml에 정의한 런쳐 액티비티를 실행합니다. 이 방식은 앱 컴포넌트 중 액티비티를 통해 앱이 실행되는 경우입니다.

두 번째로 앱에서 알람을 등록했다고 합시다. 지정한 시간이 되면 알람을 받는 앱의 브로드캐스트 리시버가 호출이 됩니다. 이 경우는 브로트캐스트 리시버를 통해 앱이 실행되는 케이스입니다. 같은 방식으로 서비스, 컨텐츠 프로바이더를 통해 동일하게 앱이 실행되는 시나리오가 있을 수 있습니다.

1.2. 프로세스와 메인 쓰레드

위에 설명한 실행 경로를 통해 앱이 실행되면 하나의 리눅스 프로세스가 생성되고 프로세스 안에는 하나의 쓰레드가 기본으로 생성됩니다. 이 쓰레드가 바로 메인 쓰레드입니다. 메인 쓰레드는 아주 중요하기 때문에 어떤 일을 하고 어떻게 동작하는지 잘 이해해야 좋은 앱을 만들 수 있습니다.

먼저 앱의 네 가지 컴포넌트는 메인 쓰레드에서 실행됩니다. 따라서 앱 컴포넌트 중 하나인 액티비티의 라이프사이클 관련 콜백이나, 브로드캐스트 리시버의 onReceive()등도 모두 메인 쓰레드에서 실행됩니다.

두 번째로 UI 위젯을 통한 사용자 이벤트와 드로잉 이벤트가 메인 쓰레드에서 실행됩니다. 즉 안드로이드 UI toolkit에 있는 android.widget, android.view의 사용자 이벤트 처리나 드로잉 관련 메소드가 여기 해당됩니다.

조금 이해가 가지 않는 다면, onClick, onKeyDown, onDraw 같은 콜백들을 생각하면 됩니다.

이렇게 사용자 이벤트와 드로잉 이벤트가 메인 쓰레드에서 처리되기 때문에 메인 쓰레드를 UI 쓰레드라고도 합니다. 하지만 엄밀히 말하면 둘은 서로 같은게 아닙니다. 메인 쓰레드가 UI 쓰레드를 포함 하는 개념으로 보시는게 좋습니다.

1.3. 부드러운 UI 개발을 위해 알아야 하는 것

앱개발을 좀 해봤다면 메인쓰레드 내에서 16ms 이상 걸리는 작업을 하면 안된다는 얘기를 많이 들어보셨을 겁니다. 우리가 보는 화면의 움직임은 결국 프레임의 연속입니다. 조금씩 변하는 프레임이 연속으로 빠르게 이어지면 사람의 뇌는 이걸 움직임으로 인식합니다.

이 프레임이 너무 낮거나 불규칙하게 이어지면 사용자는 UI가 부드럽지 않다고 느끼게 됩니다. 안드로이드는 초당 60 프레임, 즉 60fps을 유지하도록 권장합니다. 60fps가 사람이 인지할 수 있는 선에서 가장 부드러운 수치이기 때문입니다. 1초는 1000ms 이기 때문에 60fps를 달성하려면 1000/60, 즉 프레임이 16ms당 한번씩 새로 그려질 수 있어야 60fps가 유지됩니다. 이에 대한 이야기는 아래 유튜브 영상에서 보실 수 있습니다.

PerfMatter Why 60fps

여기서 이제 가장 중요한 개념이 등장합니다. 앞서 메인 쓰레드는 UI 업데이트 즉 드로잉 작업도 처리한다고 언급하였습니다. 그래서 메인 쓰레드를 UI 쓰레드라고 부르기도 한다고 했죠. 즉 이 메인 쓰레드에서 16ms 이상 걸리는 작업을 하면 메인 쓰레드는 16ms 간격으로 프레임을 업데이트 할 수 없게 됩니다. 즉 프레임 드랍이 일어납니다.

우리가 리사이클러뷰에서 스크롤을 하거나 화면에 애니메이션이 그려지고 있는 도중에 이런 프레임 드랍이 생기면 화면이 뚝뚝 끊기겠죠? 이러한 화면 끊김을 안드로이드에서는 Jank 라고도 부릅니다.

결국 부드러운 UI 개발을 위해 가장 중요한 것은 메인쓰레드에서는 16ms 이상 걸리는 작업은 하지 않는 것이라고도 볼 수 있습니다.

1.4. 워커 쓰레드(백그라운드 쓰레드)

앞에서 설명한 대로 메인쓰레드는 사용자 이벤트와 드로잉 이벤트를 처리하기 위해 사용되기 때문에 메인 쓰레드에서 시간이 오래걸리는 작업을 하는것은 금물입니다. 좀 더 엄밀히 말하면 16ms을 넘기지 않는게 좋습니다.

그럼 시간이 오래 걸리는 작업들은 어떻게 처리해야 할까요? 답은 간단합니다. 다른 쓰레드를 만들어서 메인 쓰레드가 아닌 곳에서 작업을 처리하면 됩니다. 이렇게 시간이 오래 걸리는 작업을 처리하기 위해 생성한 쓰레드를 워커 쓰레드 또는 백그라운드 쓰레드라고 부릅니다.

자바에서는 쓰레드를 생성하기 위해 Runnable과 Thread, Executors 클래스를 제공합니다. 이것들을 이용해서 시간이 오래 걸리는 작업을 처리해도 되고 안드로이드에서 편의를 위해 제공하는 AsyncTask, AsyncTaskLoader, ThreadHandler, ThreadPoolExecutor 등을 사용할 수도 있습니다.

1.5. 워커 쓰레드의 기본적인 사용 패턴

기본적으로 16ms 이상 걸릴 수 있는 무거운 일들은 메인 쓰레드에서 처리하면 안됩니다. 따라서 이러한 작업들은 보통 위에서 언급한 다양한 클래스를 이용해 워커 쓰레드를 생성하고 여기서 처리합니다. 또한 메인 쓰레드는 쓰레드 세이프 하지 않습니다. 따라서 메인 쓰레드가 아닌 워커 쓰레드에서 UI를 조작하면 정상적으로 반영이 되지 않을 수 있고 비정상적인 동작을 초래할 수 있습니다.

그런데 워커 쓰레드에서 작업을 하고 이를 UI에 업데이트 하려면 어떻게 해야할까요? 워커 쓰레드에서 시간이 오래걸리는 작업을 하고 그 결과를 UI에 반영해서 사용자에게 결과를 보여주는 것은 앱 개발에서 가장 많이 보이는 패턴중에 하나입니다. 서버에 데이터를 요청하고 이를 화면에 보여주거나 이미지를 가공해서 이를 사용자에게 보여주는 경우 등, 사실 대부분의 경우 워커 쓰레드는 UI 업데이트를 동반하는 경우가 많습니다.

이를 위해 워커 쓰레드와 메인 쓰레드 간에 통신하는 가장 기본적인 방법은 핸들러(Handler)를 이용하는 방법입니다.

두 번째로, 안드로이드는 이를 좀 더 간편하게 할 수 있도록 AsyncTask라는 유틸 클래스를 제공합니다. AsysncTask는 워커 쓰레드에서 처리할 일을 doInBackground()에 작성하고 진행 사항이나 결과를 UI에 반영 하는 코드는 onProgressUpdate(), onPostExecute()에 작성하여 메인 쓰레드에서 이를 간편히 실행 시킬 수 있습니다.

이 외에도 액티비티의 runOnUiThread(), 뷰의 post(), postDelayed()를 이용할 수도 있습니다.

2. 메인 쓰레드와 워커 쓰레드를 잘못 다루었을 때 생길 수 있는 일들

2.1. ANR(Application Not Responding)

메인 쓰레드는 이름처럼 아주 중요합니다. 앞서 말했던 것처럼 사용자 이벤트와 드로잉 이벤트를 처리하기 때문이죠. 때문에 메인 쓰레드에서 시간이 오래 걸리는 작업을 하면 그만큼 메인 쓰레드는 사용자 이벤트와 드로잉 이벤트를 처리할 수 없게 됩니다.

즉 메인 쓰레드 내에서 시간이 오래 걸리는 작업을 하게 되면 사용자가 앱의 버튼을 클릭하거나 키보드 입력도 할 수 없고, 앱의 UI도 업데이트가 되지 않아 멈춘 것처럼 보이게 됩니다. 이것이 바로 ANR입니다.

그럼 ANR을 한번 직접 만들어볼까요? 아주 간단합니다. onClick()과 같은 사용자 인풋 이벤트는 메인 쓰레드에서 실행된다고 언급하였습니다. 그럼 여기서 5초 이상 걸리는 작업을 하도록 하면 바로 ANR을 발생 시킬수 있겠죠?

1
2
3
4
5
6
7
8
9
10
11

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        button.setOnClickListener {
            Thread.sleep(10000)
        }
    }
}

안드로이드 시스템은 안드로이드 버전에 따라 다르지만 약 5초 이상 UI 쓰레드가 차단되면 ANR 대화 상자를 띄움으로써 사용자가 앱을 강제로 종료할 수 있게합니다.

2.2 워커 쓰레드와 UI 처리

앱 개발을 하다보면 워커 쓰레드의 작업 결과를 메인 쓰레드에서 UI에 반영하는 경우가 많은데 이 때 자주 하는 실수가 있습니다.

하나는 워커 쓰레드에서 작업을 끝내고 이를 UI에 반영할 때 해당하는 View가 View hierachy에서 제거 되었거나 객체 자체가 삭제 되었을 수 있습니다. 안드로이드에선 네트워크 호출은 워커 쓰레드에서 호출하도록 하고 있는데 서버로 API 호출을 한 후 이 응답값을 이용해서 UI를 수정하는 경우 흔히 발생 할 수 있는 경우입니다.

좀 더 구체적인 예를 들면 액티비티 위에 프레그먼트가 있고 여기서 네트워크 콜을 합니다. 이후 네트워크 응답이 오기 전에 사용자가 백키를 눌러서 프레그먼트를 프레그먼트 스택에서 제거합니다. 이렇게 되면 프레그먼트는 액티비티의 View hierachy에서 제거 됩니다. 이제 네트워크 응답이 오고 액티비티의 View hierachy에서 제거된 프레그먼트의 UI를 수정합니다. 생각해보면 특별한 경우가 아니고 앱 개발 시 굉장히 자주 있는 시나리오입니다.

두 번째는 워커 쓰레드에서 액티비티의 레퍼런스를 갖고 있는 경우 입니다. 이렇게 되면 해당 액티비티는 워커 쓰레드가 종료될 때까지 가비지 컬렉터에 의해 제거 될 수 없습니다. 워커 쓰레드가 종료되기 전에 configuration change 이벤트가 발생하거나 하면 동일한 액티비티가 여러개 생길 수도 있는 상황이 발생합니다.

워커 쓰레드에서 액티비티의 레퍼런스를 직접 갖고 있지 않은 경우에도 문제가 생길 수 있습니다. 액티비티에 내부 클래스로 AsyncTask를 선언하고 사용하는 경우입니다. 내부 클래스는 외부 클래스에 대한 암시적 참조를 갖기 때문에 위의 상황처럼 AsyncTask가 종료 될 때가지 액티비티는 가비지 컬렉터에 의해 제거되지 않습니다.

여기서 암시적 참조라는 말이 조금 어렵게 느껴질 수 있는데, 내부 클래스는 외부 클래스의 멤버 변수를 참조 할 수 있습니다. 어떻게 이게 가능할까요? 직접 내부 클래스에 외부 클래스의 레퍼런스를 참조하는 코드를 작성하지 않더라도 자바는 내부 클래스에 대한 참조를 생성하기 때문입니다. 이것을 바로 암시적 참조라고 합니다.

아래 예제 코드는 암시적 참조에 의한 메모리 릭의 예를 보여줍니다. 아래 코드에서, doInBackground()에서 어떤 작업을 하고 있는 동안은 MyActivity는 메모리에 계속 남아있게 됩니다. 또한 화면 방향 전환이나 단말의 언어설정 변경 등에 의해 액티비티가 재시작이 되면 동일한 액티비티가 여러 개 생성될 수도 있으며, 액티비티가 종료된 후에 onPostExecute()에서 유효하지 않은 액티비티내의 객체나 UI 요소에 대한 상태를 변경하면 예기치 못한 동작이 발생할 수 있습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

public class MyActivity extends AppCompatActivity {

    private TextView mText;

    @Override
    public void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        mText = findViewById(R.id.text);
        new MyAsyncTask().execute();
    }

    class MyAsyncTask extends AsyncTask<Void, Void, String> {

        @Override
        protected void onPreExecute() {
            mText.setText("MyAsyncTask.onPreExecute()");
        }

        @Override
        protected String doInBackground(Void... voids) {
            try {
                Thread.sleep(50000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            return "MyAsyncTask.doInBackground() is finished";
        }

        @Override
        protected void onPostExecute(String s) {
            mText.setText(s);
        }
    }
}

마지막으로 안드로이드 개발을 시작한지 얼마 안된 사람들이 쉽게 착각하는 것 중 하나는 액티비티와 쓰레드의 생명주기가 동일하다고 착각하는 것입니다. 하지만 액티비티의 생명주기와 쓰레드의 생명주기는 관계가 없습니다. 쓰레드가 특정 액티비티에서 생성이 되고 해당 액티비티가 종료되어도 이 쓰레드는 이와 상관없이 실행됩니다.

이를 제대로 이해하지 못하면 첫 번째로 언급한 이슈가 발생하기 쉽습니다. 이런 실수를 하게되면 결국 앱은 비정상 종료를 하게 됩니다.

3. 마무리

이번 포스팅에서는 안드로이드의 프로세스와 쓰레드에 대해 개념적인 내용들을 정리해 보았습니다.

이를 정리하자면 아래와 같습니다.

1. 메인 쓰레드는 사용자 이벤트, 드로잉 이벤트 등을 처리하는 매우 중요한 쓰레드이며 여기서 시간이 오래 걸리는 일을 하면 앱이 끊기거나 먹통이 될 수 있다.
2. 1과 같은 이유로 많은 시간이 걸리는 작업은 새로 쓰레드를 만들어서 처리해주어야 하며 이를 워커 쓰레드라 부른다.
3. 사람이 느낄 수 있는 가장 부드러운 수치는 60fps 정도 이기 때문에 안드로이드에서도 앱 개발 시 60fps를 유지하도록 권장한다. 이를 위해 메인 쓰레드에서는 16ms 이상 걸리는 작업을 하지 않는다.
4. 워커 쓰레드에 액티비티나 View의 레퍼런스를 갖는 것은 메모리 릭과 앱의 비정상 종료를 일으킬 수 있기 때문에 매우 위험하다.

개인적으로 안드로이드 앱 개발 시 가장 중요하다고 생각하는 부분이기도 합니다. 다음에는 좀 더 구체적으로 쓰레드에 대해 자세히 알아보고 상황에 따라 어떤 방식으로 쓰레드를 사용해야 하는지 다뤄보도록 하겠습니다.

참고자료

• ANRs
• Crashes
• Platform architecture
• App components
• Process and thread
• Perfmatter - Understanding Android Threading
• Slow rendering