Vive Hodie

[Android/Project] 기존 앱에 Jetpack Compose 도입기: LazyColumn 활용

Hodie! — Sat, 12 Aug 2023 15:50:54 +0900

기존 앱에 Jetpack Compose 도입기: LazyColumn 활용

배경

지난 7월말 Google I/O Extended Seoul 컨퍼런스를 다녀오고, 여러 자료들을 보면서 더이상 Compose에 대한 공부를 늦추면 안되겠다는 생각을 많이하게 되었다.
특히, 최근 업데이트 과정에서 Compose에 대한 지원이 아낌없이 이루어지고 있는 점, Figma와 같은 협업 툴에서도 관련 내용들이 속속들이 등장하고 있는 모습을 보면서, XML은 여전히 많이 사용되고있지만 점차 저물고 있는 해라는 생각을 많이 하게되었고 언제까지 XML만 사용할 수 있을까? 하는 의문이 많이 들었다.
따라서, 현재 진행하고 있는 프로젝트에서 새롭게 화면을 만들어야 하는 부분을 Compose로 개발하기로 확정짓고 개발하게 되었다.
Compose로 처음 개발하는 만큼, 안드로이드를 처음 배웠을 때가 오버랩되면서 만족스러운 코드가 나왔다고는 할 수 없지만, Compose를 처음 접하는 입장에서 개발한 과정을 공유하면 좋을 것 같다는 생각이 들어 작성하게 되었다.

개발 기능

Compose로 처음 개발하는 만큼, 다양한 기능이 존재하는 화면보다는 단순한 화면에서부터 적용시키는 것이 사이드 이펙트가 적을것이라고 판단하였고 사이드 이펙트가 적은 화면을 개발 대상 기준으로 하였다.
마침, 개발하고 있는 앱이 좋아요 기능이 존재하는데 좋아요를 누른 사람의 리스트가 보여지는 화면을 만들어야 하는 상황이라 해당 화면을 Compose로 만들어보기로 했다. 좋아요 리스트를 보여주는 것이외에는 많은 동작이 없는 화면이라 적합하다고 판단하였다.

물론, XML로 만들어진 레이아웃에도 ComposeView를 이용해 Compose로 개발할 수 있지만, 새 화면에서 Compose로 개발을 진행하면, 좀 더 Compose에 대해 잘 사용할 수 있을 것 같아 새로운 화면을 선택하였다.

기본 세팅

Compose를 통해 개발하기 위해서는 개발에 앞서 여러 세팅들을 요구 한다.
대부분 공식문서에 있는대로 차근차근 따라가면 된다.
~~물론, 버전업을 하면서 다른 의존성과의 호환성 문제가 있을 수 있다.~~
- build.gradle (app 수준)
  1. Compose 버전 설정시 현재 Kotlin Version과 Compose Compiler Version의 호환성 체크
    - Pre-release Kotlin Compatibility
```
android {
    buildFeatures {
        compose = true
    }

    composeOptions {
        kotlinCompilerExtensionVersion = "본인의 Compose Version"
    }
}
```
  2. 이후 원하는 의존성 선택적으로 추가
```
dependencies {

 val composeBom = platform("androidx.compose:compose-bom:2023.08.00")
 implementation(composeBom)
 androidTestImplementation(composeBom)

     ...

}
```

기존 앱에 Compose를 도입하기 위한 구현 순서

만들어야 하는 페이지 레이아웃 샘플

기존 앱은 하나의 Activity에 여러 개의 Fragment을 Navigation Component를 이용해 각 화면을 구성하고 있던 상태였고, 이를 고려했어야 했다.
구현해야 하는 주요 부분은 크게 상단 액션바와, 그 아래 유저에 대한 정보가 담긴 컴포넌트가 반복되는 레이아웃이라고 볼 수 있다.
1. 액션바와
2. 유저 정보가 담긴 컴포넌트에 대한 레이아웃을 만든뒤
3. 이를 서버에서 받아온 정보를 활용해 유저에게 리스트뷰 형식으로 보여주면 된다.

Implementation(구현)

Fragment

기존에 Fragment와 Navigation Component를 활용해, 앱을 구성하고 있던 상황이었기 때문에, 기존 Fragment를 활용하는 방식을 유지하되 Compose를 도입하는 방향으로 생각하게 되었고, 공식문서에서도 이러한 방법을 안내하고 있어 동일하게 진행하였다.
Compose 공식문서 중 Migration Strategy의 Build new feature with Compose - New Screens 참고해 새로운 화면을 만들었다.
→ 이를 활용하면, XML없이도 Compose를 이용해 기존 앱에서 레이아웃을 구현할 수 있다.

class PostLikeUsersFragment : Fragment() {
        override fun onCreateView(
        inflater: LayoutInflater, container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View {
        return ComposeView(requireContext()).apply {
            setViewCompositionStrategy(ViewCompositionStrategy.DisposeOnViewTreeLifecycleDestroyed)
            setContent {
                MaterialTheme {
                    Scaffold(topBar = { SetPostLikeUsersActionbar() }) { contentPadding ->
                        Box(modifier = Modifier.padding(contentPadding)) {
                            SetPostLikeUsers()
                        }
                    }
                }
            }
        }
    }
}

setViewCompositionStrategy는 Composition을 Dispose해야하는 시기를 정의하는 역할을 한다.

기본적으로 설정되어 있는 DisposeOnDetachedFromWindowOrReleasedFromPool는 View가 Window으로부터 detach 될 때마다 Composition을 삭제한다.
(RecyclerView와 같이 pooling container의 일부가 아닌 경우에)

따라서, ComposeView가 Fragment View에 있을 떄 사용하는 DisposeOnViewTreeLifecycleDestroyed로 변경해 설정한다.
전적으로 Compose에 기반하는 새로운 화면을 생성하기 위해서 XML 파일을 사용하는 대신 setContent() 메서드를 호출하고, 이 메서드 내에서 레이아웃을 정의한다.
- 따라서, 이 메서드 내에서 주요 UI를 구현하는 Action bar 구현 메서드와 유저 리스트를 구성하는 메서드를 호출한다.
가장 기본적인 Compsable UI를 작성하는 방식은 Column, Row를 사용하는데, LinearLayout과 유사하다고 보면 될 것 같다.
- 다만 여기선 유저 리스트 1개만 존재하므로 Box로 구성하였다.
Scaffold는 Material design의 기본 layout 구조를 만들기 위한 상위 레벨의 slots를 제공한다. TopAppBar, BottomAppBar, FloatingActionButton, Drawer의 slot을 제공해 쉽게 구현할 수 있도록 해주며, 이 부분들을 채워 넣으면서 알맞은 위치에 components를 배치하고 동작하도록 할 수 있다.
- 여기서 특이한 점은 contentPadding 부분인데, Scaffold의 content에 해당하는 람다에서 다른 Composable 객체를 추가할때 처럼 추가하면 영역이 잘리기 때문에, Padding값을 TopBar와 BottomBar가 차지하는 영역의 크기에 해당하는 contentPadding값을 추가해서 정해줘야 하며, 정해주지 않으면 IDE에서도 경고한다.
MaterialTheme는 구성 가능한 함수의 스타일을 지정하는 방법이다. Theme를 지정하는 경우에 setContent에서 Theme로 감싸주는게 일반적인 형태라고 한다.

Custom Action Bar

구현해야 하는 커스텀 액션바

Action bar Title 설정

앱의 Custom Actionbar에서 구현해야 하는 부분은 2가지 이다.
1. 뒤로가기 버튼
2. 타이틀 텍스트

    @OptIn(ExperimentalMaterial3Api::class)
    @Composable
    private fun SetPostLikeUsersActionbar() {
        val interactionSource = remember { MutableInteractionSource() }
        CenterAlignedTopAppBar(
            colors = TopAppBarDefaults.centerAlignedTopAppBarColors(
                containerColor = colorResource(id = R.color.white_FFFFFF)
            ),
            title = {
                Text(
                    text = stringResource(id = R.string.post_like_users_title),
                    style = TextStyle(
                        fontSize = 16.sp,
                        lineHeight = 24.sp,
                        fontWeight = FontWeight(600),
                        color = colorResource(id = R.color.gray_1_313131),
                        textAlign = TextAlign.Center
                    )
                )
            },
            navigationIcon = {
                IconButton(
                    onClick = { findNavController().navigateUp() },
                ) {
                    Icon(
                        painter = painterResource(id = R.drawable.ic_back_sign),
                        contentDescription = "back sign",
                    )
                }
            }
        )
    }

Scaffold는 Material3에서 제공하는 요소이고, 모든 Material3 부분은 아직 Experimental에 해당하기 때문에 @OptIn(ExperimentalMaterial3Api::class) Annotation을 추가시켜야 한다.
여기서 Title은 상단바에서 한가운데 위치해야하기 때문에 CenterAlignedTopAppBar를 활용해 구현해주었다.
뒤로가기의 경우 navigationIcon parameter에 람다로 넣어주면 된다. 이때 IconButton을 활용해주면 된다.
Compose에서도 XML에서와 마찬가지로 리소스를 가져와 적용할 수 있다. stringResource, colorResource, paintingResource 등을 이용해 리소스를 가져와 적용 시킬수 있고, resource id를 작성해주면 된다.
- Context를 가져올 수도 있지만, 굳이 사용할 이유는 없어보인다.
기존 Android View 시스템의 ImageButton은 Compose에서 IconButton과 매칭되기 때문에, 뒤로가기 버튼의 경우 Icon Button으로 작성해준다.
Button과의 차이점은 IconButton은 내부에 보통 Icon을 포함하고, Button은 내부에 보통 Text를 포함한다는 점이다.

IconButton의 parameter중 클릭시 어떤 동작을 할지 설정하는 onClick과 IconButton에 그려질 Icon을 포함하는 content는 반드시 전달해야 한다.

또한, content는 androidx.compose.material.icons.Icons의 아이콘을 사용하는 아이콘이여야 한다. 만약 사용자 지정 아이콘을 사용하는 경우 내부 아이콘의 일반적인 크기는 24x24가 된다.
- 참고로 IconButton은 Box를 내부에 포함하고 있다. 해당 박스 내부에 우리가 전달한 content(Icon)이 그려지게 된다.
- 클릭시 발생하는 이벤트는 Box의 Modifier의 clickable 인자로 전달되어 이벤트가 처리된다.

좋아요 누른 유저 정보 레이아웃

구현해야 하는 유저 정보가 나타나는 레이아웃 리스트 방식

Paging3

Compose에서도 페이징을 처리하기 위해 Jetpack Paging Library를 사용하였다.

@Composable
    private fun SetPostLikeUsers() {
        val likeUsers = postViewModel.postLikeUsers.collectAsLazyPagingItems()
        when (likeUsers.loadState.refresh) {
            is LoadState.Loading -> {
                        //TODO implement loading state
                        }

            is LoadState.Error -> {
                        //TODO implement error state
                        }

            else -> {
                SetPostLikeUsersLayout(likeUsers = likeUsers)
            }
        }
    }

postViewModel으로부터 poseLikeUsers을 통해 좋아요를 누른 유저리스트가 담긴 정보를 받아오기 위해 viewModel로부터 flow를 collect를 위한 collectsLazyPagingItems을 사용해lazyPagingItems로 받아오게 된다.

이를 이용하게 되면, Compose는 유저가 로드한 리스트의 끝에 도달하면 해당 객체를 어떻게 handle하고, 더 많은 아이템을 request하기 위한 방법을 알고 있다.

따라서, 해당 객체를 composable 화면에 전달하면 된다.
- 추가로, LazyPagingItems 는 LazyColumn, LazyRow, LazyHorizontalGrid or LazyVerticalGrid과 같은 lazy 레이아웃에 pass할 수 있다. 자세한 정보는 here를 참고하자
- collectAsLazyPagingItmes()는 cold flow를 LazyPagingItems 인스턴스로 변환한다.
LazyPagingItems은 LoadState에 대한 정보를 가지고 있기 때문에 loading state를 handling할 수 있다.

위 코드에서는 refresh event(처음 로드하거나, data를 invalidating하는)에만 동작하는 코드를 작성했지만, append, prepend 등에 대해서도 handling할수 있다.

LazyColumn

기존에 RecyclerView로 구성했던 리스트뷰를 LazyColumn으로 구현할 수 있다.
- 다만 RecyclerView처럼 하위 항목을 재사용하지는 않는다. 대신 스크롤을 따라 새로운 Composable들을 emit하는데, Android View를 인스턴스화하는 것보다 Composable을 emit하는 것이 상대적으로 Cheap하기 때문에 재활용하지 않더라도 여전히 성능이 좋다.

        @Composable
    private fun SetPostLikeUsersLayout(likeUsers: LazyPagingItems<LikeUser>) {
        LazyColumn(
            modifier = Modifier
                .padding(vertical = 4.dp)
                .fillMaxSize()
                .background(color = colorResource(id = R.color.white_FFFFFF))
        ) {
            items(likeUsers.itemCount) { index ->
                val item = likeUsers[index]
                LikeUserLayout(likeUser = item!!)
            }
        }
    }

이렇게 하면, 유저 리스트를 보여줄 수 있다. RecyclerView를 이용해 리스트 뷰를 구현했던 것과 비교하면 엄청나게 간단해진 셈이다.
- 기존 RecyclerView 구현시 작성해야 했던 항목들
  1. RecyclerViewAdapter 생성
  2. 유저 정보에 대한 XML 및 ViewHolder 생성
  → 기존 UI에서 구현했어야 했던 양에 비하면, 코드 양에서부터 엄청나게 간결해졌다. 많은 보일러플레이트 코드를 줄일 수 있다는 점에서 큰 발전이라고 생각한다.
items는 Composable을 반복해서 나타내고자할 때 사용한다. 여기에서는 유저의 정보를 보여주는 부분에 해당한다.

특히 items를 여러 개 구성할 수 있어서 더이상 ConcatAdapter 같은 것도 필요없다.

items의 parameter에는 코드에서처럼 특정 item 리스트의 count를 넣을수도 있고, 특정 item을 직접 넣을수도 있다.
- 다만, 불과 며칠전에 paging-compose가 3.2.0으로 업데이트 되면서, LazyListScope만 지원하는 items(lazyPagingItems)나 itemsIndexed(lazyPagingItem)는 Deprecated 되었다. 따라서 이전에 LazyColumn과 paging3을 함께 구현했던 여러 블로그에서의 예제 중 items(LazyPagingItems)는 더이상 사용할 수 없다. count만 넣어야할 듯 하다.

User Layout

구현해야 하는 유저 정보가 나타나는 레이아웃

@Composable
    private fun LikeUserLayout(likeUser: LikeUser) {
        Surface(
            color = colorResource(id = R.color.white_FFFFFF),
            modifier = Modifier.fillMaxWidth()
        ) {
            Row(
                verticalAlignment = Alignment.CenterVertically,
                modifier = Modifier
                    .fillMaxWidth()
                    .clickableSingle { navigateUserProfile(likeUser.memberId) }
                    .padding(horizontal = 18.dp, vertical = 8.dp)
            ) {
                LikeUserImageLayout(likeUser = likeUser)
                LikeUserNicknameLayout(userNickname = likeUser.nickname)
                Spacer(modifier = Modifier.weight(1f))
                if (likeUser.memberId != DayoApplication.preferences.getCurrentUser().memberId) {
                    LikeUserFollowLayout(likeUser = likeUser)
                }
            }
        }
    }

Compose에는 margin이 없고, padding만이 존재한다. Modifier에서 padding이 적용된 순서에 따라 margin처럼 적용되기도 하고, padding처럼 적용되기도 한다. 따라서, modifier를 사용할때의 코드의 순서가 매우 중요하다.만약, padding이 clickable보다 앞에 존재하는 경우엔, 우리가 알던 margin처럼 적용되어 padding으로 추가된 공간을 클릭하더라도 아무런 동작도 하지않게 된다.

이 경우, padding이 가장 마지막으로 적용되어있는데, clickable이 그 앞에 적용되어있다. 이렇게 적용시키게되면, 기존에 우리가 알던 padding처럼 적용되어 padding으로 추가된 공간을 포함에 전체 영역을 클릭할 경우 clickable에 작성한 동작을 하게된다.

만약 유저가 접속한 본인이라면 팔로우 버튼이 보여져서는 안된다. 따라서, 만드려고 하는 유저 UI가 본인인지에 대한 State에 depend해서 버튼이 만들어지도록 설정했다.
좌측에 유저의 이미지와 닉네임이 나타나고 우측에 버튼이 나타나는 형태이다. 이미지와 닉네임은 좌측으로 align시키고, 버튼은 우측으로 align시켜야 하기 때문에 닉네임과 버튼 사이에 Spacer를 통해 공간을 주고 weight를 적용시켜 닉네임, 이미지, 버튼의 영역이외에는 Spacer가 모두 채울 수 있도록 공백을 추가시켜줬다.
- 닉네임에 가중치를 줘도 되지만, 이 경우 닉네임의 영역이 버튼 직전까지 채워지기 때문에 Spacer를 추가시켜주는 것이 적절하다고 생각했다.

Glide Image

유저 이미지 예시

    @Composable
    private fun LikeUserImageLayout(likeUser: LikeUser) {
        GlideImage(
            imageModel = { "Profile Image Url" },
            imageOptions = ImageOptions(
                contentDescription = "image description",
                contentScale = ContentScale.Crop,
            ),
            modifier = Modifier
                .height(USER_THUMBNAIL_SIZE.dp)
                .aspectRatio(1f)
                .clip(CircleShape)
        )
    }

이미지를 표시하기 위해서는 ImageLoader가 필수적인데, 기존엔 Glide를 사용했지만 아직 Glide에서 공식적으로 Compose를 지원하지는 않는것 같다. 다행히, 이러한 상황에 대해 Compose로 Glide로 사용할 수 있게 해놓은 오픈소스가 있어서 손쉽게 사용할 수 있었다.
- 해당 라이브러리는 Glide이외에도 Coil 등 몇 개의 이미지 로더 라이브러리를 지원하는데, 기존에 Glide를 사용중이었기 때문에, 동일한 스펙으로 맞추는게 좋을 것 같아 GlideImage를 선택하였다.
1:1 비율의 원 모양인 이미지가 필요했기 때문에, Image를 Crop하고, asepectRatio를 통해 비율을 설정해 준뒤, clip을 통해 원 모양을 설정해주었다.

Follow Button

해당 유저를 팔로우 하지 않음

해당 유저를 팔로우한 상태

