라이브러리 현명하게 선택

앱 최적화를 사용 설정하려면 Android 최적화와 호환되는 라이브러리를 사용해야 합니다. 라이브러리가 Android 최적화용으로 구성되지 않은 경우(예: 연결된 유지 규칙을 번들로 묶지 않고 리플렉션을 사용하는 경우) Android 앱에 적합하지 않을 수 있습니다. 이 페이지에서는 일부 라이브러리가 앱 최적화에 더 적합한 이유를 설명하고 선택에 도움이 되는 일반적인 팁을 제공합니다.

리플렉션보다 코드 생성 선호

일반적으로 리플렉션 대신 코드 생성 (codegen)을 사용하는 라이브러리를 선택해야 합니다. 코드 생성기를 사용하면 최적화 프로그램이 런타임에 실제로 사용되는 코드와 삭제할 수 있는 코드를 더 쉽게 확인할 수 있습니다. 라이브러리에서 코드 생성 또는 리플렉션을 사용하는지 확인하기 어려울 수 있지만 몇 가지 징후가 있습니다. 도움말을 참고하세요.

코드 생성과 리플렉션의 차이점에 관한 자세한 내용은 라이브러리 작성자를 위한 최적화를 참고하세요.

라이브러리 선택 시 일반적인 도움말

이 팁을 사용하여 라이브러리가 앱 최적화와 호환되는지 확인하세요.

최적화 문제 확인

새 라이브러리를 고려할 때는 라이브러리의 문제 추적기 및 온라인 토론을 살펴보고 축소와 관련된 문제나 앱 최적화 구성이 있는지 확인하세요. 이러한 라이브러리가 있다면 해당 라이브러리의 대안을 찾아야 합니다. 다음 사항에 유의하세요.

  • AndroidX 라이브러리Hilt와 같은 라이브러리는 리플렉션 대신 코드 생성을 사용하므로 앱 최적화와 잘 작동합니다. 리플렉션을 사용하는 경우 필요한 코드만 유지하도록 최소한의 유지 규칙을 제공합니다.
  • 직렬화 라이브러리는 객체를 인스턴스화하거나 직렬화할 때 상용구 코드를 방지하기 위해 리플렉션을 자주 사용합니다. 리플렉션 기반 접근 방식(예: JSON용 Gson) 대신 코드 생성기를 사용하여 이러한 문제를 방지하는 라이브러리를 찾아보세요(예: Kotlin 직렬화 사용).
  • 패키지 전체 유지 규칙이 포함된 라이브러리는 가능한 경우 피해야 합니다. 패키지 전체 유지 규칙은 오류를 해결하는 데 도움이 될 수 있지만 광범위한 유지 규칙은 결국 필요한 코드만 유지하도록 개선해야 합니다. 자세한 내용은 최적화 점진적으로 채택하기를 참고하세요.
  • 라이브러리에서는 문서의 유지 규칙을 프로젝트의 파일에 복사하여 붙여넣도록 요구해서는 안 됩니다. 특히 패키지 전체 유지 규칙은 더욱 그렇습니다. 이러한 규칙은 장기적으로 앱 개발자에게 유지관리 부담이 되며 시간이 지남에 따라 최적화하고 변경하기가 어렵습니다.

새 라이브러리를 추가한 후 최적화 사용 설정

새 라이브러리를 추가한 후 최적화를 사용 설정하고 오류가 있는지 확인합니다. 오류가 있는 경우 해당 라이브러리의 대안을 찾거나 유지 규칙을 작성하세요. 라이브러리가 최적화와 호환되지 않으면 해당 라이브러리에 버그를 신고하세요.

규칙은 중복하여 적용될 수 있습니다.

보관 규칙은 중복하여 적용될 수 있습니다. 즉 라이브러리 종속 항목이 포함하는 특정 규칙은 삭제할 수 없고 앱의 다른 부분을 컴파일하는 데 영향을 줄 수 있습니다. 예를 들어 라이브러리가 코드 최적화를 사용 중지하는 규칙을 포함하는 경우 그 규칙은 전체 프로젝트의 최적화를 사용 중지합니다.

리플렉션 사용 여부 확인 (고급)

코드를 검사하여 라이브러리가 리플렉션을 사용하는지 확인할 수 있습니다. 라이브러리에서 리플렉션을 사용하는 경우 연결된 유지 규칙을 제공하는지 확인하세요. 라이브러리가 다음을 수행하는 경우 리플렉션을 사용하고 있을 수 있습니다.

  • kotlin.reflect 또는 java.lang.reflect 패키지의 클래스 또는 메서드를 사용합니다.
  • Class.forName 또는 classLoader.getClass 함수를 사용합니다.
  • 런타임에 주석을 읽습니다. 예를 들어 val value = myClass.getAnnotation() 또는 val value = myMethod.getAnnotation()를 사용하여 주석 값을 저장한 다음 value로 작업을 실행하는 경우입니다.
  • 메서드 이름을 문자열로 사용하여 메서드를 호출합니다. 예를 들면 다음과 같습니다.

    // Calls the private `processData` API with reflection
    myObject.javaClass.getMethod("processData", DataType::class.java)
    ?.invoke(myObject, data)
    

잘못된 보관 규칙 필터링 (고급)

실제로 삭제해야 하는 코드를 유지하는 유지 규칙이 있는 라이브러리는 피해야 합니다. 하지만 사용해야 하는 경우 다음 코드와 같이 규칙을 필터링할 수 있습니다.

// If you're using AGP 8.4 and higher
buildTypes {
    release {
        optimization.keepRules {
          it.ignoreFrom("com.somelibrary:somelibrary")
        }
    }
}

// If you're using AGP 7.3-8.3
buildTypes {
    release {
        optimization.keepRules {
          it.ignoreExternalDependencies("com.somelibrary:somelibrary")
        }
    }
}

우수사례: 최적화로 인해 Gson이 중단되는 이유

Gson은 리플렉션을 많이 사용하므로 앱 최적화에 문제를 일으키는 경우가 많은 직렬화 라이브러리입니다. 다음 코드 스니펫은 일반적으로 Gson이 사용되는 방식을 보여주며, 이로 인해 런타임에 비정상 종료가 쉽게 발생할 수 있습니다. Gson을 사용하여 User 객체 목록을 가져올 때는 생성자를 호출하거나 팩토리를 fromJson() 함수에 전달하지 않습니다. 다음 중 하나 없이 앱 정의 클래스를 생성하거나 소비하는 것은 라이브러리가 개방형 리플렉션을 사용하고 있을 수 있다는 신호입니다.

  • 라이브러리 또는 표준 인터페이스나 클래스를 구현하는 앱 클래스
  • KSP와 같은 코드 생성 플러그인
class User(val name: String)
class UserList(val users: List<User>)

// This code runs in debug mode, but crashes when optimizations are enabled
Gson().fromJson("""[{"name":"myname"}]""", User::class.java).toString()

R8이 이 코드를 분석할 때 UserList 또는 User가 어디에도 인스턴스화되지 않는 것을 확인하면 필드의 이름을 바꾸거나 사용되지 않는 생성자를 삭제하여 앱이 비정상 종료될 수 있습니다. 다른 라이브러리를 비슷한 방식으로 사용하는 경우 앱 최적화를 방해하지 않는지 확인하고 방해하는 경우 사용하지 않아야 합니다.

RoomHilt는 모두 앱 정의 유형을 생성하지만 리플렉션이 필요하지 않도록 코드 생성기를 사용합니다.