그런데 이상한 점이 있습니다. 처리하는 일은 많아졌는데 매출은 기대만큼 늘어나지 않습니다. 생산성이 높아졌다면 사업의 결과도 함께 좋아져야 할 것 같지만, 현실은 꼭 그렇지 않습니다.

사업가 알렉스 호르모지가 이야기한 레버리지의 관점에서 보면 이유는 단순합니다. AI는 일을 빠르게 만들어 주지만, 어떤 일을 해야 하는지까지 결정해 주지는 않기 때문입니다.

AI가 속도를 높여도 사업의 병목이 그대로라면 결과는 달라지지 않습니다.

핵심 요약

• AI는 일을 빠르게 처리하지만, 어떤 일을 해야 하는지 결정하지는 못합니다.
• 매출을 높이려면 도구보다 먼저 판매와 서비스 제공 구조를 점검해야 합니다.
• 가장 강력한 레버리지는 중요하지 않은 일을 멈추고 하나의 병목에 집중하는 의사결정입니다.

1. 생산성이 높아졌는데 왜 매출은 그대로일까?

레버리지란 적은 노력으로 더 큰 결과를 만들어 내는 힘을 뜻합니다. 그런 의미에서 AI는 분명 강력한 레버리지입니다. 반복 업무를 줄이고, 자료 조사와 초안 작성에 필요한 시간을 크게 단축해 줍니다.

문제는 남는 시간을 어디에 사용하느냐입니다.

업무 처리 능력이 늘어나면 예전에는 시간과 인력이 부족해 포기했던 일까지 다시 시작하게 됩니다. 매출에 직접적인 영향을 주지 않는 보고서를 더 만들거나, 고객이 요청하지 않은 기능을 추가하고, 중요하지 않은 회의를 더 자주 여는 식입니다.

중요하지 않은 일을 아무리 빠르게 처리해도 사업의 결과는 달라지지 않습니다. 오히려 해야 할 일이 많아졌다는 착각만 만들 수 있습니다.

AI는 속도를 높여 주는 도구이지, 방향을 정해 주는 도구가 아닙니다. 잘못된 방향으로 달리고 있다면 더 빠른 속도는 목적지에서 더 멀어지게 만들 뿐입니다.

2. 기술 없이도 수익을 높이는 구조의 힘

사업의 효율을 높이기 위해 반드시 새로운 기술이 필요한 것은 아닙니다. 때로는 판매 구조나 서비스를 제공하는 방식만 바꿔도 훨씬 큰 레버리지가 만들어집니다.

1:1에서 그룹 방식으로 바꾸기

한 시간 동안 한 명을 상담하던 사람이 같은 시간에 10명을 상담할 수 있다면, 단순 계산만으로 제공 효율은 10배 가까이 높아질 수 있습니다. 새로운 프로그램을 개발하지 않아도 서비스 구조를 바꾸는 것만으로 시간의 한계를 줄일 수 있습니다.

비동기 방식 도입하기

모든 상담을 정해진 시간에 실시간으로 진행할 필요는 없습니다. 고객이 질문을 남기고 담당자가 가능한 시간에 답변하는 방식을 도입하면 일정의 제약이 줄어듭니다. 고객은 기다리는 시간을 줄이고, 담당자는 비슷한 질문을 모아 더 효율적으로 처리할 수 있습니다.

영업 전에 충분한 정보 제공하기

가격, 서비스 방식, 자주 묻는 질문을 상담 전에 충분히 전달하면 영업 과정도 달라집니다. 고객은 자신에게 필요한 서비스인지 미리 판단할 수 있고, 영업 담당자는 구매 의사가 높은 고객과 더 깊은 대화를 나눌 수 있습니다.

이처럼 레버리지는 새로운 도구를 도입하는 것뿐만 아니라 기존의 일을 어떤 구조로 제공하느냐에 따라 달라집니다.

3. 가장 강력한 레버리지는 의사결정입니다

자동화보다 더 큰 효과를 만드는 것은 중요하지 않은 일을 하지 않기로 결정하는 것입니다.

잘못된 결정을 내린 상태에서 AI를 사용하면 실수도 더 빠르게 확대됩니다. 필요 없는 기능을 더 빨리 만들고, 효과 없는 광고 문구를 더 많이 생산하고, 읽히지 않는 보고서를 더 정교하게 작성하게 됩니다.

사업가에게 필요한 능력은 더 많은 일을 벌이는 것이 아닙니다. 지금 하지 않아도 되는 일을 제거하고, 가장 중요한 문제 하나를 선택하는 능력입니다.

한 번의 올바른 판단은 여러 사람의 업무 방향을 바꾸고 수백 시간의 낭비를 막아 줍니다. 반대로 잘못된 우선순위는 아무리 좋은 도구를 사용해도 만회하기 어렵습니다.

4. 우리 사업의 진짜 병목을 찾는 방법

사업을 성장시키려면 현재 가장 막혀 있는 지점, 즉 병목(Bottleneck)을 먼저 찾아야 합니다. 사업의 흐름은 크게 세 단계로 나눌 수 있습니다.

• 수요 창출: 상품을 알리고 잠재 고객을 유입시키는 단계
• 전환: 관심을 보인 고객이 실제 구매를 결정하는 단계
• 제공: 구매한 고객에게 기대한 결과를 전달하는 단계

어느 단계가 병목인지에 따라 해결해야 할 문제도 달라집니다.

• 신규 고객 유입이 부족하다면 메시지와 유입 채널을 점검해야 합니다.
• 문의는 많지만 구매로 이어지지 않는다면 제안, 가격, 신뢰 요소를 개선해야 합니다.
• 구매는 발생하지만 환불과 불만이 많다면 서비스 품질과 제공 과정을 살펴봐야 합니다.

신규 고객 유입이 문제인데 AI로 내부 보고서 시스템만 개선한다면 매출은 늘어나지 않습니다. 문의는 충분한데 구매가 일어나지 않는다면 자동화보다 제안을 먼저 개선해야 합니다.

새로운 AI 도구를 도입하기 전에 다음 질문부터 확인해 보는 것이 좋습니다.

1. 지금 사업의 성장을 가장 크게 막고 있는 숫자는 무엇인가?
2. 그 숫자를 개선하면 실제 매출이나 이익이 달라지는가?
3. 최근 데이터와 고객의 반응이 같은 문제를 가리키고 있는가?
4. 이 문제와 관계없는 업무 중 당장 멈출 수 있는 것은 무엇인가?

이 질문에 답할 수 있다면 AI를 어디에 사용해야 할지도 자연스럽게 분명해집니다.

결론: AI는 도구이고, 본질은 판단력입니다

모든 사업의 시간, 사람, 자본은 한정되어 있습니다. 사업가의 실력은 이 자원을 얼마나 많은 일에 나누느냐가 아니라, 가장 큰 결과를 만들 단 하나의 문제에 얼마나 집중하느냐에서 드러납니다.

AI는 그 문제를 해결하는 훌륭한 가속 장치가 될 수 있습니다. 하지만 무엇이 문제인지 찾아내는 일까지 대신해 주지는 않습니다.

AI를 더 많이 사용하는 방법을 고민하기 전에 먼저 물어봐야 합니다.

지금 우리 사업의 성장을 막고 있는 단 하나의 병목은 무엇인가?

그 답을 찾는 순간, AI는 유행하는 도구가 아니라 실제 성과를 만드는 레버리지가 됩니다.

