Android : 초기화 로직을 담는 "App StartUp 라이브러리" 알아보기

들어가기 전에

이번에 소셜 로그인을 구현하여 각 로그인 별로 초기화 코드를 작성해줘야했다.

코드를 작성해주면서 내 고민은 

- onCreate와 init 중 어느 메서드에 포함해야할지

- 현재의 액티비티 클래스와  Application 클래스 중 어디에 작성해주어야하는지기준에 대한 것이었다. 

 

둘다 시도를 해보았지만 명확한 차이를 알기 어려워  멘토 개발자분께 질문을 드렸다!

개발자분께서는 별도의 초기화 모듈을 만들어서 진행할 수 있다고 말씀 주셨고 그 방식이 바로 App StartUp 라이브러리를 사용해서 초기화하는 것이었다!!

그래서 로그인 코드와 관련하여 내 코드를 App StartUp 를 사용하기 전후  코드를 비교하고 내용을 이해해보려한다! 

 

이전까지는...

이전에는 초기화해야하는 구성 요소에 관해 별도의 content provider를 정의해주어야했다. 그러나  content provider는 초기화 순서를 보장해주지 않고 비용이 많이 든다는 단점이 있었다.  하지만 이제 App startUp 라이브러리를 통해 단점을 극복 할 수 있다.

App startUp

startUp 라이브러리는 앱 시작 시 구성 요소를 초기화하고 종속항목을 명시적으로 정의하는데 효율적인 방법을 제공해주는 라이브러리다! 이 라이브러리를 통해서 시작 시퀀스를 간소화하고 초기화 순서 명시적으로 설정할 수 있다. 또한 앱 시작 시간도 개선된다고 한다!!

 

구성 요소 이니셜라이저 구현

이 라이브러리를 사용하여 시작 시 구성요소를 자동으로 초기화하려면 앱에서 초기화해야하는 각 구성요소의 구성 요소 이니셜라이저를 정의해야한다. 

 

Initializer<T> 인터페이스를 구현하는 클래스를 만들어서 각 구성요소 이니셜 라이저를 정의해준다. 

이 인터페이스는 2가지 메서드를 정의한다.

1️⃣  create 메서드  : 구성 요소를 초기화하는데 필요한 모든 작업을 포함하고 T 인스턴스를 반환한다.

2️⃣ dependencies 메서드 : 이니셜라이저에 종속된 다른 Initializer<T> 객체 목록을 반환한다. 이 메서드를 사용해서 앱이 시작될 때 이니셜 라이저를 실행하는 순서를 제어할 수 있다.

 

우선 startUp 라이브러리를 사용하지 않았을 때 초기화해주는 형태는 아래와 같았다.

 

카카오 초기화

startUp 라이브러리 적용 전  : Application 파일에서  초기화 로직을 담고 있다. 

@HiltAndroidApp
class FilmoApp : Application() {
    override fun onCreate() {
        super.onCreate()
        KakaoSdk.init(this, getString(R.string.kakao_app_key))

 

 

startUp 라이브러리 적용 후
startUp 라이브러리에서 구현해주어야하는 create 인터페이스와 dependencies 인터페이스를 통해 Initializer<T>를 정의하고 있다.

class KakaoInitializer : Initializer<Unit> {
    override fun create(context: Context) {
        KakaoSdk.init(
            context = context,
            appKey = context.getString(R.string.kakao_app_key),
        )
    }

    override fun dependencies(): List<Class<out Initializer<*>>> {
        return listOf()
    }
}

 

네이버 초기화의 경우

startUp 라이브러리 적용 전

class NaverInitializer : Initializer<Unit> {
    override fun create(context: Context) {
        NaverIdLoginSDK.initialize(
            context = context,
            clientId = context.getString(R.string.naver_client_id),
            clientSecret = context.getString(R.string.naver_client_secret),
            clientName = context.getString(R.string.naver_client_name),
        )
    }

    override fun dependencies(): List<Class<out Initializer<*>>> {
        return listOf()
    }
}

 

startUp 라이브러리 적용 후

class NaverInitializer : Initializer<Unit> {
    override fun create(context: Context) {
        NaverIdLoginSDK.initialize(
            context = context,
            clientId = context.getString(R.string.naver_client_id),
            clientSecret = context.getString(R.string.naver_client_secret),
            clientName = context.getString(R.string.naver_client_name),
        )
    }

    override fun dependencies(): List<Class<out Initializer<*>>> {
        return listOf()
    }
}

 

구글 로그인 초기화는?

구글 로그인 초기화는 왜 initilizer를 사용하지 않을까? 

구글 로그인은 별도의 초기화코드를 작성하지 않고  GetGoogleIdOption  객체 구현 후 GetCredentialRequest 객체를 구현하고  이를 통해 credentialManager을 이용하여  로그인이 이루어지기 때문에 초기화 코드가 필요하지 않다

 initializer 초기화 순서 정하는 방법

dependencies 인터페이스를 통해 실행 순서를 제어할 수 있다.

아래오 ㅏ같이 dependencies를 정의해준 경우 WorkMangerInitializer를 초함하므로 startUp은 ExampleLogger 전에 WorkManager를 초기화한다!

class ExampleLoggerInitializer : Initializer<ExampleLogger> {
    override fun create(context: Context): ExampleLogger {
        // WorkManager.getInstance() is non-null only after
        // WorkManager is initialized.
        return ExampleLogger(WorkManager.getInstance(context))
    }

    override fun dependencies(): List<Class<out Initializer<*>>> {
        // Defines a dependency on WorkManagerInitializer so it can be
        // initialized after WorkManager is initialized.
        return listOf(WorkManagerInitializer::class.java)
    }
}

 

내부 동작 뜯어보기

 

배운 점

이제 초기화 로직을 어떻게 구현해야할지 고민을 하지 않아도 되어서 좋다. 또한 별도의 모듈로 추출하는 점이 코드구조에도 효율적이라는 생각이 들었다.

아직 더 알고 싶은 점은 이렇게 startUp 라이브러리를 사용해서 시작되었을 때와 사용하지 않았을 때 시작 시간 개선에 얼마나 많은 영향이 있는지 직접 측정해서 차이를 비교해보아야겠다