'Android' 카테고리의 글 목록

Android

조각들

2024.09.08

다른 분의 코드를 보다가 LifecycleObserver라는 것을 새로 알게 되었다. 생명주기 관련하여 특정 동작을 처리하고 싶을 때 사용하는 것인데 "Activity나 Fragment에서 onDestroy() 등 필요한 시점을 override해서 쓰면 되는 거 아닌가? 왜 이렇게까지 하지?"라는 의문이 들었다. 개인적으로는 생명주기 관련 처리들을 따로 관리함으로써 아래와 같은 장점이 있을 것 같다고 느꼈다.관리 수월가독성 개선 그리고 공식 문서를 찾아보니 내 생각과 비슷한 내용이 있었다.수명 주기의 현재 상태에 따라 UI와 다른 구성요소를 관리하는 호출이 너무 많이 발생하게 됩니다. 여러 구성요소를 관리하면 onStart() 및 onStop()과 같은 수명 주기 메서드에 상당한 양의 코드를 배치하게 ..

Fragment에선 왜 viewLifecycleOwner를 써야할까

2024.09.08

안드로이드 처음 시작했을 때 이 그림을 보고는 "Activity처럼 Fragment도 생명주기가 있다는 내용이구나"하고 넘겼었다. 제대로 안 본 것이다. 다시 봐보니 Fragment와 별개로 View의 Lifecycle이 존재한다는 것을 알았다. 보통 fragment를 쓰면 onDestroy 부분에 binding 객체를 null로 하여 참조를 제거해주는 코드를 베이스로 많이 쓴다. 이걸 왜 해주는지안다면 viewLifecycle도 모를 수가 없었을 텐데. 결론부터 얘기하자면 뷰의 수명이 fragment보다 짧기 때문이다. 따라서 뷰는 죽어있는데 fragment는 살아있는 경우가 있을 수 있다. 이때 죽어있는 뷰에 대한 참조를 계속 가지고 있으면 GC가 메모리 회수를 못해서 메모리 leak이 일어난다. ..

UI 상태 관리를 할 때 어떤 것들을 고려할 수 있을까

2024.09.07

요약구성 변경이란 onDestroy로 인스턴스가 소멸되고 onCreate부터 새 인스턴스가 생성되는 것이다.구성 변경이 일어날 수 있는 여러 상황이 있다.구성 변경이 일어날 때 data를 유지할 수 있는 방법으론 크게 3가지가 있다.로컬 DB (SharedPreference, DataStore, Room)뷰모델SavedInstanceState (SavedStateHandle)구성 변경이 일어날 때 동작하는 콜백이 있고 이 콜백 안에서 어느 요인해 의해 변경이 일어났는지 파악해볼 수 있다.구성 변경이 일어나지 않게 제한할 수 있다.내용이 표 하나가 많은 걸 알려주고 있다. 공식문서에 프로세스에 의한 kill 경우를 대놓고 소개해주고 있었다. 마음이 쓰리지만 이제라도 알 수 있어서 다행이다. 뷰모델ViewM..

프롤로그

2024.09.01

마음의 평화를 위해 삽을 뜨기로 했다. 뛰진 못해도 걷기라도 하자.화이팅.

평균 10초가 걸렸던 API 응답에 대한 대응

2024.07.21

디프만 14기 활동 중 개발했던 프로젝트에서 겪었던 트러블 슈팅 경험을 정리하고자 합니다. 기능 소개사용자들의 관심사를 입력 후 핸드폰을 흔들면 적절한 대화 주제를 추천해주는 기능입니다.이때 대화 주제는 GPT를 활용하여 추천해주기로 했습니다. 아래 영상은 흔들기 데모 영상입니다. 자이로센서로 뷰들의 x,y 값을 실시간으로 수집하여 동적으로 뷰의 위치를 갱신하도록 구현했습니다. 트러블 슈팅사용자에게 5개의 대화 주제를 추천해주어야 했습니다. 그런데 서버에서 만들어준 API에선 한 번에 5개의 data를 내려주고 있었는데 GPT 서버 상태에 따라 응답 시간이 불규칙했고 평균 10초라는 긴 시간이 걸렸습니다. 이렇게 시간이 오래 걸리게 되면 사용성이 매우 떨어진다는 점에서 api 응답 시간을 줄이는 고민이 ..

코루틴

2024.05.30

단일 스레드의 한계멀티 스레드 프로그래밍이 필요한 이유병렬 처리사용자 스레드, 데몬 스레드 ExecutorExecutor 프레임웍은 작업 처리를 위해 스레드풀을 미리 생성해 놓고 작업을 요청 받으면 쉬고 있는 스레드에 작업을 분배한다. 이때 각 스레드가 작업을 끝내더라도 스레드를 종료하지 않고 다음 작업이 들어오면 재사용한다. 이를 통해 스레드풀에 속한 스레드의 생성과 관리 및 작업 분배에 대한 책임을 Executor 프레임웍이 담당하므로 개발자는 더 이상 스레드를 직접 다루거나 관리하지 않아도 된다. 개발자가 해야 할 일은 스레드풀에 속한 스레드의 개수를 설정하고, 해당 스레드풀을 관리하는 서비스에 작업을 제출하는 것 뿐이다. 개발자가 ExecutorService 객체 내부의 동작을 전혀 신경 쓰지..

조각들