자주 묻는 질문

AI를 도입하면 매출이 자동으로 늘어나나요?

아닙니다. AI는 업무 속도를 높이는 도구일 뿐입니다. 매출을 막고 있는 병목과 우선순위를 먼저 해결해야 AI의 생산성이 실제 성과로 이어집니다.

AI보다 먼저 확인해야 할 것은 무엇인가요?

수요 창출, 전환, 제공 중 어느 단계가 사업 성장을 막고 있는지 확인해야 합니다. 병목이 신규 고객 유입이라면 내부 자동화보다 메시지와 유입 채널을 먼저 개선해야 합니다.

기술 없이도 레버리지를 높일 수 있나요?

가능합니다. 그룹 상담, 비동기 응답, 상담 전 정보 제공처럼 서비스 구조를 바꾸는 것만으로도 같은 시간에 더 많은 고객에게 가치를 제공할 수 있습니다.

문제점

사용자는 플레이스토어로 이동하여 수동으로 업데이트 버튼을 눌러야하며, 업데이트가 끝날때 까지 기다려야 합니다. 업데이트시간이 오래걸리게 되면 이탈하게 되어 업데이트하고 있다는 사실을 인지하지 못하고 업데이트된 후 앱을 재 실행하지 않게 될 수 도 있습니다. 또한 베타/알파 테스터나 앱 출시를 단계적으로 배포 하게 될경우 해당 사용자는 플레이스토어로 이동해도 최신버전의 앱으로 업데이트 받지 못할 수도 있습니다.

AppUpdateManager

구글은 이런 오래된 업데이트 처리방식에 대해 지원 하기위해 AppUpdateManager를 라이브러리를 통해 추가하였습니다. AppUpdateManager를 이용하면 실제 업데이트 해야할지 질의할 수 있으며, 플레이스토어로 이동할 필요 없이 자연스러운 앱 업데이트를 처리 할 수 있습니다.

dependency

build.gradle에 아래와 같이 종속성을 추가합니다.

implementation 'com.google.android.play:core:1.6.1’

업데이트 체크하기

AppUpdateManager를 통해 appUpdateInfo로 현재 업데이트 상태를 가져올 수 있습니다.

val appUpdateManager = AppUpdateManagerFactory.create(this)
  
launch{
  val appUpdateInfo = appUpdateManager.appUpdateInfo.await()
  
  when(appUpdateInfo.updateAvailability()){
      UpdateAvailability.UPDATE_AVAILABLE ->{
         //업데이트 가능한 상태
      }
  }
}

appUpdateInfo를 가져오기 위해 addOnCompleteListener를 통한 Callback구조를 suspendCoroutine를 이용해 suspend 함수로 간단하게 만들수 있습니다.

suspend fun Task<AppUpdateInfo>.await(): AppUpdateInfo {
    return suspendCoroutine { continuation ->
        addOnCompleteListener { result ->
            if (result.isSuccessful) {
                continuation.resume(result.result)
            } else {
                continuation.resumeWithException(result.exception)
            }
        }
    }
}

UpdateAvailability 4가지 상태

• DEVELOPER_TRIGGERED_UPDATE_IN_PROGRESS : AppUpdateType.IMMEDIATE 타입을 통해 업데이트를 수행중인 경우
• UNKNOWN: 알수 없음
• UPDATE_AVAILABLE: 현재 최신버전이 아니며 업데이트가 필요한 경우
• UPDATE_NOT_AVAILABLE: 현재 최신버전이며 업데이트가 필요 하지 않은 경우

업데이트 수행하기

업데이트가 필요한 상황을 인지 했다면, 이제 실제로 앱 업데이트 동작을 수행하게 해야 합니다. 플레이스토어로 이동하는 방법이 아닌 AppUpdateManager.startUpdateFlowForResult()를 이용하여 2가지 타입의 업데이트 방법을 사용자에게 제공해 줄 수 있습니다.

appUpdateManager.startUpdateFlowForResult(
    appUpdateInfo,
    AppUpdateType.FLEXIBLE , // or AppUpdateType.IMMEDIATE
    activity,
    REQUEST_CODE_UPDATE)

즉시 업데이트

AppUpdateType.IMMEDIATE 타입을 사용하면 별도의 업데이트 UI를 표시하게 되며 사용자가 업데이트전 다른 작업을 하지 못하도록 블락시키게 됩니다. 강제 업데이트 해야 할 경우 적절합니다. 앱이 업데이트 되면 자동으로 어플리케이션이 자동으로 재시작됩니다. 업데이트가 완료 되는 경우 onActivityForResult()를 통해 결과를 확인 할 수 있습니다.

업데이트중에는 항상 업데이트 UI만 보여지게 하기위해서는 UpdateAvailability.DEVELOPER_TRIGGERED_UPDATE_IN_PROGRESS 상태로 처리하면 됩니다.

override fun onResume() {
    super.onResume()
    appUpdateManager.appUpdateInfo
        .addOnSuccessListener {
            if (it.updateAvailability() == UpdateAvailability.DEVELOPER_TRIGGERED_UPDATE_IN_PROGRESS) {
                appUpdateManager.startUpdateFlowForResult(
                    it,
                    AppUpdateType.IMMEDIATE,
                    activity,
                    REQUEST_CODE_UPDATE)
            }
        }
}

자연스러운 업데이트

AppUpdateType.FLEXIBLE 타입을 사용하는 경우 사용자에게 좀 더 자연스럽게 업데이트를 처리 할 수 있습니다. 사용자가 업데이트를 누르면 DownloadManager를 통해 업데이트할 앱을 백그라운드를 통해 다운로드 받으며, 다운로드 완료가 되면 사용자에게 별도의 UI를 통해 알리고 설치 할 수 있도록 처리합니다.

다운로드 진행사항을 InstallStateUpdatedListener를 통해 Callback받을 수 있습니다. 다운로드 완료시 사용자에게 방해가 안될 정도의 UI를 표시하여 설치를 유도합니다. 여기서는 Snackbar를 이용하였습니다. appUpdateManager.completeUpdate()를 호출하면 설치 UI로 넘어가게 되며 설치 완료시 자동으로 어플리케이션이 재실행됩니다.

val listener = InstallStateUpdatedListener {
    if (it.installStatus() == InstallStatus.DOWNLOADED) {
        Snackbar.make(coordinator_layout, "업데이트 버전 다운로드 완료", Snackbar.LENGTH_INDEFINITE)
                .setAction("설치/재시작", View.OnClickListener {
                    appUpdateManager.completeUpdate()
                }).show()
    }
}
appUpdateManager.registerListener(listener)

사용가능한 새 버전이 있음에도 불구하고 특정 기기나 계정에서 새로운 버전을 사용할 수 없을 수 있습니다. 해당 업데이트가 실제 구글 플레이앱에서 제공되는지 여부를 확인 하는것이 중요합니다. appUpdateInfo.isUpdateTypeAllowed()를 이용하면 실제로 업데이트 가능한지 확인 할 수 있습니다.

참고:
https://developer.android.com/guide/app-bundle/in-app-updates
https://proandroiddev.com/theres-a-new-update-available-75a2c5bda76e

WokrManager는 Android Jetpack의 일부로 1.0.0버전으로 얼마전 공개되었습니다. Google은 이미 JobScheduler, Firebase JobDispatcher와 같은 백그라운드 작업을 위한 라이브러리를 수차례 공개하였습니다. 또한 Everonet의 Android Job이 있습니다. WorkManager는 이미 공개된 라이브러리보다 많은 장점이 있습니다.

