출처: 안드로이드 공식 문서 (https://developer.android.com/guide/fragments/animate)

개요

Transition Animation은 기존에 떠있는 뷰가 다음 뷰의 위치와 연결되면서 움직이는 듯한 효과 를 얘기합니다. 마치 재활용 되는 듯한 느낌을 낼 수 있고, 보다 자연스럽게 화면 전환이 이루어지는 효과를 낼 수 있습니다.

이번 글에서는 Fragment에서 RecyclerView 아이템을 클릭했을 때 Transition Animation을 적용할 수 있는 방법에 대해 얘기할 것입니다.

원인

https://developer.android.com/guide/navigation/navigation-animate-transitions 위 링크에서 프래그먼트 대상으로 공유 요소 전환 이라는 섹션의 가이드를 따라해보면 이 방법이 RecyclerView에서 Fragment로의 작동되지 않는다는 것을 알 수 있습니다. (몸으로 꺠달았습니다)

이유는 다음과 같습니다

• TransitionName을 Unique하게 지어야 한다.

RecyclerView의 각각의 item에 동일한 TransitionName을 적용시켰기 떄문에 어디서 어떻게 움직여야 하는지 알 수가 없게 되어 작동하지 않게 됩니다.

그래서 유니크한 이름을 정할 수 있도록 작업을 진행하고, 이를 받을 수 있도록 작업한다면 Transition Animation을 만들 수 있습니다.

해결

가장 먼저 유니크하게 값을 줄 수 있도록 xml resource를 선언해줍니다.

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <string name="characterImageTransition">characterImage %s</string>
    <string name="characterNameTransition">characterName %s</string>
</resources>

이후 기본적으로 DataBinding을 사용하고 있다는 가정하에, RecyclerView의 각각의 아이템의 고유한 값을 적용시켜 StringValue를 완성시키면 됩니다.

    <data>

        <variable
            name="character"
            type="com.ssong_develop.core_model.Characters" />
    </data>
.... 중략 ....
    android:transitionName="@{@string/characterImageTransition(String.valueOf(character.id))}"

만약 앱이 API 14이하를 제공한다면, xml attribute가 아닌 직접 메서드를 호출하여 setTransitionName(name: String)적용시킵니다.

그 다음 Transition의 효과를 선언하기 위한 xml file을 하나 더 생성합니다

<?xml version="1.0" encoding="utf-8"?>
<transitionSet>
    <changeBounds />
    <changeTransform />
    <changeClipBounds />
    <changeImageTransform />
</transitionSet>

changeBounds : 장면의 변경 전후에 대상 뷰의 경계를 캡처, 전환 중에 해당 내용을 애니메이션으로 만듬 changeTransform : 뷰의 스케일(scale) 또는 회전을 캡처하고 전환 중 해당 내용을 애니메이션으로 만듬 changeClipBounds : 변경 전후 getClipBounds() 를 캡처 및 전환 중 해당 내용을 애니메이션으로 만듬 changeImageTransform : ImageView의 매트릭스를 캡처 및 전환 중 해당 내용을 애니메이션으로 만듬

그외에도 여러 attribute가 존재하지만 검색하시면서 사용하시길 바랍니다

여기까지 됐다면 이젠 연결만 남았습니다. 기존의 Adapter와 click을 연결한 interface 혹은 lamda를 수정해 애니메이션을 적용하고자 하는 view와 TransitionName을 인자로 넘겨줍니다

/** click interface **/ 
interface ItemClickDelegate {
    fun onItemClick(
        characterImageView: View,
        characterNameView: View,
        characterImageTransitionName: String,
        characterNameTransitionName: String,
        characters: Characters
    )
}

/** viewHolder **/
    override fun onClick(view: View) {
        itemClickDelegate.onItemClick(
            characterImageView = binding.ivCharacterImage,
            characterNameView = binding.tvCharacterName,
            characterImageTransitionName = binding.ivCharacterImage.transitionName,
            characterNameTransitionName = binding.tvCharacterName.transitionName,
            characters = characters
        )
    }

각각의 리사이클러뷰 구현이 다를테니 부분만 캡쳐해서 확인하였습니다. 이후엔 공식문서에 나와있는 대로 RecyclerView를 구현하고 있는 fragment에서 메서드를 호출하고FragmentNavigatorExtras를 적용해주면 끝이 납니다.

/** fragment **/
 override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        postponeEnterTransition()
        (binding.root.parent as? ViewGroup)?.doOnPreDraw {
            startPostponedEnterTransition()
        }
        ... 중략 ...
    }

    override fun onItemClick(
        characterImageView: View,
        characterNameView: View,
        characterImageTransitionName: String,
        characterNameTransitionName: String,
        characters: Characters
    ) {
        val bundle = Bundle()
        bundle.putParcelable(CHARACTER_KEY, characters)
        val extras = FragmentNavigatorExtras(
            characterImageView to characterImageTransitionName,
            characterNameView to characterNameTransitionName
        )
        findNavController().navigate(
            R.id.action_characterFragment_to_characterDetailFragment,
            args = bundle,
            navOptions = null,
            navigatorExtras = extras
        )
    }

결론

이와 같은 방법을 통해서 RecyclerView와 Fragment간의 Transition Animation 구현을 만들었습니다.

예시코드

https://github.com/SSong-develop/RickMorty

https://developer.android.com/topic/architecture/ui-layer

안드로이드 개발문서 중 아키텍처와 관련된 내용을 다루고 있는 페이지 입니다. 아키텍처의 레이어 중에서 Ui 레이어에 대한 설명이 자세하게 나와 있으니 이를 확인하시면 좋을 거 같습니다. 이 글은 위의 글을 읽고 생각을 정리하고 다양한 방법을 적어놓은 글입니다.

내용

프로젝트를 진행하면서 느끼는 거지만 UI는 확실히 단편적인 것이 좋은거 같다. 안드로이드 프로그래밍을 하다보면 많은 스트림(Flow, Observable, etc..)들이 생겨나고, 스트림들을 엮어서 다른 상태의 스트림을 다시 만들어낸다 (버튼의 활성화 조건, 혹은 여러가지 이벤트) 이 방법은 확실히 규모가 커지고, 화면 내에서 체크해야 하는 조건이 많아질 수록 가독성은 떨어지는 것 같다. 예를 한번 들어보자 아이디 와 비밀번호를 입력받고 원하는 조건이 성립하면 버튼을 활성화 해주는 로직을 ViewModel에 작성한다고 해보자 TwowayDataBinding과 StateFlow (혹은 LiveData)를 잘 알고 있는 개발자라면 이와 같이 작성할 수 있다.

class MainViewModel : ViewModel() {

    var idState = MutableStateFlow("")

    var passwordState = MutableStateFlow("")

    val enableState = combine(
        idState,
        passwordState
    ) { id, password ->
        id.length in 1..10 && password.length in 2..10
    }.stateIn(
        scope = viewModelScope,
        started = SharingStarted.WhileSubscribed(5000L),
        initialValue = false
    )
}

StateFlow는 항상 최신의 값을 emit할 수 있도록, BufferSize는 replay로 1를 걸어놨기 때문에 언제든 사용자의 인터랙션에 변화해 최신의 값을 반환한다. 그러므로 이 로직자체에서 사이드 이펙트를 찾기는 어렵다 물론 감춰지지 않은 var 필드의 setter를 이상한 레이어에서 사용한다면..그것도 사이드 이펙트라면 어마어마한 사이드 이펙트가 존재하긴 한다. 그러나 화면에서 조건이 늘어나서, 주소란과 상세 주소란이 생기고 전화번호까지 생겨난다면 어떨까? 그 조건에서 버튼의 활성 조건이 더욱 세분화 되고 다양해 진다면, combine(엮어진) 스트림인 enableState는 아마...처참해질 것이다.

