Deview 2019 Day 2 후기

안녕하세요 :) Zedd입니다.

운이 좋게 동료분께..데뷰 Day2 티켓을 얻어서 다녀오게되었습니다 :D 

그럼 후기 시작

정말 뻔한 이야기지만

"늦잠을 잤습니다"

너무 미스테리하단 말이죠....오늘 맞춰놓은 시간보다 맨날 일찍 일어나는데..어떻게 못들을 수 있지

암튼 그래서

1교시 못들음ㅋ

암튼 어제 Day1에서는 문재인 대통령님이 오셨다는데...

AI가 비전..

즉, 프론트와 모바일은 비전이 없다..?

농담ㅎㅎ...근데 iOS세션은 1도 없어서....아쉬웠지만

저는 굿즈받으러 컨퍼런스 가는 사람이니까요 :D

등록

보이시나요 커피쿠폰??

작년에도 이은 커피쿠폰

커피를 줘야 컨퍼런스지

하지만 커피 줄이 너무 길어서 나중에 먹어야지 하다가

못썼음

ㅎㅎ..

에코백 안에 들어있는건 정말..........놀랍게도

물과 M&M초콜릿...

아니 스티커가 어떻게 없을 수 있지

브라운 샐리 스티커 뿌려주시면 안되나요

아니 왤케 호러스럽게 찍혔지...

 

암튼 저는 그래서 2교시 부터 들음

 

안드로이드 앱의 다중 웹뷰 환경에서 성능 병목 진단 및 최적화 사례

그래도 같은 모바일이니까.....

아 그리고 이제부터 제가 필기한거를 적을텐데..스피커분이 말씀하시는걸 들어서 ㅈ거은건데 

제가 잘못 받아적은(?) 부분이 있을 수 있다는 점...그래서 혹시 틀린 내용이 발견된다면 댓글로 말해주세용

아니 근데...그 데뷰에서 발표자료를 올려주셨는데 제가 그걸 캡쳐해서 여기에 올려도 되는건가요?...

뭔가 제가 찍은건 괜찮은데, 멀쩡한 발표자료를 캡쳐해서 여기에 올리면 뭔ㄱㅏ 안될것 같은 느낌적인 느낌이

아니그래도 올려주신거니까 괜찮을 것 같긴한데..

.사실 제가 찍은거 올리는거나 발표자료 캡쳐나 똑같은건데 왜 고민이 드는거죠..?

암튼..

네이티브인줄 알았는데 웹뷰인가봐요!

암튼 

네이버 앱에서 웹뷰를 쓰는데

안드로이드에서 웹뷰를 지원하는 방식은 크게 2가지임.

1. 전용 웹브라우저를 탑재

2. 안ㄷ드 OS에서 제공하는 시스템웹뷰 사용

각각 장단점 있음

네이버앱은 사용성 개선을 위해 다중 웹뷰를 사용했대요

앱 초기화 단계시에 복수의 웹뷰를 사전 생성했다구함

다중 웹뷰의 가장 큰 효과? -> 백그라운드 로딩 및 렌더링 수행하여 반응성 개선(마치 로딩이 거의 없는 것 같은)

위 그림처럼 좌우에 이미 웹뷰를 할당해놓고 스와이프 했을 때 로딩이 안걸리는 것 처럼, 

즉각적인 반응을 보여줄 수 있게 해놨대요

다중 웹뷰를 생성할때의 이런저런 부담들이 있음

웹페이지 로딩의 병목구간

- (대용량 또는 중복된) css parsing

- 자바스크립트 실행

- 레이아웃 변동

- 리소스 리퀘스트에 대한 response 지연.

First paint- 화면에 뭐라도 최초로 나타나는 순간

First contentful paint -가장 첫번째 content가 보여지는 시점? html파싱이 끝난 상황

First meaningful paint - 페이지의 레이아웃이 가장 급격히 변하는 순간

Time to interactive.(로딩에 소모되는 자원이 여유가 생기는 순간) 1st CPU Idle

결론 http cache - 사용하면 네트워크 지연이 준다!

이미지 로딩의 부하

- 저사양 단말에서의 불필요한 고해상도 이미지 로딩.

- 네트워크 전송 및 이미지 디코딩에 따른 부담

=> 단말 최적화 이미지 전송 (proxy vs. client hint)

프록시 기반.

프록시 서버가 중간에 가로채서(?) 리사이징 어쩌구 저쩌구 한다. 

Client hint 단말의 화면 해상도 정보를 header에 실어 서버에 요청.

적합한 크기 및 품질의 이미지를 담은 응답을 처리. => 하지만 이미지 품질을 더 떨어드려서 주게 되더라..(?)

앱 패러다임 변화 어떻게 적응할 것인가? 

(모듈 중심의 안드로이드 앱 설계)

네이버 앱 개발을 10년동안 하셨대요 ㄷㄷ

제가 메모를 했는데..이걸 복붙을 하기가 좀..애매한 상태군요

일단 시대가 변했잖슴