• 이전버전과의 호환성(API14이상 모두 지원)
• GooglePlay Service에 대한 의존성이 없음
• 체인기반의 작업 관리
• 작업 상태 쿼리가능

이제 프로젝트에 적용해봅시다!

항상 그렇듯 build.gradle에 종속성을 추가합니다.

allprojects {
    repositories {
        google()
        jcenter()
    }
}

dependencies {
    def work_version = 1.0.0

    // (Java only)
    implementation "android.arch.work:work-runtime:$work_version"

    // Kotlin + coroutines
    implementation "android.arch.work:work-runtime-ktx:$work_version"

}

백그라운드에서 일부 작업을 실행하는 예제를 보도록하겠습니다. 현재 좌표를 하루에 두번씩 서버로 전송하는 예제이며, 몇가지 제약조건이 추가됩니다. 기기가 Wi-Fi에 연결되어 있고 저장 용량이 부족하지 않은 경우에만 작동합니다.

class LocationWorker(context: Context, workerParams: WorkerParameters) 
    : Worker(context, workerParams) {
    
    ...
    
    override fun doWork(): Result {
        
        val latitude = inputData.getDouble(KEY_LATITUDE, 40.1903484)
        val longitude = inputData.getDouble(KEY_LONGITUDE, 44.5148367)
        
        val sendDataService = SendDataService.getInstance()
        sendDataService.sendLocation(latitude, longitude)
            .addSuccessCallback {
            
            }
            .addFailureCallback {
            
            }

        return Result.success()
    }
}

Worker가 생성되고, 주기적으로 실행되는 작업 공간의 큐에 추가됩니다.

fun createConstraints() = Constraints.Builder()
                        .setRequiredNetworkType(NetworkType.UNMETERED)  //와이파이 연결된 경우
                        // 다른값(NOT_REQUIRED, CONNECTED, NOT_ROAMING, METERED)
                        .setRequiresBatteryNotLow(true)                 // 배터리가 부족하지 않는 경우
                        .setRequiresStorageNotLow(true)                 // 저장소가 부족하지 않는 경우
                        .build()

fun createWorkRequest(data: Data) = PeriodicWorkRequestBuilder<LocationWorker>(12, TimeUnit.HOURS)// 12시간 반복
                .setInputData(data) // 입력 데이터                                                  
                .setConstraints(createConstraints()) // 작업을 재시도 할경우에 대한 정책
                .setBackoffCriteria(BackoffPolicy.LINEAR, 
                                PeriodicWorkRequest.MIN_BACKOFF_MILLIS, TimeUnit.MILLISECONDS)
                .build()

fun startWork() {
    // 입력 데이터를 설정합니다. Bundle와 동일합니다.
    val work = createWorkRequest(Data.EMPTY)
    
    /* 작업을 큐에 넣을때 동일한 작업인 경우에 대한 정책을 지정할 수 있습니다. 
    ExistingPeriodicWorkPolicy.KEEP은 동일한 작업을 큐에 넣게되며, 
    ExistingPeriodicWorkPolicy.REPLACE인 경우 작업이 대체됩니다. */
    WorkManager.getInstance().enqueueUniquePeriodicWork("Smart work", ExistingPeriodicWorkPolicy.KEEP, work)
    
    // 작업의 상태를 LiveData를 통해 관찰하게 됩니다. 
    WorkManager.getInstance().getWorkInfoByIdLiveData(work.id)
        .observe(lifecycleOwner, Observer { workInfo ->
            if (workInfo != null && workInfo.state == WorkInfo.State.SUCCEEDED) {
                // 작업 완료
            }
        })
}

앞서 WorkManager의 장점으로 소개 했던 체인기반의 작업에 대해서도 알아 보겠습니다.

fun chainWorks(filter1: Work, filter2: Work, compress: Work, upload: Work) {
  WorkManager.getInstance()
    // Worker를 동시에 병렬로 실행합니다.
    .beginWith(listOf(filter1, filter2))
    // 이전 beginWith의 모든 작업이 끝난 경우 실행됩니다.
    .then(compress)
    //compress작업이 완료 된경우 upload가 실행됩니다.
    .then(upload)
    //enqueue()를 호출해야 이 모든 작업이 실행됩니다.
    .enqueue()
}

Worker는 우리가 원했던 작업구현 방식입니다. doWork() 메소드에서 필요한 작업을 구현하면 됩니다.

WorkRequest는 Worker의 arguments(입력된 데이터)와 constraints(네트워크 연결) 작업을 당담합니다.

WorkManager는 WorkRequest를 큐에 담고 작업을 시작합니다. 이 작업을 스케쥴링 하기위해 Room 데이터베이스에 저장 하는 가장 좋은 방법을 사용합니다. 이 작업 결과는 LiveData를 통해 전송됩니다.

결론

WorkManager는 앱이 종료되거나 기기가 재시작되어도 실행되며, 비동기 작업을 구현하는 가장간단하면서 효과적인 솔루션입니다. 또한 제약사항을 통해 앱의 소비전력도 줄일 수 있습니다.

참고:
https://medium.com/@RobertLevonyan/android-workmanager-manage-periodic-tasks-c13fa7744ebd https://developer.android.com/topic/libraries/architecture/workmanager

앱에 많이 사용되고있지만 확실히 좋은 위젯은 아닙니다. FragmentPagerAdapter나 FragmentStatePagerAdapter를 사용할때 Fragment없이 ViewPager를 사용하면 안되는지에 대해 적어도 한번 이상은 궁금했었습니다. 그리고 RTL지원과 수직페이징 처리등 다양한 기능을 지원하도록 요청하였습니다. 오픈소스를 통한 솔루션은 있으나 공식적인 라이브러리 업데이트는 아직 없습니다. 지금까지 였습니다..

이제 모두 지원 합니다.

ViewPager2

프로젝트는 AndroidX로 구성하고 minSdkVersion 14이상을 지원해야 합니다. build.gradle에 아래 라이브러리를 추가합니다.

implementation 'androidx.viewpager2:viewpager2:1.0.0-alpha01'

RecyclerView에 익숙하다면 ViewPager2를 구성하는것은 매우 익숙합니다. RecyclerView.Adapter를 상속받아 어댑터를 생성합니다. 물론 ViewHolder도 필요합니다.

class AppPagerAdapter(private val apps: Array<String>) : RecyclerView.Adapter<AppViewHolder>() {
    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): AppViewHolder {
        return AppViewHolder(LayoutInflater.from(parent.context).inflate(R.layout.app_pager_item, parent, false))
    }

    override fun onBindViewHolder(holder: AppViewHolder, position: Int) {
        holder.txtApp.text = apps[position]
    }

    override fun getItemCount() = apps.size
}

class AppViewHolder(view: View) : RecyclerView.ViewHolder(view) {
    val txtApp: TextView = view.findViewById(R.id.txt_app)
}

마지막으로 RecyclerView와 마찬가지로 ViewPager2의 Adapter를 설정합니다. 여기서 RecyclerView에서 처럼 LayoutManager는 필요없습니다. ORIENTATION_VERTICAL를 통해 스크롤 하도록 성정가능합니다.

ViewPager2.orientation = ViewPager2.RIENTATION_VERTICAL