그래서 최근 이러한 무분별한 스트림의 생성을 어떻게 하면 가독성이 좋게, 할 수 있을까 생각하다가 공식문서를 확인할 수 있었고, 그곳에서 새로운 방법을 찾아내었다.

class Main2ViewModel : ViewModel() {
    var uiState = MutableStateFlow(Main2UiState())
        private set

    fun updateId(id: String) {
        uiState.value = uiState.value.copy(id = id)
        updateButtonEnable()
    }

    fun updatePassword(password: String) {
        uiState.value = uiState.value.copy(password = password)
        updateButtonEnable()
    }

    private fun updateButtonEnable() {
        uiState.value = uiState.value.copy(
            buttonEnable = ((uiState.value.id.length in 1..10) && (uiState.value.password.length in 2..10))
        )
    }
}

data class Main2UiState(
    val id: String = "",
    val password: String = "",
    val buttonEnable: Boolean = false
)

결론부터 얘기하자면, 화면의 상태(State)를 나타내는 단 1개의 스트림을 두는 것이 좋지 않을까라고 생각했고, 공식문서에서도 이와 같은 방식을 권장했다. 이렇게 된다면, ui가 변경되는 변경지점을 제한할 수 있고, 무분별하게 스트림이 파생되어 가독성이 떨어지는 경우는 없을 것이다. 물론, 이게 완벽하다거나 규모가 늘어났을 때 가독성이 좋아진다!는 잘 모르겠다. 하지만 적어도 상태를 나타내는 단 하나의 스트림만 확인하고 이곳에서 부터 타고타고 가는 방식은 프로젝트에 대해 전혀 모르는 개발자가 보아도 이해할 수 있지 않을까 생각한다. 그외 뭐...변경가능성을 줄이고 이런 저런 여러가지 장점이 존재하는데 이는 위에 있는 공식문서를 확인하면 감사하겠다.

<개인적 의견> 이 방법이 오히려 fragment나 혹은 Compose에서 arguments를 받아서 처리해야하는 로직을 작성할 때 더 가독성이 좋다고 생각한다.

class Main2ViewModel @Inject constructor(
   private val savedStateHandle: SavedStateHandle
) : ViewModel() {
    var uiState = MutableStateFlow(Main2UiState())
        private set

    // (1)
    init {
       savedStateHandle.get<String>("transferData")?.let {
           uiState.value = uiState.value.copy(id = it)
       }
    }

    fun updateId(id: String) {
        uiState.value = uiState.value.copy(id = id)
        updateButtonEnable()
    }

    fun updatePassword(password: String) {
        uiState.value = uiState.value.copy(password = password)
        updateButtonEnable()
    }

    private fun updateButtonEnable() {
        uiState.value = uiState.value.copy(
            buttonEnable = ((uiState.value.id.length in 1..10) && (uiState.value.password.length in 2..10))
        )
    }
}

data class Main2UiState(
    val id: String = "",
    val password: String = "",
    val buttonEnable: Boolean = false
)

1번과 같은 식으로 표현이 가능해지는데, 만약 개별 스트림으로 작성해서 표현한다면

class MainViewModel @Inject constructor(
   private val savedStateHandle: SavedStateHandle
) : ViewModel() {

    val transferData = savedStateHandle.getStateFlow<String>("transferData")

    var idState = MutableStateFlow("")

    val combined = combine(transferData, idState) { data, id -> ... }

    var passwordState = MutableStateFlow("")

    val enableState = combine(
        idState,
        passwordState
    ) { id, password ->
        id.length in 1..10 && password.length in 2..10
    }.stateIn(
        scope = viewModelScope,
        started = SharingStarted.WhileSubscribed(5000L),
        initialValue = false
    )
}

이런식으로 작성이 되는데, 나의 경우엔 첫번째 방법이 좀 더 보기에 좋지 않나 싶긴하다.

앞으로 이러한 내용을 표현하는 다양한 방법이 존재한다면 이곳에 적어두려고 한다. 예제 코드는 아래 링크에서 확인할 수 있습니다.

https://github.com/SSong-developSampleAndroid/SampleUiState

Android Memory Types

Random Access Memory(RAM)

• RAM은 Application을 실행하는 동안 임시로 저장하는데 사용
• 여기서 Application은 현재 Foreground에서 돌고 있는 App과 Background에서 돌고 있는 App을 의미한다.
• 이것은 임시적이여서, App이 죽거나, 기기가 재시작되면 정보를 잃게 된다.

zRAM

• RAM에 일부로서 사용되지 않는 자원을 압축, 예약된 영역으로 이동해 사용 가능한 메모리량을 늘리는 역할을 한다.
• 이러한 압축하는 과정에서 CPU의 작업을 더 많이 필요로 하기 때문에 장치 작업을 느리게 할 수 있다.

Storage

• 기기가 재부팅되어도 유지되어야 하는 데이터, 사진, 비디오, 음악, 문서등을 가지고 있다.
• 예로는 SharedPreference , SQLite , Realm 등이 존재한다.
• Android의 스토리지는 다양하지만, 현재의 스토리지는 일반적으로 32GB , 64GB , 128GB , 256GB로 상당히 많은 용량을 할 수 있다. (Galaxy S21 기준 256GB인데 microSD카드는 사용하지 못하도록 한다.)
• microSD 카드 같은 것을 통해서 더 확장할 수도 있다.(최근 나온 것은 안되게 하는 경우도 존재한다)

메모리 관리 프로세스는 안드로이드 런타임(ART)와 그 이전 버전인 달빅 가상 머신으로 수행이 된다.

What are memory leaks

그럼 이제 메모리 릭이 왜 나는지를 알아야 하는데, 그전에 그렇다면 JVM은 운영체제에게서 받은 메모리를 어떻게 구분해서 사용하는지를 다시 기억을 되새김해봅시다.

JVM Runtime Data Area

기본적으로 큰 영역은 3가지입니다.

Method Area(메서드 영역)

• 코드에서 사용되는 클래스(~~.class)들을 클래스 로더로 읽어 클래스별로 런타임 상수풀 , 필드 데이터 , 메소드 데이터 , 메서드 코드 생성자 코드 등을 분류해서 저장합니다.
• 이 영역은 JVM이 시작할 때 생성되고, 모든 스레드가 공유하는 영역이 됩니다.

Heap (힙)

• 객체와 배열이 생성되는 영역
• 즉, 인스턴스와 배열이 동적으로(dynamic) 생성되는 공간입니다.
• 이곳에서 생성된 객체와 배열은 JVM 스택 영역의 변수나 다른 객체의 필드에서 참조를 하게 된다.
• 참조하는 변수나 필드가 존재하지 않는다면, 의미가 없는 객체로 판단하고 이를 GC가 힙에서 자동 제거 한다.
• 힙에 대해서 자세히 알고 싶다면 아래 자료를 확인하면 될 듯 싶다.
• 지금은 힙 얘기를 하려는 것은 아니니 이 정도면 충분하다고 생각한다.

Java Heap (with GC)

Thread

• 위의 2 영역은 정확히 영역으로 구분 되지만 이 쓰레드는 여러개가 생성될 수 있다.
• 자바에서 쓰레드를 구성하는 요소는 PC Register , JVM Stack , Native Method Stack이다.

PC Register

• 현재 수행 중인 JVM Instruction 주소를 가짐

Native Method Stack

• Java 외의 언어로 작성된 네이티브 코드를 위한 Stack(JNI 같은걸 말하겠죠??)

JVM Stack

