[행사] Naver Tech Concert Day-2 01

Naver Tech Concert Day-2

01. 변화의 시대 : 안드로이드 앱 어떻게 개발할 것인가?

• 발표자 : 신동길 (NAVER / 네이버앱개발)

• 동영상 : https://tv.naver.com/v/4635525/list/272653

• 슬라이드 : https://www.slideshare.net/NaverEngineering/21-121507374

• 세션설명 : 변화의 시대 : 안드로이드 앱 어떻게 개발할 것인가? 안드로이드는 끊임없는 OS 버전 뿐만아니라 개발 언어, 구조, GUI등 많은 부분에서 다양항 변화가 시도되고 있습니다. 많은 방법론과 라이브러리가 제공되다보니 어떤 전략과 기준으로 개발해야하는지 혼돈스러울 때가 많습니다. 네이버 앱의 개편에 적용한 기술 사례와 방법론을 통해서 효율적인 앱 개발애 대해서 얘기하고자 합니다.

• 목차 :

  1. 안드로이드 앱의 구조
  
  2. 함수형과 객체형: 함수형과 객체형 개발 어떻게 적용할 것이가?
  
  3. GUI 기반 구조: Activity 구조,Fragment 구조, View 기반의 구조의 장단점은 무엇인가? 어떤 구조를 택할 것인가?
  
  4. 데이터 모델: 데이터 모델이 필요한가? MVC, MVP, MVVM 이 정말 필요한가?
  
  5. 프로세스 와 쓰레드 어떤 모델로 가져갈 것인가? : Service, AsyncTask, Thread, JobManager, WorkManager, Coroutine ,Loader 너무 많은데
  무엇이 정답인가? 멀티 프로세스 모델 어떻게 설계할 것인가?
  
  6. 통계와 설정: 어떤 정보를 모으고 최적할 것인가?
  

  

네이버 앱을 개편하면서 베타 버전까지 냈는데, 이 때까지 고민한 것들에 대한 이야기임.

(네이버에서도 베타 중에 기능 추가 요청이 들어오는 경우가 있음.)

https://play.google.com/store/apps/details?id=com.navercorp.techcon&hl=en_US

네이버 테크 콘서트 앱은 머티리얼 디자인만 적용하여 7시간 개발한 앱임.

(다른 프레임워크는 전혀 사용하지 않음)

앱번들, 사이닝 등록과정까지 10시간 정도 걸림.

1. 무엇이 변했는가?

Hardware

• Multi-Core
• Large Memory
• Big Display

Platform

• Dalvik -> JIT/ART
• Many Strictions

다양한 프레임워크

• Lottie
• RxJava
• Retrofit
• Glide, Picasso, OkHttp

좋은 앱이란

1. Big Sized
2. Mulit-Core Processor
3. Mulit-Featured
4. Multi-Media

단말이 바뀌고 좋아지다 보니 보다 많은 기능을 더 빠르게 개발할 것을 요구함.

애니메이션도 많이 붙게 되고, 오히려 느려지는 현상도 있음.

환경에 효율적이어야 함. (네이버 앱도 전면 개편 필요....)

네이버 앱은 웹뷰 사용하지 않고 웹 엔진을 사용함. (웹뷰 문제와 웹뷰의 수정 지연 때문에)

크로스워크 XWalk를 사용하고 직접 수정 및 미지원 기능 등은 기본 웹뷰를 사용함.

웹뷰에서 불가한 low 레벨 통계도 사용함.

자바의 문제점

1. 상속과 오버라이드 (3단계 이상시)
2. 객체 내 모두 선언해야 함 (딱딱함)
3. Listener 표현의 복잡함

즉 Big Size, 복잡한 GUI 환경에는 적합하지 않음.

좀 더 간결한 코딩 필요(많은 기능 필요)

Functional vs Objective Programming

Functional Programming

UI 코드를 간결히 표현할 도구 필요

코어 로직에 대해 간결히 표현할 방식의 필요

많은 함수를 가진 큰 객체 이벤트 처리 효율성 재고 필요

네이버 앱에서는 로직의 계층구조를 플랫하게 변경하기 위해 자바 8을 고려함.

자바 8의 스트림, 데이터의 파이프라이닝을 안드로이드 N부터 지원함.

레트로 람다 등의 도입을 고려했으나 협업을 고려했을 때 쉽지 않음.

결국 코틀린을 고려했지만, 언어를 바꾸는 것이라 고민하던 중 안드로이드 언어로 지정되어 적용하게 됨.