ViewPager2는 아직 알파버전인 단계로 버그나 문제점은 보여집니다. 하지만 ViewPager의 View 재사용성 문제를 RecyclerView의 ViewHolder패턴을 그대로 사용하면서 해결함과 동시에 RecyclerView에 익숙한 개발자들에게 별도의 학습없이 적용할 수 있게 솔류션을 제공하였습니다. 또한 orientation기능 도입으로 가로 스크롤뿐만 세로스크롤도 지원하게 되었습니다. 또한 RTL도 지원합니다!

추가 기능외 전 버전의 notifyDataSetChanged()가 실행되지 않는 문제를 해결하였습니다. getItemPosition에서 POSITION_NONE을 강제로 반환하도록 하여 문제를 회피했던 경험 모두 있으실것 같은데 이제 해결되었습니다.

알려진 버그 (1.0.0 알파 01기준)

-ClipToPadding 미지원
-TabLayout 미지원
-pageWidth 미지원(강제 가로/세로 100%)
-currentItem 설정시 이전 페이지 보이는 현상

async 블록이 예외를 throw하는 경우 try/catch블록으로 감싸는 것만으로 모든 예외를 처리 할수 있다는 것에 신뢰하면 안됩니다.

val job: Job = Job()
val scope = CoroutineScope(Dispatchers.Default + job)
// may throw Exception
fun doWork(): Deferred<String> = scope.async { ... }   // (1)
fun loadData() = scope.launch {
    try {
        doWork().await()                               // (2)
    } catch (e: Exception) { ... }
}

위의 예제에서 doWork() 함수는 처리되지 않는 예외를 throw할 수 있는 새로운 코루틴(1)을 시작합니다. try/catch 블록(2)으로 doWork() 함수를 감싸게 되면 충돌이 발생합니다.

이는 자식 Job이 실패 하는 경우 부모도 즉각적으로 실패 해버리기때문에 발생하는 문제입니다.

충돌을 피할 수 있는 한 가지의 방법은 SupervisorJob을 사용하는 것입니다.

자식의 실패또는 취소로 인해 Job이 실패 되지 않으며 이로 인해 다른 자녀들에게 영향을 주지않게 됩니다.

val job = SupervisorJob()                               // (1)
val scope = CoroutineScope(Dispatchers.Default + job)
// may throw Exception
fun doWork(): Deferred<String> = scope.async { ... }
fun loadData() = scope.launch {
    try {
        doWork().await()
    } catch (e: Exception) { ... }
}

참고: 이 기능은 SupervisorJob으로 코루틴 범위에서 비동기를 명시적으로 실행하는 경우에만 작동합니다. async가 부모 코루틴(1)의 범위에서 시작되었기 때문에 아래 코드는 여전히 크래시가 납니다.

val job = SupervisorJob()                               
val scope = CoroutineScope(Dispatchers.Default + job)
fun loadData() = scope.launch {
    try {
        async {                                         // (1)
            // may throw Exception 
        }.await()
    } catch (e: Exception) { ... }
}

크래시를 피하는 또 다른 방법은 coroutineScope(1)을 사용하여 async를 감싸서 사용하는 방법이 있습니다. 이로 인해 async 내부에서 예외가 발생하면 외부 범위를 건드리지 않고 이 범위에서 작성된 다른 모든 coroutine만 취소 됩니다.(2)

val job = SupervisorJob()                               
val scope = CoroutineScope(Dispatchers.Default + job)
// may throw Exception
fun doWork(): Deferred<String> = coroutineScope {     // (1)
    async { ... }
}
fun loadData() = scope.launch {                       // (2)
    try {
        doWork().await()
    } catch (e: Exception) { ... }
}

루트 코루틴은 Main 디스패처를 선호하자.

백그라운드 코루틴에서 백그라운드 작업을 수행하고 UI업데이트를 해야 하는 경우 Main 디스패처에서 실행해야 합니다.

val scope = CoroutineScope(Dispatchers.Default)          // (1)
fun login() = scope.launch {
    withContext(Dispatcher.Main) { view.showLoading() }  // (2)  
    networkClient.login(...)
    withContext(Dispatcher.Main) { view.hideLoading() }  // (2)
}

위의 예에서 기본 디스패처(1)에서 코루틴을 실행합니다. 이 접근 방식을 사용하면 UI를 터치 할때 마다 Main 디스패처로 컨텍스트를 전환해야 합니다.(2)

이런 경우 Main 디스패처로 코루틴을 실행 하는 것이 코드가 훨씬 단순해지며 컨텍스트 전환이 더 명확해집니다.

val scope = CoroutineScope(Dispatchers.Main)
fun login() = scope.launch {
    view.showLoading()    
    withContext(Dispatcher.IO) { networkClient.login(...) }
    view.hideLoading()
}

불필요한 async/await 사용을 피하자.

async 함수를 사용하고 즉시 await하는 경우라면 코드를 당장 걷어내야합니다.

launch {
    val data = async(Dispatchers.Default) { /* code */ }.await()
}

만약 코루틴 컨텍스트를 바꾸고 즉시 중단하고 싶다면 withContext를 사용하는 것이 훨씬 좋은 방법이 될 수 있습니다.

launch {
    val data = withContext(Dispatchers.Default) { /* code */ }
}

포퍼먼스 측면으로는 큰 문제는 아니지만( 심지어 async가 작업을 수행하기위해 새로운 코루틴을 생성해도) 의미론적으로 async 하다는 것은 백그라운드에서 여러개의 코루틴을 시작한 뒤 기다리고 있음을 의미하기때문에 적절하지 않습니다.

scope Job을 취소하지 말자.

코루틴을 취소해야 하는 경우 스코프 작업을 취소하면 안됩니다.

class WorkManager {
    val job = SupervisorJob()
    val scope = CoroutineScope(Dispatchers.Default + job)
    fun doWork1() {
        scope.launch { /* do work */ }
    }
    fun doWork2() {
        scope.launch { /* do work */ }
    }
    fun cancelAllWork() {
        job.cancel()
    }
}
fun main() {
    val workManager = WorkManager()
    workManager.doWork1()
    workManager.doWork2()
    workManager.cancelAllWork()
    workManager.doWork1() // (1)
}

위의 코드의 문제는 작업을 취소할 때 완료 상태로 만들어 버리는 것에 있습니다. 이미 완료된 작업 범위에서 실행된 코루틴은 재 실행되지 않습니다. (1)

특정 범위의 모든 코루틴을 취소하기위해서는 cancelChildren 함수를 사용할 수 있습니다. 또한 개별 작업 취소기능을 제공합니다.(2)

class WorkManager {
    val job = SupervisorJob()
    val scope = CoroutineScope(Dispatchers.Default + job)
    fun doWork1(): Job = scope.launch { /* do work */ } // (2)
    fun doWork2(): Job = scope.launch { /* do work */ } // (2)
    fun cancelAllWork() {
        scope.coroutineContext.cancelChildren()         // (1)                             
    }
}
fun main() {
    val workManager = WorkManager()
    workManager.doWork1()
    workManager.doWork2()
    workManager.cancelAllWork()
    workManager.doWork1()
}

분명하지 않은 디스패처는 suspend 함수로 작성하지 말자.

명백한 코루틴 디스패처에 대한 실행인 경우 suspend 함수로 작업하지 않아야 합니다.