    @Composable
    private fun LikeUserFollowLayout(likeUser: LikeUser) {
        val followInteractionSource = remember { MutableInteractionSource() }
        val followIsPressed by followInteractionSource.collectIsPressedAsState()

        var followState by rememberSaveable { mutableStateOf(likeUser.follow) }
        val followSuccess by .. 
        val unFollowSuccess by ..

        TextButton(
            onClick = {
                if (followState) {
                    DeleteFollow()
                    if (unFollowSuccess) followState = false
                } else {
                                        CreateFollow()
                    if (followSuccess) followState = true
                }
            },
            interactionSource = followInteractionSource,
            colors = ButtonDefaults.buttonColors(
                if (followState or (!followState and followIsPressed)) colorResource(id = R.color.white_FFFFFF)
                else colorResource(id = R.color.primary_green_23C882)
            ),
            contentPadding = PaddingValues(0.dp),
            modifier = Modifier
                .defaultMinSize(1.dp)
                .border(
                    width = 1.dp,
                    color =
                    if (followState or (!followState and followIsPressed)) colorResource(id = R.color.gray_3_9FA5AE)
                    else colorResource(id = R.color.primary_green_23C882),
                    shape = RoundedCornerShape(size = FOLLOW_BUTTON_RADIUS_SIZE.dp),
                )
                .background(
                    color =
                    if (followState or (!followState and followIsPressed)) colorResource(id = R.color.white_FFFFFF)
                    else colorResource(id = R.color.primary_green_23C882),
                    shape = RoundedCornerShape(size = FOLLOW_BUTTON_RADIUS_SIZE.dp)
                )
                .width(FOLLOW_BUTTON_WIDTH.dp)
                .height(FOLLOW_BUTTON_HEIGHT.dp)
        ) {
            Text(
                text = if (followState) stringResource(id = R.string.follow_already)
                else stringResource(id = R.string.follow_yet),
                style = TextStyle(
                    fontSize = 14.sp,
                    lineHeight = 21.sp,
                    fontWeight = FontWeight(600),
                    color = if (followState or (!followState and followIsPressed)) colorResource(id = R.color.gray_3_9FA5AE)
                    else colorResource(id = R.color.white_FFFFFF),
                    textAlign = TextAlign.Center,
                ),
                modifier = Modifier
            )
        }
    }

현재 만든 화면에서 가장 복잡했던 코드였는데, State에 따라서 변화되어야 하는 것들이 많았기 때문에 좀 더 신경써서 구현했어야 했다. 다만, 잘 짠 코드라고 생각하진 않아서 아쉬웠지만.. 좀 더 살펴봐서 개선시켜나가고 싶다.
Jetpack Compose에서 데이터의 상태관리는 Recomposition 될 때에 따라 잘 관리되어야 한다. 이때 remember를 사용하면 특정 상태 변경으로 인해 Recomposition이 되더라도 데이터를 보존시켜줄 수 있다.

하지만, Configuration이 변경되는 등의 상황에서는 보존을 보장하지 못하므로, 이때는 자동으로 Bundle에 값을 저장할 수 있는 rememberSaveable을 사용해야 한다.

이 rememberSaveable은 직접 Saver를 구현해 저장하는 조건등의 로직을 커스텀할 수 있도록 구현되어 있다.
해당 함수는 LazyColumn 내부에서 호출되고 있다. LazyColumn 자체가 RecyclerView처럼 화면에 보여지는 Composable만을 표시하는 scrollable한 Column이다. 그렇기 때문에, 화면 로딩 시간을 최적화 시킬 수 있다는 장점을 가지고 있다.

하지만, 이러한 이유인 탓인지, LazyColumn 내부에서 remember을 이용해 특정값을 유지시키려고 하더라도 스크롤을 내리는 등의 동작으로 composable이 보여지지 않으면 특정값 유지가 되지 않는 문제가 발생한다. 스크롤을 내리면서 composable이 destroy되고 그에따라 dispose됨에 따라 값이 유지되지 않고 리셋되는 것으로 보인다.
따라서, 화면을 내리더라도 상태를 유지하기 위해서는, LazyColumn 바깥 영역에서 remember을 사용하거나, Bundle에 값이 저장되는 rememberSaveable을 사용해야 한다.

위와 같은 화면에서는 LazyColumn 하나하나 상태를 기억해줬어야 했으며, Decomposition이 된 후에 다시 composition이 이루어지더라도 상태가 유지되었어야 했다.

기본적으로 처음 화면이 보여질 때 최초의 팔로우 여부를 설정한 후, 유저가 팔로우를 하거나 팔로우를 취소하는 상태를 저장하고 스크롤하더라도 그 모습이 유지되어야하기 때문이다. 따라서 이경우에 followState에 대해 rememberSaveable을 사용하였다.
다만, followInteractionSource의 경우 버튼이 press되고 있는지 여부에 대해 판단하기 위함이였기 때문에 Decomposition되고 다시 initial Composition되었을 때 초기화되더라도 상관없었기 때문에 remember로 작성해주었다.

[Review] Google I/O Extended Seoul 2023 참석 후기

Hodie! — Mon, 31 Jul 2023 20:31:00 +0900

Google I/O Extended Seoul 2023 참석 후기

꽤 오랜만에 안드로이드 내용이 담긴 오프라인 행사에 참석하였다.

이번에 참석한 Google I/O Extended Seoul 2023는 7월 29일 코엑스에서 13시부터 17시까지 진행되었는데, 시간대 별로 1개 내지 2개의 세션이 진행되었고 나는 그 중에 주로 Track 1 세션을 들었다.

더 기억이 나지 않기전에, 각 발표자분들이 발표한 내용들 중 새롭게 알게되거나 깊이 공감해서 기억에 남았던 부분들을 중심으로 작성해 놓으려고 한다.

참 석 세션 요약

이번 행사에서 참석해서 들었던 세션은 다음과 같다.

1. What’s New in Android Development Tools - 노현석 (카카오뱅크)

2. Dagget Hilt로 의존성 주입하기 - 안성용 (네이버웹툰)

3. Flutter에 Clean Architecture을 얹어보자 - 양수장 (GDG Songdo / Flutter Songdo)

4. 일 잘하는 개발자는 회사에서 어떻게 일할까? - 박상권 (헤이딜러)

참석 세션

1. What's New in Android Development Tools

세션 소개

Android 앱 개발자를 위한 최신 Android Studio의 새로운 기능을 소개합니다. Android Studio Flamingo/Giraffe/Hedgehog 버전을 다룹니다.

기억에 남았던 부분

해당 세션은 13시 20분 부터 시작했었는데... 다소 늦게 참석한 관계로 중간부분부터 들었다.
그럼에도 불구하고, Android Studio의 업데이트 된 기능에 대해 잘 모르고 있던 부분이 많았다고 느껴졌고, 생각보다 유용하게 사용할 수 있는 기능들을 잘 소개해주셔서 기억에 많이 남는 세션이었다.
특히, 프로젝트를 진행하다보면 개발환경을 한번 세팅하고 나면 최대한 개발 외적인 사이드 이펙트를 줄이고자 사용하고 있는 개발 환경을 그대로 유지하는 경우가 많고 그 과정에서 Android Studio의 업데이트를 뒤로 미루는 경우도 많은데 이번 세션을 통해서 Android Studio 버전을 한 번 업데이트 해봐도 괜찮을 것 같다고 생각했다.

Network Inspector interception
- 통신을 하는 앱이라면 성능 체크시에 Network Inspector를 사용해본 경험이 있을 것이다. 그때, 보통은 Response 내용과 주고받는 트래픽 등에 대해서 Real-time으로 볼 수 있었을 것이다.
- 여기까지는 Network logging interceptor를 보통 사용하므로 별로 흥미롭지 않을수도 있지만, Android Studio Flamingo 버전부터 incoming connection에 대해 custom-rule을 적용할 수 있고 이를 통해 앱에서 실제로 보여지는 응답값을 보여줄 수 있다는 것이 기억에 남는 점이었다.
- 기억에 남았던 이유는, 기존에 네트워크 통신시에 Response 값을 변경하기 위해서는 서버의 도움을 받거나, 직접 테스트 관련 내용들을 만들어서 다시 빌드했어야 했는데, 이를 거치지 않고 Rule을 적용하면 실시간으로 Network Response/header 등을 변경할 수 있다는 것이었다.
- 이를 통해 Empty List가 오는 상황과 null이 오는 상황등 처럼 오류를 발생시킬 수 있는 엣지케이스들을 직접 확인하고자 할 떄 유용하게 사용할 수 있을 것으로 생각된다.
- 이에 대해 소개한 내용을 따로 검색한 결과, 나중에 사용할 때 다시 알아보도록 해야겠다.
  Applying Rules for Network Inspector in Android Studio Flamingo [Link]
Gradle Version Catalogs
- 기존 Dependency를 관리하는 방법에는 여러가지 방식이 있었다.
- 이때 Version Catalog를 통해 관리하게 되면 버전을 깔끔하게 관리할 수 있고, bundle형태로 묶어서 관리할 수도 있다!
Compose Animation Preview
- 기존에도 Compose를 이용한 Animation에 대한 Preview가 가능했는데, 이번에 이것이 좀 더 개선이 되었다고 한다
- 상태를 설정해서 애니메이션 디버깅도 가능하고, 여러 부분에서 개선이 이루어지고 있다고 한다
Android Studio Bot
- Android Studio내에서 사용할 수 있는 프로그래밍 보조 AI Studio Bot이 발표되었다고 한다.
- Coding Assistant인 만큼, IDE내에서 도구창으로 통합되어 사용할 수 있는 것을 볼 수 있었는데, 한국어와 영어로 물어봤을 때 발표당시에 보인 자료로는 영어가 좀 더 정확하게 대답해 주는 것 같았다. 특히, 어떤 코드에 대해서 주석을 다는 것을 요구하는 모습을 보여주셨는데, 코딩을 할 때 보조 도구로 잘 사용할 수 있지 않을까? 하는 예시였던 것 같다 (다른 사람의 코드를 읽는 것은 힘든 일이니까...)
- 다만, 아직까지는 실험버전이라 부정확한 모습을 많이 보인다고 한다.
- 거기다, 미국 국내에서만 이용가능하도록 제한이 걸려있기 때문에, 사용하려면 VPN을 거쳐서 사용해볼 수 있을 것 같다.
- 그럼에도 IDE에 이러한 것들을 통합시키려는 것만으로도 의미가 있다고 생각했다!

2. Dagger Hilt로 의존성 주입하기

세션 소개

Dagger Hilt를 이용하여 의존성을 주입하는 방법을 알아보고, 실제 경험을 기반으로 권장할 만한 UseCase를 공유합니다.

Dagger Hilt로 의존성 주입하기

2023년 7월 29일 (토) I/O Extended 2023 Seoul 행사에서의 발표자료입니다. https://festa.io/events/3683

speakerdeck.com

기억에 남았던 부분

기존에 Hilt를 많이 사용했었기 때문에 어느정도 익숙한 상태에서 들을 수 있었다!
발표는 특정 상황에서 Hilt를 활용하는 방법으로 케이스 중심으로 진행되었다. Hilt을 어떻게 하면 활용하는게 잘 활용하는 것인지 다시 생각해보게 되는 계기가 되었다. 여전히 Hilt는 어려운것 같다
다행히 발표시간이 짧았던 탓인지 코드부분이 빠르게 넘어가서 아쉬웠는데, 발표자료를 올려주신 곳이 있어서 참고할 수 있을 것 같다!

3. Flutter에 Clean Architecture을 얹어보자

세션 소개

플러터로 서비스를 런칭하면서 적용했던 아키텍처 구조와 사용한 라이브러리에 대해 발표를 진행하며, 실제 동작가능한 예제와 간단한 유닛테스트를 함께 공유합니다. 해당 예제를 통해 Flutter에서 Clean Architecture의 구현 방법을 실제로 살펴보고, 간단한 유닛 테스트로 앱을 더욱 견고하게 만드는 방법을 다룹니다.

기억에 남았던 부분

기존에 Flutter 개발을.. 해본적이 없었기 때문에, 걱정은 조금 했지만 다행히 발표자분도 그러한 부분을 어느정도 이해하신건지 Android 네이티브만 개발한 입장에서도 대략적으로 이해갈 수 있게 설명해주셨다고 느꼈다.
특히 마지막에 Folder Structure에 대해서 소개해주셨는데, 이부분이 가장 기억에 남았고 Clean Architecture에 대해서 짚어주셔서 이에 대해 다시 한번 되새기는 계기가 되어서 좋았다..

4. 일 잘하는 개발자는 회사에서 어떻게 일할까?

세션 소개

‘일을 잘하는 개발자’란 어떤 사람들을 말하는걸까요? 단순히 기술적인 코딩을 잘하는 사람이 회사에서 ‘일을 잘한다' 라고 평가 받을까요? ‘일을 잘하는 개발자'들이 회사에서 어떤 방식으로 일하는지 공유합니다.

기억에 남았던 부분

많은 공감을 하게되는 세션이였고, 실제로 주변의 다른 사람들도 발표를 들으시면서 많이 공감하셨던것 같다.
"일 잘하는 개발자는 어떻게 일할까?"에 대해 발표자분이 개인적으로 생각하신 부분에 대해 맨 처음에 목차로 13개를 소개해주셨는데, 하나하나 다 맞는 말이라 생각했다. ~~(실천하기가...어려울 때가 있을 뿐...)~~
특히 1번째로 "암묵지 없애기"를 말씀하셨었는데, 너무 공감됐던 부분이었다. 동시에 없어질래야 없어지기 어려운 부분이라 어떻게 해결해야 하는지 다시 한 번 되새기는 계기가 되었다. 같은 프로젝트를 진행해도 동상이몽을 꾸는 경우가 너무 많은데 이 부분에 대해서 어떻게 해결해 나가고 있는 지에 대해 사례로 보여주셔서 좀 더 참고하는 계기가 되었고 너무 좋았다.
그외의 "최적의 피쳐 개발방향 찾기"중 완성도를 5%를 떨어트리더라도 개발시간을 80%이상 단축할 수 있다면 제안하는 것이 중요하다는 부분에서 기존의 기획을 무조건적으로 지키려고 했던 지난 날들이 스쳐지나갔다... 자식 같은 코드라고 집착하지 않는게 중요한데.. 개발하다보면 자꾸 그 부분을 놓쳐서 아쉬웠던 만큼 다시 한 번 생각하는 계기가 되었다..
이외에도 회고의 중요성 등을 이야기 해주셨는데, 하나하나 마다 과거의 내 모습이 스쳐지나가면서 공감되면서도 다시 한 번 반성하게 되는 계기가 되었던 세션이였다..

전체 후기

세션 발표 내용중에 알고있어서 공감되거나, 다시 한 번 생각하는 부분들도 있고, 미처 인지하지 못해서 놓쳤던 부분들도 있었는데 그러한 것들을 모두 느낄 수 있는 행사였어서 참석 여부를 고민했던 행사였는데 가길 잘했다고 생각했다!
특히, 이번에 발표된 내용들을 보면 내용에는 잘 안드러났지만, Jetpack Compose과 엮어서 설명하는 부분이 많았는데 확실히 Compose를 처음 알게되었을 때보다 Compose로 대세가 옮겨가고 있는건가? 싶은 생각은 많이 들었던 행사였다. XML을 레이아웃을 만드는데 주로 사용하고 있지만, XML은 언제까지 갈 수 있을까? ~~(Legacy가 있는한..?)~~ Compose에 대해 좀 더 배우고 진행하는 프로젝트에 한 번 사용해봐야겠다는 생각이 많이 들었다.

[Android/Refactoring] Memory Leak - 3. View's Reference는 Memory Leak의 대상일까?

Hodie! — Fri, 28 Jul 2023 07:59:39 +0900

View's Reference는 Memory Leak의 대상일까?

이어지는 글

2023.07.21 - Memory Leak - 1. 안드로이드 앱에서의 메모리 누수 찾기

2023.07.25 - Memory Leak - 2. 자주 발생하는 안드로이드 메모리 누수 방지하기

배경

지난번까지 메모리 누수를 자주 일으키는 요소들에 대해 방지하는 방법에 대해 알아보았다. 그러던 중, View를 참조하는 변수들이 메모리 누수를 일으키는 원인으로 Leakcanary에서 자주 식별되어, View의 요소를 참조하는 것이 메모리 누수를 일으키는 원인이 될 수 있는 지에 대해 알아보고자 한다.
- Fragment에서 myTextView = view.findViewById(R.id.myTextViewId) 혹은 myTextView = binding.myTextViewId 처럼 initialize해준 뒤, View가 Destroy 되는 경우 해당 variable에 대해 null 처리를 해주지 않으면 Leak이 실제로 발생하는 지에 대한 여부를 알아보고자 한다.

View’s Reference에 대해 Null 처리하는 예시

AOSP에서의 코드

실제로 AOSP(Android Open Source Project)에서의 ListFragment[Link] and PreferenceFragment[Link] 의 예시코드를 보면 ListView인 mList에 대해 mList = null를 Destory 하는 경우에 호출해 null 처리 해주는 것을 볼 수 있다.
그렇다면 실제로 View를 참조하는 것이 메모리 누수를 일으킬 수 있을 확률이 있어 그러는 것일까?
이와 같은 의문을 나만 가진게 아니였기에, StackOverflow를 통해 이러한 질문을 가진 사람을 어렵지 않게 찾아볼 수 있었고, 이를 참고했다.

Memory Leak 발생의 가정

Fragment A가 Instance field로, 해당 View의 childView에 대한 reference가 있다고 가정한다.
Fragment A에서 Fragment B로의 navigation은 특정 FragmentTransaction을 사용한 FragmentManager를 통해 이루어지게 된다.
Transaction의 Type에 따라, Manager는 View만 kill하고, Fragment A의 instance는 유지할 수 있다 (lifecycle 부분에서 “fragment는 Backstack에서 layout으로 돌아간다”를 참조)
Fragment B에서 Fragment A로 다시 이동하는 경우, Fragment A의 instance의 previous instance가 Front로 이동하지만, 새로운 View가 Created된다.
- 이때, 문제는 만약 lateinit property에서 view를 instance로 유지하고, reference를 삭제하지 않으면, view가 완전히 destroyed되지 않아 Memory Leak이 발생할수 있다

→ 위와 같은 단계를 생각해보면, Fragment간 이동 중에 Memory Leak이 발생할 것이라고 예상할 수 있다.

가정에 대한 증명

사고실험

먼저 단계별로, 메모리가 어떻게 할당및 해제되는 지에 대해 단계적으로 살펴보자

Fragment A를 Open할 때
- 해당 Content/root View와 Textview가 메모리에 할당된다.
Fragment B로 Naivgate할 때
- Fragment A의 onDestroyView()가 호출되지만, Fragment A의 View는 destroyed되지 않는다.
  - 왜냐하면 TextView가 Fragment A에 대한 Strong reference를 유지하고 있고, Fragment A는 TextView에 대한 Strong Reference를 유지하고 있기 때문이다
  - (the TextView holds a strong reference to it and FragmentA holds a strong reference to TextView)
Fragment B에서 Fragment A로 Navigate Back 하는 경우
- View와 TextView의 이전 할당(previous allocation)이 cleared된다.
- 또한, 동시에 onCreateView()가 호출될 때 새로운 할당(new allocation)을 받게 된다.
Fragment A에서 Back을 클릭하는 경우
- 새로운 할당이 clear 된다.

사고실험의 결론

위의 단계를 살펴 봤을 때 2단계에서 View의 retain memory가 원래대로 확보되지 않아 Memory Leak이 발생하는 것을 볼 수 있다.
반면 3단계부턴 유저가 Fragment로 돌아오자마자 메모리가 복구되는 것을 확인할 수 있다.
따라서, FragmentManager가 Fragment를 다시 가져올 때 까지 Memory Leak이 지속됨을 알 수 있다.

실제 수행을 통한 증명: Statical Analysis (Heap Memory 이용)

실제로 Button이 있는 Activity와 Fragments에 대한 container인 FrameLayer가 있다고 하고 이는 다음과 같이 생성한다.
- Button을 누르면 Container가 Fragment A로 바뀐다.
- Fragment A에는 Container를 Fragment B로 replace하는 Button이 있다
- Fragment B는 Instance Field로 Fragment에 저장하는 TextView가 있다

출처: https://stackoverflow.com/a/58248851

위의 Report는 가정을 한 Application을 실행해 Operation을 실행했을 때 관찰되는 Heap Dump와 이외의 정보들이다.
위의 리포트는 아래의 Operation을 실행하였을 때 나온 결과이다.
1. Opened the app: Activity가 보인다.
2. Pressed the Button in the Activity: FragmentA visible
3. Pressed the Button in FragmentA: FragmentB visible 되고, FragmentA onDestroyView()
4. Pressed the Button in the Activity: FragmentA의 2번째 instance가 Visible되고, FragmentB onDstroyView()
  (위에서 4단계로 수행했던 예시의 2번째 단계와 동일하다. Fragment B가 A 역할을 하고, Fragment A의 2번째 instance가 B 역할을 한다는 점을 제외하곤)
5. Pressed the Button in the 2nd instance FragmentA: FragmentB의 2번째 instance가 visible and FragmentA의 2번째 instance가 onDestroyView().
6. Pressed Back Button: FragmentA의 2번째 instance가 visible and FragmentB의 2번째 instance가 onDetach()
7. Pressed Back Button: FragmentB의 1번째 instance가 visible and FragmentA의 2번째 instance가 onDetach()
8. Pressed Back Button: FragmentA의 1번째 instance가 visible and FragmentB의 1번째 instance가 onDetach()
9. Pressed Back Button: FragmentA의 1번째 instance가 onDetach()
10. Pressed Back Button: 앱 종료

Report 분석

Report를 봤을 때, 1단계에서 앱이 닫힐 때 까지 각각의 view와 모든 view는 앱이 닫힐 때까지 살아있다.
2단계에서는 Fragment A의 View (e.g. FrameLayout과 child, Button 등)이 할당되어 있으며, 예상한대로 3단계에서 모두 clear 되었다.
3단계에서는, Fragment B의 View (e.g. FrameLayout과 그 child, TextView 등)이 할당되어 있지만, 4단계에서는 삭제하지 않아 메모리 누수가 발생했다.
그러나, 7단계에서 View가 다시 created 되고 새롭게 create된 view에 할당될 때, clear된다.
반면에 5단계에서 생성된 View는 6단계에서 삭제돼, 메모리 누수가 발생하지 않았다. 이는, fragment가 detach되어, fragment가 cleard up하는 것을 prevent하지 않았기 때문이다.

실제 수행의 결과를 통한 결론

이러한 과정을 통해 유저가 fragment로 돌아갈 때 까지, fragment에 view를 저장함으로써 leak이 발생한다는 것을 observe할 수 있었다.
Fragment가 다시 돌아가는 경우 (e.g. onCreatedView()가 호출되는 등)에 leak은 다시 복구(recover)된다.
반면에 fragment가 top에 있고 뒤로가기만 가능한 경우에는 어떠한 leak도 일어나지 않는다.

결론

위와 같이 단계적인 증명과 이를 바탕으로 실제로 앱을 만들어 실행해보았을 때 View’s Reference들은 다른 Fragment로 이동했을 때 Leak을 발생시키지만, 해당 Fragment로 돌아갔을 때 다시 Recover되므로 현재까지 이에 대해 알지 못했더라도 큰 문제가 되지 않았던 것으로 판단된다.
따라서, View’s Reference의 경우 아래와 같이 유의해서 사용하면 될 듯 하다.
1. Fragment에서 Forward transaction이 없는 경우, View는 onDetach()에서 clear되므로, Strong reference로 View를 저장하는 것에 아무런 문제가 없다.
2. 만약, forward Transaction이 존재하는 경우, view의 weak Reference를 저장함으로써, onDestroyView()에서 clear되도록 할 수 있다.
  - 혹은 개인적으로 Destroy하는 경우에 해당 reference를 null처리 함으로써 leak이 발생하지 않도록 할 수 있을 것이라 생각한다.

참고

Keeping a reference to a View in a Fragment causes memory leaks?

Somebody told me the following, but I am a bit perplexed. Please, would you be able to confirm or dispute it? (the Fragment is not retained via setRetainInstance() At the moment it is a common

stackoverflow.com

[Android/Refactoring] Memory Leak - 2. 자주 발생하는 안드로이드 메모리 누수 방지하기

Hodie! — Tue, 25 Jul 2023 07:08:32 +0900

[Android/Refactoring] Memory Leak - 2. 자주 발생하는 안드로이드 메모리 누수 방지하기

이어지는 글

2023.07.21 - [IT/Android] - [Android/Refactoring] Memory Leak - 1. 안드로이드 앱에서의 메모리 누수 찾기

[Android/Refactoring] Memory Leak - 1. 안드로이드 앱에서의 메모리 누수 찾기

배경 개발을 해놓고 나니 메모리가 이미지를 로딩하는 등 앱을 지속적으로 실행시키면서 메모리가 슬금슬금 증가하는 모습을 안드로이드 프로파일러를 통해서 발견했다. 앱을 사용하면서 지속

hodie.tistory.com

Static References

Activities, Fragments, views, context 에 대해 static references를 과도하게 사용하지 않아야 한다.
Static 객체는 Application이 실행되는 동안 살아있지만, View(또는 Context)에 대한 Static Reference는 제 때 지워지지 않을 확률이 높기 때문이다.
Application이 Class를 JVM에 로드하면 해당 static member들이 메모리 할당되고 증가된 lifespan에 의해 Class가 garbage collection의 대상이 될 때 까지 메모리에 남아있게 된다.

예시

Static variable인 TextView를 선언하고, 다음과 같이 TextView의 값을 업데이트하는 클래스가 있고 이를 onCreate() 메소드에서 실행한다고 하자

private static TextView textView;

private void changeText() {
    textView = (TextView) findViewById(R.id.testview);
    textView.setText("Update Hello World greetings!");
}

해당 Static View는 changeText() 클래스를 실행하는 동안 Activity의 일부분이다. 따라서, 특정 Activity에 대한 static reference가 hold된다. 해당 Static View는 Activity의 Lifecycle 이후에도 실행되게 된다.
따라서, 이경우 여전히 Activity에 대한 참조를 view가 가지고 있기 때문에 Activity가 garbage collected되지 않는다. 이는 곧 메모리 누수가 발생함을 의미한다.
Static은 주어진 클래스에서 동일한 variable를 모든 객체에서 사용하기 위해 사용된다. 따라서, View가 statically 유지 되어야만 하는 경우에는 onDestroy()에서 해당 reference를 null 처리하면 메모리 누수를 막을 수 있다.

@Override
protected void onDestroy() {
  super.onDestroy();
  textView = null;
}

위처럼 Destroy할 때 null 처리하여 메모리 누수를 막을 수도 있지만 가장 좋은 것은, 가능한 static keyword를 사용하지 않고 선언하는 것이다.

예시 2 (Static Context)

private static Context mContext;
...
.. onCreate() {
    mContext = this;
}

위처럼 onCreate() 메소드 안에서 Activity Context를 Static reference하려는 경우 acitivty에 대한 leak을 발생시킬 수 있으며, 안드로이드 스튜디오도 이를 경고할 것이다.
그러나, static field에 두어야만 한다면, virtual/weak reference를 사용해 hold할 수 있다.

private static WeakReference<Context> mContext;

따라서 onCreate() 메소드 내부에서
```
mContext = new WeakReference<> (this);
```
를 사용할 수 있고, onDestroy() 메소드 내부에서 null 처리해 사용할 수 있다.

mContext = new WeakReference<> (this);

Binding leaks

ViewBinding을 사용하는 경우에 onDestroyView() lifecycle 메소드에서 binding = null 처리한다.

Context

Context는 Application에서 다른 components간에 communicate가 가능하도록 allow해준다.
이를 통해, 새로운 객체를 만들거나, 리소스(layout, image, string 등)에 접근할 수 있도록 해주며, activity, database와 기기의 내부 저장소를 launch할 수 있도록 해준다.
따라서 Context에 Access할 수 있는 방법에도 여러 방법이 있는데, this 와 getApplicationContext가 있다.
Context는 다른 component에 대한 참조를 유지한다. 따라서, context를 사용하는 방법은 application에서 중요하다.

예시

public class SingletonClass {

    private static SingletonClass singletonClassInstance;

    private Context context;

    private SingletonClass(Context context){
        this.context = context;
    }

    public static void singletonClassInstance(Context context){

        if (singletonClassInstance == null){
            singletonClassInstance = new SingletonClass(context);

        }
    }
}

해당 예시에서, SingletonClass.singletonClassInstance(this)를 사용해 MainActivity의 SingletonClass 클래스에 접근하게 된다.
- 이때, SingletonClass 데이터를 가져오기 위해, parameter this를 사용해 해당 클래스의 context를 얻게 된다.
이 경우, context는 Java 클래스이다. 이는, Application components나 다른 OS feature에 대한 정보를 얻기 위한 방법을 제공한다.
그러나, 이처럼 this context를 사용해 MainActivity에서 SingletonClass를 exceuting하면 activity가 누수(leak)될 수 있다.

Context의 사용법

Context는 전체 Application의 lifecycle에 묶여있다. 따라서, Context를 잘못 사용하는 경우 메모리 누수로 이어질 수 있는 것이다.
- 따라서, 다른 Context를 사용하는 경우 위치와 사용시기를 확인해야 한다.
예를 들어, getApplicationContext는 객체가 Activity Lifecycle을 넘어서까지 살아있어야 하는 경우 사용할 수 있다. 그러나, UI와 관련된 component들에선 사용할 수 없다.
- Singleton이 있는 경우, 항상 ApplicationContext를 사용해야 한다는 것이다.
또한 this는 객체가 activity lifecycle의 과거에 살아 있지 않은 경우에만 사용할 수 있다. 다만, UI component들을 참조하는데는 사용 할 수 있다.
- UI component들은 장시간 실행되는 작업이 아니고, activity lifecycle을 초과해 살아있을 수 없다.
- this Context는 XML 레이아웃이나, dialogue, getting resources, starting activity를 하는 여러 operation에 사용될 수 있다.

예시 2 (ApplicationContext - Singleton)

SingletonClass를 사용하는 경우, Context-implementing 객체는 1개만 있을 수 있으므로, getApplicationContext를 사용하는 것이 적절하다.
getApplicationContext는 singleton Context이다. 이는, 얼마나 많이 context에 접근하는 지 중요하게 생각하지 않으며 항상 같은 instance를 얻게 된다.
따라서 해당 instance는 새로운 context를 만들지 않는다. 따라서 SingletonClass를 사용하는 경우 아래와 같이 사용하면 memory leak을 방지할 수 있다.

SingletonClass.singletonClassInstance(getApplicationContext());

Fragment Lifecycle vs ViewLifecycleOwner Lifecycle

Fragment에서 LiveData를 observing하는 경우, `this` 대신 `viewLifecycleOwner` 전달

viewLifecycleOwner은 UI에 있는 한(onCreateVew() ~ onDestroyView()), fragment에 묶여있는데(tied to fragment UI) 반해
반면에 this는 fragment의 전체 lifecycle (onCreate() ~ onDestroy())에 묶여있기 때문에 아래의 그림처럼 viewLifecycleOwner보다 this를 사용하는 경우 더 오랜 시간 observe하게 된다.
출처: https://write.agrevolution.in/memory-leaks-in-android-apps-45a27c6ac35d

이것은 곧 this를 lifecycle owner로 전달(pass)하는 경우 메모리 누수를 일으키는 원인이 될 수 있음을 의미한다.
예를 들어, view가 destroyed되었으나, (onDestroyView() is called), fragment는 destroy되지 않은 경우 (onDestroy() is not called), LiveData 객체의 모든 변경사항이 여전히 observed되기 때문에 Crush가 발생할 수 있다.

FragmentStateAdapter Constructor에서 lifecycle 객체 대신 viewLifecycleOwner.lifecycle 전달

위와 비슷한 이유로, FragmentStateAdapter Constructor에서 Adapter의 범위를 Fragment가 아닌, Fragment의 View의 lifecycle로 Scope를 지정해야 하기 때문에 viewLifecycleOwner의 Lifecycle을 전달해야 한다.
- FragmentPagerStateAdapter(fragment) 혹은 FragmentPagerStateAdapter(fragmentActivity)에서 FragmentPagerStateAdapter(fragmentManger, lifecycle)로 변경한다
- 1번째와 2번째는 fragmentActivity.getLifecycle()과 fragment.getLifecycle()를 이용해 LifecycleEvent를 관찰한다. 따라서, previous memory leak이 일어나게 된다.
- 3번째를 사용해 fragment의 viewLifecycleOwner를 2번째 인자로 넣어줘 사용할 수 있다.
- 위의 식으로 인해, View가 destryoed되고 나서, 다른 fragment로 이동한 후, onDetach를 calling할 때 까지 response를 받는다.
- viewModel.orders.collectLatest { adapter?.submitData(it) }
- 이때 위와 같은 식이 있다면, fragment의 view가 destroy됐음에도 불구하고, recyclerview에 액세스하려고할 것이며 이는, adapter에 대한 참조를 가지고 있으면서 memory leak을 일으키는 원인이 된다.

Threaded Code

Threaded code는 메모리 누수를 일으킬 가능성이 매우 높다. Thread들은 실행 logic을 여러개의 동시 tasks로 decompose한다.
안드로이드는 스레드를 사용해, 동시에 실행되는 여러 task들을 처리한다. 스레드에는 고유한 실행 환경이 없기 때문에, 부모 task로부터 실행 환경을 상속한다. 따라서 스레드는 단일 프로세스 범위 내에서 서로 데이터를 쉽게 통신하고 교환할 수 있다.

예시

Thread Task를 초기화하고, threaded task를 set up한 뒤, onCreate() 메소드에서 task를 실행한다

private final ThreadedTask thread = new ThreadedTask();

  private class ThreadedTask extends Thread {
      @Override
      public void run() {
          // Run the ThreadedTask for some time
          SystemClock.sleep(1000 * 20);
      }
  }

  thread.start();

Thread Task가 시작되면 실행이 완료될 때까지 시간이 걸리게 된다.

만약, task 실행이 끝나기 이전에 activity를 닫게되면, 실행되고 있는 ThreadedTask는 Activity가 garbage collected되는 것을 막을 것이다. Background에서 발생하는 view, activity또는 context에 대한 참조를 가지고 있는 것은 메모리 누수를 발생할 확률이 있다.

이러한 누수를 해결하기 위해 static class를 사용할 수 있다. static class는 static class를 둘러싼 activity class에 대한 참조를 가지고 있지 않기 때문이다.

  // make ThreadedTask static to remove reference to the containing activity
  private static class ThreadedTask extends Thread {
      @Override
      public void run() {
          // check if the thread is interrupted
          while (!isInterrupted()) {
              // Run the ThreadedTask for some time
              SystemClock.sleep(1000 * 20);
          }
      }
  }

또는 Activity가 destroy되는 onDestroy()에서 해당 스레드를 중단시킬수 있다.

  // If the activity is destroyed, isInterrupted() will return true, and the thread will be stopped:

  @Override
  protected void onDestroy() {
      super.onDestroy();
      //kill the thread in activity onDestroy
      thread.interrupt();
  }

Handler Threads

Handler는 Java background Thread이다. 이것은 background에서 계속 실행되며, Appplication이 스레드 실행을 종료할 때 까지 순차적으로 다른 task들을 실행한다.
Handler는 주로 Application UI와 통신하고, 실행 스레드를 기반으로 다른 component들을 업데이트 한다.
- 가장 대표적인 handler application 예시가 progress bar
Handler는 메시지큐를 만드는데 loopers를 사용하기에, 이를 이용해 메시지를 예약하고, 다른 반복 tasks를 기반으로 UI를 업데이트 할 수 있다.
다만, Handler는 스레드이며, 여러번 반복해 실행되기 때문에, 어떻게 사용하느냐에 따라 메모리 누수가 발생할 가능성이 존재한다

예시

handler task를 선언하고, onCreate() 메소드에서 task를 실행한다.

handler.postDelayed(new Runnable() {
   @Override
   public void run() {
      textView.setText("Handler execution done");
   }
   // delay its execution.
 }, 1000 * 10);

private final Handler handler = new Handler(Looper.getMainLooper());

해당 handler가 실행되었을 때, 해당 handler는 activity에 callback을 register한다. 이것은 activity가 garbage collecting되는 것을 막고, 이는 곧 메모리 누수를 일으키게 된다.

@Override
protected void onDestroy() {
   super.onDestroy();
   //remove the handler references and callbacks.
   handler.removeCallbacksAndMessages(null);
}

따라서, 메모리 누수를 해결하기 위해, 모든 callback들을 삭제해야 한다.
- 스레드는 단일 프로세스 범위 내에서 서로 데이터를 통신하고 교환하기 때문에, onDestroy() 메소드가 호출될 때 관련 callback을 제거해야 한다.
- 이렇게 하면 Handler references가 제거되고, 메모리 누수가 해결된다.
Application에서 스레드가 누수 될수 있는 가능성은 많다. 따라서 Threaded 실행이 잘 되도록 하려면, 스레드가 생성된 시점부터 제거된 시점까지 Thread Lifecycle이 완전히 실행될 수 있도록 해야 한다.
또한, inner class에서 outer(parent) class에 대한 모든 implicit references를 관찰해야 한다.

Viewpager

ViewPager를 사용하는 경우 관련된 누수를 방지하기 위해 onDestroyView() 메소드 에서 다음과 같이 처리해주어야 한다.
```
override fun onDestroyView() {
	super.onDestroyView()
	binding.apply {
		viewPager.adapter = null
		tabLayout.removeOnTabSelectedListener(tabSelectedListener)
	}
    _binding = null
    tabLayoutMediator?.detach()
    tabLayoutMediator = null
}
```

RecyclerView

RecyclerView를 사용하는 경우 onDestroyView() Lifecycle 메소드에서 RecyclerView 객체에 대한 참조를 holding하는 것을 방지하기 위해 RecyclerView.adapter = null 처리를 해줘야 한다.
RecyclerView가 onCreateView() 에서 만들어 진뒤 해당 RecyclerView는, RecyclerViewAdapter에 대한 reference를 hold하고 있게 된다. 만약 fragment가 adapter의 reference를 hold하게 된다면, 이것은 Adapter를 통해 직접 및 간접적으로 RecyclerView를 hold하게 된다.
- RecyclerView is created inside onCreateView(), and it holds a reference to RecyclerViewAdapter. If the fragment also holds the reference of the adapter, it holds RecyclerView both directly and indirectly through adapter.
onDestyoView()가 호출됐을 때, fragment는 RecyclerView에 대한 직접적인 reference는 해제할 수 있지만, 간접적인(indircet) reference는 해제할 수 없기 때문에, RecyclerView가 leak되게 된다.
만약 Fragment가 Adapter의 reference를 hold해야 하는 경우, reference를 null로 set해줘야 하고 이것이 onDestroyView에서 null로 set해주는 것이다.
출처: https://weidianhuang.medium.com/how-to-prevent-common-memory-leaks-inside-android-fragment-c243ed7074d6
- null로 Set 해줌에 따라, reference를 break 해줄수 있다.

이를 통해서, RecyclerView → Adapter로의 reference를 break해주는 것을 이해할 수 있는 있지만, Adapter → RecyclerView의 reference를 break하는 것에 대해선 부족한 설명일 수 있다. 이는 Android RecyclerView source code를 통해 확인할 수 있다.
```
public void setAdapter(@Nullable Adapter adapter) {
	// bail out if layout is frozen
    setLayoutFrozen(false);
    setAdapterInternal(adapter, false, true);
    processDataSetCompletelyChanged(false);
    requestLayout();
}
```
- 위에서 setAdapterInternal를 호출하는 것을 알 수 있다.
```
private void setAdapterInternal(@Nullable Adapter adapter, 
	boolean compatibleWithPrevious,
	boolean removeAndRecycleViews
) {
	if (mAdapter != null) {
    mAdapter.unregisterAdapterDataObserver(mObserver);
    mAdapter.onDetachedFromRecyclerView(this);
    }
    ......
    final Adapter oldAdapter = mAdapter;
    mAdapter = adapter;
    ......
}
```
  - 해당 메소드에서 mAdapter는 previous reference이고, new reference가 업데이트 되기 이전에, 이것은 unregisterAdapterDataObserver를 호출해 adapter 내부의 observable한 항목을 제거하도록 한다.
    → 이를 통해 Adapter에서 Adapter → recyclerView의 reference가 break됨을 알 수 있다.
Destroy하는 경우에 null 처리하는 것이 싫다면, RecyclerViewAdapter의 reference를 Fragment에서 유지하지 않고, 항상 recyclerView.adapter를 이용해 RecyclerViewAdapter에 acces 하는 것도 하나의 방법이다.

SwipeRefreshLayout

SwipeRefreshLayout의 경우 라이브러리 자체적으로 Leak을 가지고 있는 것이 Google Issue Tracker에서도 이미 보고되었다. 문제는 여전히 고쳐지지 않고 있다는 보고가 지속적으로 올라오고 있기 때문에 이에 대한 대비를 해둘 필요가 있다고 판단했다.
이를 위해 onResume ~ onPause 동안만 사용할 수 있도록 코드 내부에서 자체적으로 enable를 true/false 처리 해줄필요가 있다.
In OnResume
```
  swipeRefresh.isEnabled = false
```
In onPause
```
swipeRefresh.isEnabled = true
```

기타

모든 listeners, broadcast receiver 등에 대해 적절한 lifecycle 메소드에서 리소스 누수를 방지하기 위해 unregister 처리를 해줘야 한다.
- 예를 들어, onViewCreated()에서 receiver를 설정한 경우, onViewDestroyed()에서 unregister처리를 해줘야 한다.

[Android/Refactoring] Memory Leak - 1. 안드로이드 앱에서의 메모리 누수 찾기

Hodie! — Fri, 21 Jul 2023 07:47:35 +0900

배경

개발을 해놓고 나니 메모리가 이미지를 로딩하는 등 앱을 지속적으로 실행시키면서 메모리가 슬금슬금 증가하는 모습을 안드로이드 프로파일러를 통해서 발견했다.
앱을 사용하면서 지속적으로 새로운 것들을 사용하기 때문에 메모리가 증가하는 것은 어떻게 보면 당연하지만, 문제는 사용하지 않는 것들에 대해선 적절하게 GC가 수거해주어야 하고, 그에 따라 메모리가 줄어들고 난 뒤에 다시 늘어나는 경향을 보여야 하는데 메모리 사용량이 지속적으로 늘어나기만 하는 모습을 보였다.
이는 어디에선가 사용하지 않는 객체를 해제하지 않아 메모리를 지속적으로 차지하고 있는, 메모리 누수가 일어나고 있는 것으로 판단하였고 이를 개선하기 위해 메모리 누수에 대해 알아보고 개선하고자 하였다.
- 이러한 판단의 배경에는 저사양 기기로 테스트하는 경우에 OOM 에러로 앱이 종료되는 현상이 있었고 해당 현상은 객체의 참조로 인해 화면 종료시에도 GC가 제대로 되지 않으면서 계속적으로 Activity 객체들이 쌓이고 있다고 판단했기 때문이다.
- Activity의 멤버 변수가 다른 Class에 참조되어 메모리 해제가 되지 않으면, 그 Activity 까지도 메모리가 완전히 해제가 되지 않아서, 사용하면 할수록 메모리 사용량의 증가가 비대해지는 영향을 끼친다.

Memory Leak이란?

출처: https://write.agrevolution.in/memory-leaks-in-android-apps-45a27c6ac35d

메모리 누수는, Garbage Collector가 객체에 메모리를 할당하지만(allocate), 다시 해제(deallocate)하지 않는 경우에 발생한다.
즉, Garbage Collector 객체 할당해제에 실패하여 Application에서 해당 객체를 더 이상 필요로 하지 않는 경우에도 객체를 계속해서 사용함에 따라 비효율적인 메모리 사용을 초래하는 것을 메모리 누수 라고 한다.
이는 Garbage Collector가 해당 객체는 여전히 필요한 객체라고 생각하기 때문인데, 이는 다른 객체로 부터 참조되고 있다고 판단하기 때문에 필요한 객체라고 판단하는 것이다. 그러나, 해당 참조는 Cleared되었어야 한다는 점에서 정상적인 판단이라 보기 어렵다.
만약, 지속적으로 이러한 일이 일어난다면 Heap Memory를 지속적으로 사용할 것이고 기기는 한정된 메모리를 가지고 있고, 앱에 할당할 수 있는 메모리가 제한되어 있기 때문에 더이상 메모리를 할당하지 못해, 결국엔 앱이 Crash 날 것이다.
즉, 메모리 누수는 garbage collecting 될 대상에 참조가 포함된 객체가 있을 때 발생한다. 해당 객체의 Instance가 점점 더 많이 생성됨에 따라, 이전 Instance는 여전히 응용 프로그램의 메모리에 남아있게 된다.
메모리에 오래 머물게 되면, 결국 Application에 할당된 메모리가 모두 소모되고 유저에 Application의 poor memory performance를 알리고 앱이 crash가 나게 되는 것이다.

Memory Leak을 탐지하는 방법

안드로이드 스튜디오에선 기본적으로 Profiler를 통해 리소스의 사용량과 누수를 확인할 수 있고, Memory탭 에선 Leaks이 발생했음을 표시해주는 기능이 있기 떄문에 이를 통해 메모리 누수를 확인할 수 있다.
- 시스템의 메모리에 앱이 어떤 영향을 주고 있는 지에 더 자세히 알아볼 수 있다는 장점이 있지만… 추적하기 쉽지않다는 것이 가장 큰 단점이다.
이외에 안드로이드에서 좀 더 편리하게 메모리 누수를 탐지하기 위한 방법으로 LeakCanary를 사용할 수 있다.
Memory Heap 파일을 Dump뜬 뒤 MAT 를 이용해 하나하나 인스턴스 개수를 찾아가며 하는 방법이 있다.

Android Studio Profiler

Instance View에서 할당된 object의 detail 확인 가능 / 출처:  https://developer.android.com/studio/profile/memory-profiler

탐지 방법

앱 빌드후 앱이 실행되고 있는 상태에서, Android Studio IDE 하단에 보이는 Profiler 탭을 열어 Profiler를 연다
해당 탭에서 + 버튼을 눌러 새로운 세션을 추가한다. 이 때, 앱이 실행되고 있는 기기를 선택한 뒤, 생성한 Application Package를 선택한다.
해당 탭을 열어 실행되고 있는 앱을 디버깅하기 시작하면, Memory 부분에서 현재 메모리가 어느정도 사용되고 있는지 실시간으로 보이게 된다.
- Heap의 종류
  - default heap When no heap is specified by the system.
  - image heap The system boot image, containing classes that are preloaded during boot time. Allocations here are guaranteed to never move or go away.
  - zygote heap The copy-on-write heap where an app process is forked from in the Android system.
  - app heap The primary heap on which your app allocates memory.
  - JNI heap The heap that shows where Java Native Interface (JNI) references are allocated and released.
Memory 영역을 선택하게 되면, 메모리에 대한 자세한 내용을 확인할 수 있는데, 메모리 누수를 찾기위해서 휴지통 모양의 아이콘을 여러 번 클릭해 Force Garbage Collection을 수행한다.
- 이 동작후 GC로도 해제되지 않은 메모리를 검출할 수 있다.

출처:https://developer.android.com/studio/profile/memory-profiler

이후, capture heap dump를 선택후 Record를 클릭하면, Heap Dump와 함께 Leaks 항목을 통해 Memory Leak이 일어나고 있는 개수를 확인할 수 있다.
여기서 Leaks를 클릭하면, 메모리가 해제되지 않은 클래스를 보여준다.
- Leaks의 개수는 그 개수만큼 Memory Leak이 발생한 의미가 아닌, 반복 테스트한 횟수 만큼의 reference 숫자 만큼 보여지는 것이고, 만약 context가 해제되지 않고, 살아있다면 해당 reference까지 모두 잡히기 때문에 SupportRequestManagerFragment, ReportFragment까지 검출되게 된다.
중요한 것은 Application의 Class 중 1번째 항목부터 분석하는 것이다.
1번째 항목을 선택하고, 나오는 Instance List에서도 1번째 항목을 선택하면, Instance Detail 항목을 볼 수 있다. 여기서 References 탭을 클릭해, 1번째 항목을 선택하고 child로 타고 내려가다 보면, 의심스러운 변수명을 발견할 수 있다.
이제 여기서부터 발견해 나가는 것이 개발자의 역량이다. 1번째 reference child가 아니라면 다른 reference들을 찾아나가는 과정을 거치면서 어떤 원인으로 메모리 누수가 발생해냈는 지를 유추해 나가야 한다.

LeakCanary

탐지방법

내부적으로 LeakCanary가 하는 것은, 단순히 destroy된 Activity를 모니터링 하며, 5초동안 기다린 뒤에, Garbage Collection을 강제하는 것이다.
- LeakCanary는 destroyed object들의 weak reference들을 hold하기 위해 objectWatcher을 사용한다. AppWatcher는 더이상 필요하지 않은 object들을 watch한다. 만약, 해당 weak reference들이 5초 내에 clear되지 않는 다면, watched instance들은 retain되는 것으로 간주하고, leaking instance의 가능성이 있음을 표시한다
- Application이 실행되고 표시되는 동안 ObjectWatcher가 보유한 Instance retained object의 개수가 5개에 도달하거나 개발자의 조작을 통해, LeakCanary는 Java Heap을 파일 시스템에 저장된 .hprof 파일에 Dump한다. 그런 다음 Heap을 분석 보관된 Instance가 Garbage collection되지 않도록 하는 references chain을 확인한다.
위의 과정을 거치면서 만약 Activity가 여전히 존재하는 경우, LeakCanary는 Potential Leak으로 간주한다.
이는 기본적으로 프로파일러를 사용해 수동으로 수행하던 Force Garbage-Collector와 Dump Heap을 모니터링하고 강제로 실행했던 Manual Process의 자동화라고 볼 수 있다.
- LeakCanary는 Activity, Fragment, ViewModel, Service, Fragment’s View를 모니터링한다.

Leak Sources

Leaks는 2개의 카테고리에서 일어난다.
- App Level
- Library Level
App Level
- App level Leak은 leak를 식별하고, 자체적으로 각 leak을 해결할 수 있다
Library Level
- Library level Leak은 할 수 있는 것이 많지 않다.
- 따라서, LeakCanary에선 library leak을 자체적으로 표시해서 알려준다

따라서, workable leaks에 초점을 맞추거나, significant한 leak을 일으키는 library에 대해 assist 할 수 있다는 점이 LeakCanary의 장점이다.

LeakCanary 사용법

단순히 build.gradle 파일에 아래를 추가해줌에 따라 사용 가능하다.LeakCanary는 Debug에서만 사용되기 떄문에, debugImplementation으로 implementation 한다.
```
debugImplementation 'com.squareup.leakcanary:leakcanary-android:$version'
```
이후 Application을 실행하던 도중에, Suspected leak이 존재하면, 알림을 받을 수 있다.

출처: https://write.agrevolution.in/memory-leaks-in-android-apps-45a27c6ac35d
해당 알림을 클릭하거나, leak object가 5개가 되었을 때 해당 leak과 관련해 analyze를 진행하게 된다.
이후 analyze가 완료되고 나서, 다시 알림을 클릭하면 아래 이미지의 좌측과 같이 leak list가 나오게 되고, 각각의 leak을 클릭하면 우측과 같이 어떠한 leak이 몇 번 발생헀는지 알려준다. 동시에 leak trace를 보여주게 된다.

출처: https://square.github.io/leakcanary/

최하단으로 내리면, ‘Leaking: YES’ 와 동시에 ObjectWatcher was watching this because com.example.myApplication.ListFragment received Fragment#onDestroyView() callback (references to its views should be cleared to prevent leaks) 처럼 표시된 부분이 있다.
leak trace에서는 leak이 발생할 수 없는 곳은 빨간색의 밑줄이 그어지지 않고, 발생 가능한 지점부터 leak이 최초로 발생되었을 것으로 간주해 빨간색의 밑줄을 그어준다. 따라서, 해당 부분 부터 어디서 누수가 발생했을 지를 아래에서 부터 찾아가면 된다.
Android Studio Profiler보다는 조금 더 친절하지만, 여전히 메모리 누수의 원인을 찾아내는 것은 개발자의 몫이다. 따라서, 메모리 누수가 발생하는 흔한 원인을 먼저 제거하는 것이 중요하다.

[모바일] 무한 스크롤과 디자인 윤리

Hodie! — Fri, 14 Jul 2023 11:31:55 +0900

개요

무한스크롤 구현과 관련된 내용을 찾아보다, 무한스크롤이 메이저 UX에서 버려지고 있는 추세라는 점을 알게되었다. 여전히 많은 앱들에서는 체류시간 증가를 위해 무한 스크롤을 사용하고 있지만, 사용자에게 UI를 사용하는 액션 자체에 중독시킨다는 디자인 윤리의 문제 , 푸터로 접근이 불가능한 형태로 구현되는 경우가 많다는 점이 그 이유였다.

특히, 페이지네이션과 콘텐츠 로드가 디자인 윤리라는 관점에서 접근한다는 것은 단순히 모바일 개발만 하던 나에게 새로운 관점이었다.

사실, 서비스를 개발하는 입장에선 단순히 어떻게 하면 사용자를 붙잡을 수 있을지, 불편함을 느끼지 않을지 정도까지가 가지고 있는 생각이었는데, 이를 기획하거나 디자인하는 입장에서는 윤리와 같은 부분까지 고려한다는 점에서 모바일 환경의 서비스를 개발하는 입장에서도 알아두면 좋을 것 같아 한번 알아보았다.

무한 스크롤이란

무한 스크롤이란 매끄러운 사용자 경험의 대표적 예시로, 페이지를 사용자가 제어할 수 있는 부분이 없고 더 많은 콘텐츠를 보고 싶을 때 손가락으로 화면을 밀어올리기만 하면 새로운 내용이 하염없이 이어지는 방식이다.

대부분의 SNS, 페이스북, 틱톡, 인스타그램 등뿐만 아니라, 쇼핑몰 페이지 등에서도 적극적으로 도입된 디자인으로 이전 페이지와 다음 페이지간의 경계나 정지 신호 없이 무한히 콘텐츠가 이어진다는 면에서 무한 스크롤이라고 불린다.

여기서 정지신호란 예를들어, 게임의 경우 접속 시간을 공지해주는 기능이 있다. ‘접속 후 1시간이 지났습니다.’ ‘2시간이 지났습니다.’ 하는 것도 정지 신호라고 할 수 있다. 유튜브 영상으로 이야기 한다면 한 편이 끝나는 지점이 정지신호라 볼 수 있는 것이다.

디자인 윤리관점에서의 무한 스크롤의 문제

무한 스크롤 기능을 처음 만들어낸 디자이너는 에이자 래스킨이다. 넷플릭스 디자인 다큐 'Abstract' 이안 스폴터편에는 무한 스크롤을 처음 디자인한 '에이자 래스킨'의 인터뷰가 짧게 등장하는데, 해당 인터뷰에서 그는 '스크롤하고 있다는 건 이미 화면을 더 보고 싶다는 증거인데, 굳이 더보기 버튼을 하단에 배치해야 하는가?'라고 생각을 바탕으로 화면에서 더보기 버튼을 없앴다고 말한다.

에이자 래스킨의 가설은 적중했고, 무한 스크롤은 현대 UI를 대표하는 것 중 하나가 되었다. 그러나, 다큐 말미 그는 자신이 만든 UI에 강한 윤리적 경각심을 내비치고 있는 것을 볼 수 있는데, 자신이 매끄러운 사용자 경험을 위해 개발한 무한 스크롤이 정지신호가 없어 이용자의 시간을 너무 많이 빼앗고 중독으로 빠뜨리고 있는 현실을 보게 된것이다. 래스킨은 자신의 개발에 대해 반성하고 트리스탄 해리스와 함께 ‘인도적 기술 센터’를 설립해 인터넷에 정지신호를 복원하자는 주장을 하고 있다.

결론

무한 스크롤이 디자인 윤리와 관련되어 있다는 점은 사실 알아볼수록 이미 그 위험성을 알고 있었지만, 외면하고 있었던 부분이라고 생각한다. 스마트폰 중독과 관련된 부분이 해당 UI와 관련되어 있다는 점은 부정할 수 없는 사실이라고 생각한다.

하지만, 그렇다면 서비스를 제공하는 입장에서 최대한 사용자를 붙잡아야 하는데 정지신호라는 사용자 이탈점이 생기는 부분과 윤리적 관점에서 서비스를 제공해야 한다는 부분은 상충되는 부분이다. 그렇다면 앞으로 서비스를 개발해 나갈때 어떤 방향으로 보완해 개발해 나갈 수 있을까?

예를 들어 인스타그램의 경우엔 이전과 달리 피드에선 새로운 게시글을 다 본 후엔 이미 본 게시글들을 다시 보기위해선 이전 게시글들을 보기 위한 버튼을 한번 더 눌러야 하고, 사용시간에 대한 알람을 설정할 수 있다. 그러나, 여전히 돋보기라고 불리는 발견 탭은 무한스크롤임이 변함이 없고 릴스의 경우에도 무한정으로 내려갈 수 있다. 그정도가 서비스를 제공하는 입장에서의 최대한의 타협점일까?

참고자료

‘무한 스크롤’ 개발 디자이너도 나섰다…“이젠 정지신호 복원할 때”

무한 스크롤은 디자인 윤리에 어긋날까?

인간을 위한 디자인 / 무한 스크롤과 에이자 래스킨

[Android] RecyclerView Deep Dive - 2. RecyclerView에서의 활용과 최적화

Hodie! — Mon, 10 Jul 2023 11:08:10 +0900

이어지는 글

[Android] RecyclerView Deep Dive - 1. RecyclerView 정의와 동작원리 및 생명주기

개요 이전에 RecyclerView에 대한 글을 정리한 적이 있었다. 당시에는, RecyclerView의 등장 의의와 RecyclerView를 사용하는 경우에 구현해야 하는 구현부에 대한 내용을 중심으로 작성했었다. 2022.12.22 - [I

hodie.tistory.com

RecyclerView.ViewHolder에서의 ViewTreeLifecycleOwner 사용

참고: https://pluu.github.io/blog/android/2021/09/20/lifecycleowner/

기존 ViewTreeLifecycleOwner 사용시

출처:https://pluu.github.io/blog/android/2021/09/20/lifecycleowner/

기존 onBindViewHolder에서 위와 같이 null이 반환되는 것을 볼 수 있다.

ViewTreeLifecycleOwner의 간단한 개념

Android에는 생명주기 개념을 가지는 Component로 Activity/Fragment가 있다.
그리고, 생명주기를 다룬다는 정의를 LifecycleOwner 인터페이스를 통해서 선언하고 있다.

public interface *LifecycleOwner* {
    @NonNullLifecycle getLifecycle();
}

// 출처: https://github.com/androidx/androidx/blob/androidx-main/lifecycle/lifecycle-common/src/main/java/androidx/lifecycle/LifecycleOwner.java

AndroidX에는 ComponentActivity와 Fragment에서 LifecycleOwner interface를 구현하고 있다.
그래서, 해당 Component에서는 직접 getLifecycle() 함수를 통해서 직접 생명주기를 다룰 수 있다.

코드 분리

리팩토링 등으로 Activity/Fragment에 코드는 없지만, Activity/Fragment의 LifecycleOwner 인터페이스에 접근해야 할 경우가 있다.
→ 이때 유용한 API가 바로 ViewTreeLifecycleOwner

그리고, LifecycleOwner은 ViewTreeLifecycleOwner.get 혹은 View.findViewTreeLifecycleOwner KTX를 통해서 가져올 수 있다.

public fun View.findViewTreeLifecycleOwner(): LifecycleOwner? = ViewTreeLifecycleOwner.get(this)

// 출처: https://github.com/androidx/androidx/blob/androidx-main/lifecycle/lifecycle-runtime-ktx/src/main/java/androidx/lifecycle/View.kt

RecyclerView.ViewHolder에서의 LifecycleOwner를 사용할 위치

Lifecycle에 맞춘 핸들링은 Activity/Fragment뿐만 아니라 경우에 따라서 View가 존재하는 어느 곳이더라도 필요할 수도 있다.
또한, View.findViewTreeLifecycleOwner KTX를 사용하면 쉽게 LifecycleOwner를 가져올 수 있다는 것을 이미 알고 있다.
onBindViewHolder에서도 ViewHolder의 itemView를 사용하면 당연히 LifecycleOwner가 반환될 것이라고 기대하지만, 위에서 봤다시피 결과는 null을 반환한다.
그 이유가 무엇일까?

1. ViewTreeLifecycleOwner

이를 위해 먼저 살펴볼 것은, ViewTreeLifecycleOwner.get 이다.
- findViewTreeLifecycleOwner KTX 또한 ViewTreeLifecycleOwner.get을 호출하고 있으므로 LifecycleOwner를 가져오는 핵심 코드라고 볼 수 있다.
```
public class ViewTreeLifecycleOwner {
   @Nullable
   public static LifecycleOwner get(@NonNull View view) {
      LifecycleOwner found = (LifecycleOwner) view.getTag(R.id.view_tree_lifecycle_owner);
      if (found != null) return found;
      ViewParent parent = view.getParent();
      while (found == null && parent instanceof View) { // View#getParent가 유효한지 체크
         final View parentView = (View) parent;
         found = (LifecycleOwner) parentView.getTag(R.id.view_tree_lifecycle_owner);
         parent = parentView.getParent();
      }
      return found;
   }  
}
```
  → 기본 동작은 View.getParent를 반복적으로 호출하면서 LifecycleOwner 가 존재하는지 체크하는 형태이다
- 이어서 onBindViewHolder에서 View.getTag와 View.getParent를 확인해 보면
  
  → 당연히 View.getTag를 통한 LifecycleOwner는 null이다.
- → 그러나, ViewHolder에서 View에 해당하는 itemView의 parent는 null이라고 출력된다.
- ViewTreeLifecycleOwner#get 로직에서 내부적으로 View.getParent를 호출하면서 LifecycleOwner가 존재하는 객체를 찾지만, 여기에서는 parent가 null이므로 최종적으로 null로 반환되었던 것이다.
  → null이 반환되는 원인은 ViewHolder가 가리키는 View의 부모 View가 null이기 때문이었다.

2. RecyclerView 생명주기

위에서 살펴봤듯이, RecyclerView 사용 시에 onCreateViewHolder를 통해서 View가 생성되고, onBindViewHolder를 통해서 값을 반영하는 코드라는 것을 알고 있다.
그런데, onBindViewHolder 단계에서 ViewHolder의 View는 RecyclerView에 Add되었을까? ViewHolder의 itemView는 Attach되었을까?
→ 정답은 No이다. 이전 RecyclerView Deep Dive - 1. RecyclerView 정의와 동작원리 및 생명주기 글에서의 RecyclerViewㅢ Birth의 요약을 보면, 최초 ViewHolder를 생성하는 경우, Bind한 뒤에, 마지막 단계에 addView()를 하고, onViewAttachedToWindow()를 호출하는 것을 볼 수 있다.

→ 즉, ViewHolder는 onBindViewHolder 시점이 되더라도 RecyclerView에 add 되지 않은 상태이기에, . onBindViewHolder에서 parent가 null로 반환됐던 것이며, findViewTreeLifecycleOwner 결과가 null로 나온 것이다.

3. onViewAttachedToWindow

그렇다면, onViewAttachedToWindow 이후엔 View가 add되었다 볼 수 있다. 그렇다면 결과가 달라질 수 있을까?
출처:https://pluu.github.io/blog/android/2021/09/20/lifecycleowner/
- ViewHolder의 itemView의 parent가 RecyclerView로 지정된다
  (RecyclerView의 child로 add 됨)
- parent가 존재하므로 findViewTreeLifecycleOwner API 결과로 유효한 LifecycleOwner가 반환된다

→ 따라서 LifecycleOwner를 사용하기 위해선 View가 Attach된 이후에 사용해야 한다

RecyclerView에서 LifecycleOwner의 사용

RecyclerView.ViewHolder를 통한 LifecycleOwner 탐색 시 2가지 사실을 알 수 있었다.
1. ViewTreeLifecycleOwner.get에서 parent를 반복적으로 호출하면서 LifecycleOwner를 소유하는 객체를 찾는다
2. onBindViewHolder 단계에서는 RecyclerView의 child로 추가되지 않는다
LifecycleOwner를 얻는 시점을 onViewAttachedToWindow에서 다룰 수도 있지만,
매번 Adapter에서 ViewHolder에 LifecycleOwner를 주입하는 코드는 놓치기 쉬운 코드며 모든 ViewHolder에서는 필요한 경우는 드물다.
대신 ViewHolder의 초기화 단계(init)에서 doOnAttach KTX 함수를 사용하면 ViewHolder에서 코드를 작성할 수 있다.
→ 결과로 간단하게 View가 Attach된 이후에 ViewTreeLifecycleOwner.get API를 사용할 수 있다.

class ViewHolder(
   private val binding: ItemRecyclerViewSampleBinding
) : RecyclerView.ViewHolder(binding.root) {
   private var lifecycleOwner: LifecycleOwner? = null
  
   init {
      itemView.doOnAttach {
         lifecycleOwner = itemView.findViewTreeLifecycleOwner()
      }
      itemView.doOnDetach {
         lifecycleOwner = null
      }
   }
}

그 결과

출처: https://pluu.github.io/blog/android/2021/09/20/lifecycleowner/

Tips & Tricks

No Update == No OnBind

아이템을 업데이트하지 않는다면 → 그 아이템에 대한 onBind는 호출되지 않는다.
즉, 아이템이 새로운 아이템으로 업데이트 되지 않는다면 onBind는 재호출되지 않는다.

❌ Don’t this (잘못된 코드)

mAdapter.notifyItemMoved(1, 5);
// onBind 호출 X
// onBind가 일어나지 않으므로 invalidate도 없다.

public void onBindViewHolder(final ViewHolder holder, final int position) {
    holder.itemView.setOnClickListener(
        new View.OnClickLister() {
            @Override
            public void onClick(View v) {
                removeAtPosition(**position**);
            }
        }
    }
}    
// 아이템이 이동되었을 때 position을 가지고 뭔가 추가하거나 제거하려는 동작을 구현하였으나
// 아래 코드 상황에서 position이 올바르게 동작하지 않는 버그가 발생한다.

onBindViewHolder(holder, 5);
notifyItemMoved(5, 15);
holder.itemView.callOnClick();
// 버그 발생!

✅ Do this

public void onBindViewHolder(final ViewHolder holder, final int position) {
    holder.itemView.setOnClickListener(
        new View.OnClickLister() {
            @Override
            public void onClick(View v) {
                removeAtPosition(**holder.getAdapterPosition**);
            }
        }
    }
}
// ViewHolder는 현재 어댑터의 position을 알고 있기에 getAdapterPosition을 
// 사용하면 아이템이 이동되는 이벤트에도 정확한 position을 구할 수 있다.

Payloads

아이템의 변경에 Payload를 사용할 수 있다.
예를 들어, 유저의 좋아요 이벤트 같은 아이템의 변경에 페이로드를 사용해볼 수 있는데 이는 onBind를 더 효율적으로 만들며, 더 나은 애니메이션을 제공할 수 있다.

mAdapter.notifyItemChanged(position, LIKE_UPDATE);
// "좋아요" 이벤트가 발생하여 아이템을 업데이트

onBind에서 payloads가 비었는지를 체크해볼 수 있다.
- payloads가 존재한다면 전체 아이템을 전부 다시 Bind할 필요가 없어진다.
  payloads를 통해 오직 변경점에 대한 부분만 다시 Bind할 수 있게 되는 것

public void onBindViewHolder(MyViewHolder holder, int position, List payloads) {
	if (payloads.isEmpty()) {
		// 전체 Re-Bind
		onBindViewHolder(holder, position);
	} else if (payloads.contains(LIKE_UPDATE)) {
		// 부분적인 Re-Bind
		Item item = mItems.get(position);
		holder.likeButton.setEnabled(!item.isLiked());	
	}
}

`OnCreate` Means “`create`”

자주하는 실수는 헤더 뷰 같은 것을 구현할 때 발생한다.
아래 코드에서 기존의 헤더 ViewHolder가 존재한다면 재사용해주도록 Return하고 있다.

❌ Don’t this

ViewHolder onCreateViewHolder(ViewGroup parent, int viewType) {
    if (viewType == HeaderViewHolder.TYPE) {
        if (mHeaderViewHolder == null) {
            mHeaderViewHolder = new HeaderViewHolder(parent);
        }
        return mHeaderViewHolder;
    }
    return new MyViewHolder(parent);
}

하지만 위 코드는 버그를 발생시킬 수 있는데, 이에 대해 onCreateViewHolder가 어떤 의미인지 생각해볼 필요가 있다.
말 그대로 ‘생성’을 의미하는 것이기 때문에 위 코드는 바람직하지 않다.

✅ Do this

ViewHolder onCreateViewHolder(ViewGroup parent, int viewType) {
    if (viewType == HeaderViewHolder.TYPE) {
        return new HeaderViewHolder(parent);
    }
    return new MyViewHolder(parent);
}

Positions : `Adapter` vs `Layout`

adapterPosition과 layoutPosition은 아이템 리스트의 변경이 생겼을 때 차이가 발생하게 된다.
왜냐하면 다음 레이아웃 과정에서 이 position을 계산하는 과정이 비동기적이기 때문이다.
비로소 레이아웃 과정을 마치고 View가 refresh 된 이후에야 adapterPosition과 layoutPosition이 일치하게 되는 것이다.

→ 그러므로 데이터에 접근할 때는 adapterPosition을 사용하는게 좋을 것이고
유저가 무언가를 클릭 했을 때 위, 아래에 있는 아이템에 접근해야할 경우에는 layoutPosition을 사용하는게 좋다.

RecyclerView의 최적화

1. RecyclerView/Adapter의 함수를 효율적으로 응용

`setHasStableIds`와 `getItemId`

HasStableIds 사용을 통해, 데이터를 바인딩하는 경우, onBindViewHolder()를 최적화되게 호출 할 수있다.
참고로, DiffUtil을 사용하는 경우, setHasStableId(true) , getItemId()는 사용하지 않아도 된다.
차이 알고리즘에 의해 필요한 부분만 업데이트가 이미 되기 때문이다.

`HasStableIds` 사용으로 최적화 호출이 가능한 조건

둘 중 하나의 조건에만 해당한다면 성능을 크게 향상시킬 수 있다
1. 똑같은 데이터가 반복적으로 나타나는 리스트
2. notifyDataSetChanged를 자주 호출한다

최적화 호출 원리

setHasStableIds(true) 를 사용하면 각각 아이템 position에 지정된 id를 기준으로 상황에 따라 onBindViewHolder() 호출을 제외시킨다.
값이 변경된 id만 onBindViewHolder를 호출하거나 호출된 아이템의 id가 이전 position 아이템에 이미 존재할 시 onBindViewHolder 함수를 호출 하지 않고 이전에 같은 id를 가진 View를 대신 보여준다.
이러한 원리로 같은 데이터임을 알고, 데이터 바인드를 할 필요가 없기 때문에 호출되지 않으며 그만큼 성능이 향상될 수 있는 것이다.

사용 방법

HasStableIds는 Adapter.setHasStableIds(boolean)을 통해 설정할 수 있고, 사용하는 경우 Adapter의 getItemId(int)를 반드시 구현해야 작동한다.
getItemId(int)를 통해 해당 아이템은 고정된 상태로 설정된다.

사용 예시 (https://blog.kmshack.kr/Stable-Id를-이용한-RecyclerView-성능-향상법/)

position	return
0	100
1	200
2	300
3	100
4	400
5	500

위와 같이 값이 반환되게 구현된 경우, onBindViewHolder(view, int)는 position 0, 1, 2, 4, 5만 호출된다.
3번은 0번째 포지션에서 같은 고정된 ID를 반환했기 때문에 같은 데이터로 인식하여 onBindViewHolder(view, int)가 호출되지 않는다
→ 같은 데이터임을 알고 데이터 바인드를 할 필요가 없기 때문에 호출되지 않으며 그만큼 성능은 향상된다.

position	return
0	100
1	200
2	600
3	300
4	100
5	400
6	500

position 2번에 데이터를 추가하고 notifyDataSetChanged()를 호출하였다. 이때, onBindViewHolder(view, int) 는 현재 보이고 있는 포지션이 모두 호출되지만 StableId를 사용하게 된다면 이미 호출된 고정된 ID를 제외한 위치가 호출된다.
notifyDataSetChanged()를 하였음에도 변경되는 ID만을 골라 해당 포지션만 onBindViewHolder(view, int)를 호출하게 됨으로 그만큼 성능은 향상된다.

`setHasFixedSize`

RecyclerView는 데이터가 삽입, 삭제가 될 때 각각 아이템의 레이아웃을 다시 계산해야할지 정한다.
hasFixedSize가 true 일 경우 고정값으로 인식하고,
false일 경우 requestLayout() 호출이 되어 아이템의 레이아웃 계산이 다시 이루어진다.
View와 관련된 작업은 모두 UI Thread가 위임하기 때문에, 버벅거림이 없는 60프레임을 달성 하려면 최대한 UI Thread를 효율적으로 활용 해야한다.
따라서 아이템 UI의 사이즈가 고정이라면 true로 하는게 좋다.

중첩 RecyclerView간의 Pool 공유

중첩되어 구현된 RecyclerView에서 RecyclerView간의 pool를 공유해 성능을 향상 시킬 수 있다.
→ 바깥쪽과 안쪽 pool를 공유하면 된다.

예시

override fun onCreateViewHolder(...): RecyclerView.ViewHolder {
    val innerLm = LinearLayoutManager(...) innerRv.apply{
        layoutManager = innerLm recyclerViewPool = sharedPool
    } return OuterAdapter.ViewHolder(innerRv)
}

2. `View` 및 `onBindViewHolder` 최적화

`onBindViewHolder`에서 복잡한 로직 피하기

onBindViewHolder는 가능하면 순수 data set만 하는 것이 가장 이상적이다.
data를 외부에서 미리 가공해서 onBindViewHolder에서 set 하는 것이 가장 안정적이다.

구체적 예시

onBindViewHolder에서 가능하면 for, while 과 같은 반복문은 피한다.
onBindViewHolder에서 특별한 경우를 제외하고 콜백,리스너 정의를 하지 않아야 한다.
(ex: onClickListener)

ovrride fun onBindViewHolder(
    holder: RecyclerView.ViewHolder,
    position: Int
) { 
// 앱 성능 저하의 원인 
    for (...) {...}
    
// 불 필요한 코드
    view.setOnClickListenr { ... }
    
//아래 처럼 set만 하는 코드만 존재하는 것이 가장 이상적
    imageView.set...(data[position].url)
    textView.text = data[position].text
}

ViewHolder 및 onCreateViewHolder에서 가능한 미리 값 처리

예시 코드

예시로 width를 디바이스 기기의 3분의 1 크기로 고정값으로 사용해야하는 경우

class ViewHolder(v: View) :
    RecyclerView.ViewHolder(v) {
    init {
        // 가능하면 미리 정할 수 있는 값은 ViewHolder나 onCreateView에서 처리하는 것이 좋다.
        v.layoutParms = LayoutParms(....)
        v.itemView.setOnClickListener { ... }
    }

    override fun onBindViewHolder(...) {
        //별로 좋지않는 코드, 성능 저하의 원인 중 일부분이 될 수 있음 
        holder.layoutParms = LayoutParms(....)
        holder.itemView.setOnClickListener { ... }
    }
}

→ 위 처럼 가능하면 ViewHolder에서 미리 처리할 수 있는 것은 set을 해두는 것이 좋고 onBindViewHolder에 최대한 부담을 없애야 한다.

`OnBindViewHolder`에서 `Html.fromHtml()` 사용 지양

html 를 사용하기 때문에 마찬가지로 onBindViewHolder에 적합하지 않다.
성능저하의 원인 중 하나가 된다.

아이템 레이아웃 UI 계층 단순화

안드로이드 xml은 View가 위치한 depth가 한단계 씩 깊어질 수록 UI 연산이 배로 증가한다
https://android-developers.googleblog.com/2017/08/understanding-performance-benefits-of.html
→ 성능 저하의 원인으로 이어질 수 있다
따라서, 특별한 경우를 제외하고 가능하면 xml 에서 ConstraintLayout를 사용해 1 depth로 View를 그리는 것이 좋다
- 이상적코드

<android.support.constraint.ConstraintLayout> 
<ImageView /> 
<ImageView /> 
<TextView /> 
<EditText /> 
<TextView /> 
<TextView /> 
<EditText /> 
<Button /> 
<Button /> 
<TextView /> 
</android.support.constraint.ConstraintLayout>

부모 계층 `ViewGroup`이 `ScrollView` or `RecyclerView`

recyclerView.setNestedScrollingEnabled(false)

상위 뷰에 따라 스크롤이 부드럽지 않는 경우도 있다.
그럴 때 위 코드를 적용하면 한층 더 좋아짐을 알 수가 있으며 XML에서도 설정 가능하다

`item`에 복잡한 `drawable` 사용 지양

<layout-list> 로 이루어진 복잡한 drawable을 item XML에 가능하면 사용하지 말아야한다.
→ 저가용 기기에서 GPU 에 부하를 주기 때문에 가능하면 심플하게 사용해야 한다

`ViewStub` 사용

ViewStub으로 지연 인플레이트를 사용하는 것이 좋다.
visible 로 설정된 경우에 inflate 하기 때문에 성능 컨트롤에 효율적이다.

투명색은 가능하면 지양

투명색 사용은 저가용 기기에서 상당한 부하가 될 수 있다.
이는 투명색 처리는 연산처리가 많기 때문에 가급적 피하는 것이 좋다.

3. 이외의 시도

`LayoutManager` custom을 통해 `onCreateView` 호출을 여러번 미리 가져오기 (`PreCache`)

최적화 원리

ViewHolder 생성 ~ 제거 Lifecycle에서 onCreateViewHolder 는 최초로 ViewHolder 생성한다.
하지만 [생성]을 미리 해놓는 경우, 다음 LifeCycle에서 onCreateViewHolder 호출 횟수를 줄이는 방법이 존재한다
→ 바로 RecyclerView가 내부적으로 인식하는 화면 사이즈를 크게 잡는 것
RecyclerView는 사용자가 눈으로 볼 수 있는 화면 + 보이지 않는 위아래 가상의 영역의 사이즈가 있는데 이 전체 사이즈를 내부적으로 늘리면
→ 기본적으로 갖는 아이템의 양의 수보다 더 많은 아이템을 onCreateViewHolder로 생성 해놓을 수 있다.
스크롤을 하게 되면 이미 onCreateViewHolder 로 생성한 아이템들로 인해 onCreateViewHolder 함수의 호출이 적어진다.

class PreCacheLayoutManager(context: Context, private val extraLayoutSpace: Int) :
    LinearLayoutManager(context) {
    override fun getExtraLayoutSpace(state: RecyclerView.State?) = extraLayoutSpace
}
//Activity 에서..
recyclerView.adapter = PreCacheLayoutManager(context,600)

단점

그러나, 사이즈를 너무 크게 잡아버리면 init 시 호출되는 onCreateViewHolder가 많아지고 가상으로 인식하는 사이즈가 매우 넓기 때문에 init 타이밍에 버벅거림이 존재할 수 있다.
따라서, 이 방식은 적재적소하게 사용하는 것이 좋다.

`LayoutManager.setItemPrefetchEnabled(true, false)` 사용

RecyclerView 25.0.0 부터 기본적으로 setItemPrefetchEnabled()이 true로 설정되어 있다.
→ 따라서 true로 하고 싶다면 별도의 설정을 하지 않아도 된다

최적화 원리

// false 하고 싶을 때만 직접적으로 명시
layoutManager.itemPrefetchEnabled = false

onBindViewHolder를 몇 프레임 앞서서 미리 호출하는 방식이다.
→ 유저가 빠른 스크롤을 할때 미리 onBindViewHolder를 미리 호출한 것을 보여주기 때문에 자연스러운 스크롤을 달성할 수 있다.
(1) UI thread에서 View의 inflate 와 bind가 완료되면
(2) 순차적으로 GPU Render Thread에서 렌더링 작업을 하게 되는데,
(3) 이때 UI Thread는 유휴 상태가 된다.
→ 스크롤 할때 이 순서를 반복
하지만 스크롤할때 새로운 View가 등장하기 위해 UI Thread는 다시 infalte & bind 작업을 하게 되는데, 문제는 위 작업이 Render Thread 에서 렌더링이 끝나고 UI가 사용자 눈에 표시 되려 하는 순간과 겹치게 된다.
→ 그래서 UI Thread 의 View infate & bind 작업은 비용이 매우 크면서 동시에 렌더링 된 UI가 표시가 되기 때문에
→ 순간적으로 버벅거림이 생기게 된다.
따라서 Prefetch 방식을 통해 스크롤 할때 inflate 가 필요한 경우,
UI 스레드가 유휴상태에 들어가는 동안 미리 추가적으로 onBindViewHolder() 를 호출한다.

사용 조건

RecyclerView 버전이 업데이트 되면서 setItemPrefetchEnabled() 가 기본적으로 true로 설정되어 있다. 그러나, ViewCache 메모리를 추가적으로 사용하게 된다.
→ 추가적인 비용 소요
따라서 스크롤이 조금만 발생을 하도록 유도한 UX, 전체 아이템 갯수가 매우 적을 경우 → false
반대로 많은 스크롤이 일어나는 일반적인 경우 → true

`init` 시에만 `AsycLayoutInflate` 사용, UI 스케줄러 제작
(안드로이드 개발자 Phil Olson의 방식 )

Smooth RecyclerView scrolling in Android

Tips for using complex views without skipping frames

medium.com

RecyclerView에 adapter를 set하면서 동시에 RecyclerView Adapter 를 사용하는 경우가 아닌, Adapter에 뒤늦게 아이템이 insert 되는 경우, AsycLayoutInflate 를 사용해 미리 onCreateViewHolder에서 사용할 View를 만들어 두어 onCreateViewHolder의 부담을 더는 방법

예시

class SmoothListAdapter(val context: Context) :
    ListAdapter<ListItem, SmoothListAdapter.ListItemViewHolder>(ListItemViewHolder.MyDiffCallback()) {
    data class ListItem(val id: String, val text: String)
    class ListItemViewHolder(view: View) : RecyclerView.ViewHolder(view) {

        private val asyncLayoutInflater = AsyncLayoutInflater(context)
        private val cachedViews = Stack<View>()
        init {
            //Create some views asynchronously and add them to our stack 
            for (i in 0..NUM_CACHED_VIEWS) {
                asyncLayoutInflater.inflate(
                    R.layout.list_item,
                    null
                ) { view, layoutRes, viewGroup -> cachedViews.push(view) }
            }
        }

        override fun onCreateViewHolder(
            parent: ViewGroup,
            viewType: Int
        ): ListItemViewHolder {
            //Use the cached views if possible, otherwise if we ran out of cached views inflate a new one 
            val view = if (cachedViews.isEmpty()) {
                LayoutInflater.from(context).inflate(R.layout.list_item, parent, false)
            } else {
                cachedViews.pop().also {
                    it.layoutParams = LinearLayout.LayoutParams(MATCH_PARENT, WRAP_CONTENT)
                }
            }
            return ListItemViewHolder(view)
        }

        fun populateFrom(listItem: ListItem) {
            //TODO: populate your view 
        }
        override fun onBindViewHolder(viewHolder: ListItemViewHolder, position: Int) =
            viewHolder.populateFrom(getItem(position))

        class MyDiffCallback : DiffUtil.ItemCallback<ListItem>() {
            override fun areItemsTheSame(firstItem: ListItem, secondItem: ListItem) =
                firstItem.id == secondItem.id override fun areContentsTheSame(
                    firstItem: ListItem,
                    secondItem: ListItem
                ) = firstItem == secondItem
        }

        companion object {
            const val NUM_CACHED_VIEWS = 5
        }
    }
}

만약 위 코드 처럼 ListAdapter를 사용한다면 미리 adapter를 초기화 해두고 submitList(colleaction<T>) 를 뒤늦게 사용하게 된다면 미리 만들어둔 view를 stack에 담아놨던걸 그대로 사용하면 된다.
또한 UI 스케줄러를 따로 만들어 사용 가능하다.

object UIJobScheduler {
    private const val MAX_JOB_TIME_MS: Float = 4f private
            var elapsed = 0L private
                    val jobQueue = ArrayDeque<() -> Unit>() private
                            val isOverMaxTime get () = elapsed > MAX_JOB_TIME_MS * 1_000_000 private
                            val handler = Handler()

    fun submitJob(job: () -> Unit) {
        jobQueue.add(job) if (jobQueue.size == 1) {
            handler.post { processJobs() }
        }
    }

    private fun processJobs() {
        while (!jobQueue.isEmpty() && !isOverMaxTime) {
            val start =
                System.nanoTime() jobQueue . poll ().invoke() elapsed += System . nanoTime () - start
        } if (jobQueue.isEmpty()) {
            elapsed = 0
        } else if (isOverMaxTime) {
            onNextFrame { elapsed = 0 processJobs () }
        }
    }

    private fun onNextFrame(callback: () -> Unit) =
        Choreographer.getInstance().postFrameCallback { callback() }
}

위 코드는 최대 4ms를 사용한다.
MAX_JOB_TIME_MS 상수를 바꿔서 원하는 최대 ms를 설정할 수 있다.

AsyncLayoutInflater 를 사용해서 infalte, bind
(Dmitrii Kachan 의 방식)

Improve UI Performance with Async RecyclerView Layout Loading

RecyclerView is one of the most commonly used Android UI components. It can be very powerful but unfortunately it sometimes becomes very…

proandroiddev.com

AsyncLayoutInflater 를 사용해 onCreateViewHolder 에서 ViewHolder를 생성하고,
생성 후 onBindViewHolder에서 bind까지 하는 방식
→ 기존에 UI Thread가 하던 일을 background Thread 에 맡기는 형식
→ background Thread 에서 레이아웃 계산부터 모두 비동기 방식으로 사용이 가능하다.

예시

open class AsyncCell(context: Context) : FrameLayout(context, null, 0, 0) {
    init {
        layoutParams = LayoutParams(MATCH_PARENT, WRAP_CONTENT)
    }

    open val layoutId = -1

    // override with your layout Id 
    private var isInflated = false
    private val bindingFunctions: MutableList<AsyncCell.() -> Unit> = mutableListOf()

    fun inflate() {
        AsyncLayoutInflater(context).inflate(layoutId, this) { view, _, _ ->
            isInflated = true addView (createDataBindingView(view)) bindView ()
        }
    }

    private fun bindView() {
        with(bindingFunctions) {
            forEach { it() }
            clear()
        }
    }

    fun bindWhenInflated(bindFunc: AsyncCell.() -> Unit) {
        if (isInflated) {
            bindFunc()
        } else {
            bindingFunctions.add(bindFunc)
        }
    }

    // override for usage with dataBinding
    open fun createDataBindingView(view: View): View? = view
}

위에 FrameLayout를 더미로 만들고 addView를 해서 아래처럼 사용

class RecyclerViewAsyncAdapter(private val items: List<TestItem>) :
    RecyclerView.Adapter<RecyclerView.ViewHolder>() {
    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): RecyclerView.ViewHolder =
        SmallItemViewHolder(SmallItemCell(parent.context).apply { inflate() })

    override fun getItemCount(): Int = items.size
    override fun onBindViewHolder(
        holder: RecyclerView.ViewHolder,
        position: Int
    ) {
        if (holder is SmallItemViewHolder) {
            setUpSmallViewHolder(holder, position)
        }
    }

    private fun setUpLargeViewHolder(holder: LargeItemViewHolder, position: Int) {
        (holder.itemView as LargeItemCell).bindWhenInflated {
            items[position].let { item ->
                holder.itemView.binding?.item = item
            }
        }
    }

    private fun setUpSmallViewHolder(holder: SmallItemViewHolder, position: Int) {
        (holder.itemView as SmallItemCell).bindWhenInflated {
            items[position].let { item ->
                holder.itemView.binding?.item = item
            }
        }
    }

    private inner class SmallItemViewHolder internal constructor(view: ViewGroup) : RecyclerView.ViewHolder(view)

    private inner class SmallItemCell(context: Context) : AsyncCell(context) {
        var binding: SmallItemCellBinding? = null override
        val layoutId =
            R.layout.small_item_cell override fun createDataBindingView(view: View): View? {
                binding = SmallItemCellBinding.bind(view) return view.rootView
            }
    }
}

단점으로 복잡한 View를 가진 아이템에서는 간혹 UI가 제대로 렌더링 못하는 경우가 있거나, 오히려 더 느려지는 문제점이 생기기도 한다.
→ 마찬가지로 상황에 맞게 사용해야 한다

`ViewHolder` paramter로 넘어가는 `View`를 `inflate` 해서 생성하지 않고 class로 만들기

onCreateViewHolder에서 기본적으로 XML를 LayoutInflate로 View로 inflate 해서 사용하는게 일반적인 경우
대신 XML를 사용하지 않고 ItemView 자체를 class로 직접 만들어 ViewHolder paramter 로 넘기는 방법
→ inflate 을 하지않고 바로 View를 넘기기 때문에 ViewHolder 생성 비용을 아낄 수 있음

예시

class ProductCardView : MaterialCardView { 
    ...
}
abstract class MyAdapter : RecyclerView.Adapter<MyAdapter.ViewHolder>() {
    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): RecyclerView.ViewHolder {
        return RecyclerView.ViewHolder(
            ProductCardView(parent.context)
        )
    }
    ...
}

단점

하지만 유지보수 측면에서 XML에 비해 효율은 좋지 않음.
성능을 중심으로 코딩 하는 상황이 아니라면 가급적 사용하지 않는 방법.

Compose LazyComposable 사용

Compose를 통해 목록형 UI를 만드는 방법
늦은 초기화를 통해 View가 사용자 눈에 보일 때 UI 렌더링 합니다.
→ 복잡한 Adpater 관리도 사라지며 composable function 안에서 쉽게 List 관리가 가능하다.
XML과 혼용해 사용할 수 있기 때문에 List부분만 LazyComposable를 이용해 만드는 것도 하나의 방법

예시

LazyColumn {

// Add a single item
    item { Text(text = "First item") }

// Add 5
    items items (5) { index -> Text(text = "Item: $index") }

// Add another single 
    item item { Text(text = "Last item") }
}

[Android] RecyclerView Deep Dive - 1. RecyclerView 정의와 동작원리 및 생명주기

Hodie! — Wed, 5 Jul 2023 07:14:02 +0900

개요

이전에 RecyclerView에 대한 글을 정리한 적이 있었다. 당시에는, RecyclerView의 등장 의의와 RecyclerView를 사용하는 경우에 구현해야 하는 구현부에 대한 내용을 중심으로 작성했었다.
2022.12.22 - [IT/Android] - [Android] RecyclerView 이해하기
이외에 RecyclerView에서 사용하는 Adapter를 중심으로 알아봤었다
2022.12.23 - [IT/Android] - [Android] RecyclerView 갱신의 효율성을 높이는 방법
그러나 RecyclerView를 사용하면서, 근본적인 RecyclerView에 대한 이해를 필요로 하는 일이 늘어났고 특히, RecyclerView의 내부 동작에 대한 이해가 필요로 하는 일이 늘어남에 따라 이번에는 RecyclerView의 내부 구조 동작을 중심으로 알아보고자 한다.

목적

RecyclerView의 작동 방식 및 LifeCycle을 중심으로 알아볼 예정이다.
이외에 ListView의 문제점을 비롯한 RecyclerView의 등장 배경과 정의, 성능 향상방법 등을 Google I/0 2016에 소개된 내용을 중심으로 알아볼 예정이다.

RecyclerView의 등장 의의

등장 이전: `ListView`

안드로이드에선 List를 보여주기 위해 ListView를 사용했었다. 그러나, ListView에는 고질적인 문제가 존재했다
1. ListView의 ItemView 생성속도
2. ItemView 애니메이션 구현의 어려움
3. ItemView 재사용 여부 분기 처리
4. 변경된 Item Data의 Position을 알 수 없음

ListView 문제점 - 1. `ListView`의 `ItemView` 생성속도

대표적인 문제점으로, 아이템 리스트를 표현하는 ItemView의 개수가 수백개 이상으로 많아지는 경우, ListView가 ItemView를 생성하는 속도가 매우 느려진다는 것이었다.
- 이에 따라 구글은 내부적으로 Adapter라는 것을 사용해, 당장 눈에 보이는 ItemView만 생성하는 대응책을 내놓았고, 눈에 안보이던 새로운 ItemView가 눈에 보여져야 할 때 기존에 생성했던 ItemView를 그대로 재사용한다는 속임수를 사용했었다. (ViewType이 동일한 경우에만)
- → ListView가 ItemView를 재사용하지 않고 한번에 그리기 때문에 속도가 느리다 는 말은 ListView의 Adapter라는 재사용 메커니즘을 사용하지 않았을 때 적용되는 말이다.
  → 즉, ListView도 View를 재활용 할 수 있다.
  문제는, 이 재사용에 의해 후술할 애니메이션 처리라는 문제점이 생겨났다.
- 이러한 문제들을 비롯해 ListView에 대한 개발자들의 요구사항이 점점 커지고, ListView API가 지나치게 복잡해짐에 따라 오작동을 일으키는 경우가 빈번해지기 시작했다

ListView 문제점 - 2. `ItemView` 애니메이션 구현의 어려움

또한 ListView가 가진 가장 큰 문제는, ItemView에 애니메이션을 구현하는 것이 너무 어렵다는 것
- ItemView를 제거하는 애니메이션을 구현한 경우, ItemView를 하나씩 클릭하여 제거했을 경우에는 원하는 대로 작동하는 것 같았지만 여러 개의 ItemView를 클릭한 후 빠르게 스크롤하면 몇몇 ItemView가 아무런 데이터도 없는 상태로 비어있는 현상이 발생하게 된다.
  (ItemView의 애니메이션이 진행되는 동안 재사용 대상으로 선택 됐기때문이다)

- 애니메이션 효과가 완전히 끝나면 이 ItemView에 해당하는 객체가 메모리 상에서 제거되지만, 이 객체는 재사용되기로 약속된 객체이기 때문에 다시 사용되어야 한다.
- 하지만 애니메이션으로 인해 메모리 상에서 제거된 경우, ListView가 새로운 데이터를 세팅할 재사용 ItemView를 메모리에서 찾지 못하게 되는데 이를 `ListView의 붕괴 현상`이라고 부른다.
- → 현재는 ListView의 붕괴 현상을 해결하기 위해 안드로이드가 제공하는 ViewPropertyAnimator API를 사용하면 된다. 이것을 사용하면 애니메이션 효과가 진행 중인 ItemView는 작업이 진행중인 객체로 인식되어 재사용 대상으로 선택되지 않게 된다.

ListView 문제점 - 3. `ItemView` 재사용 여부 분기 처리

이외에 ListView를 구현할 때는 개발자가 직접 ItemView를 생성하는 로직(onCreate)과 데이터를 연결하는 로직(onBind)을 분리해서 코드를 작성해야 했다.
- 따라서 개발자들은 if 조건문을 통해 재사용될 ItemView가 존재하면 바로 데이터를 재사용될 ItemView에 연결하고,
  재사용될 ItemView가 존재하지 않으면(null) 새로운 ItemView를 생성하는 코드를 추가해야 했다.
문제는 이 로직 분리 작업을 까먹는 경우도 많았고 이로 인해 ListView의 ItemView 재사용 기능이 동작하지 않게 돼 앱의 성능을 악화시키는 원인이 되기도 했다.

ListView 문제점 - 4. 변경된 `Item Data`의 `Position`을 알 수 없음

ListView에 보여질 데이터가 바뀐 경우, 기존의 ListView의 Adapter는 데이터가 변경되었다는 사실만 알 수 있을 뿐 구체적으로 목록에서 몇 번째 데이터가 변경되었는지 인식할 수 없었다.
- 예를 들어, 사용자의 눈에 보이고 있는 ItemView 중 3번째 ItemView에 연결된 데이터가 어떠한 처리에 의해 바뀌게 되면 Adapter는 데이터가 바뀌었다는 사실만 알 뿐 몇 번째 ItemView에 연결된 데이터를 바꿔야 하는지는 알 수 없었다.
- 따라서 3번째 ItemView의 데이터를 바꾸기 위해 모든 ItemView에 데이터를 다시 연결해야 했다
- → 이러한 문제는 애니메이션 처리를 더욱 어렵게 만드는 원인이 되기도 했다.
위와 같은 문제들이 발생하자 Google Android API 개발팀은 Google I/O 2016에서 기존 ListView 설계에 실수가 있었음을 인지하고 이 실수를 반복하지 않고자 RecyclerView를 개발했다고 발표하였다

요약

ListView는 한번에 ItemView를 그리기 어려웠음
→ 속임수 1) 눈에 보이는 ItemView만 생성
→ 속임수 2) 맨위에 있던 ItemView를 그려져야할 위치에 재사용
→ 문제 1) 개발자들 요구사항 증가
→ 문제 2) 다른 뷰에서 제공하는 비슷한 기능이 ListView에 추가되며 혼란 → 문제3)애니메이션 처리 문제
→ 문제 3) 재사용될 ItemView인지 분기처리 필요
→ 문제 4) Adapter는 변경된 Item Data의 Position 알 수 없음
⇒ RecyclerView 등장

