Android는 앱간에 중복 라이브러리를 공유하기 위해 어떤 작업을 수행합니까? 그것은 운영 체제 중복 lib 해시를 감지하고 각 애플 리케이션에 대한 별도의 사본을 피할 것으로 보인다.Android 앱 라이브러리 효율성
사용자가 50 개의 앱을 설치했으며 그 중 많은 앱에 Android 지원, Kotlin 및 Guava 라이브러리 버전이있는 경우 디스크 공간을 절약 할 수있는 좋은 기회가됩니다.
Android는 앱간에 중복 라이브러리를 공유하기 위해 어떤 작업을 수행합니까?
번호
OS가 중복 lib에 해시를 감지하고 각 응용 프로그램은 디지털 서명
각 응용 프로그램에 대해 별도의 복사본을 피하기, 그래서 여부의 결정 수 있다는 것 라이브러리를 포함하지 않는 것은 빌드시에 완료되어야합니다. 당신이 원하는 것은 처음부터이 기능을 갖기 위해 안드로이드를 "retcon"하기 위해 타임 머신을 필요로하는 것처럼 보일 것입니다. 또는 다른 시나리오 (예 : 최신 기기는 APK sans 라이브러리를, 이전 기기는 APK 라이브러리를 제공함)별로 다른 APK 에디션을 제공하려면 배포 채널 지원이 필요하며 모든 배포 채널이이를 지원하지는 못합니다.
multidex 및 ProGuard와 관련하여 이것이 어떻게 작동하는지에 대해서도 명확하지 않습니다. 공유 라이브러리 복사본은 ProGuard를 통해 제거 된 항목이 아닌 전체 라이브러리 여야합니다. 다른 앱은 라이브러리의 다른 부분을 필요로하기 때문입니다. 이렇게하면 모든 앱이 일반적으로 필요하지 않은 곳에서도 multidex를 사용하게됩니다.
보안이 더 문제가되기 시작합니다. 공유 라이브러리 복사본의 출처는 어디입니까? 일부 "잘 알려진"라이브러리 (예 : Kotlin 런타임)로 제한하려는 경우 Google에서 관리 할 수 있습니다. 그러나 "가장 먼저 승리 한"접근 방식은 공유되는 바람을 일으키는 라이브러리의 악성 복사본을 배포하는 앱의 유령을 제기합니다.
전반적으로, 귀하의 접근 방식은 1990 년대의 "DLL 지옥"과 2000 년대의 "JAR 지옥"에 대한 강점을 보여줍니다. 앱 전반의 공유 라이브러리는 적절하게 관리하기 까다 롭습니다.
사용자가 50 개의 앱을 설치했으며 그 중 다수가 Android 지원, Kotlin 및 Guava 라이브러리 버전을 보유하고 있다면 디스크 공간을 절약 할 수있는 좋은 기회가됩니다.
Guava는 크기 때문에 Android 개발에 많이 사용되지 않습니다. appcompat-v7이라는 예외를 제외하고 대부분의 Android 지원 라이브러리는 비교적 작습니다. 나는 이것이 생각할 수있는만큼의 디스크 공간을 절약 할 것이라고 생각하지 않으며, 저축의 비용은 개발자의 몫을 차지하게 될 것입니다.
빌드 프로세스의 일부로 proguard를 활성화하여 사용하지 않는 메소드와 클래스를 제거하므로 apk를 줄일 수도 있습니다. – petey