suspend fun login(): Result {
    view.showLoading()
    val result = withContext(Dispatcher.IO) {  
        someBlockingCall() 
    }
    view.hideLoading()
    return result
}

위의 예제는 로그인하는 기능으로 Main 디스패처가 아닌 곳에서 실행하면 크래시를 발생하는 suspend 함수 입니다.

launch(Dispatcher.Main) {     // (1) no crash
    val loginResult = login()
    ...
}
launch(Dispatcher.Default) {  // (2) cause crash
    val loginResult = login()
    ...
}

CalledFromWrongThreadException 생성된 원래 스레드에서만 해당 뷰를 제어해야 합니다.

suspend 함수는 어떠한 코루틴 디스패처에 대해 실행할 수 있도록 디자인되어야합니다.

suspend fun login(): Result = withContext(Dispatcher.Main) {
    view.showLoading()
    val result = withContext(Dispatcher.IO) {  
        someBlockingCall() 
    }
    view.hideLoading()
    return result
}

이제 모든 디스패처에서 로그인 기능을 실행할 수 있습니다.

launch(Dispatcher.Main) {     // (1) no crash
    val loginResult = login()
    ...
}
launch(Dispatcher.Default) {  // (2) no crash ether
    val loginResult = login()
    ...
}

GlobalScope 사용을 피하자.

만일 안드로이드 어플리케이션에서 GlobalScope를 사용하고 있다면 당장 사용을 중단해야 합니다.

GlobalScope.launch {
    // code
}

GlobalScope는 전체 어플리케이션 수명 동안에 작동하고, 취소되지 않는 최상위 수준의 동시 처리를 시작하는데 사용됩니다.

별로도 정의한 CoroutineScope를 사용해야하며 async를 사용하거나 GlobalScope 인스턴스에서 실행하는 것이 좋습니다.

안드로이드에서 코루틴은 Activity, Fragment, View 또는 ViewModel의 수명주기로 쉽게 범위를 지정할 수 있습니다.

class MainActivity : AppCompatActivity(), CoroutineScope {

    private val job = SupervisorJob()

    override val coroutineContext: CoroutineContext
        get() = Dispatchers.Main + job

    override fun onDestroy() {
        super.onDestroy()
        coroutineContext.cancelChildren()
    }
    
    fun loadData() = launch {
        // code
    }
}

참고: https://proandroiddev.com/kotlin-coroutines-patterns-anti-patterns-f9d12984c68e

아직 ConstraintSet을 사용해보지 않으셨다면 아래 Sean McQuillan @objcode의 영상을 보시기 권해드립니다.

위의 영상에서 볼수 있듯 ConstraintLayout과 TransitionManager를 통해 애니메이션을 만드는 쉬운 방법을 제공합니다. 이런 기본적인 아이디어를 바탕으로 MotionLayout은 개념을 훨씬 확장하게 됩니다.

MotionLayout?

MotionLayout은 레이아웃 전환과 복잡한 모션처리 사이를 컨트롤 쉽게 하기위해 만들어졌습니다. 사용자와 상호 작용해야하는 요소인 버튼, 타이틀 등의 실제 UI요소를 이동하거나 크기 조정또는 애니메이션처리 해야 하는 경우 가장 유용합니다. 단순히 애니메이션을 처리 하기위해서는 기존 안드로이드 프레임워크에서 지원하는 여러가지 방식을 사용하면 됩니다.

• Animated Vector Drawable
• Property Animation
• LayoutTransition
• TransitionManager
• CoordinatorLayout

MotionLayout은 기존 애니메이션 방식과는 전혀다릅니다. 이름에서도 알 수 있듯 레이아웃이며 이에따라 요소들을 배치할 수 있습니다. 실제로 ConstraintLayout을 상속한 하위클래스로 풍부한 레이아웃 기능을 기반으로합니다.

Property Animation + TransitionManager + CoordinatorLayout = MotionLayout

두 레이아웃 사이의 전환에 있어 최상위 레이아웃 뿐만 아니라 하위 레이아웃 속성에 애니메이션을 적용 할 수 있습니다. 또한 CoordinatorLayout과 같이 애니메이션의 포지셔닝을 마음대로 조절가능합니다. 터치 핸들링과 키프레임을 지원함으로 자신의 필요에 맞게 쉽게 전환 효과를 정의 할 수 있습니다.

MotionLayout은 전혀 코드가 필요하지 않고 xml로 완벽하게 작동할 수 있게 합니다. 이렇게 코드와 디커플링됨에 따라 Android Studio에서 xml을 보여주는 훌륭한 그래픽 도구를 제공 할 수 있을 것으로 보입니다.

마지막으로 MotionLayout을 지원하는 ConstraintLayout 2.0에서는 API 레벨 14(ICS) 부터 서포트 라이브러리를 통해 사용할 수 있습니다. 이는 현재 안드로이드 기기의 99.8%를 지원하는 수준입니다.

MotionLayout 프로젝트에 추가
Gradle file:

dependencies {
    implementation 'com.android.support.constraint:constraint-layout:2.0.0-alpha2'
}

MotionLayout 사용
Layout file:

<android.support.constraint.motion.MotionLayout .../>

MotionScene

MotionLayout은 일반적인 레이아웃과는 달리 res/xml 디렉토리에 저장되는 별도의 xml파일인 MotionScene에 속성을 정의합니다. 여기에는 애니메이션을 지정하는 필요한 Transition 처리, 키 프레임, 터치 처리등의 요소들이 포함됩니다.

기존 ConstraintSet을 이용한 방식을 MotionLayout에 적용

ConstraintLayout을 사용하여 첫번째 화면 왼쪽에 위젯 배치, 두번째 화면 오른쪽에 위젯 배치의 2개의 ConstraintSet을 만들어 좌/우 전환하는(TransitionManager를 사용하면 애니메이션 처리) 예를 들어보겠습니다.

• 화면 왼쪽에 위젯 배치

<android.support.constraint.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <View
        android:id="@+id/button"
        android:background="@color/colorAccent"
        android:layout_width="64dp"
        android:layout_height="64dp"
        android:layout_marginStart="8dp"
        android:text="Button"
        app:layout_constraintBottom_toBottomOf="parent"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintTop_toTopOf="parent" />

</android.support.constraint.ConstraintLayout>

• 화면 오른쪽에 위젯 배치

<android.support.constraint.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <View
        android:id="@+id/button"
        android:background="@color/colorAccent"
        android:layout_width="64dp"
        android:layout_height="64dp"
        android:layout_marginEnd="8dp"
        android:text="Button"
        app:layout_constraintBottom_toBottomOf="parent"
        app:layout_constraintEnd_toEndOf="parent"
        app:layout_constraintTop_toTopOf="parent" />

</android.support.constraint.ConstraintLayout>

ConstraintLayout을 사용하면 두개의 레이아웃을 ConstraintSet을 이용하여 서로 전환할 수 있습니다. TransitionManager를 사용하는 경우 전환 애니메이션으로 표시됩니다. 이 방식의 문제는 전환이 시작되면 중도에 중단할 수 없다는 것에 있습니다. 전환시 특정 지점으로 이동하도록 지원하지 않기때문에 사용자와의 상호작용할 수 없습니다.

MotionLayout은 이런 모든 문제를 해결 할 수 있습니다. 이를 위해 기존의 2개의 레이아웃을 이용하여 MotionLayout을 통해 자동으로 초기화 하는 방식으로 바꿔보겠습니다.