• 각 쓰레드 별로 1개씩 존재하고 스레드가 시작될 떄 할당된다.
• 이는 메서드를 호출할 때마다 프레임이라는 단위로 추가하고 메서드가 종료되면 해당 프레임을 제거하는 동작을 수행한다.
• 프레임 내부에는 로컬 변수 스택이 있고, 기본 타입 변수, 참조 타입 변수가 추가 되거나 제거 된다.
• 변수가 이 영역에 생성되는 시점은 초기화가 될 때, 즉 최초로 변수에 값이 저장될 때임
• 변수는 선언된 블록 안에서만 스택에 존재하고 블록을 벗어나면 스택에서 제거가 된다.
• 기본 타입 변수는 스택 영역에 직접 값을 가지고 있다.
• 참조 타입 변수는 값이 아니라 힙 영역이나 메서드 영역의 객체 주소를 가진다. ( 그림 1 참조 )

그림 1

이렇듯 Heap영역에서 만들어진 객체를 회수하기 위해서 Android에서는 GC(Garbage Collector)를 사용합니다.

Heap영역을 추적해 더이상 사용하지 않는 객체를 힙영역에서부터 회수함으로써 메모리 영역을 남기는 것이다.

그렇다면 생각을 한번 해보면 우리가 사용하지 않는 힙영역의 객체를 계속해서 유지하고 있다면 GC는 이 객체가 계속해서 사용중이라고 생각할 거고 쓰레기라고 생각하지 않을 것이다.

이는 즉 객체를 메모리에서 해제하지 못하게 되는 것이고 이때 메모리 릭이 발생한다.

이러한 데이터들을 하나 , 둘씩 제거하지 못한다면 어드샌가 UI는 굳고 뭐...앱이 망가는 그런 상태가 발생하는거죠 OutOfMemory가 발생하게 되는 것입니다.

자 그럼 지금은 자바의 예로 들었으니까 이를 Android에 대입해서 생각을 한번 해봅시다

MainActivity 1개만 존재하는 App이 있습니다

class MainActivity : AppCompatActivity(){

   override onCreate(savedStateInstance : Bundle?) {
       // 그냥 생각나는 대로 적은 겁니다 일단 있다고 합시다.
   }
} // (1)

이 상황에서 어떠한 다른 Thread를 생성하지 않았기 때문에 Main Thread 즉 UI Thread만 존재합니다.

그럼 MainThread 의 JVMStack 영역에는 MainActivity class에 대한 값이 있어야 하는데

그 값이 실 객체 값을 가지는 Call by Value 형태가 아닌 Heap 영역에 MainActivity에 대한 구현체는 있고 JvmStack에는 MainActivity 클래스의 주소인 주소 값만을 가지고 있는 형태가 될 것입니다.

뭐 기타..여러가지 Context라던가 이러한 Activity를 구성하기위한 여러가지 상위 객체들 또한 Stack에 올라가있는 형태가 되겠지요(MainThread Stack에)

여기서

class SingletonExample(context : Context) {
   private var mContext = context 

   companion object{
       var instance : SingletonExample? = null

       fun getSingleton(context : Context) : SingletonExample {
            if(instance == null) {
                instance = SingletonExample(context)
            }
            return instance as SingletonExample
       }
   }
}

이와 같은 SingletonExample이라는 클래스를 만들어 Context를 Singleton 형태로 받을 수 있도록 해봅시다. ( 예시일 뿐입니다 결코 좋은 형태가 아닙니다. )

class MainActivity : AppCompatActivity(){

   override onCreate(savedStateInstance : Bundle?) {
       val singleton = SingletonExample.getSingleton(this)
   }
} // (2)

여기서 singleton이라는 객체는 kotlin이라서 안적혀 있지만 new라는 것을 통해서 동적으로 생성된 객체입니다.

SingletonExample이 MainActivity에서 호출된 시점부터 SingletonExample은 MainActivity의 Context를 가지게 된 것이고 MainActivity가 죽게 되더라도, 즉 JVMStack영역에서 참조되는 것이 사라져 GC에서 제거 대상으로 포함해 제거를 하더라도, SingletonExample에서 계속 참조 중이기에 인스턴스를 아직 사용하고 있다고 간주하고 회수를 할 수 없게 됩니다. 이러한 상황이 메모리 누수를 일으킬 수 있게 됩니다.

일반적인 누수 패턴

1) 정적 참조에 대한 Activity 누수

Activity는 여러번 만들어지고 제거될 수 있는 객체이다.

하지만 정적 참조로 Activity를 참조한다면 앱이 메모리에 있는 동안 계속 유지되기 때문에 생명주기에 의해 제거되어도 GC가 수거할 수 없다.

따라서 Activity에서 정적 변수를 사용할 때 매우 주의 해야한다. 만약 정적 변수가 Activity를 직접 혹은 간접적으로 참조할 가능성이 있는 경우 onDestroy() 에서 참조를 끊어줘야한다.

세부적인 case

1. static 변수에서 Activity를 참조하는 경우
2. static View 에서 Activity를 참조하는 경우.
3. 싱글턴 객체에 Activity 참조를 넘기는 경우.

2) Inner & 익명 클래스 사용으로 인한 Activity 누수

inner class는 outer class 변수에 접근 가능하다는 특징이 있다. 이 경우 inner class는 outer class의 참조를 유지해야한다는 특성이 있기 때문에, 내부/익명 클래스가 outer class 보다 오랫동안 유지 될 경우 누수가 발생한다.

따라서 누수 위험을 피하기 위해서는 내부/익명 클래스는 정적 클래스를 사용한다.

주로 중요하게 작용하는 지점은 다음과 같다 Activity 내부에서 Thread, handler, AsyncTask 를 사용하는경우

3) 스레드 사용으로 인한 Activity 누수

스레드의 경우 Activity보다 오래 작업할 수 있다. 따라서 Thread의 작업을 onDestroy() 에서 종료해야한다.

메모리 누수가 일어나면 왜 좋지 않은가?

1. 메모리 부족

메모리 누수가 발생하면, 기존에 차지한 메모리가 반환되지 않는다. 이 상황에서 다시 메모리를 요청하며 결과적으로 더 많은 메모리를 차지하게 된다.

하지만 메모리에는 한계가 있기 때문에, 더 이상 메모리에 할당할 수 없다면 앱은 메모리 부족으로 인해 강제 종료 된다.

⇒ 메모리 부족으로 앱이 종료되는 경우 사용자 입장에서 강제 종료의 경험을 겪는다.

2. GC 발생시 UI렌더링과 이벤트 처리가 중단된다.

메모리 누수가 발생하면 결과적으로 Android 시스템은 GC를 빈번하게 일으키게 된다. GC가 발생하면 UI 랜더링 및 이벤트 처리가 중단된다.

안드로이드는 대략 화면을 16ms로 그린다고 한다. 만약 GC가 오래걸리면 안드로이드는 프레임이 떨어진다. ⇒ 결과적으로 사용자 입장에서 앱이 느리다는 것을 인지하게 된다. 또한 심각한 경우 ANR 조건으로 ANR이 발생할 수 있다.

사용자는 일반적으로 100ms~200ms 이상 걸리는 작업에서 앱이 느리다고 인지하게 된다.

3. 재현이 어려움, QA 테스트로 찾기 어려움.

안드로이드 시스템이 메모리 할당을 거부할 때를 재현하기에는 어려움이 있다.

더불어 크래시 리포트로 추론하기도 어려움이 있다.

그럼 어떻게 해야할까?

결국 프로그래머가 GC가 어떻게 작동하는지 잘 이해해야 한다.

그리고 메모리 누수를 찾기 위해서 코드 작성과 리뷰에 노력을 해야한다.

안드로이드에서 일부 코드가 의심스러울 경우 누수를 예측할 수 있는 방법을 소개하면 다음과 같다.