RecyclerView의 정의

RecyclerView는 안드로이드 프레임워크에서 제공하는 View 레이아웃 중 하나이다.
RecyclerView는 사용자가 관리하는 많은 수의 데이터 집합(Data Set)을 개별 아이템 단위로 구성해 화면에 출력하는 뷰그룹(ViewGroup)이며, 한 화면에 표시되기 힘든 많은 수의 데이터를 스크롤 가능한 리스트로 표시해주는 위젯이다
RecycleView는 Android Jetpack 구성 요소 중 하나이기 때문에 안드로이드 프레임워크에서 라이브러리 형식으로 제공하고 있다.

→ 개발자는 이 라이브러리를 가져다 사용해서 원하는 모양대로 응용하기만 하면 되는 것이다

RecyclerView의 성능 향상 방법

ViewHolder 패턴을 통해 ListView의 성능을 RecyclerView에서 크게 향상할 수 있었다. 재활용하는 View들의 클래스를 View 태그 또는 Array에 저장하고, 필요할 때 바로 가져와서 사용하는 방법으로 성능을 크게 향상하였다.
ListView에서 재활용되는 View를 해당 포지션에 맞게 가져오는 곳에서 성능을 향상할 수 있었다면,
RecyclerView는 가져온 View에 데이터를 Bind하는 경우 최적화할 수 있는 방법을 제공하고 있다.