프레임워크를 쓰기 위해서 프레임워크에 대한 공부가 우선되기 때문에 대규모(5명 이상?) 프로젝트일 경우 신중해야 함.

그래서 협업자들에 대한 커뮤니케이션이 필요함. (다 생각이 다르고 설득이 어려움)

2. 앱의 구조

네이버 앱에서 Web Engine이 중심

Activity란?

라이프 싸이클은 왜 존재하는가? (다른 OS는 앱 단위에서 관리함)

Activity는 상태 관리와 UI 관리를 같이 함.

Activity는 각각이 앱이라 봐도 됨. (별도 프로세스, 런처 가능하여 멀티 런처 가능함)

안드로이드는 하나의 패키지 안에 복수개의 앱을 만들 수 있게 되어 있음.

Activity 간에는 Package 말곤 연계 없음

Activity 간에는 다 오픈 되있는 개념.

위가 안드로이드 UI 개념의 특징임.

Fragment는 화면 분할 개념이 시작이었으나 Activity 내에서 네비게이션 기능을 주로 함.

Intent란?

Intent는 RPC 역할. (프로세스 간의 통신)

Parcel로 Serialize한 정보 저장 역할.

Activity를 늘리는 건 좋은 방법이 아니고 비효율적임.

Ui Navigation

• Activity만 사용
• Activity 내 Fragment 사용
• Activity 내 View 단위 사용 (많이 사용)

Activity나 뎁스가 깊어지면 안좋은 구조.

Fragment는 attach/dettach 시에 문제가 많음.

네이버 앱 내 탭의 Fragment는 좌우플리킹시 라이프 싸이클이 있어 제어에 문제가 있음.

라이프 싸이클 사용은 객체 각자 관리해야 하면 결국 상속 구조로 가야 함.

(꼭 프레임워크 제공 라이브러리 등에 의존할 필요 없음)

Event Dispatching (Big SizeComponent)

이벤트에 대해서 각 기능(ex. 툴바, 탭 등등)마다 처리함. (ex. Back 키 등)

각 기능에서 할 경우 최상위에서 상속받아 계층별로 사용하게 됨.

이를 루트 액티비티에서 처리하게 해도 됨.

루트 액티비티에서 이벤트 맵/리스트 관리 후 콜백 등을 처리하면 됨. (예전에는 기피했으나 멀티 코어 세상이라..)

네이버 앱의 경우 웹뷰의 NestedScroll이 필요한 경우 웹뷰의 엔진으로 어떤 것을 쓸지 몰라 추상화가 필요함.

인터페이스 상속과 큰 클래스에서 엔진 두가지를 다 관리하는 방법이 있었는데, 인터페이스 상속을 택함.

멀티프로세스

1. 메인과 구별되는 기능요소
2. 별도의 모듈(Dynamic Linked Library) 로드하는 요소 so 사용 등은 메모리 제거 안되므로 프로세스 분리 필요. (외부 라이브러리 등)
3. 모듈의 크기가 큰 경우
4. 멀티미디어와 같이 자원을 많이 소요하는 요소
5. 크래시시 모듈 차단

추가로 UI 쓰레드도 멀티가 될 수 있음.

쓰레드

쓰레드풀(AsyncTask, Coroutine)

쓰레드풀은 멀티미디어 프로세스에서 못써서 쓰레드를 우선 순위 컨트롤해 사용. (쓰레드풀 사용시 성능 저하)

3. Design Architecture 적용

네이버 앱은 MVP (일반 브라우저와 Ai 기능 분리 사용)

객체 크기가 크다보니 MVVM보다 적합함

인앱 브라우저는 MV/Plugin (Processor(Controller)는 플러그인 형태)

Piped Filter Model

Piped Input(Output) Steam 사용.

source, transform, sink 필터 만들어 사용.

4. Multi Package

1. Apk Extension(.obb)
2. Another Apk
3. App Bundle
4. Instant App

앱 패키징은 앱번들 고려 중

5. 다양한 Framework 어떻게 활용할 것인가?

네이버 앱은 프레임워크를 많이 안씀.

Lottie, OkHttp, Glide, Retrofit 정도 사용 중.

Framework는 주로 native code, 오픈 소스 많지 않음.

대규모 서비스 앱에서 오픈 소스 사용에 신중해야 함.

(네이버 앱은 유저 3천만에 UV 억단위인데 Crash 천단위를 유지하기 위해 오픈 소스에 신중했음)