1. 안드로이드 스튜디오 메모리 프로파일러

   이 경우, 개발자가 결국 GC를 잘 이해하고 어디에서 누수가 날지 인지해야한다. 누수를 찾는 방법은 아래와 같은 순서를 거친다.

   1. 디버그 모드 실행
   2. 의심스러운 Activity로 이동하고 이전으로 돌아간뒤 다시 실행한다.(예측된 누수 상황 재현)
   3. 메모리 프로파일러 메모리 섹션 → GC 시작 버튼
   4. Dump java heap 버튼
   5. d 과정에서 .hprof파일이 열리는데 해당 뷰어에서 다음과 같은 작업으로 누수를 탐지할 수 있다. Activity 객체가 하나 이상인경우 누수가 있다는 것이다.
      • Analyzer Tasks 도구를 사용하여 누수되는 Activity 자동 탐지
      • Class List View 를 Package Tree View로 변경하여 Destory해야하는 Activity를 찾는다.
   6. 누수되는 Activity를 찾았다면 하단 참조트리 창에서 Activity를 참조하는 객체를 찾으면 된다.

2. Square - Leak Canary

   앱 액티비티들에 약한 참조를 만들어 GC 이후에 참조가 지워지는지 확인한다.

   그렇지 않은 경우 .hprof 를 이용하여(힙 덤프) 분석하고 누수 발생을 확인한다.

   만약 누수가 있는경우 알림이 표시되고 별도 앱을 통해 누수가 발생된 위치를 트리형태로 표시한다.

   주의) 개발/테스트 빌드시에만 Leak Canary를 설치하는 것이 좋다. 사용자 빌드 전에 개발자와 QA가 미리 메모리 누수를 찾기 위함.

결과적으로 프로그래머 자신이 GC의 작동과 어떤 경우에 누수의 위험이 있는지 잘 인지하고 이를 신경쓰고, 주의하여 코드를 작성해야한다.

1. Room DataBase에 Blob의 형태로 ByteArray를 담는다.

2. Flow로 ByteArray를 받아, 이를 map연산자를 활용해 ImageBitmap으로 변환 해 이를 LazyColumn에서 보여준다.

3. 이 과정에서 ImageCache를 위해 LruCache를 활용해 담아둔다.

이와 같은 방식으로 앱을 만드는데, LazyColumn에서 이미지를 보여주기는 하나 이미지가 2개만 되어도 렉이 걸린다. 무슨 이유인지 잘 모르겠다.

구조를 잘못 짠건지...뭔지..혹시나 이 글을 읽는 사람 중에 구조를 보고 이상하다 생각하면 댓글이든 뭐든 남겨줬으면 싶다.

https://github.com/SSong-develop/ImCrazyAboutTodo/blob/master/feature-todo/src/main/java/com/ssong_develop/feature_todo/subscreen/removetodo/RemoveTodoScreen.kt

https://leetcode.com/problems/letter-combinations-of-a-phone-number/

문제 해석

2 ~ 9까지 주어진 숫자에는 각각 알파벳을 형상화 한다. 예를 들어 2 -> a,b,c를 표현할 수 있다. 뭐 이런식으로 말이다. 이랬을 떄 숫자가 주어지면 만들 수 있는 문자열을 전부 나열하라는 문제다.

문제 해결

필요한 거

1. 각 숫자마다 매칭해 넣을 문자열 map
2. 완전 탐색 기술

코드

class Solution {
    val map = mapOf<Char,String>(
        '2' to "abc",
        '3' to "def",
        '4' to "ghi",
        '5' to "jkl",
        '6' to "mno",
        '7' to "pqrs",
        '8' to "tuv",
        '9' to "wxyz"
    )

    fun letterCombinations(digits: String): List<String> {
        val res = mutableListOf<String>()
        if (digits.isEmpty()) {
            return res
        }
        combination(res,digits,"",0)
        return res
    }

    fun combination(res: MutableList<String>,digits: String, temp: String, level: Int) {
        if (level == digits.length) {
            res.add(temp)
            return
        }
        val c = map.get(digits.get(level))
        c?.toCharArray()?.forEach {
            combination(res,digits,temp + it.toString(),level + 1)
        }
    }
}

핵심은 combination 함수인거 같다.

먼저 함수가 digits 문자열을 끝까지 탐색했는지를 알려 줄 수 있는 level 변수를 하나 둔다. 이후 재귀의 종결 조건을 level == digits.length로 하고, 종결되었을 경우, 만들어진 문자열 temp를 리스트에 넣고 종료한다.

재귀의 종결 조건을 만들었다면 재귀해야할 로직을 넣어줘야 하는데, 먼저 digits의 각 문자가 표현할 수 있는 문자들을 map에서 찾아내고, 각각 이 변수들을 반복해서 temp에 넣어주고 재귀를 반복하면 결국엔 temp변수에 가능한 문자열들이 생겨나게 될 것이다.

상태공간트리를 만들어서 문제를 푼다면 더욱 쉽게 이해할 수 있다.

https://leetcode.com/problems/number-of-islands/

문제 해석

간단한 DFS문제이다. (BFS로도 가능하다) 1이면 땅이고, 0이면 물이기 때문에 상하좌우를 탐색해서 1인 녀석들이 존재하지 않을 때까지 반복하고, 한 그룹이 끝났다면 +1을 해준다. 이런 식으로 반복해서 총 몇개의 그룹이 존재하는지 찾는 문제이다.

문제 풀이

나의 경우 처음으로 생각난게 BFS였다.(아직 부족해서 DFS가 바로 떠오르지 않나 보다..) 문제를 보자마자 이차원 배열 내에서 1을 찾는 순간 주변에 몇개가 있는지를 파악하고 전부 0이 된다면 +1 을 한다가 먼저 생각난거 같다. 생각을 조금만 전환한다면, 시작지점을 찾았다면, 상하좌우로 다시한번 너비로 탐색을 한다면 굳이 Queue를 사용하지 않고도 보다 깔끔하게 코드를 작성할 수 있다.

코드

<BFS>
class Solution {
    // 왼, 상단, 오른쪽, 하단
    private val nx = listOf(-1, 0, 1, 0)
    private val ny = listOf(0, 1, 0, -1)

    fun numIslands(grid: Array<CharArray>): Int {
        var cnt = 0
        // 방문 했는지에 대한 ARRAY가 있으면 좋은게 아니라 필요해 싯팔
        val visited = Array(grid.size) {
            BooleanArray(grid[0].size) { false }
        }

        val queue: Queue<Pair<Int, Int>> = LinkedList<Pair<Int, Int>>()
        for (i in 0 until grid.size) {
            for (j in 0 until grid[i].size) {
                if (grid[i][j] == '1' && !visited[i][j]) {
                    queue.add(Pair(i, j))
                    visited[i][j] = true

                    while (queue.isNotEmpty()) {
                        val pos = queue.poll()

                        for (k in 0 until 4) {
                            if ((pos.first + nx[k] < 0 || pos.first + nx[k] >= grid.size) || (pos.second + ny[k] < 0 || pos.second + ny[k] >= grid[0].size)){
                                continue
                            }
                            else {
                                if (grid[pos.first + nx[k]][pos.second + ny[k]] == '1' && !visited[pos.first + nx[k]][pos.second + ny[k]]) {
                                    queue.add(Pair(pos.first + nx[k], pos.second + ny[k]))
                                    visited[pos.first + nx[k]][pos.second + ny[k]] = true
                                }
                            }
                        }
                    }
                    cnt++
                }
            }
        }
        return cnt
    }
}

<DFS>
class Solution2 {
    fun numIsland(grid: Array<CharArray>): Int {
        if (grid.size == 0) return 0
        var result: Int = 0

        grid.forEachIndexed { i, it ->
            it.forEachIndexed { j, value ->
                if (grid[i][j] == '1') {
                    result += dfs(grid,i,j)
                }
            }
        }
        return result
    }