RecyclerView의 동작 원리

RecyclerView는 내부 아키텍처는 컴포넌트 기반의 아키텍처이며, 내부 아키텍처를 구성하는 컴포넌트는 RecyclerView, LayoutManager, ItemAnimator, Adapter 등이며, 이 중 아래의 3가지 컴포넌트가 가장 중요하다
- 컴포넌트 기반 아키텍처: 이렇게 RecyclerView, LayoutManager, ItemAnimator, Adapter 등의 컴포넌트가 서로 상호작용하여 하나의 목록형 레이아웃을 동작하게끔 만들기 때문에 컴포넌트 기반 아키텍처

출처: https://medium.com/hongbeomi-dev/recyclerview-deep-dive-with-google-i-o-2016-21e0895819d2

이 3가지 컴포넌트가 적절하게 상호작용해야 ItemView를 올바르게 RecyclerView안에 배치할 수 있다

1. LayoutManager

LayoutManager 정의

LayaoutManager은 RecyclerView가 Item을 화면에 표시할 때, ItemVIew들이 RecyclerView 내부에서 배치되는 형태를 관리하는 컴포넌트이다
- LayoutManager는 선형, 그리드, 엇갈린 그리드 모양으로 RecyclerView의 모습이 보여지도록 하는 작업을 담당하는 컴포넌트이다
- Layoutmanager는 각각 LinearLayoutManager(선형), GridlayoutManager(그리드), StaggeredLayoutManager(크기가 각각인 엇갈린 그리드)로 분류된다
즉, RecyclerView는 자신이 어떤 모습으로 그려질지는 모르며, 오직 LayoutManager가 담당하며, RecyclerView의 모양을 만드는 작업을 책임지고, RecyclerView 모양에 따라 ItemView를 적절한 위치에 배치하는 작업을 담당한다.