멀티코어..큰 디스플레이..대용량 메모리..이런게 나오면서 좀 더 간결한 코딩이 필요해졌다..로 요약하면 될 것 같음

설계의 핵심은 액티비티!! 

액티비티가 iOS의 ViewController같은거라고 이해하면 되는건가?

역시나 MVVM, MVC, MVP이런 디자인 패턴 이야기도 잠깐 나왔었는데,

 스피커분이 자기는 MV를 하라고 말한다고 하셔서 좀 공감됐음 

그러니까 Model, View고 Controller가 없잖아요? 

그러니까 Control할 부분을 적게하는게 좋다..! 라고 하신게 공감댔음.

단순구조에 적용은 신중해야함. 배보다 배꼽이 더 클 수 있음. ㄹㅇ공감

마지막에 하셨던 말은 새로운 기능 하나 추가하는데, 전부 컴파일 할 필요가 있음? 

안드로이드는 리소스를 한곳에 몰아넣을 수 밖에 없는데 나눠서 관리하려면 프로젝트를 쪼갤 수 밖에 업승ㅁ

~ 점심 ~ 

부대전골 머금

ㄲㄲ

사실 오후에 제가 들을게 1도 없어요 진짜...

그래도  엄선하고 엄선하여 

속도의, 속도에 의한, 속도를 위한 몽고DB 

(네이버 컨텐츠검색과 몽고DB)

아 이게 오늘 데뷰에서 제일 좋았던 세션...

사실 몽고DB에 대해서 저는 잘..아니 그냥 이름만 아는? 아예 모르는 수준인데, 뭔가 이해가 잘 갔어요.

왜지? 같이 갔던 친구도 좋았다구 그래씅ㅁ

왜 몽고디비 썼냐

빠르고 scalable하니꼔

Frequent Swap. 메모리에 인덱스를 ㄴ올려놓기 때문에 인덱스 많이 올리면 Frequent Swap.이 발생

-> 퍼포먼스 떨어짐. 데이터를 업데이트 할때마다 연결된 데이터가 업데이트 되어야 하기 때문에 write performance감소

-> read performance감소.

인덱스가 많으면 쿼리 플래너가 엉뚱한 인덱스를 골라서 오히려 성능이 떨어진다.

즉, 불필요한 인덱스를 만들지 않는 방법으로 개발하자. 

- 인덱스 prefix를 사용하자.

- 중복되는 인덱스들을 지울 수 있다. 

멀티 소팅.

Sort key들은 반드시 인덱스와 같은 순서로 나열 되어야만 한다. !! 컴파운드 인덱스의 지원을 받을 수 있음.

인덱스 필드의 cardinality가 낮아질 가능성이 높다.

-> 중복되는 value가 많다. Lookup 프로세스에 악영향을 미침 

-> 불필요한 인덱스를 많이 거쳐야 하기 때문에.

제가 메모한건데..아ㅓ무튼 발표자료 보세요,,

음 제 생각에 정확한 예를 들어주셔서 발표가 좋았던것 같아요! 

어떠한 상황이 있었고 

그걸 왜 그런지 생각했고 

이게 왜그렇더라~~ 이게 아주 깔끔했던...

쿼리 플래너의 존재도 알게 되었습니다 ^-^ 다른 DB에도 다 있는 그런 개념이겠죠?

Tracing, 눈발자국 만들기

사실 아 들으면 뭔가 로깅이나 뭐 그런거 할때의 팁을 좀 얻어갈 수 있으려나? 했지만..

정말zzzzzz 정말 하나도 못알아듣겠더라구요...........

제가 GCC, JS를 몰라서..암튼 중간부터 못따라가겠음

트레이싱은 printf를 활용하는 방식.

프린트문은 자기가 만든거 안에서만 사용할 수 있다. 

라이브러리나 그런 부분에서 문제가 생겼을 때 추적해야할때 printf문을 쓸 수 없다.

Uftrace? 함수의 시작부분에 강제로 삽입?

너무 말이 빨라서 못알아듣겠음

특정 오픈소스(발표자같은 경우는 안드로이드)를 분석해야하는경우.

분석할 데이터를 최소화하는것이 제일 중ㅇ요하다.

트레이서..ㅋㅋ

결론

눈발자국이 뒷사람의 이정표가 된다.

이거 넘 웃겼어요

마지막 세션

스케일아웃없이 순간 급증하는 주문 처리하기 

(Microservice with Kafka)

카프카...이름만 많이 들어봤지..

오라클은 증설이 어려움 ㅠ

목소리가 굉장히 바르다

~~~많은 안들이 있어는데 결과를 기다리지않고 통보를 받는 형식으로 처리.

하나의 주문이 특정 시간안에 세마포어를 확득하지 못하면 에러(?)

모니터링.

결제의 지연이나 세마포어 획득 실패 => 커스텀 메트릭ㄷ

키바나?

제가 뭘 적은거죠?...암튼..

오랜만에 본 분들과 정말 많은 개발이야기를 한 것 같은

데뷰 후기 끝!@!@!!!