    fun dfs(grid: Array<CharArray>, i: Int, j: Int): Int {
        if (i < 0 || j < 0 || i >= grid.size || j >= grid[0].size || grid[i][j] == '0') {
            return 0
        }
        grid[i][j] = '0'
        dfs(grid,i + 1, j)
        dfs(grid, i - 1, j)
        dfs(grid, i, j - 1)
        dfs(grid, i, j + 1)
        return 1
    }
}

아이디어는 단순한 Boolean 값에 의존하는 것이 아니라 SingleSelection의 핵심은 선택한 포지션을 저장한다는 것에 있다는 것을 잊지 않는다는 것입니다.

간단하게 코드 설명을 한다면, Composable Scope 상단에

var selectedPosition by remember { mutableStateOf(-1) }

이 선언되어 있는 상태에서 각 아이템의 checkBox마다 선택 시, 선택 index를 담아두는 기능을 달아둡니다. 이후 선택을 표시해야할 경우, selectedPosition == index 인 경우 이므로 위의 코드 처럼 표현을 해준다면, 간단하게 singleSelection을 구현할 수 있습니다.

또한 기존의 리스트를 Flow로 받든, List 형태로 받던, selectedPosition 변수가 선택 index를 가지고 있기 때문에, 리스트 원소 접근에도 문제가 없습니다.

Question

저의 경우 저 selectedPosition 데이터를 Composable이 가져도 된다고 생각합니다. ViewModel에 있는 것보다 말입니다. ViewModel이 보관해야할 Business Data가 아닌 Ui Data에 가까워서 저는 이렇게 생각하긴 하는데, 다른 분들은 어떻게 생각하는지 댓글 남겨주시면 감사하겠습니다.

물론 반박도 좋습니다!!! 감사합니다.👍

안드로이드는 Callback의 연속이다. 당장 우리가 Default로 앱을 생성하게 되면 가장 먼저 만들어져 있는 것은 callback이다. ( override fun onCreate ) 이러한 callback 패턴에는 제약이 많이 생긴다. Retrofit을 사용한다고 예를 들어보자 Call객체를 활용해서 retrofit객체에 enqueue를 하게 되면 callback으로 우리는 이러한 형태의 로직을 작성하게 된다

object : Callback<Wrapper<Info, Characters>> {
                override fun onResponse(
                    call: Call<Wrapper<Info, Characters>>,
                    response: Response<Wrapper<Info, Characters>>
                ) {
                    // response가 성공이거나 실패이거나 등등의 내용의 Logic
                }

                override fun onFailure(call: Call<Wrapper<Info, Characters>>, t: Throwable) {
                   // 실패했을 경우의 Logic
                }

이러한 형태가 나쁘다는 것은 아니지만, 머리로 생각한 알고리즘을 코드로 풀어나가면서 부자연스러워진다. (개인적으로 난 그랬다. 이게 편하다면.. 이 다음의 내용은 읽지 않는 것을 추천한다.) 코드로 풀어나가기 힘들다는 게 어떤 의미인지를 생각해보면, callback은 한국말로 표현하자면 _"우리 이런 행동을 하기로 약속하고, 넌 저 약속을 어떻게 실행할지 나에게 보여줘!"_같은 느낌이다. 순전히 내 느낌이다. 그러나 세상의 요구사항은 그리 편하지 않다. 때론 callback이 아니라 값의 형태로 이를 받아내고 반환된 값으로 연속적으로 다른 행동을 할 수 있도록, 즉 _"이 작업을 하고 그 결과 값을 나에게 줘!!"_를 하고 싶어진다는 것이다. 이러한 표현방법을 할 수 있도록 Kotlin에서는 suspendCoroutine , CallbackFlow을 제공한다. Coroutine이며, Flow의 기본 지식이 있어야 사용하는데 수월함이 있다.

이 글은 suspendCoroutine, CallbackFlow를 어떻게 활용할지에 대한 글이지 내부가 어떻게 생겼는지를 얘기하는 글은 아닙니다. 추천하는 블로그 아티클은 https://tourspace.tistory.com/442?category=797357 여기입니다. 굉장히 잘 작성되어 있습니다.

공통점

suspendCoroutine, callbackFlow 둘다 callback의 결과를 반환받을 수 있다.

차이점

간단하게 얘기하면 suspendCoroutine -> 단일 객체 callbackFlow -> Flow 스트림을 반환한다.

callback을 진행하면 익명의 객체가 특정 상태일 떄마다 callback을 실행한다. 그때 값을 단 한번만 받아서 사용한다면 suspendCoroutine, 계속해서 callback이 참조된 함수를 호출하며 값이 계속 변할거 같다. 즉, observe 패턴이 적용되는게 더 어울릴거 같을 떄 callbackFlow를 사용한다.

구현

suspendCoroutine

    Repository.kt

