세션설명 : 안드로이드의 앱들은 현재 프로 가드를 통해서 보호되고 있고 향후로는 구글이 작성한 R8으로 대체할 예정에 있다. 난독화 도구들을 써봤지만 막연히 쓰는 경우가 많은데 난독화 도구가 어떤 일을 하고 있고 기본적인 메커니즘이 어떻게 구현되어있는지 프로가드, R8은 무엇인지, 그리고 안드로이드 빌드 과정에 어떻게 통합되는지를 살펴보는 시간을 갖는다.
안드로이드 코드의 특징
이식에 좋은 바이트 코드 사용
동적 컴파일에 기반한 성능 향상
의존성도 동적으로 로드
암호화되지 않은 클래스와 리소스로 구성
공간 효율적인 데이터 포맷
바이트 코드에 대한 간략한 이해
자바 Bytecode
스택 기반의 VM을 사용 (검증이 쉽지만 레지스터 기반의 실제 기기와 차이로 성능상 단점)
32비트 스택 하나의 요소가 대부분의 타입 커버
256개의 연산
자바는 상수의 종류를 구반하지 않음.
1+2 연산시 1과 2의 스택을 쌓은 후 두 스택을 꺼내 연산 후 3을 스택에 쌓음.
istore의 i는 int형을 의미.
기본적으로 ARM이나 x86 기계어보다는 단순함.
달빅 Bytecode
레지스터 기반의 VM 사용 (실제 하드웨어와 매핑에 이점으로 메모리 덜 쓰나, 상대적으로 검증이 어려운 단점)
32비트 레지스터 하나의 요소가 대부분의 타입 커버
64K 개의 레지스터 하지만 주로 앞의 256개, 가끔은 16개만 사용.
const 명령을 통해 레지스터 v1, v2에 상수를 넣음.
add-int를 통해 v2와 v3의 합을 v0에 저장.
자바와 달빅 bytecode 차이점
desugar는 자바 8을 지원하기 위함. (람다 등을 제거하여 자바 7 컴파일러가 돌 수 있도록)
.class 파일을 dex(dx, d8)을 통해 .dex 파일로 변환.
DX - 안드로이드 스튜디오 3.0 전 (D8보다 시간이 오래 걸리고 용량도 큼)
D8 - 안드로이드 스튜디오 3.0 이후 (써드파티 툴에서 새로운 DEX를 지원하지 못하는 문제 있을 수도)
세션설명 : 코틀린을 안드로이드에 적용하기 위해서는 안드로이드에 맞는 모듈의 개발, 거버넌스, 코딩 패턴, 디자인 패턴 등의 전략적 고려 사항이 필요합니다. 네이버앱에 코틀린을 적용한 경험을 토대로, 기존 프로젝트(또는 신규 프로젝트)에 코틀린을 적용할 때 반드시 고려해야 할 사항과 적용하면서 나온 사례를 통해서 최적화된 적용 방법을 공유합니다.
네이버 테크 콘서트 앱는 머티리얼 디자인만 사용하여 개발함.
자바를 컨버팅해 코틀린을 적용한 경우 심플하지 않고 문제도 많았음.
컨버팅시 물음표를 너무 많이 만듬.
코틀린 코드를 자바에서 사용할 경우 코틀린 코드에 붙어야할 부분도 많음.
코틀린을 배워도 자바 스타일로 짜는 경우가 많음. (코드를 너무 줄여서 가독성이 떨어진다는 평들)
dependencies {
implementation 'com.google.android.material:material:1.0.0'
// Other dependencies
}
...
// androidx 사용 전이라면 support 28버전 이상 사용
dependencies {
implementation 'com.google.android.support:design:28.0.0'
implementation 'com.google.android.support:support-v4:28.0.0'
// Other dependencies
}
직접 Material components 빌드하여 사용하기(포함된 샘플 앱은 빌드 안됨;)
세션설명 : 통계에 따르면 2018년 1분기에는 앱스토어에 약 220만개, 구글플레이에 약 380만개의 앱이 등록되어 있다. 이 치열한 경쟁속에서 사용자에게 오래도록 사랑받는 앱이 되려면 UX디자인은 선택이 아닌 필수다. UX디자인은 디자이너만의 영역이 아닌 개발팀 모두가 함께 만들어내야하는 가치이다. UX디자인에 관심을 갖고 참여한 개발자가 서비스 성공에 어떤 역할을 해 내는지 알아보자.
잘 나가는 앱을 만들고 싶다면? UX 디자인에 참여 필요.
사용자에게 중요한 건? 내 삶에 어떤 가치를 주는 가.
사용자에겐 서비스에 들어간 기술과 시간과 노력엔 관심이 없음.
UX 디자인은 일종의 프레임워크라 할 수 있음.
Focused on product
Focused on user
디자인적 사고는 문제를 발견해 해결 방법을 제시하는 것.
모두는 디자이너라 할 수 있음.
Lean UX Cycle
PLAN -> think -> make -> check -> think -> make
Lean UX 경험내용 1
UX 디자인 분석 단계를 개발팀과 함께 진행.
Key Feature 워크샵.
결과 : 기능의 목적과 목표를 이해하고 구현 가능한 스펙을 정의하여 품질 완성도가 올라감.
Lean UX 경험내용 2
UX 디자인 워크샵.
서비스 목표와 전략 수립. 핵심 기능 도출.
결과 : 사용자 가치 중심으로 스펙 변경, 플랫폼 전체를 바라보는 시각 형성.
UX Design을 개발자와 함께 함으로 목표와 가치 도출하고 사용성 테스트를 통해 문제점 발견이 용이함.
그 결과로는 기술 중심에서 사용자 중심으로 사용자에게 의미 있을만한 것을 제공하기 위해 집중함.
UX 디자인 함께 하면 좋은 점
공동의 목표 세워, 자발적이고 주체적인 의사결정 가능
시간과 비용 중심이 아닌 사용자 가치 중심의 스펙 정의가 가능
밀접한 협업 가능
신속한 결과 도출 및 검증 가능
낭비를 줄이고, 위험요소 미리 감지 가능
서비스 질이 좋아짐
UI와 UX 디자인
User Interface
Technical
어떻게 작동하는가? 어떻게 보이는가?
사용편의성, 일관성, 심미성
User eXperience
Emotional
어떻게 느끼는가?
사용자 가치, 사용자 환경(Context), 만족도, 재접근
Experience
오가닉 경험(Organic Experience) : 즉흥의, 즉석의 등 의도가 없는 순수한 경험
설계된 경험(Designed Experience) : 사용자가 고려되고 계획던 경험. 사용자가 경험했으면 하는 감정을 정의.
사용성보다 사용자 가치가 더 우선적
효율적인 UX 디자인 프로세스 = Lean UX + Agile UX
애자일 UX 방식은 초기 비용이 높으나 후반으로 갈 수로 낮고 상대적으로 워터폴은 비용 뿐만이 아니라 리스크도 높아짐.
세션설명 : 구글이 Android Architecture Component 의 ViewModel 을 발표하면서 다양한 시각의 MVVM 구현이 제시되고 있습니다. 여전히 많은 사람들이 혼동하는 MVVM 구현에 대해 올바른 안드로이드 MVVM 구현을 공유하고자 합니다. 이를 위해 안드로이드에서 어떠한 기본 작업이 선행되어야 하는지, 다양한 문제 상황에 대한 해결책에 대해 알아보고 MVVM 이 Grab 에서 어떻게 활용되고 있는지 알아보겠습니다.
국내 MVVM 이해도 오류가 많음. (국내 포스팅 등...)
예로 아래의 경우 뷰에서 옵저빙을 하는 부분이 문제임.
classMainViewModel {
val title LiveData<String>
}
...
classMainActivity {
val viewModel:ViewModelval textView:TextViewfunonCreated() {
viewModel.title.observe(this) {
textView.text =it
}
}
}
Android Architecture Component의 ViewModel
AAC의 ViewModel은 MVVM의 ViewModel과는 무관함.
AAC의 ViewModel은 Activity와 Fragment의 Life Cycle 의존성을 낮추는 것.
LiveData는 Repository로부터 데이터 변화 반응/적용이 목적이며 ViewModel은 LiveData로부터 View에 필요한 데이터를 관리함.
MVVM의 ViewModel
View와 ViewModel 연결 최소화
ViewModel은 데이터의 변화를 View에 전달
View는 화면 정보의 변화를 ViewModel에 전달
위에서 잘못된 코드는 아래와 같이 변경되어야 함.
classMainActivity {
val viewModel:ViewModelfunonCreated() {
dataBinding.setVariable(BR.vm, viewModel)
}
}
안드로이드에서 DataBinding 사용에 문제 사항들
LifeCycle
Databinding으로 다 표현하기 힘든 View 이벤트
Resource 등 Context를 접근해야 하는 경우
LifeCycle
그랩에서는 LifeCycle 문제를 위해 RxBinder를 만들어 사용함. (Trello의 RxBinder 참조)
value : XML Attribute Name List, 다수 개일 경우 메소드 파라미터 순서와 매칭이 되어야 함.
requireAll : value()의 Attribute가 모두 존재할 때만 처리할지 여부. false일 경우 int/double/float/... 등의 타입의 Attribute가 없을 경우는 값은 0, Object 타입의 Attribute가 없을 경우는 null로 처리됨.
발표자께서는 requireAll=false 을 사용하였었으나, 다수 개의 Attribute에서 어떤 값만 옵셔널하게 처리가 안되어 아래와 같이 오버로딩하면서 쓰고 있음.
Q. recyclerView의 스크롤 이벤트 같은것도 데이터 바인딩으로 받을 수 있을까요? (스크롤 위치에 따라서 이벤트 처리를 하고 싶은 경우에)
해보지는 않았는데요. Listener를 Setting해서 값을 가져오는 방식이라면 가능합니다. InverseBindingAdapter를 이용하면 될것 같은데요.
참고로 저의 경우에는 ViewPager의 Page 이동과 offset 이동도 InverseBinding으로 처리하고 있습니다.
Q. 데이터바인딩을 사용하게 되면서 코드 가독성이 떨어진 점은 없었나요? Textview.setText면 충분하지 않았나 싶은 생각도 들고 그러는데 데이터바인딩의 장점이 궁금합니다.
이건 취향차이기인 해요. 저는 오히려 코드 가독성이 올라가는 부분도 있다라고 생각합니다. View에 대한 로직은 모두 xml에서 볼 수 있다라고 생각할 수 있으니까요. 로직이 복잡해지면 xml도, 코드에서도 복잡하긴 한건 매한가지 이긴 하니까…?
사실. 이 DataBinding은 코드의 가독성을 높인다. 개발 생산성을 높인다.의 이야기와는 맞진 않다고 생각합니다. 정확하게는 Java/코틀린 코드에서 View에 대한 참조를 제거하는 도구이다. 라고 보시는 쪽이 맞긴 해요. 또한… 이런저런 장점들이 있기는 한데… 가장 크게 예를 들면 Image Loading 같은 경우에요. 그냥 코드로 작성하게 되는경우 Image를 Load하는 모든 지점에서 자바/코틀린으로 Loading 로직을 작성해주셔야 하는데 Binding을 이용한다면 이런식으로 작성하면 끝! 할수도 있거든요
막상 열심히 써보면 편해요. 굉장히 편합니다. View를 사용할 때 thread 걱정도 사라지고요. 얘가 NullPointer도 잡아주고요… 내 손으로 작성하는 코드의 양을 줄여서 실수를 줄여주는 부분도 있습니다. 이제 저는… Binding 없이는 코딩이 좀 어렵다. 생각이 들 정도로 적어도 제게는 정말 편리한 도구입니다
10. AI & Cloud. 모바일 개발자를 위한 ML Kit: Machine Learning SDK 소개
발표자 : 신정규 (Founder & CEO, Lablup Inc.)
세션설명 : 모바일 개발자를 위해 더 쉬워진 머신 러닝! Firebase에서 사용 가능한 머신 러닝 SDK, ML Kit가 발표되었습니다. ML Kit을 사용하면 Android와 iOS 모든 플랫폼에서 강력한 머신 러닝 기능을 앱에 적용할 수 있습니다. 초보자도 쉽게 시작할 수 있는 ML Kit을 국내 머신 러닝 전문가, Google GDE인 Lablup Inc.의 신정규 대표가 소개합니다.
TensorFlow
TensorFlow <--> TensorFlow Lite <--> TensorFlow.js
발표자 : Kaz Sato (Staff Developer Advocate, Cloud Platform, Google)
세션설명 : TensorFlow Lite는 모바일과 임베디드 디바이스에 최적화된 머신러닝 프레임워크로, 낮은 지연시간과 작은 바이너리 크기로 디바이스 상에서의 머신러닝 추론이 가능하며 안드로이드 신경망 API를 사용한 하드웨어 가속화도 지원합니다. TensorFlow Lite를 통해 최신 AI 기술을 모바일에 적용하는 법을 알아보세요.