<android.support.constraint.motion.MotionLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:id="@+id/motionLayout"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    app:layoutDescription="@xml/scene_01"
    tools:showPaths="true">

    <View
        android:id="@+id/button"
        android:layout_width="64dp"
        android:layout_height="64dp"
        android:background="@color/colorAccent"
        android:text="Button" />

</android.support.constraint.motion.MotionLayout>

레이아웃 inflate시 MotionScene은 @xml/scene_01파일을 참조하게 됩니다.

<MotionScene
    xmlns:motion="http://schemas.android.com/apk/res-auto">

    <Transition
        motion:constraintSetStart="@layout/motion_01_cl_start"
        motion:constraintSetEnd="@layout/motion_01_cl_end"
        motion:duration="1000">
        <OnSwipe
            motion:touchAnchorId="@+id/button"
            motion:touchAnchorSide="right"
            motion:dragDirection="dragRight" />
    </Transition>

</MotionScene>

scene_01은 전환에 사용 할 ConstraintSet 시작(motion_01_cl_start)/종료(motion_01_cl_end) 레이아웃을 지정할 수 있습니다. 또한 핵심인 onSwipe는 전환에 있어 핸들러를 지정했음을 주목해야합니다.

OnSwipe

OnSwipe 핸들러는 사용자의 액션이 일치되는 경우 전환을 시작합니다.

주요 속성

• touchAnchorId 추적해야 할 대상 (@+id/button)
• touchAnchorSide 손가락을 추적해야하는 물체의 측면 (right/left/top/bottom)
• dragDirection 추적중인 동작의 방향 (dragRight/dragLeft/dragUp/dragDown)

이제 코드 한줄 없이 사용자의 스와이프 이벤트를 통해 네모박스가 자연스럽게 애니메이션되면서 끝에서 끝으로 이동 합니다.

MotionLayout 자체로 MotionScene 구현

위의 예제 ConstraintSet을 사용하여 2개의 레이아웃으로 전환하였으나 이번에는 MotionLayout으로만 사용하여 빠르게 레이아웃을 수성하도록 해보겠습니다.

MotionLayout은 res/xml 디렉토리에 있는 MotionScene 파일에서 ConstraintSet을 직접 설정하는 기능을 지원합니다. 이는 ConstraintSet을 사용하기위한 다양한 레이아웃 생성을 하지 않아도 되는 장점이 있습니다. 이는 코드와 별도로 동작하기때문에 나중에 Adnroid Studio에서 모션레이아웃 뷰어를 지원할 가능성이 높습니다.

MotionLayout의 속성

• alpha
• visibility
• elevation
• rotation, rotation[X/Y]
• translation[X/ Y/Z]
• scaleX/Y

첫번째 예제에서 사용한 ConstraintLayout대신 MotionLayout을 사용하여 레이아웃을 다시 구성하였습니다.

<android.support.constraint.motion.MotionLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    android:id="@+id/motionLayout"
    app:layoutDescription="@xml/scene_02"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <View
        android:id="@+id/button"
        android:background="@color/colorAccent"
        android:layout_width="64dp"
        android:layout_height="64dp"
        android:text="Button" />

</android.support.constraint.motion.MotionLayout>

첫번째 예제에서 constraintSetStart와 constraintSetEnd속성 값으로 사용할 @layout을 지정해준 반면 정의한 ConstraintSet @id를 지정해줍니다.

<MotionScene xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:motion="http://schemas.android.com/apk/res-auto">

    <Transition
        motion:constraintSetStart="@+id/start"
        motion:constraintSetEnd="@+id/end"
        motion:duration="1000">
        <OnSwipe
            motion:touchAnchorId="@+id/button"
            motion:touchAnchorSide="right"
            motion:dragDirection="dragRight" />
    </Transition>

    <ConstraintSet android:id="@+id/start">
        <Constraint
            android:id="@+id/button"
            android:layout_width="64dp"
            android:layout_height="64dp"
            android:layout_marginStart="8dp"
            motion:layout_constraintBottom_toBottomOf="parent"
            motion:layout_constraintStart_toStartOf="parent"
            motion:layout_constraintTop_toTopOf="parent" />
    </ConstraintSet>

    <ConstraintSet android:id="@+id/end">
        <Constraint
            android:id="@+id/button"
            android:layout_width="64dp"
            android:layout_height="64dp"
            android:layout_marginEnd="8dp"
            motion:layout_constraintBottom_toBottomOf="parent"
            motion:layout_constraintEnd_toEndOf="parent"
            motion:layout_constraintTop_toTopOf="parent" />
    </ConstraintSet>

</MotionScene>

기존의 위젯은 Constraint로 모두 대체합니다. 속성 변경을 원하는 위젯만 Constraint를 지정해야 적용가능 합니다. 만약 10개의 위젯이 있는 레이아웃일 경우 2개만 애니메이션 처리하고 싶은 경우 MotionScene의 ConstraintSet은 해당 위젯에 대한 Constraint를 지정하면 됩니다.

MotionLayout 속성

• app:layoutDescription="reference" 예제에서 본것 처럼 MotionScene xml파일을 지정해야 합니다.
• app:applyMotionScene="boolean" MotionScene을 적용할지 여부를 지정합니다.
• app:showPaths="boolean" 동작 경로를 표시합니다. (기본값= false). 릴리즈 빌드시 끄는것을 잊지마세요.
• app:progress="float" 특정 위치의 진행 장면으로 이동합니다. (0~1)
• app:currentState="reference" 레이아웃 초기화시 특정 ConstraintSet을 강제로 실행합니다.

이제 한줄의 코드 없이 사용자 이벤트를 통한 상호작용과 부드러운 애니메이션을 처리를 할 수 있습니다.
위의 모든 예제 코드는 Github를 통해 보실 수 있습니다.

소프트키보드가 표시되면 안드로이드는 콘텐츠의 크기를 즉각 변경합니다. (windowSoftInputMode를 설정하지 않은경우) 이로 인해 레이아웃에 부자연스러운 변화가 생깁니다. 아쉽게도 플랫폼이나 대다수의 앱이 이를 처리하지 않기때문에 사용자들은 정상적으로 작동한다는것으로 착각하고 있습니다.

역시 글로만 봐서 이해하기 힘들기때문에 차이점을 명확히 알아보기 위해 Google Keep과 Dank 앱을 영상으로 비교 해보겠습니다.

Google Keep

Dank

위의 화면을 통해 비교해 보면 Dank앱이 키보드가 반응하면 콘텐츠를 위쪽으로 부드럽게 크기를 조정하며 스크롤하는것을 볼 수 있습니다. 반면 Google Keep은 키보드의 반응에 변동이 없어 컨텐츠영역에도 아무런 반응이 없어 보입니다.

좀 더 부드러운 화면으로 비교를 원한다면 영상으로 확인해보세요.( Google Keep, Dank)

눈치 빠른 분들은 Dank앱이 처리하는 작은 트릭을 발견하실 수 있습니다. 이 작은 트릭은 키보드가 표시되면 Activity의 전체 화면의 크기가 조정된다는 것에 있습니다. 이는 Activity를 구성하는 View 계층의 최상단 레이아웃(DecorView)에 아무런 영향을 받지 않고 처리 했다는 사실을 알 수 있습니다. 실제로 뷰의 크기가 저장되는 레이아웃ID는 콘텐츠 레이아웃(android.R.id.content)입니다. 이것은 DecorView내의 컨텐츠 레이아웃을 제어할 수 있다는 것을 의미합니다.