    suspend fun fetchCharacter(page: Int): Wrapper<Info, Characters>? {
        val result = suspendCancellableCoroutine<Wrapper<Info, Characters>?> { continuation ->
            val callbackImpl = object : Callback<Wrapper<Info, Characters>> {
                override fun onResponse(
                    call: Call<Wrapper<Info, Characters>>,
                    response: Response<Wrapper<Info, Characters>>
                ) {
                    val res = response.body()!!.apply {
                        isNetworkSuccessTag = "success"
                    }
                    continuation.resume(res) {}
                }

                override fun onFailure(call: Call<Wrapper<Info, Characters>>, t: Throwable) {
                    // Wrapper 클래스에 성공과 실패를 나눠줄 수 있는 Value를 둬서 그걸로 Trigger해도 괜찮다,
                    // 대신 더미로 만든다던지 Response의 값이 전부 nullable하게 된다는 단점이 존재한다.
                }
            }
            // Coroutine scope이 cancel 될 때 호출된다.
            continuation.invokeOnCancellation {
                // Thread - safe한 함수만 호출되어야 한다.

            }

            service.fetchCharacter(page).enqueue(callbackImpl)
        }

        return result
    }

callbackFlow

Repository.kt

suspend fun fetchCharacterWithFlow(page: Int): Flow<Wrapper<Info, Characters>> =
        callbackFlow<Wrapper<Info, Characters>> {
            val callbackImpl = object : Callback<Wrapper<Info, Characters>> {
                override fun onResponse(
                    call: Call<Wrapper<Info, Characters>>,
                    response: Response<Wrapper<Info, Characters>>
                ) {
                    trySend(response.body()!!.apply { isNetworkSuccessTag = "success" })
                }

                override fun onFailure(call: Call<Wrapper<Info, Characters>>, t: Throwable) {
                    close()
                }
            }

            service.fetchCharacter(page).enqueue(callbackImpl)

            // coroutineScope 이 cancel 또는 close 될때 호출

            // ProducerScope block의 코드의 실행이 완료되고 나서 바로 종료되는 것을 막는 코드.
            // addListener로 특정 이벤트를 관찰하는 겨웅에는 callback이 호출되는 걸 지속적으로 관찰해야 하기 때문에 api를 사용해 지속적으로 callback을 전달 받을 수 있도록 flow를 유지한다.

            // awaitClose는 flow가 cancel되거나 close 될 떄(channel close()가 명시적으로 호출될 때) 해당 블록을 호출
            // 해당 block안에서는 resource를 해제하는 코드가 들어가야한다.
            awaitClose {
                cancel()
            }
        }

Navigation과 ViewModel Hoisting을 위해서 Hilt Navigation을 사용했습니다. 또한 이번에 Hilt 버전을 가장 최신인 2.43.2로 올리면서 Kotlin과 Compose 버전을 최신으로 올렸습니다. 버전을 최신으로 바꿈으로써 hiltViewModel()을 사용할 때 위와 같은 에러가 발생하며 앱이 크래쉬 나서 죽는 현상이 발생했습니다.

이슈 원인

원인은 찾는대로 글을 갱신하겠습니다.

이슈 해결법

• androidx.navigation:navigation-compose:${currentVersion}
• androidx.fragment:fragment-ktx:${currentVersion}

이 2개를 dependency에 추가하게 되면 이슈를 해결할 수 있습니다.

짐작으로는 fragment ktx에서 ViewModel을 만드는 factory가 사용되면서 navigate할 때 주입이 된것으로 보인는데 정확하게는 분석해서 원인란에 적어놓겠습니다.

개발자들은 편리함을 만들어 내기 위해 공부한다. 나는 이게 항상 모순됐다고 생각했다. 편리함을 위해, 보다 게으르기 위해 부지런히 공부하고 만들어낸다. 제목에서 _Wifi plugin_이라 붙여서 '플러그인 설정방법'으로 생각할 수 있는데 아쉽지만 이 글은 그런게 아니다.

그렇다면 이글은 무엇인가? 항상 나는 왜 이런게 탄생했을까? 에 대해 궁금해 하는 편이다. 이번 글도 그런것과 비슷하다. 저 플러그인이 왜 탄생했고, 어떤 귀찮은 일을 덜어준것일까? 에 대한 고찰이다.

adb

안드로이드는 리눅스 기반 "운영체제"다. 안드로이드 프로그래밍을 하면서 Application Layer(그..안드로이드 구성요소 그려진 사진을 생각하면 된다)에서 코딩을 하기에 나는 가끔씩 운영체제임을 놓칠 때가 있다.(그럼 안되는데..) 여튼 운영체제고 리눅스 기반이기에 명령어로써 모든 기능들을 할 수 있다. IO작업 또한 마찬가지이다. 여기서 adb는 안드로이드 장치를 조작할 수 있는 다리의 역할을 하는 녀석이다 원문은 Android Debug Bridge 말 그대로 다리다.

Wifi Connect

자 기계를 처리하는 명령어를 가진 녀석이 adb라는 것은 알았다. 그렇다면 왜 wifi plugin으로 adb 얘기를 꺼낸 것인가 그걸 알아야 한다. 결론부터 얘기하자면 adb 명령어로 안드로이드 기기를 wifi로 연결할 수 있고, 이를 대신 해주는 것이 plugin이라는 녀석이기 때문이다. 생각보다 방법은 심플하다.

1. 안드로이드 터미널을 켜든, 뭐든 터미널을 킨다(리눅스여야 한다. 난 윈도우이기 때문에 터미널에서 켰다) 1-1. terminal은 정확하게 특정 프로젝트를 만들어야만 쓸 수 있기 때문에 프로젝트 앱과 관련된 것들이 세팅되는 것이다.
2. wifi 연결을 하고 싶은 device가 usb로 컴퓨터와 연결 되어 있어야한다. 처음 한번은 필요하다. 또한 현재 내 안드로이드 기기가 연결된 wifi의 ip주소를 알아야 한다.
3. adb devices로 연결이 되어 있는지 확인
4. adb tcpip 5555로 포트번호를 설정한다. (5555가 기본임)
5. adb connect (wifi-ip)로 device를 연결한다. 이러면 끝이다. 심플하지 않은가?

그렇다면 plugin은 왜

저런 과정으로 adb가 안드로이드 운영체제와 연결이 되지만, 사람이 1개의 프로젝트만 할 수 없는지라 변경될 때마다 저 명령어를 쳐줘야 한다. 이는 usb 연결선을 항상 가지고 다녀야하는 귀찮음도 동반된다. 편할려고 한건데 생각보다 편해지지 않게 된것이다. 그래서 그런 것을 대신 해주는 plugIn이 나온게 아닐까 라고 생각한다.(물론 내 생각이다)

번외

adb명령어를 최근 자주 쓰게 되면서 안드로이드 apk 빌드 과정에서 재밌는 것을 찾았다. 우린 단순하게 ide에서 삼각형 버튼?을 통해서 기기에 apk를 빌드하는데 결국 그것들은 전부 명령어로써 이루어 질텐데 어떤 명령어로 될까?에 대한 궁금증이였다. window에서도 해볼 수 있다.

1. apk파일 폴더 경로까지 찾아간다.
2. Shift + 마우스 우클릭을 통해서 power shell로 shell을 연다
3. root 권한을 받은 상태에서 adb remount를 통해 기기의 read, write 권한을 얻어온다.
4. adb push (apk 경로)를 통해서 기기에 apk를 push 해놓는다.
5. adb shell ps를 사용해 현재 내 앱이 사용하는 process의 id값을 찾는다.(grep으로 찾아도 됨)
6. adb shell로 root 권한을 해제하고, 찾았던 pid로 프로세스를 죽인다.
7. 그렇게 되면 push 되었던 녀석이 process에 재생될 것이다. 이와 같은 방법으로 안드로이드가 빌드하고 있는게 아닐까 라고 생각했다.

꽤 재밌다.

https://programmers.co.kr/learn/courses/30/lessons/64061

풀이

여러가지 방법이 존재한다고 생각한다 처음에 생각했던 것은 board로 받아내는 것을 stack 리스트로 변경해서 표현하는 방식을 생각도 해봤는데 크기가 최대 30 * 30이라서 이 방법은 바로 접었다. 두번째로 무난하게 떠올랐던 것은 board의 size를 반복하는 i와 moves를 표현하는 j를 사용하여 board[i][j-1]의 값이 0이 아니면 stack에 담는 방법으로 문제를 해결했다. 이때 담는 과정 중에 stack.peek의 값이 같다면 넣지말고 pop하는 식으로 해 While문을 줄여서 사용했다

코드

// 처음에 생각한 거
fun solution2(board: Array<IntArray>, moves: IntArray): Int {
        var answer = 0
        val stack = Stack<Int>()
        for(i in 0 until moves.size){
            loop@for(j in 0 until board.size) {
                if(board[j][moves[i]-1] != 0){
                    stack.add(board[j][moves[i]-1])
                    board[j][moves[i]-1] = 0
                    break@loop
                }
            }
        }
        while(!stack.isEmpty()){
            val pop = stack.pop()

            if(!stack.isEmpty()){
                if(pop == stack.peek()){
                    answer += 2
                    stack.pop()
                }
            } else {
                break
            }
        }
        return answer
    }

// stack 연산을 굳이 빼서 하지 않고, board 반복문 내에서 처리
fun solution(board : Array<IntArray>, moves: IntArray) : Int {
        var answer = 0
        val stack = Stack<Int>()
        moves.forEach {
            for(i in 0 until board.size){
                if(board[i][it -1] != 0){
                    if(stack.isNotEmpty() && stack.peek() == board[i][it-1]){
                        answer += 2
                        stack.pop()
                    } else {
                        stack.push(board[i][it-1])
                    }
                    board[i][it-1] = 0
                    break
                }
            }
        }
        return answer
    }

https://programmers.co.kr/learn/courses/30/lessons/42889

풀이

문제 자체는 굉장히 심플했다. _Map_을 얼마나 자유자재로 사용하는가에 대해서 묻는 질문 같았다.(정작 나도 제대로 못 사용하고 있다;;;)

• 스테이지, 현재 멈춰있는 유저의 수를 담아줄 Map
• 스테이지, 실패율을 담아두는 Map

이렇게 2개를 활용해서 문제를 해결했다. 고민했던 부분은 분수를 어떻게 표현할까였는데, Kotlin의 기초적인 것을 까먹은거 같아서 굉장히 자괴감이 많이 들었던 문제다...

코드

fun solution(N : Int, stages: IntArray) : IntArray {
        var answer = IntArray(N)
        val m1 = mutableMapOf<Int,Int>() // 스테이지 번호, 현재 멈춰있는 유저 수
        val m2 = mutableMapOf<Int,Double>() // 스테이지, 실패율

        stages.forEach {
            if(m1.containsKey(it)) {
                m1[it] = m1.getValue(it) + 1
            } else {
                m1[it] = 1
            }
        }

        var users = stages.size

        for(i in 1..N) {
            if(m1.containsKey(i)){
                m2[i] = (m1.getValue(i) / users.toDouble()) // 분수 표현식이네요
                users -= m1.getValue(i)
            } else {
                m2[i] = 0.0
            }
        }

        val list = m2.toList().sortedByDescending { (_,value) ->
            value
        }

        for(i in 0 until N){
            answer[i] = list[i].first
        }

        return answer
    }

느낀점

분수를 표현하는 방법을 까먹지 말자...;;; 문제 푸는 것에 급급해서 가끔 자료형을 까먹거나 놓치는 경우가 많은거 같다. 이 점 유의해야할 거 같다.

최근 취업준비 때문에 오픈소스 프로젝트를 못했었다(굉장히 슬픈 일이야...😂) 지원서들을 적고나서 일단락 된 거 같아 다시 내 프로젝트들을 보면서 보안할 점이나 새로 만들어볼만한 것을 찾고 있었는데 그 중 ToDoReminder가 오픈소스 사이트에서 소개되고 있는거 같았다.

앱 링크 https://github.com/SSong-develop/ToDoReminder

웹사이트 링크 https://awesomeopensource.com/project/SSong-develop/ToDoReminder

느낀 점

이전 프로젝트가 올라간 적은 있어도 개인 프로젝트가 올라간건 처음인데, 생각해보면 오픈소스 프로젝트는 그냥 올라가도 되는게 맞는게 아닐까 생각한다. 결국 오픈소스니까..동의없이 크롤링 해가는게 맞는거 아닐까 생각한다. 그래도 이렇게 게시되어 유입된 사람도 있는걸 보니 뿌듯했다. 많은 이들이 이 프로젝트를 보고 도움을 받았으면 좋겠다. 그리고 도움 받았으면 좀 흔적으로...Star라던가 issue 같은걸 만들어 줘도 좋을거 같다.(그럼 내가 뿌듯할거 같음)

https://www.acmicpc.net/problem/2309

풀이

문제 해결 방법

첫번째로 9명의 난쟁이 중 가짜는 2명임을 알 수 있으므로 9C2 = 36가지 이므로 2중 for문을 사용해서 해결할 수 있는 문제다. (난쟁이의 수가 터문이 없이 커진다면 다른 방법을 선택해야하는데, 그 경우는 아직 모르겠다. 댓글로 남겨주면 행복할 거 같습니다.) 순서도를 그려보게 되면

이와같은 방법으로 문제를 해결할 수 있다.

자료구조

두번째로 입력받은 9명의 난쟁이 키 데이터를 어떻게 보관할 것인가이다. 결국엔 2개의 데이터를 제거해야하기 때문에 LinkedList에 데이터를 담는 것이 효과적이라고 생각한다. 하지만, 내가 처음 문제를 풀었을 때는 리스트 2개를 사용해서 문제를 해결했다;;;

코드

fun solve(){
        val l : ArrayList<Int> = arrayListOf()
        val tempL = arrayListOf<Int>()
        repeat(9){
            val h = readLine()!!.toInt()
            tempL.add(h)
        }
        l.addAll(tempL)

        for(i in 0 until l.size){
            for(j in (i+1) until l.size){
                val v1 = l[i]
                val v2 = l[j]
                l.remove(v1)
                l.remove(v2)
                if(l.sum() == 100){
                    l.sort()
                    l.forEach {
                        println(it)
                    }
                    return
                }else{
                    l.clear()
                    l.addAll(tempL)
                }
            }
        }
    }

문제를 처음 해결 했을 때는 리스트를 2개 사용했다 알고리즘 자체는 생각을 그대로 표현해서

1. 리스트에 data 2개 제외

2. 합이 100이 되는가?

3. 된다면 정답출력

4. 안된다면 원본 리스트를 다시 담는다. 이 알고리즘의 문제는 삭제가 빈번히 일어난다는 것이다. 효과적이지 못하다 그래서 두번째로 구현 했을 때는