LayoutManager가 하는일

(1) 만약 유저가 리스트를 더 보기 위해 RecyclerView를 위로 스크롤 했다고 가정해보는 경우,
(2) RecyclerView는 새로운 ItemView를 보여줘야한다는 것을 인식한다.

출처: https://medium.com/hongbeomi-dev/recyclerview-deep-dive-with-google-i-o-2016-21e0895819d2

(3) 하지만 새로운 ItemView를 어디에 배치할 지는 LayoutMananger가 알고 있다.
(4) 그러므로, 위 상황에서 RecyclerView는 LayoutManager에게 새로운 ItemView를 보여달라고 메시지를 전달한다.
(5) 그럼 LayoutManager는 적절한 위치에 데이터가 연결된 ItemView를 연결하게 된다.

2. Adapter

RecyclerView에서도 ListView와 동일하게 Adapter에 의존한다.
(다른 adapter처럼 뷰와 데이터를 Bind)
하지만 ListView Adapter와의 차이점은 ItemView 생성 외에도 ViewHolder라는 것을 생성하는 작업을 담당한다는 것이다.
- RecyclerView는 ViewHolder를 기본적으로 사용하기 때문에, View를 생성하지 않고, inflated(XML의 레이아웃이 메모리에 객체화된)뷰를 갖는 ViewHolder를 생성하게 된다.
  → ViewHolder가 생성되어 캐시가 쌓이면 필요할 때 재사용된다