Activity를 구성하는 View Tree는 일반적으로 다음과 같습니다.

DecorView

- LinearLayout
-- FrameLayout  <- android.R.id.content
--- LinearLayout
---- Activity content

리사이즈 되는 부분을 제어하기 위해 콘텐츠 레이아웃(android.R.id.content)의 크기가 변경되는 것을 감지하는 유틸 클래스를 만들었습니다. View의 크기가 변경되면 컨텐츠의 전체 높이에서 변경된 높이만큼 변경되도록 애니메이션처리 합니다.

val decorView = activity.window.decorView

decorView.viewTreeObserver.addOnPreDrawListener { 
  val contentHeight = contentViewFrame.height
  val sizeChanged = contentHeight != previousHeight

  if (sizeChanged) {
    animateSizeChange(from = previousHeight, to = contentHeight)
  }

  previousHeight = contentHeight
}

fun animateSizeChange(from: Int, to: Int) {
  // Immediately snap back to the original size.
  contentView.setHeight(from)
  
  ObjectAnimator.ofInt(from, to)
    .addUpdateListener { 
      val h = it.animatedValue as Int
      contentView.setHeight(h) 
    }
    .start()
}

이와 관련된 모든 코드는 여기를 통해 확인하세요.

컨텐츠 뷰의 크기에 따라 애니메이션처리를 하여 높이를 변경하는 것은 손이 많이 가는일이지만 앱의 품질을 높이는 큰역할을 합니다. 다르게 구현할 수 있는 방법도 많고, 이것이 최상의 솔루션은 아니지만 여러달 테스트하면서 문제점을 발견하지는 못하였습니다.

참고: https://saket.me/smoothly-reacting-to-keyboard/

Architecture Components를 아직 사용하지 않고 있다면 build.gradle에 아래와 같이 라이브러리를 추가 합니다.

dependencies{
  kapt "android.arch.lifecycle:compiler:1.1.1"
  implementation "android.arch.lifecycle:extensions:1.1.1"
}

Activity(or Fragment)의 Lifecycle 상태를 모니터링할때 사용하는 LifecycleObserver 인터페이스를 동일하게 하나 구현합니다.

class AppLifecycleObserver : LifecycleObserver {

    @OnLifecycleEvent(Lifecycle.Event.ON_START)
    fun onForeground() {
        //foreground
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_STOP)
    fun onBackground() {
        //background
    }
}

구현된 인터페이스를 Activity가 아닌 Application의 onCreate()에 ProcessLifecycleOwner를 이용하여 Observer하도록 합니다. ProcessLifecycleOwner는 내부적으로 Activity의 갯수및 Lifecycle 상태를 모니터링 하는 역할을 합니다.

class AppApplication : Application() {

    override fun onCreate() {
        super.onCreate()

        ProcessLifecycleOwner.get().lifecycle
            .addObserver(AppLifecycleObserver())
    }
}

이제 우리는 ON_START이벤트가 발생하는 경우 앱이 Foreground 상태로 진입을 의미하며, ON_STOP이벤트의 경우 Background로 진입했다는 것을 알 수 있습니다. 이러한 이벤트는 Activity의 Lifecycle를 모니터링 하기때문에 의도치 않게 Activity가 중도에 destory이 되어 새롭게 create되는 경우 이벤트가 지연될 수 있습니다. 이는 밀리세컨드의 단위로 정확성을 요구하는 곳에서 사용이 부적절할 수 있음을 의미합니다. ProcessLifecycleOwner에 대한 더 많은 정보는 안드로이드 개발문서를 참고 해주세요.

우리는 이런 문제를 해결 하기위해서 아래와 같은 몇가지 방식을 사용합니다.

1. AsyncTask – 순서대로 짧은 연산 실행, 동시에 수행 할 수 있음
2. Executors – 고정된 스레드 풀과 동시에 작업 실행
3. Intent Service – 순서대로 긴 연산을 실행, 큐잉 처리함
4. RxJava – 가장 인기 있으며, 안드로이드 프레임워크에서 지원하지 않음
5. Raw Threads

위의 방식은 훌륭하지만 올바르게 사용하기 위해선 미묘한 차이를 보입니다. 또, 디버깅과 취소처리가 간단하지 않습니다.

Kotlin Coroutines

코틀린 코루틴는 순차적으로 일어나는 일을 비동기 처리하기위한 방법입니다. 코루틴을 생성하는 것은 스레드를 만드는 것에 비해 비용이 적게듭니다. 그 이유는

코루틴은 컴파일 기술을 통해 완벽하게 구현됩니다. (VM 또는 OS측면에서 지원이 필요없습니다). Suspend는 코드 변환을 통해 작동합니다.

코루틴은 여전히 실험단계에 있으며, 이는 API가 앞으로 변화될 가능성을 의미합니다. 하지만 JetBrains은 이전 버전과 같은 호환성을 제공할것 이라고 약속했습니다. (여기를 통해 확인 해보세요.)

Code

코루틴을 사용하기위해서 함수를 suspend로 표시해야 모든 정상기능을 사용할 수 있습니다. 이러한 기능을 사용하기위해 실행및 비동기화(Launch & Async)하는 코루틴 빌더가 필요합니다.

Launch & Async

• Launch – 현재 스레드를 차단하지 않고 새로운 코루틴을 싱행하고 코루틴을 제거하는데 사용 할 수 있는 작업으로 코루틴에 대한 참조를 반환합니다.
• Async – 새로운 코루틴을 실행하고 지연후 결과를 반환합니다.

public actual fun launch(
    context: CoroutineContext = DefaultDispatcher,
    start: CoroutineStart = CoroutineStart.DEFAULT,
    parent: Job? = null,
    block: suspend CoroutineScope.() -> Unit
): Job {
    val newContext = newCoroutineContext(context, parent)
    val coroutine = if (start.isLazy)
        LazyStandaloneCoroutine(newContext, block) else
        StandaloneCoroutine(newContext, active = true)
    coroutine.start(start, coroutine, block)
    return coroutine
}

public actual fun <T> async(
    context: CoroutineContext = DefaultDispatcher,
    start: CoroutineStart = CoroutineStart.DEFAULT,
    parent: Job? = null,
    block: suspend CoroutineScope.() -> T
): Deferred<T> {
    val newContext = newCoroutineContext(context, parent)
    val coroutine = if (start.isLazy)
        LazyDeferredCoroutine(newContext, block) else
        DeferredCoroutine<T>(newContext, active = true)
    coroutine.start(start, coroutine, block)
    return coroutine
}

• CoroutineContext – 코루틴 빌더가 실행되는 스레드를 정의합니다.
• DefaultDispatcher – CommonPool을 사용합니다. 개발자는 실행해야하는 스레드를 지정할 수있는 모든 권한을가집니다. 다른 옵션은 UI 스레드에서 실행되는 UI입니다.
• CoroutineStart – 시작 방법 정의
  • DEFAULT - 즉시 실행을 시작
  • LAZY - 코루틴을 느리게 시작
  • ATOMIC - 자동으로 최적화된 방법으로 시작
  • UNDISPATCHED - 분산 처리방법으로 시작

예제