   fun solve2(){
        val l = LinkedList<Int>()
        var total = 0
        repeat(9){
            val h = readLine()!!.toInt()
            total += h
            l.add(h)
        }
   
        loop@for(i in 0 until l.size - 1){
            for(j in (i+1) until l.size){
                if(total - (l[i] + l[j]) == 100){
                    val v1 = l[i]
                    val v2 = l[2]
                    l.remove(v1)
                    l.remove(v2)
                    break@loop
                }
            }
        }
        l.sort()
        for(element in l){
            println(element)
        }
    }

   LinkedList를 사용하였고, loop@ break@loop를 통해 2중 for문의 중지를 제어하였다. 또한 list의 값을 삭제하고 다시 담는 것이 아니라, total 변수에서 값을 차감해본 후 100이 된다면 list에서 삭제함으로써 삭제가 필요한 경우에만 발생하도록 하였다.

일기1에서 만들던 앱에서 부족한 점을 보완해서 만들어 냈다

앱 링크 https://github.com/SSong-develop/RickMorty

이전 일기 https://velog.io/@willow_ryu/%EC%95%B1%EB%A7%8C%EB%93%9C%EB%8A%94-%EC%9D%BC%EA%B8%B01

만들면서 어려웠던 점

Flow와 함수형 언어의 특징을 이용해서 App의 상태에 따른 View를 보여주고자 했다. 그러기 위해 Repository단에서 Flow를 반환하고 그 값을 기존의 값에서 연산자를 통해서 받는 식으로 앱의 구조를 작성해야 했는데, 그 구조를 잡는 과정에서 애를 꽤나 많이 먹었다. 물론 작성하고 나니 작동이 잘되는 거 같아서 다행이다.

https://programmers.co.kr/learn/courses/30/lessons/42839

내 생각

완전탐색의 전형적인 유형이다. 전부 다 해보고 그 중 되는 것들의 갯수를 세어 결과를 반환하는 방법으로 코드를 작성했다.

깨달은 점

BooleanArray를 사용한 checking 되는 방법은 잊지않고 상기시켜야 할 거 같다. 재귀 공부는 꾸준히...재귀 공부는 꾸준히...재귀 공부는 꾸준히... 또한 소수 판별을 할 때 Count 변수로 세면 시간초과가 뜬다. 나눠지는 수가 존재했을 때 false가 반환되는 함수 형태로 고쳐서 했더니 바로 문제를 해결할 수 있었다.

코드

``` class Problem2 { private val numberSet = mutableSetOf() lateinit var tempNumbers: String lateinit var check: BooleanArray

fun solve(numbers: String): Int {
    var answer = 0
    tempNumbers = numbers
    check = BooleanArray(tempNumbers.length)

    func(0, "")
    answer = numberSet.size
    return answer
}

fun func(depth: Int, strNum: String) {
    if (depth == tempNumbers.length) {
        var counter = 0
        if (strNum == "") return
        val number = strNum.toInt()
        if (number == 0) return
        if (number == 1) return

        if(isPrime(number)){
            numberSet.add(number)
        }
        return
    }

    for (i in tempNumbers.indices) {
        if (!check[i]) {
            check[i] = true
            func(depth + 1, strNum + tempNumbers[i])
            check[i] = false
            func(depth + 1, strNum)
        }
    }
}

fun isPrime(number : Int) : Boolean{
    for(i in 2 until number){
        if(number % i == 0) return false
    }
    if(number <= 1) return false

    return true
}

}

SOPT 28기 앱잼에서 만들었던 프로젝트인 "DooRiBon" 레포지토리가 어느 웹사이트에 등재된 거 같다. 조금 있으면 릴리즈 관련으로 일을 시작해야해서 프로젝트 확인 차 레포지토리를 보았는데 androidRepo.com 이라는 곳에서 방문한 사람이 존재했다.

유용한 라이브러리나 Repo들이 모여 있는 거 같은 사이트라 추천은 할 만한거 같다. https://androidrepo.com/

나의 느낌

사실 좀 깜짝 놀랐다. 해커톤 개념으로 만든 것이라 보안을 철저히 신경쓴 것도 아니였어서 이렇게 사람들이 보게 된다면 보다 코드를 잘 구성할 걸 이라는 생각도 했지만 한편으로 보안에 위배되는 건 아닌가 라는 생각을 하게되었다. 앞으로 개발할 때는 보다 철저히 보안에 신경써서 개발에 임해야겠다는 생각을 하게 됐다.

앱 링크 https://github.com/TeamDooRiBon/DooRi-Android

그래도 언제든 프로젝트를 보고 PR을 날려주는 것은 환영이다.

RickAndMorty라는 애니메이션을 보고 캐릭터를 설명해주는 api가 있지 않을까 싶었는데 아니나 다를까 쉽게 찾을 수 있었다. 그래서 최근 만드는 프로젝트에서 Flow와 Serialization을 사용한 Retrofit을 사용할 일이 있는데 공부할 겸 만들어 보았다.

앱 링크 https://github.com/SSong-develop/RickAndMorty

만들면서 어려웠던 점

이번 프로젝트는 각 브랜치마다 공부하는 기술을 적용해 다른 버전의 앱들을 만드는 걸 목표로 했기 때문에 만드는 모든게 공부다. LiveData를 Flow로 고치는 데만 오늘 3시간 정도 썼고, 사용하는 법만 알게 된거지 내부 동작은 공부하지 않아서 이 또한 공부해야한다. 또한 UI의 상태에 따른 View의 상태가 변할 수 있도록 처리를 해줘야 하는데 그 부분도 조금 약한거 같아 보완해야할 거 같다.

공부할거

1. Flow 이론 및 사용법
2. UI 상태 관리
3. Detail 화면 만들지 않아서 만들어야 함 😂

Options

링크를 타고 오신 분들은 언제든 코멘트를 남겨주신다면 감사하겠다!!

Come And PR!!!

개인적으로 ToDoReminder 라는 앱을 만들었는데, 여러 기술과 View를 커스텀하여 만든 첫번째앱이다 보니 많은 시간이 소요되고 있다.

앱 링크 https://github.com/SSong-develop/ToDoReminder

앱에 달력과 Spinner 그외 RecyclerView Item View까지 커스텀해서 들어가다 보니 작업하면 어지럽기 따름이다. 앱을 사용하는데는 큰 문제는 없는데, 문득 과연_ 내가 만든 커스텀뷰는 최적화를 잘 했는가???_ 에 대한 의문점이 생겼고 이를 분석해보았다.

OverDraw(오버드로)

첫번째로 확인해본 것은 OverDraw다. 오버드로라는 것은 앱이 같은 프레임 내에서 두번 이상 같은 픽셀을 그릴 때 오버드로가 발생한다. 그러므로 최대한 이러한 작업이 생기는 구간을 없애주는 것이 중요하다.

공식문서 https://developer.android.com/topic/performance/rendering/inspect-gpu-rendering?hl=ko#profile_rendering 보다 자세한 내용은 공식문서를 확인해주세요.

오버드로 설정을 켜고서 본 결과는 충격적이였다.

다시 색상을 봐도 어지럽다. Coordinator Layout이 들어가는 부분은 4회 이상의 OverDraw가 발생했고, 그외에도 2회,1회가 발생하는 곳들이 존재했고, 그 부분은 거의 RecyclerView에서 일어났다.

HWUI

두번째로 HWUI 프로파일링을 사용했다. 이걸 사용하게 되면 화면들이 반응하는 과정을 볼 수 있는데, 이 막대기가 곧 성능을 나타내기도 한다. 이것 또한 굉장히 어지럽다.

HWUI 프로파일링 막대기에서 나타내는 색상이 어떤 것을 의미하는 지는 위에 있는 공식문서를 확인하면 보다 자세하게 알 수 있다.

공식문서 https://developer.android.com/topic/performance/rendering/inspect-gpu-rendering?hl=ko#profile_rendering 보다 자세한 내용은 공식문서를 확인해주세요.

뷰가 처음 켜질 때 연산되는 내용 중 Vsync 지연과 관련된 내용이 많았고, 이는 과한 작업량을 의미하기도 합니다. 어쩔 수 없이 처음 켜지면 연산을 많이 해야하긴 하지만 어떻게 하면 저 하늘을 뚫을 듯 한 막대기를 줄일 수 있을지 고민해봐야 할 거 같습니다

]]> https://velog.io/@willow_ryu/%EC%8A%A4%EC%9C%95-%EB%9D%BC%EC%9D%B8-%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98Sweep-Line-Algorithm https://velog.io/@willow_ryu/%EC%8A%A4%EC%9C%95-%EB%9D%BC%EC%9D%B8-%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98Sweep-Line-Algorithm Fri, 24 Sep 2021 08:06:17 GMT 정렬을 사용하여 문제를 푸는 기법중 하나인 스윕 라인 알고리즘이다.

정렬된 순서대로 처리되는 이벤트의 집합으로 문제를 모델링 하는 방법

주로 O(N^2)의 시간복잡도를 갖는 방법으로 해결이 불가능하거나, DP를 사용하기에 메모이제이션 해야하는 데이터의 크기가 너무 클때 고려한다.

정렬 후 로직을 처리하므로 O(NlogN)의 시간 복잡도를 가진다.

예제

BOJ 2170 선긋기

https://www.acmicpc.net/problem/2170

내 생각

선을 겹쳐서 긋는 것에 대해서는 차이가 없기 때문에 좌표 위치만 확인하면 된다.

선이 어디서 시작하는지가 중요하기 때문에 x좌표를 기준으로 정렬을 진행한다.

이후 처음에 0번째의 left , right를 x와 y좌표를 담아두고, 반복하면서 다음 좌표의 y좌표가 기존의 left 보다 작다면 이는 연결되어 있는 녀석이라고 판단한다.

이 경우가 아니라면 연결되어 있지 않은 선분이라 판단하고, 연결되어 있던 정보를 계산한 후 새로운 x,y 좌표를 담아 다시 선분을 시작한다.

코드

class BOJ2170 {
    fun solve(){
        val n = readLine()!!.toInt() // 선 그은 횟수 , 최대 1,000,000임
        val list = mutableListOf<Pair<Int,Int>>()

        var left = (-1e9).toInt()
        var right = (-1e9).toInt()
        var result = 0

        repeat(n){
            val (x,y) = readLine()!!.split(' ').map { it.toInt() }
            list.add(Pair(x,y))
        }

        list.sortBy { it.first }

        for(i in 0 until n){
            // 만약 , x좌표가 기존의 right보다 작다면 , 이는 합칠 수 있는 선분임
            if(list[i].first < right){
                right = max(right,list[i].second) // 합침
            } else { // 합칠 수 없는 선분이라면 , 혹은 반복문의 첫번째 단계라면
                result += (right - left) // 그 전까지의 선분들을 전부 계산하고
                left = list[i].first // 새로운 왼쪽과
                right = list[i].second // 새로운 오른쪽으로 갱신후 다시 작업을 진행한다
            }
        }

        result += right - left
        println(result)
    }
}

깨달은 점

그리디 알고리즘을 하다보면 정렬한 후에 작업을 해야하는 경우가 있는데 정렬에 대해서 좀 더 공부가 필요하다고 생각했다.

시간복잡도에 보다 신경을 써야할 거 같다.

이와 관련된 문제는 쉽지 않다...😂

]]>