- 이 때 기억해야 할 점은 ViewHolder는 position이 아닌 itemViewType에 의해 생성되는 것이다.
  → 이렇게 함으로써 재사용할 뷰를 더 쉽게 찾고 쉽게 추가할 수 있게된다.

Adapter가 하는 일

View와 ViewHolder를 만든다
ViewHolder에 아이템을 바인드
RecyclerView에게 데이터셋이 변경 되었을 때 이를 알린다
각각 데이터의 변경 이벤트를 처리
아이템의 상호작용(ex: 클릭)을 처리
ItemView의 ViewType이 여러 가지일 경우를 처리
재활용 실패에 대한 수습을 처리 (onFailedToRecyclerView)

`onBindViewHolder()`

onBindViewHolder()는 parameter로 ViewHolder 객체와 position 값을 받고 Return 타입은 없다.
- position 값은 Adapter 클래스 property 인 데이터셋의 특정 포지션이다.
  예를 들어 데이터 셋이 배열 자료구조로 구성되었으면 position은 배열의 특정 index인 것이다.
- ViewHolder객체는 데이터 셋의 특정 position에 저장되어 있는 아이템을 보여주기 위해 업데이트 되어야하는 ViewHolder이다
onBindViewHolder() 메소드는 특정 position의 데이터(item)을 보여주기 위해 RecyclerView가 호출하는 것이다.
즉 호출하는 주체가 RecyclerView인데 RecyclerView는 내부의 tryBindViewHolderByDeadLine()이라는 메서드 내부에서 mAdapter.bindViewHolder()를 호출한다.
- bindViewHolder()에서 onBindViewHolder()가 호출된다
즉 RecyclerView가 특정 상황이 발생했을 때 이를 알리기 위해 bindViewHolder를 호출하고,
이 알림을 받았을때 해야하는 작업을 우리가 Adapter내에 onBindViewHolder()메소드를 오버라이딩해 함수 내부에서는 RecyclerView.ViewHolder.itemView의 컨텐츠를 업데이트하는 작업이 실행된다.

