android - versión - play store

Compruebe si la biblioteca se utiliza en la aplicación de Android

Question

Recibí un código de aplicación heredado (no desarrollado por mí, pero por algún otro equipo, sin documentación), que tiene casi más de 20 dependencias, en build.gradle .

Ahora, quería limpiar las bibliotecas / dependencias no utilizadas, eliminándolas de build.gradle

Busqué en Google y encontré este project para reducir los recursos. Pero parece que se usa para eliminar recursos que no se usan, en el momento de la compilación, en la aplicación empaquetada y esto también elimina los recursos de las bibliotecas de las que depende si su aplicación no las necesita realmente.

Además, uso ProGuard , para ofuscación y encogimiento junto con shrinkResources true en build.gradle

Mi intención es eliminar las bibliotecas / dependencias no utilizadas de build.gradle, sin romper la funcionalidad de la aplicación.

¿Hay alguna forma o herramienta que muestre qué biblioteca es segura eliminar sin romper la funcionalidad de la aplicación?

Answer 1

En lugar de comentar todas las dependencias, iría al revés: comentar una dependencia a la vez y ver qué se rompe. De esta manera, también obtendría una idea de los casos de uso de todas las dependencias porque el IDE le indicará el lugar donde se rompió el código. Si nada se rompe después de comentar una dependencia, sabrá que no se usa. Otra cosa que podría hacer es analizar una versión .apk no oculta donde faltarán todas las dependencias no utilizadas pero se conservará la estructura del paquete.

Answer 2

Por más de 20 dependencias, no necesita herramientas y puede hacer una verificación manual.

Yo procedería así:

1. Comente todas las dependencias y verifique qué falla (ver más abajo)
2. Descomentar la dependencia que causa el fallo.
3. Repetir

De esta manera, también puede notar dependencias que rara vez se usan o pueden reemplazarse con bibliotecas estándar u otras bibliotecas que usa en el proyecto.

Estas son las cosas que le indicarán que se requiere una dependencia (en el orden de ralentizar el ciclo de retroalimentación):

• errores de compilación
• errores de prueba unitaria
• Errores de prueba de integración / sistema / extremo a extremo / dispositivo (sea cual sea su uso y cómo los llame)
• funcionalidad de la aplicación en tiempo de ejecución
• rendimiento de la aplicación en tiempo de ejecución

Las dependencias en tiempo de ejecución pueden ser especialmente difíciles. Por ejemplo, su código podría no depender de una biblioteca, pero esta biblioteca proporciona una implementación en tiempo de ejecución para alguna otra biblioteca de la que dependa. La eliminación de dicha dependencia solo será visible en tiempo de ejecución como funcionalidad faltante o problemas de rendimiento.