Modern Android development
Google I/O 2018
Modern Android development
Android 1.0이 2008년에 나오고 지난 10년간, 개발자들을 위한 기능과 API 등 정말 많은 것들이 출시되고 변해왔습니다.
그 과정에서 여러 매체를 통해 다양한 정보들을 찾아볼 수 있는데, 그 당시에는 정말 좋은 정보들일 수 있으나 현재는 쓸모없어진 정보들도 혼재되어 있는 상황입니다.
구글에서도 이를 인지하고 있고 이에 대해 간략히 훑어보는 수준의 "Modern Android development"이라는 세션을 준비했습니다.
개인적으로 새로운 기능과 API 같은 모르는 내용만 듣다가 조금이라도 알고 있는 내용을 다뤄서 인지 제일 기억에 남는 세션이었습니다.
History of Android
#02 History of Android지난 10년간 Android의 주요한 출시 기능과 기술, 도구들에 대해 살펴봤습니다.
#Android 1.0
Android 1.0이 2008년에 나온 뒤, 몇 년 동안은 최적화에 집중했기 때문에 별 다른 내용이 없었다고 했습니다.
웹에 따르면 Android에서 bad API들을 개발하는데 바빴다고 하는 내용도 언급하며 디스 하는 거 보면 정말 별게 없었나 보네요.
#Android Studio
Eclipse에서 Android Studio로 바뀌면서 개발하기 더 쉬워졌습니다.
#Art
Android KitKat을 통해 Art가 나왔습니다.
Lollipop부터는 Dalvik 대신 Art을 기본 runtime으로 이용했습니다.
#RecyclerView
ListView보다 더 나은 RecyclerView가 나왔습니다.
플랫폼이 아닌 support 라이브러리를 통해 출시하면서, OS나 플랫폼에 상관없이 동일하게 이용할 수 있습니다.
#ConstraintLayout, Kotlin, Arch Components, Studio Profilers, Ktx, Paging
작년과 올해 여러 API들과 도구가 나왔습니다.
Kotlin을 위한 확장 라이브러리인 Ktx, 앱의 성능을 파악하는 Studio Profilers 등입니다.
커뮤니티로부터 여러 피드백들을 받아 이를 기반으로 더 간편하게 작업할 수 있는 개발자 API들을 만드는 것이 전체적인 목표입니다.
Tools
# Hierarchy Viewer >> Layout Inspector
Hierarchy Viewer은 레이아웃의 계층을 검사할 수 있는 도구입니다.
있는지도 몰라서 한 번도 안 써봤는데 현재는 deprecated 되었고 Layout Inspector로 대체되었습니다.
#03 Hierarchy ViewerLayout Inspector도 레이아웃의 계층을 검사할 수 있는 도구입니다.
개발자 도구의 '레이아웃 범위 표시' 기능과 비슷한데, Android Studio 자체 도구로서 이전 도구보다 더 빠르고 편합니다.
#04 Layout Inspector# Trace View >> Systrace >> Android Profiler
Trace View는 10년도 넘은, Eclipse 시절부터 있던 코드 프로파일링(profiling) 도구입니다.
측정하는데 비용(시간, 부하)도 많이 걸리긴 했지만, 실제 측정된 데이터의 신뢰성에도 문제가 있었습니다.
수년간 개선도 해왔지만, 여전히 사용하기 힘들었기 때문에 좋은 도구는 아녔습니다.
몇 년 뒤 시스템 전체를 포괄적으로 볼 수 있는 Systrace가 나왔습니다.
Android Studio 3.0부터 Android Profiler가 나왔습니다.
이전 도구들에 비해 훨씬 빠르고 기능도 다양합니다.
그리고 CPU, MEMORY, NETWORK 상태를 그래프 형태로 볼 수 있고, 색상에 따라 병목 현상도 파악할 수 있습니다.
#06 Android ProfilerDesign
# XML >> Visual Editor >> Motion Editor
안드로이드 레이아웃을 작성하기 위해서는 Java나 XML을 이용할 수 있습니다.
그리고 Android Studio에서는 위젯을 드래그하는 방식으로 레이아웃을 작성할 수 있는 Visual Editor(Layout Editor)가 있습니다.
Layout Editor는 Android 2.3(API 레벨 9) 이상과 호환되는 지원 라이브러리에 제공된 레이아웃 관리자인 ConstraintLayout을 사용하여 새 레이아웃을 빌드할 때 특히 유용합니다.
Editor를 이용하면 반영한 레이아웃을 실시간으로 확인할 수 있다는 장점이 있습니다.
추후에는 ConstraintLayout을 사용하여 애니메이션을 생성하기 위한 Motion Editor가 출시될 예정입니다.
Runtime
# Dalvik >> ART
T-Mobile G1이 처음 출시(2008년)되었을 때는 가용 메모리가 192메가였고, 그중 일 부분만을 application에서 접근할 수 있습니다.
따라서 Dalvik은 공간(space)에 최적화되어 있었습니다.
application이 이용할 수 있는 메모리 공간이 제한되었기 때문에, 여러 가지 문제점이 있었습니다.
메모리 할당(Allocation)하고 수집(Collection)하는데 비용도 많이 들었고 느리기도 했습니다.
이 과정에서 여러 이유들로 인해 Heap 메모리 영역이 파편화되거나 leak이 발생하면서 GC나 OOM이 발생하기도 했습니다.
ART는 KitKat에서 처음 공개되었고, Lollipop에서는 기본으로 이용되었습니다.
Dalvik과 달리 메모리보다는 성능에 최적화되어 있습니다.
그리고 메모리 할당(Allocation)과 수집(Collection)이 빠르고, Heap 메모리 영역의 파편화를 조각 모음도 합니다.
Dalkiv 시절에는 Enum 대신 int를 이용하라고 권장했습니다.
Enum 타입이 int보다 차지하는 메모리 크기가 훨씬 컸기 때문입니다.
ART에서는 Enum 타입에 대해 걱정하지 않습니다.
물론 좀 더 보수적일 필요가 있는 내부 프래임워크 코드와 API에서는 아직도 Enum 타입을 쓰지 않는 경향이 있지만, application 코드에서는 상관없습니다.
하지만 기기들은 여전히 제약들이 있다는 점에 유의하시기 바랍니다.
쓰고 싶으면 Enum 타입을 쓰라는 얘기인데, 상황에 따라 적절한 타입을 쓰라는 결론 같습니다.
Language
# Java >> Kotlin
Android를 처음 시작할 때, Java를 메인 프로그래밍 언어로 결정했습니다.
가장 인기 있는 언어 중 하나였고, 수많은 개발자와 유용하고 무료인 툴들도 많았기 때문입니다.
하지만 시간이 지남에 따라 새로운 버전의 언어를 채택하는데 시간이 걸렸습니다.
현재는 Java 1.8 버전까지 지원하지만 다음 버전을 지원하는데 까지는 몇 년이 걸릴 것입니다.
2017년도에 Kotlin이 Android의 새로운 공식 프로그래밍 언어로 선정되었습니다.
Jetbrains와 긴밀하게 협력하고 있으며, 여러 장점들이 있습니다.
기존 코드를 Kotlin으로 변환할 수 도 있고, 계속 Java를 이용해도 됩니다.
#10 KotlinAPIs
# Layouts
Android에는 여러 가지 레이아웃이 있는데, 시간이 지남에 따라 이용하는 레이아웃이 변해왔습니다.
AbsoluteLayout : 원하는 정확한 위치(x, y)에 표시할 수 있는 레이아웃 (쉬움)
LinearLayout : 가로나 세로로 정렬하는 레이아웃 (무한 중첩)
FrameLayout : 중첩해서 표시할 수 있는 레이아웃 (괜찮음)
GridLayout : 직사각형 그리드에 표시하는 레이아웃 (복잡함)
RelativeLayout : 부모나 서로를 기반으로 표시하는 레이아웃 (비쌈)
AbsoluteLayout : 더 이상 사용되지 않습니다.
LinearLayout : 간단한 레이아웃인 경우에는 괜찮습니다.
FrameLayout : 괜찮습니다.
GridLayout : Tool과 이용하면 좋지만, 실제로 그런 Tool은 존재하지 않습니다.
RelativeLayout : ConstraintLayout이 더 좋습니다.
ConstraintLayout : RelativeLayout처럼 부모나 서로를 기반으로 표시할 수 있으며, 중첩 레이아웃을 줄일 수 있기 때문에 성능상 더 좋습니다.
게다가 Visual Editor과 긴밀하게 통합되어 있기 때문에 사용하기 더 편합니다.
# AdapterView
AdapterView는 ListView나 GridView, Gallery의 기본 클래스입니다.
ListView는 여러 문제들이 있고, 나머지는 사실 잘 이용하지 않고 있습니다.
Coarse-grained changes : AdapterView에는 데이터와 뷰 사이의 인터페이스인 Adapter가 있습니다.
이 Adapter에서는 데이터가 변경되면 알려주는 기능을 담당하고 있습니다.
ListView의 문제는 거친 변경 사항(Coarse-grained changes)만 알릴 수 있습니다.
풀어 말하면, 데이터가 변경되었다는 것만 알릴 수 있고 구체적으로 어디가 변경되었는지는 알릴 수 없습니다.
ViewHolder : 말이 많았던 View Holder인데, RecyclerView에서는 기본적으로 내장되어 있습니다.
Animations : ListView에서 애니메이션을 구현하기 위해서는 이해해야 할 사항들이 너무 많았습니다.
RecyclerView를 이용하면 ListView에서 존재했던 문제들을 모두 해결할 수 있습니다.
Coarse-grained changes : 특정 데이터만 변경되었음을 알릴 수 있습니다.
https://developer.android.com/reference/android/support/v7/widget/RecyclerView.Adapter
#13 RecyclerViewFragment
# Platform Fragments >> Support Library Fragments
Fragment는 과거엔 복잡했습니다.
여러 버그들을 고치고, 이를 새로운 플랫폼이 출시될 때 반영했었습니다.
그 결과 플랫폼에 따라 동작이 달라지는 문제가 생겼고, 지금은 플랫폼 기반 Fragments는 이용하지 않고 Support Library를 통해서만 수정 사항들을 반영하고 있습니다.
Support Library 버전이나 Jetpack 버전을 이용하시기 바랍니다.
Jetpack 버전은 이번 io때 공개했는데, 아직은 정식 오픈은 안 한 거 같네요.
Activity
# Multiple Activity >> Single Activity
예전에는 기본적으로 Android 앱이 여러 개의 Activity들로 구성되었습니다.
Activity 단위로 화면을 구성했기 때문에, 이를 통해 작업들을 수행하고 전체적인 흐름을 나타냈습니다.
다른 화면으로 이동할 때는 애니메이션들도 추가할 수 있습니다.
새로운 접근법은 가능한 한 단일 Activity(single Activity)를 이용하여 Android 앱을 구성하는 것입니다.
단일 Activity를 통해 동일한 액션 바(action bar)를 가질 수도 있고, fragment 애니메이션으로 더 풍부한 애니메이션을 이용할 수 있습니다.
Fragment는 단일 Activity에 필수는 아니지만, 최근에 향상된 일부 기능이나 Navigation controller를 활용하면 많은 도움을 줄 수 있습니다.
Architecture
# MVC? MVP? MVVM? >> MVW(whatever works for you)
"앱을 개발할 때 어떤 Architecture를 써야 하나요?"라는 질문을 많이 받습니다.
그럴 때마다 대답은 항상 "We don't care."입니다.
앱이 어떻게 작동하고 어떻게 구성되어 있는지 모르기 때문에 가장 적합한 Architecture를 알 수 없습니다.
어떤 Architecture를 쓸지는 스스로 결정해야 합니다.
Android lifecycle
Android 생명 주기를 다 이해하고 암기해야 했습니다.
그리고 이 생명 주기를 추적하고 관리하기 위해서는 많은 메서드들을 재정의해야 했습니다.
이 생명주기 메서드들에 너무 많은 코드와 로직들이 들어있게 됩니다.
Lifecycle Owner를 통해 생명 주기를 추적하고 관리할 수 있습니다.
Lifecycle Owner를 서브 클래스화 하거나 Activity, Fragment에서 구현할 수 도 있습니다.
Views and Data
Activity에는 View와 관련된 모든 데이터가 있습니다.
이 데이터가 언제 바뀌는지 파악해야 하며, 잘못된 호출을 하거나 누설하지 않기 위해서 생명 주기를 계속 추적해야 합니다.
결국 이에 따른 코드가 많아지는 문제가 발생합니다.
LiveData와 ViewModel이라는 개념을 이용하면 이러한 작업들을 추상화할 수 있습니다.
Activity에서는 View에 대한 정보와 ViewModel에 대한 참조만 가지고 있어야 합니다.
Data
다양한 데이터베이스 solution들이 있는데, 원하는 아무거나 쓰면 됩니다.
전체적으로 정리하면, 아래 diagram과 같습니다.
데이터가 로컬에서 오든 웹에서 오든 쿼리 하는 입장에서는 중요하지 않기 때문에, 데이터가 어디서 왔는지를 추상화한 패턴입니다.
#21 Overall diagramData Paging
CursorAdapter라는 데이터베이스 커서에 대해 지원을 하는 클래스가 있습니다.
ListView에만 국한되었으며 기본적으로 페이징 크기와 같은 비효율적인 부분이 존재했습니다.
AsyncListUtil은 좀 더 유연했지만, 웹 트랜잭션과 같은 작업을 수행하는데 너무 비효율적이었습니다.
Paging library를 이용하면 좀 더 쉽게 구현할 수 있습니다.
Best Coding Practices
가능한 한 작업(work)들을 피하고 메모리 소모를 최소화하라고 했었습니다.
물론 디바이스는 더 좋아짐에 따라 더 많은 코어와 RAM을 가지고 있습니다.
그리고 더 나은 언어와 런타임도 가지고 있습니다.
하지만 디바이스는 여전히 제약을 받고 있고, 배터리 수명도 중요하고, 대역폭도 귀중하며, 모든 것이 UX에 도움을 줄 수 있습니다.
따라서 이러한 사항들에 대해 보수적으로 대하고 적절한 application 성능을 얻기를 바랍니다.
이 세션에 대해 다시 보면서 많이 배웠습니다.
왜 구글에서 새로운 API들을 광고하는지, 이전 기술들과 비교하는 내용들도 와 닿았습니다.
공부할게 계속 쌓이네요...