→ 업데이트만하고 반환되는 작업이 없기에 onBindViewHolder()는 콜백함수라는 걸 알 수 있다

ViewHolder의 LifeCycle

ViewHolder의 LifeCycle는 대부분의 개발자들은 ViewHolder를 작성하는 것에 시간을 많이 쓰기 때문에, 아는 것이 매우 중요하다

ViewHolder Lifecycle - 1. Birth

1. 요구하는 ItemView가 캐시에 저장되어 있을 경우

출처: https://medium.com/hongbeomi-dev/recyclerview-deep-dive-with-google-i-o-2016-21e0895819d2

(When) 유저가 스크롤 이벤트를 발생시
RecyclerView가 LayoutManager에게 새로운 ItemView의 위치를 요구한다.
(1) LayoutManager는 메시지를 받고 → 어떤 포지션에 새로운 ItemView가 배치되어야 하는지를 계산하고
(2) 이 위치를 다시 RecyclerView에게 알리는데,
(3) 위치를 보내주고 이 위치에 배치할 ItemView를 요청한다.
(4) RecyclerView는 캐시에 해당 포지션에 배치되도록 지정된 ItemView가 있는지를 확인한다
(recyclerview.getViewForPosition())
(5) 만약 이 포지션에 배치되어야 하는 ItemView가 캐시되어 있을 경우
→ 이 ItemView를 받아서 다시 LayoutManager에게 전달한다.
(Recyclerview 내부 동작 원리 상 일정 양의 ItemView를 캐시에 저장해 놓기 때문)

2. 요구하는 ItemView가 캐시에 없을 경우

출처: https://medium.com/hongbeomi-dev/recyclerview-deep-dive-with-google-i-o-2016-21e0895819d2

(4) Cache에 저장된 ItemView가 없다는 메시지가 날아오면
(5) RecyclerView는 Adapter에게(RecyclerView → Adapter)
해당하는 ItemView의 ViewType을 getViewType 메소드를 통해 물어본다 (adapter.getViewType())
(6) Adapter는 해당하는 ViewType을 알려주고
(7) RecyclerView는 이 ViewType을 가지고 Recycled Pool에서 해당하는 ViewHolder가 있는지 물어본다 (getViewHolderByType 메소드)
- 여기서 사용하는 Recycled Pool은 공유되는 Recycled Pool일 수도 있고,
  오직 이 RecyclerView에서만 사용하는 유일한 Recycled Pool일 수도 있다.

3. Recycled Pool에 ViewHolder가 존재하지 않는 경우

출처: https://medium.com/hongbeomi-dev/recyclerview-deep-dive-with-google-i-o-2016-21e0895819d2

(8) ViewType에 대한 ViewHolder가 없을 경우
(9) RecyclerView는 Adapter에 새로운 ViewHolder를 생성하라는 지시를 내리고
(createViewHolder)
(10) Adapter는 생성한 ViewHolder를 RecyclerView에 전달

4. ViewHolder가 존재하는 경우 (이미 생성된 경우)

출처: https://medium.com/hongbeomi-dev/recyclerview-deep-dive-with-google-i-o-2016-21e0895819d2

Recycled Pool에 해당 ViewType을 위한 해당하는 ViewHolder가 존재하는 경우
(8) Recycled Pool은 ViewHolder를 RecyclerView에 전달하고
(9) RecyclerView는 Adapter에게 position과 ViewHolder를 넘겨주며 bind해달라는 명령을 내린다.
(10) Adapter는 bind 작업이 완료된 ItemView를 RecyclerView에 전달하고
(11) RecyclerView는 이 ItemView를 LayoutManager에게 최종적으로 전달한다

5. 마지막 단계

출처: https://medium.com/hongbeomi-dev/recyclerview-deep-dive-with-google-i-o-2016-21e0895819d2

(12) 마지막으로 LayoutManager는 해당 위치에 ItemView를 배치하고 RecyclerView에게 배치가 완료되었다는 메시지를 보낸다 (addView())
(13) 그러면 RecyclerView는 Adapter에게 해당하는 position에 ItemView가 잘 배치되었다는 메시지를 보낸다 (onViewAttachedToWindow())

⇒ 결국 전체 과정을 살펴보면 Layout Manager가 어떤 position에 배치될 ItemView를 요청할 경우 해당 ItemView가 Cache에 저장되어 있다면 Adapter를 거치지 않고 바로 Layout Manager에게 해당 ItemView를 전달할 수 있음을 알 수 있다.

요약

1) 레이아웃 매니저가 getViewForPosition 으로 view를 요청

2) RecyclcerView는 캐시에 getViewForPosition 으로 확인. 있으면 LayoutManager에게 반환

3) 캐시에 없으면 adapter에게 type이 뭔지 물어보고 Recycled Pool에 getViewHolderByType으로 요청

4) Pool에 있으면 반환, 없으면 adapter에게 createViewHolder로 아이템 생성

5) View를 찾으면 adapter에서 bindview를 하고 LayoutManager에게 Return.

6) LayoutManager는 RecyclerView에게 addView를 수행하고 adapter의 onViewAttachedToWindow 가 호출됨.

캐시와 Recycled Pool은 RecyclerView안에 이미 선언되어있음.

setItemViewCacheSize함수로 캐시 사이즈 변경 가능.

ViewHolder Lifecycle - 2. Recycle (ItemView를 캐시에 저장하는 원리)

ViewHolder의 Birth한 다음의 재활용 과정
사용자가 스크롤을 위로 올려 기존의 ItemView가 화면에서 사라지는 경우 일어나는 일

출처: https://medium.com/hongbeomi-dev/recyclerview-deep-dive-with-google-i-o-2016-21e0895819d2

(1) LayoutManager가 화면에서 벗어난 ItemView의 position을 계산하고 RecyclerView에게 이를 알린다 (removeAndRecycleView)그러면
(2) RecyclerView는 화면에서 ItemView를 제거한 후 Adapter에게 이를 알리게 되고, (onViewDetachedFromWindow()) → ItemView 안에 있는 것들의 캐싱을 해제할 수 있게 된다.
(3) RecyclerView는 Cache에게 제거되는 position의 ItemView가 캐시에 계속 남아있어도 되는 것인지를 Cache에게 물어본다.
- 만약, 이 ItemView가 사용된 지 오래된 ItemView라면,
  (3–1) Cache는 Recycled Pool에게 이 오래된 ItemView를 전달하고,
  (3–2) Recycled Pool은 Adapter에게 이 ItemView를 메모리에서 제거해도 된다는 메시지를 보낸다.
그렇지 않고 계속 캐시에 저장할 필요가 있는 경우,
(4) Cache에 계속 저장하라는 지시를 내리고, 이를 통해 나중에 LayoutManager가 해당 position에 대한 ItemView를 요청할 경우 Adapter를 거치지 않고 사용할 수 있다.

ViewHolder LifeCycle - 3. Fancy Reserves

LayoutManager가 다시 레이아웃을 계산하는 도중 adapter가 변경되는 경우이다.
몇몇 View가 더 이상 사용하지 않게 되었을 경우의 상황은 아래 그림과 같다.

출처: https://medium.com/hongbeomi-dev/recyclerview-deep-dive-with-google-i-o-2016-21e0895819d2

(1) RecyclerView가 LayoutManager에게 사용되지 않는 ItemView가 있음을 알린 후,
(2) 사라지는 ItemView들을 다시 ViewGroup에 추가한다.
그런 다음, (3) LayoutManager에서 이 ItemView들을 숨긴다.
이 때 (4) RecyclerView는 이 ItemView들에 대해 ItemAnimator에게 애니메이션 처리를 요구하게 되고, 애니메이션 처리가 끝나면 (onAnimationFinished)
(5) Adapter의 onViewDetachedFromWindow를 호출해 제거가 완료되었음을 알린다.
그 후 (6) Cache와 Recycled Pool에게 캐시를 업데이트하고 제거된 ItemView를 재활용하라고 지시한다.

ViewHolder Lifecycle - 4. Death

ViewHolder를 잃는 경우이다
이 경우 성능 문제가 발생하기 때문에 이는 매우 중요하다

Death Case #1

출처: https://medium.com/hongbeomi-dev/recyclerview-deep-dive-with-google-i-o-2016-21e0895819d2

1번째 ViewHolder 소멸은 ItemAnimator를 사용하지 않고 애니메이션을 구현하는 경우 발생가능하다
- (1) LayoutManager는 ItemView가 더 이상 필요하지 않고 이 ItemView가 transientState에 빠진 경우(애니메이션이 진행 중인 상태, 예를 들어 Fading out) 이를 RecyclerView에게 알리는데,
- (2) RecyclerView는 이 ItemView가 유효한지 확인한 후, 유효하지 않다면 이를 Recycled Pool에 알린다.
- (3) Recycled Pool에서 다시 한 번 transientState인지 확인하고, 해당 상태라면 재활용에 사용할 수 없으므로 Adapter의 onFailedToRecycle()을 호출한다.
- → 여기서 우리는 임의로 Adapter의 onFailedToRecycle의 리턴값을 true로 재구현해 Recycled Pool에게 “날 믿고 재활용해라” 라는 메시지를 전달 할 수도 있다.
- 하지만 기본적으로 Adapter의 onFailedToRecycle()을 호출하면 false를 리턴하도록 구현되어 있어서 ViewHolder는 파괴된다.
- → 이는 우리가 원치 않는 결과이며, ItemAnimator를 사용하지 않고 애니메이션을 구현할 경우 해당 상황에 빠질 수 있다.
- → ItemAnimator를 사용하면 올바른 Lifecycle 이벤트를 수신하여 ItemView를 재활용할 수 있게 도와준다.

Death Case #2

출처:https://medium.com/hongbeomi-dev/recyclerview-deep-dive-with-google-i-o-2016-21e0895819d2

(1) `RecyclerView`에서 `ItemView`에 대한 처리를 마쳤고 이를 `Recycled Pool`에게 알린다.
Recycled Pool은 제한된 크기를 가지고 있기 때문에 해당하는 `ViewHolder`에 대해 더 이상 남는 자리가 없는 경우 `ViewHolder`가 제거된다.
일반적으로 이는 다음과 같은 경우에 발생한다
    1. 많은 `ViewHolder`들이 같은 타입인 경우 캐싱이 되지않아 `Recycled Pool`로 넘어가서 제거되었다
    2. 모든 `ItemView`들이 애니메이션이 존재할 때, `notifyItemRangeChanged(0, getItemCount())가` 호출되면서, 애니메이션이 끝나고 이 `ItemView`들을 `Recycled Pool`에 다시 추가하려고하는데,
    이 때, R`ecycled Pool`은 이렇게 많은 아이템이 필요하지 않다고 판단하고 제거된다.
이름 방지하기 위해선 다음 방법을 사용할 수 있다.
- 1. 조금 더 세밀하게 adapter를 업데이트하기 (ex: notifyItemChanged(3))
- 2. pool.setMaxRecycledViews(type, count)를 통해 pool의 크기를 늘리기

RecycledViewPool

위에서 캐시와 Recycled Pool을 탐색하며, RecyclerView가 ViewHolder를 찾는 과정과, ViewHolder의 생성을 알 수 있었다. 그렇다면, RecycledViewPool이란 어떤 것일까?

public static class RecycledViewPool {
        private static final int DEFAULT_MAX_SCRAP = 5;

        public void setMaxRecycledViews(int viewType, int max) {
            ScrapData scrapData = getScrapDataForType(viewType);
            scrapData.mMaxScrap = max;
            final ArrayList<ViewHolder> scrapHeap = scrapData.mScrapHeap;
            while (scrapHeap.size() > max) {
                scrapHeap.remove(scrapHeap.size() - 1);
            }
        }

        public int getRecycledViewCount(int viewType) {
            return getScrapDataForType(viewType).mScrapHeap.size();
        }