연속적으로 처리하는 작업

 private lateinit var job1: Job
    suspend fun getThingsDone(myThings: Int): Int {
        // Heavy computation going on here :D
        return myThings + 99
    }

    suspend fun getThingsDoneAgain(myThings: Int): Int {
        // Heavy computation going on here :D
        return myThings + 50
    }
    
    fun toDoWorkSerially() {
        job1 = launch(UI) {
            try {
                val work1 = async { getThingsDone(23) }
                val work2 = async { getThingsDoneAgain(55) }
                
                val result1 = work1.await()
                tvResult1.text = result1.toString()
                
                val result2 = work2.await()
                tvResult2.text = result2.toString()
            
            } catch (exception: Exception) {
                exception.printStackTrace()
            }
        }
    }

UI (Main Thread)는 Context를 사용하여 새로운 코루틴 Launch를 만듭니다. 이 과정에서 백그라운드에서 무거운 작업을 수행하고 UI 스레드에서 두 개의 다른 코루틴을 실행합니다. Async는 새로운 코루틴을 생성하고 지연된것을 리턴하여 기다릴 수 있게 됩니다.

간단히 말해 코드는 work1과 work2가 실행될 때 순차적으로 실행되고 result1은 work1이 완료 될 때까지 기다린 다음 result2는 work2가 완료 될 때까지 기다립니다. result1과 result2는 기본 스레드인 CommonPool을 Context로 사용했기 때문에 백그라운드 스레드에서 가져옵니다. 모든 예외는 해당 try catch 블록에서 발견됩니다.

동시에 처리 하는 작업

private lateinit var job2: Job

fun toDoWorkConcurrent() {
    job2 = launch {
        try {
            val work1 = async { getThingsDone(43) }
            val work2 = async { getThingsDoneAgain(123) }

            val result = computeResult(work1.await(), work2.await())

            withContext(UI) {
                tvResult1.text = result.toString()
            }

        } catch (exception: Exception) {
            exception.printStackTrace()
        }
    }
}

private fun computeResult(await: Int, await1: Int): Int {
    return await + await1
}
    

위의 변수의 결과는 동시에 work1과 work2가 완료 될때만 이용할 수 있습니다. 이를 위해 await() 호출시 지연된 모든 객체가 호출됩니다.

코루틴 취소는 Job에서 cancel()을 통해 간단히 호출할 수 있습니다.

Retrofit2 + Coroutines

코루틴을 Retrofit2와 함께 사용하기 위해서는 Retrofit2 Kotlin Coroutines Adapter 라이브러리를 이용하여 Service 메소드의 반환 유형으로 Deferred 타입을 사용할 수 있습니다.

class LoginRepository @Inject constructor(private val apiService: APIService, private val sharedPreferences: SharedPreferences) {

    fun getOTPForNumber(phoneNumber: String): LiveData<OTPResult> {
    
        val loginResult = MutableLiveData<OTPResult>()
        launch {
            try {
                val request = apiService.getOTPForNumber(phoneNumber)
                val response = request.await()
                if (response.isSuccessful) {
                    loginResult.postValue(OTPResult.Success(response.message()))
                } else {
                    loginResult.postValue(OTPResult.Error(response.code(), response.message()))
                }
            } catch (exception: Exception) {
                loginResult.postValue(OTPResult.Exception(exception))
            }
        }
        return loginResult
    }
    
   fun getMyThings(date: String, meal: Triple<String, String, Boolean>): LiveData<DispatchesResult> {

        val dispatchResult = MutableLiveData<DispatchesResult>()
        launch {
            try {
                val task1 = apiService.getDispatches(id, date, meal.first)
                val task2 = apiService.getDispatches(id, date, meal.second)
                val task3 = apiService.checkAppDetails()
                checkResult(task1.await(), task2.await(), task3.await(), dispatchResult)

            } catch (exception: Exception) {
                dispatchResult.postValue(DispatchesResult.Exception(exception))
            }
        }

        return dispatchResult
    }

     private fun checkResult() {
        if (task1.isSuccessful && task2.isSuccessful && (task3.isSuccessful && task3.body()?.code == 1000)) {
        
        }
    }
}

apiService 인터페이스가 기존 Call대신 Deferred를 반환하기 때문에 이를 통해 이전에 다룬 코루틴을 그대로 사용할 수 있습니다.

결론

코루틴을 사용하면 코드를 쉽게 읽을 수 있는 비동기 코드 작성이 가능하며, 오류및 유지 보수를 줄 일 수 있습니다. 또한 코드의 경량화는 말할것도 없습니다.

일반적으로 Fragment전환시 아무런 전환 효과를 주지 않습니다. commit과 동시에 컨텐츠 화면이 심심하게 바뀝니다. Fragment도 Activity에서 처럼 전환 효과를 주기위해서는 sharedElementViews를 이용하여 전환하고 싶은 View를 추가하면 됩니다. 그리고 트랜잭션 최적화 작업을 위해 etReorderingAllowed()속성을 허용합니다.

supportFragmentManager.beginTransaction()
  .setReorderingAllowed(true)
  .replace(R.id.container, GridFragment.newInstance(count))
  .addToBackStack("detail")
  .apply {
      val topFragment: Int = supportFragmentManager.fragments.size
      val fragment: GridFragment = supportFragmentManager.fragments[topFragment - 1] as GridFragment

      val recyclerView: RecyclerView = fragment.recyclerview

      var viewCount = 0
      for (itemView in recyclerView.children) {
          addSharedElement(itemView, viewCount.toString())
          viewCount++
      }

  }
  .commit()

위의 코드에서 addSharedElement를 통해 현재 보여지고 있는 View에 각각 전환될 이름을 부여 해줍니다. 그럼 Fragment가 전환된 View에 해당 전환된 이름의 View를 찾아 트랜지션 됩니다.

문제점

새로운 Fragment가 생성되면 데이터를 가져오거나 이미지를 불러오고 레이아웃을 구성하고 그리는 시간이 걸리기 때문에 전환 효과는 자연스럽지 않습니다. 이런 구성을 하는 동안 애니메이션이 끝나게 되는 경우 아무런 효과를 보지 못할 수 있습니다. 그렇기 때문에 장면 효과를 데이터나 뷰를 구성하기 전까지 지연할 필요가 있습니다.

postponeEnterTransition(), startPostponedEnterTransition()을 이용하면 장면 효과를 지연하고 시작할 수 있습니다. 우리는 뷰가 그려진다는 사실을 OnPreDrawListener를 통해 인지 할 수 있습니다. 최근에 지원된 코틀린 라이브러리 KTX를 이용한다면 OnPreDrawListener대신 doOnPreDraw를 통해 쉽게 콜백 받을 수 있습니다.

postponeEnterTransition()
 
recyclerView.doOnPreDraw {
    startPostponedEnterTransition()

이제 Fragment 전환 효과를 위한 준비는 모두 끝났습니다. 어떻게 트랜지션이 이루어 질지에 대한 정의만 해주면 되는데 기본적으로 몇가지를 지원해는데 Bounds가 변경되기 때문에 ChangeBounds() 트랜지션을 설정 하도록 하겠습니다.

override fun onCreate(savedInstanceState: Bundle?) {
      super.onCreate(savedInstanceState)
      sharedElementEnterTransition = ChangeBounds()
}

좀 더 멋진 효과를 보기위해서는 Chris Banes과 같이 ColumnedChangeBounds를 직접 구현하면 됩니다. 이 글에서 구현된 모든 코드는 https://github.com/kmshack/FragmentTransitions에 공개됩니다.