        @Nullable
        public ViewHolder getRecycledView(int viewType) {
            final ScrapData scrapData = mScrap.get(viewType);
            if (scrapData != null && !scrapData.mScrapHeap.isEmpty()) {
                final ArrayList<ViewHolder> scrapHeap = scrapData.mScrapHeap;
                for (int i = scrapHeap.size() - 1; i >= 0; i--) {
                    if (!scrapHeap.get(i).isAttachedToTransitionOverlay()) {
                        return scrapHeap.remove(i);
                    }
                }
            }
            return null;
        }

RecycledViewPool은 RecyclerView.Recycler의 inner class이다.
getRecycledView의 parameter로 ViewType을 전달하면, ViewType에 맞는 ViewHolder를 return해준다는 것을 알 수 있고, ViewType마다 ViewHolder Pool을 가지고 있다는 것을 알 수 있다.
즉 캐시에서 원하는 ViewHolder를 찾지 못한 경우 마지막으로 RecycledViewPool의 getRecycledView로 해당 ViewType에 해당하는 ViewHolder를 달라고 요청하는 것이다
또한 상수로 DEFAULT_MAX_SCRAP =5로 선언되어 있는 것은 ViewType별로 가지고 있는 pool의 기본 용량이 5개라는 것이다
setMaxRecycledViews의 parameter로 ViewType과 pool이 가지고 있는 ViewHolder의 개수를 전달하면 pool의 용량을 늘리거나 줄일 수 있다.
- 이렇게 pool의 용량을 개발자가 직접 조절할 수 있다는 것은 매우 중요한데,
  만약 화면에 동일한 viewType을 가지는 아이템이 몇십개 존재하면 이들이 동시에 변경되어야 할땐 해당 viewType을 가지는 pool의 용량을 크게 설정하는 게 좋다.
  ViewHolder를 많이 저장해두면 재사용할 수 있는 ViewHolder도 많아지기 때문이다.
  반면 화면에 딱 하나만 보여지는 ViewType이 있다면 용량을 1로 설정하면 메모리를 절약할 수 있다
또 하나 중요한 점은 RecycledViewPool가 public으로 설정된 class라는 것이다. 즉 RecyclerView.RecycledViewPool() 처럼 RecycledViewPool 객체를 생성해 해당 Pool을 '공유'할 수 있다.
→ 즉 여러 RecyclerView들이 같은 Pool을 공유해 메모리를 절약할 수 있다.

Dirty View

위처럼 pool에 있는 View들을 dirty view라고 부른다.
dirty view는 pool에 들어올 때 View와 ViewType만 남기고 potition, flags등의 상태는 초기화 되기 때문에 pool에 존재하는 dirty view들을 꺼내 쓰려면 데이터를 다시 바인딩해주어야 한다.
반면 pool이 아닌 캐시에 있는 view는 position, flags등의 상태를 그대로 가지고 있기 때문에 바인딩없이 그대로 재사용할 수 있다.

Cache

원하는 ViewHoler가 있는지 RecyclerdViewPool에서 찾기 전에 Cache를 먼저 방문한다.
Cache는 ViewHolder로 이루어진 리스트로,
RecyclerdViewPool와 다르게 viewType으로 ViewHolder를 구분하지 않는다.
- 대신 "position"을 기준으로 탐색한다. 따라서 캐시에 있는 ViewHolder는 데이터를 다시 바인딩 할 필요 없이 원래 위치해 있던 position에 그대로 재사용 될 수 있는 것이다
- 예를 들어 가장 위에 있던 position 5 아이템이 위로 스크롤 되어 화면에서 벗어난 후 다시 아래로 스크롤되어 화면에 보여질 때 position 5 에 해당하는 ViewHolder가 cache에 있었다면 5라는 position을 다시 바인딩할 필요없이 바로 재사용 할 수 있다

요약
즉, ViewHolder를 cache에서 찾았다면 → view 변경없이 바로 재활용
pool에서 찾았다면 → 바인딩 필요
ViewHolder가 어디에도 존재하지 않으면 → 새로 생성되고 바인딩됨

ViewHolder 생성의 시점과 개수
(RecyclerView의 동작방식)

RecyclerView가 ViewHolder를 재활용하는 과정에서 가장 상단에 있는 View가 사라지면 해당 ViewHolder가 스크롤시 하단에 나타나는 View에 바로 재활용된다고 생각하기 쉽다.
그러나 ViewHolder는 "바로" 재활용 되지 않는다.
가장 처음 RecyclerView가 Adapter에 set 되었을 때 호출되는 콜백함수를 보면
1. RecyclerView가 화면에 onAttachedToRecyclerView가 호출되어 붙음
2. 화면에 총 4개의 ViewHolder를 그리기 위한 onCreateViewHolder 호출
3. LayoutManager가 addView를 호출해 itemView를 position에 잘 붙인 후 RecyclerView에게 알리면 RecyclerView는 Adapter에게 onViewAttachedToWindow호출

출처:https://velog.io/@dabin/안드로이드-공식문서-파헤치기-RecyclerView의-모든-것-2탄ViewHolder수명주기#recyclerdviewpool

중요한건, 화면에 최초로 보이는 4개의 ViewHolder를 생성하고 난 후 스크롤을 내렸을 때
바로 위에 있는 ViewHolder인 0번 holder가 사라지고 5번째 itemView가 나타나면서 0번째 ViewHolder를 재사용할 것이기 때문에 바로 onCreateViewHolder를 건너뛰고 onBindViewHolder를 호출할 것이라 생각한다.
하지만 5번째 itemView가 나타나며 또 ViewHolder를 생성한다.
8번째 itemView가 나타날때까지 ViewHolder는 재활용되지 않고 계속 생성된다.
→ 이는 RecyclerView가 사라진 ViewHolder를 '바로' 재활용하지 않기 때문에 나타나는 현상이다
계속 스크롤하다가 9번째 itemView가 만들어지는 순간 가장 먼저 detached되었던 0번째 ViewHolder가 onViewRecycled되어 나타난다. onViewRecycled는 "재활용할 홀더를 가지고 왔음"을 알리는 메서드이다.
이후 9번째 itemView부터는 onCreateViewHolder가 호출되지 않고 detached되었던 ViewHolder들이 차례로 onViewRecycled되어 재사용된다.

출처:https://velog.io/@dabin/안드로이드-공식문서-파헤치기-RecyclerView의-모든-것-2탄ViewHolder수명주기#recyclerdviewpool

정리하자면, 9번째 itemView가 나타났을 때 가장 먼저 사라졌던 0번째 홀더가 재사용됨을 알리는 onViewRecycled:0 이 호출되고 이 holder가 9번째 홀더가 되어 bind되는 것이다.
→ 이는 바로 ViewHolder를 재사용한다는 의미의 콜백인 onViewRecycled가 호출되지 않는다는 것을 통해 알 수 있다
이후 RecyclerView를 파괴하게 되면 화면에서 사라짐과 동시에 onDetachedFromRecyclerView가 호출된다.

RecyclerView Adapter 메소드 호출 순서

RecyclerView Adapter는 아래의 4개의 메소드를 통해서 데이터를 바인딩한다.
1. onCreateViewHolder
2. onBindViewHolder
3. getItemCount
4. getItemViewType
호출되는 순서를 살펴보면,
1. 예를 들어 단말 화면에 10개의 리스트가 보인다면, 맨 처음 getItemCount()가 호출되면서 총 item의 갯수가 몇개인지 판단한다.
2. getItemViewType()이 호출되면서, 현재 Item View의 Position에 해당하는 ViewType이 무엇인지를 판단한다.
3. onCreateViewHolder에서 ViewType에 해당하는 ViewHolder를 생성하여 리턴한다.
  (ViewHolder는 각 Item View의 정보를 가지고 있는 애이기 때문에, Adapter는 계속해서 ViewHolder를 이용하여 Item View를 관리할 것이다. )
4. onBindViewHolder에서는 생성된 ViewHolder와 Position을 전달받아서, 현재 Position에 맞는 data를 ViewHolder가 관리하는 View들에 binding한다.

→ getItemCount()가 1번 호출되고,
그 후 getItemViewType() → onCreateViewHolder() → onBindViewHolder()가 10번씩 호출될 것이다.

출처 및 참고자료

RecyclerView ins and outs - Google I/O 2016

RecyclerView Deep Dive with Google I/O 2016

Recycler View 제대로 이해하기 - RecyclerView lifecycle

[안드로이드 공식문서 파헤치기] RecyclerView의 모든 것! - 1편(구조, 탄생배경)

RecyclerView에 대한 모든 것

[안드로이드] Recyclerview 제대로 알고 쓰자 !

Pluu Dev - RecyclerView#ViewHolder에서 ViewTreeLifecycleOwner 사용법

안드로이드 개발 (34) RecyclerView 성능 향상

[Kotlin/Coroutine] 7. Coroutine 작성시의 테스트와 디버깅

Hodie! — Mon, 19 Jun 2023 00:18:02 +0900

Coroutine의 유닛 테스팅

Coroutine의 suspend Function들은 runblocking 코드블럭으로 수행하면된다.
다만, 동적으로 Scope를 만드는 경우에는 Dispatchers를 parameter를 넘겨받는 ViewModel을 사용해야 한다.

Android Architecture Component와 함께 사용

Android Architecture Component와 함께 사용하면, LifeCycle 관리등 장점도 많이 있지만, 주의해야할 점들도 있다.
Andorid 특징을 고려해서는 Coroutine 코드는 Viewmodel에 놓는 것이 적합하다.

`Job` Debug Mode

Debug mode에서 Job을 toString하면, 아래와 같은 형식으로 나온다.

“coroutine#1”:BlockingCoroutine{Active}@6d311334

Debugging `Coroutine` and `Threads`

Coroutine은 한 Thread에서 실행되어 다른 Thread에서 Resume될 수 있다.
심지어 Single-Threaded Dispatcher의 경우에도 어떤 일을 어디서 언제 수행하는지 알아내기 힘들 수 있다.
일반적인 Debugging 방법은 **Thread name을 Log로 출력**하는 것이다, 이는 Logging Framework를 통해 쉽게 할 수 있다,.
coroutine을 사용할 때, 쓰레드만 찍으면, context 정보를 충분히 알 수 없기 때문에, kotlinx.coroutine에 debugging 용도로 함수들이 들어가 있다.
'-Dkotlinx.coroutines.debug' *JVM option 과 함께 아래 코드를 실행하면Thread.currentThread().name 만 출력해도 *“main @coroutine#1” 과 같이 출력된다.
JVM 이 -ea 옵션으로 실행되는 한 debug mode 는 항상 켜져 있으며,
debug mode 일 때는 coroutine#1 의 숫자는 순차적으로 assign 되어 출력된다.

fun log(msg: String) = println("[${Thread.currentThread().name}] $msg")
 
runBlocking{
    val a = async{
        log(“I’m a”)
        6
    }
    val b = async{
        log(“I’m b”)
        7
    }
    log(“answer is ${a.await() * b.await()}”)
}

위의 경우 아래와 같이 3개의 Coroutine이 있다.
1. answer 를 print 하는 main coroutine (#1)
2. I’m a 를 print 하는 main coroutine (#2)
3. I’m b 를 print 하는 main coroutine (#3)

Naming Coroutine For Debugging

자동으로 Assign된 id도 로그를 자주 찍으면 상호관계를 보기에는 좋다.
그러나, coroutine이 특정 request의 processing에 묶여있거나, 특정 background task를 수행한다면, Debug 용도로 이름을 주는 것이 좋다.
CoroutineName도 Context Element로 Thread Name과 같은 기능을 한다.
- 마찬가지로 Debugging mode가 켜져 있다면, thread name과 함께 표시된다.

runBlocking(CoroutineName(“main”)){
    log(“Started main coroutine”)
    val v1 = async(CoroutineName(“v1coroutine”)){
        delay(500L)
        log(“Computing v1”)
        252
    }
 
    val v2 = async(CoroutineName(“v2coroutine”)){
        delay(1000L)
        log(“Computing v2”)
        6
    }
 
    log(“The answer for v1 / v2 = ${v1.await() / v2.await(){“)
}

/* OUTPUT */
[main @main#1] Started main coroutine
[main @v1coroutine#2] Computing v1
[main @v2coroutine#3] Computing v2
[main #main#1] The answer for v1 / v2 = 42

[Kotlin/Coroutine] 6. Coroutine의 Structured Concurrency(구조화된 동시성)

Hodie! — Fri, 19 May 2023 20:32:04 +0900

Structured Concurrency(구조화된 동시성)

누가 기존의 동작을 취소할 수 있는가?
해당 동작은 Application의 LifeCycle을 충분히 준수하는가?
예외가 발생하면 이를 누가 처리하는가?
→ 이에 대한 물음을 해소하기 위해 Coroutine은 Structed Concurrency를 내세운다.
이 개념을 베이스로 만들어진, Scope, launch나 async 블록을 사용하면,
개발자는 메모리 누수 및 동시성을 가진 Function들을 올바르게 처리할 수 있게 된다.

예시

GlobalScope.launch는 top-level Coroutine을 만든다.
- 비록 Light-Weight이기는 하나, 여전히 Memory를 비롯한 Resource를 사용한다.
  → 새롭게 luanch된 coroutine이 돌고있다는 사실을 잊는다면, GloabalScope는 process가 살아 있는 한, 계속 유지되기 때문에 로직이 계속 돌것이다.
- GlobalScope에 계속해서 launch하는 작업은, 반복해서 의미없는 코드가 돌거나, 너무 많은 Coroutine이 돌아 메모리면에서 OOM 현상이 발생할 수 있고, 관리면에서 쉽게 에러를 유발할 수 있다.
만약 GloablScope.launch만 사용한다면, 이를 관리하기 위해 reference(job)을 모두 가지고 있으면서 join을 수동으로 관리해야 한다 → 이는 에러를 발생시키기 쉬운 형태이다.
이러한 수동작업을 해결하기 위해, Structured Concurrency(구조화된 동기화)를 사용할수 있다.
이는 GlobalScope에서 launch 하는 대신, Thread를 사용하듯이 우리가 사용하는 Context 범위 내에서 특정한 Coroutine Scope를 만들고, 그 안에서 새로운 CoroutineBuilder로 Coroutine을 launch하는 것이다.
그렇게 시작하면 생성된 CoroutineScope가 코드블럭의 CoroutineScope에 더해진다.
= 모든 CoroutineBuilder는 코드 블럭에 “CoroutineScope” Instance를 추가한다.
1. Coroutine이 다른 Coroutine의 coroutinScope내에서 실행되면,
  CoroutineScopre.corotuineContext를 통해, Context를 상속받고,
  부모 Coroutine job의 자식이 된다.
2. GlobalScope는 부모 Coroutine의 영향을 받지 않는다.
따라서 외부 Scope는 내부의 Coroutine들이 종료되기 전까지는 종료되지 않으므로, 우리는 이 scope에서 join 을 명시적으로 부를 필요없이 coroutine을 launch하지 않는 간단한 코드를 만들수 있다.
→ 부모 coroutine은 항상 children의 완료를 기다리며, parent는 명시적으로 children의 launch를 track할 필요가 없고 Job.join으로 그들을 기다릴 필요도 없다.

runBlocking{
    val request = launch{
        repeat(3) { i ->
            launch{
                delay((i + 1) * 200L)
                println(“Coroutine $i is done”)
            }
        }
        println(“request: I’m done and I don’t explicitly join my children that are still active”)
    }
    request.join()
    println(“Now processing of the request is complete”)
}

  /* OUTPUT */
  request: I’m done and I don’t explicitly join my children that are still active
  Coroutine 0 id done
  Coroutine 1 id done
  Coroutine 2 id done
  Now processing of the request is complete

Coroutine 외부 블럭은 내부에서 실행되는 Coroutine이 모두 완료되야만 외부 블럭이 완료된다.

fun test2_1() {
    runBlocking {
        val jobs = List(10) {
            launch {
                delay(1000L)
                Log.e(TAG, "aaa")
            }
        }
        // join을 하고 안하고에 따라 End runBlock이 먼저 찍힐지 끝나고 찍힐지가 결정된다
        // jobs.forEach { it.join() }

        Log.e(TAG, "End runBlock ")
    }
    Log.e(TAG, "End function")
}

위 코드에서는 runBlocking coroutinebuilder로 함수에 coroutine 영역으로 만들었다.
그리고 그 안에서 새로운 coroutine을 launch한다 (list를 생성하면서 10개를 launch 시킴)
runBlocking은 내부 coroutine인 list의 열번이 다 수행될때까지 block 되며, launch로 실행한 비동기 동작(자식)이 모두 끝나야 runBlocking{} 블럭이(부모) 종료된다.
End runBlock aaa aaa ... End Function

End runBlock
aaa
aaa
...
End Function

로그는 위와 같이 나오며
주석처리된 join()을 넣으면, 아래와 같은 코드 실행순서가 보장되면서 찍힌다.

aaa
aaa
...
End runBlock
End Function

join은 실행 순서를 보장하기위해 쓰였다.
코드 순서를 보장하기 위해 내부 coroutine을 join시킬수도 있지만,
Coroutine Scope를 내부에 만들어 순서를 보장할 수도 있다.

fun main() = runBlocking { // this: CoroutineScope
    launch { 
        delay(200L)
        println("Task from runBlocking#2")
    }
    
    coroutineScope { // Creates a new coroutine scope
        launch {
            delay(500L) 
            println("Task from nested launch#3")
        }
    
        delay(100L)
        println("Task from coroutine scope#1") // This line will be printed before nested launch
    }
    
    println("Coroutine scope is over#4") // This line is not printed until nested launch completes
}

Task from coroutine scope#1
Task from runBlocking#2
Task from nested launch#3
Coroutine scope is over#4

coroutineScope을 이용하여 내부에 또다른 scope을 만든다.
위에서 모든 coroutine 블럭은 내부(자식) 코루틴이 모두 완료될때까지 대기해야 한다.
이런 이유로 "Coroutine scope is over"은 coroutineScope{...}이 끝날때 까지 기다렸다가 찍힌다

Vive Hodie

[Android/Project] 기존 앱에 Jetpack Compose 도입기: LazyColumn 활용

배경

개발 기능

기본 세팅

기존 앱에 Compose를 도입하기 위한 구현 순서

Implementation(구현)

Fragment

Custom Action Bar

Action bar Title 설정

좋아요 누른 유저 정보 레이아웃

Paging3

LazyColumn

User Layout

Glide Image

Follow Button

[Review] Google I/O Extended Seoul 2023 참석 후기

참 석 세션 요약

참석 세션

1. What's New in Android Development Tools

세션 소개

기억에 남았던 부분

2. Dagger Hilt로 의존성 주입하기

세션 소개

기억에 남았던 부분

3. Flutter에 Clean Architecture을 얹어보자

세션 소개

기억에 남았던 부분

4. 일 잘하는 개발자는 회사에서 어떻게 일할까?

세션 소개

기억에 남았던 부분

전체 후기

[Android/Refactoring] Memory Leak - 3. View's Reference는 Memory Leak의 대상일까?

이어지는 글

배경

View’s Reference에 대해 Null 처리하는 예시

AOSP에서의 코드

Memory Leak 발생의 가정

가정에 대한 증명

사고실험

사고실험의 결론

실제 수행을 통한 증명: Statical Analysis (Heap Memory 이용)

Report 분석

실제 수행의 결과를 통한 결론

결론

참고

[Android/Refactoring] Memory Leak - 2. 자주 발생하는 안드로이드 메모리 누수 방지하기

이어지는 글

Static References

예시

예시 2 (Static Context)

Binding leaks

Context

예시

Context의 사용법

예시 2 (ApplicationContext - Singleton)

Fragment Lifecycle vs ViewLifecycleOwner Lifecycle

Fragment에서 LiveData를 observing하는 경우, this 대신 viewLifecycleOwner 전달

FragmentStateAdapter Constructor에서 lifecycle 객체 대신 viewLifecycleOwner.lifecycle 전달

Threaded Code

예시

Handler Threads

예시

Viewpager

RecyclerView

SwipeRefreshLayout

기타

[Android/Refactoring] Memory Leak - 1. 안드로이드 앱에서의 메모리 누수 찾기

배경

Memory Leak이란?

Memory Leak을 탐지하는 방법

Android Studio Profiler

탐지 방법

LeakCanary

탐지방법

Leak Sources

LeakCanary 사용법

[모바일] 무한 스크롤과 디자인 윤리

개요

무한 스크롤이란

Fragment에서 LiveData를 observing하는 경우, `this` 대신 `viewLifecycleOwner` 전달

`OnCreate` Means “`create`”

Positions : `Adapter` vs `Layout`

`setHasStableIds`와 `getItemId`

`HasStableIds` 사용으로 최적화 호출이 가능한 조건

`setHasFixedSize`

2. `View` 및 `onBindViewHolder` 최적화

`onBindViewHolder`에서 복잡한 로직 피하기

`OnBindViewHolder`에서 `Html.fromHtml()` 사용 지양

부모 계층 `ViewGroup`이 `ScrollView` or `RecyclerView`

`item`에 복잡한 `drawable` 사용 지양

`ViewStub` 사용

`LayoutManager` custom을 통해 `onCreateView` 호출을 여러번 미리 가져오기 (`PreCache`)

`LayoutManager.setItemPrefetchEnabled(true, false)` 사용

`init` 시에만 `AsycLayoutInflate` 사용, UI 스케줄러 제작
(안드로이드 개발자 Phil Olson의 방식 )

AsyncLayoutInflater 를 사용해서 infalte, bind
(Dmitrii Kachan 의 방식)

`ViewHolder` paramter로 넘어가는 `View`를 `inflate` 해서 생성하지 않고 class로 만들기

등장 이전: `ListView`

ListView 문제점 - 1. `ListView`의 `ItemView` 생성속도

ListView 문제점 - 2. `ItemView` 애니메이션 구현의 어려움

ListView 문제점 - 3. `ItemView` 재사용 여부 분기 처리

ListView 문제점 - 4. 변경된 `Item Data`의 `Position`을 알 수 없음