Nuevas direcciones para el desarrollo de una plataforma ya familiar: siempre es interesante. Por un lado, está expandiendo la base de clientes, por otro lado, no está invirtiendo en la creación de software desde cero, sino que está utilizando los desarrollos existentes. Pero si la dirección es realmente nueva, con sus propios detalles, entonces no será posible manejarla con muy poca sangre. En la próxima reunión de la comunidad Mosdroid en nuestra oficina, el desarrollador Arthur Vasilov
Arturka habló sobre la adaptación de la aplicación Yandex al sistema Android Go.
En promedio, si no escribe una calculadora, un reloj despertador, etc., entonces está muy bien, bien hecho e hizo todo bien, o su aplicación toma 150-170 megabytes.
- Mi nombre es Arthur, soy desarrollador de Android, estoy trabajando en la aplicación Yandex. Hoy compartiré con ustedes una historia sobre cómo nos adaptamos a Android Go. Te diré qué tipo de rastrillo nos topamos, qué no funcionó para nosotros y cómo funciona todo, por qué es necesario.
Una pequeña digresión sobre de qué se trata. Android Go es una versión especial de Android diseñada para dispositivos de bajo costo. Cuestan entre 60 y 100 dólares y, por lo tanto, son muy débiles, lentos y ralentizados. Entonces Google decidió que crearan su propio sistema para que al menos de alguna manera funcionen normalmente. Se anunció en Google I / O en 2017, es decir, han pasado un año y varios meses. Por lo tanto, cuando se anunció el mitap, se planteó una pregunta lógica: "¿Todavía estás vivo o qué?" Entonces dije que todo está bien, todo está bien, lo diré. Y ahora, como un héroe típico de Internet, responderé ex post por qué sucedió.
¿Qué pasó exactamente? Google dijo: "Estamos haciendo tal sistema". Luego dijo: "Está bien, necesitamos tiempo para finalizar" y todo eso. Después de eso, los proveedores siempre tienen algún tipo de retraso en la adaptación de esta versión. Y la nueva versión con nosotros ya se lanzó no antes de un año después, por lo que no hay nada sorprendente aquí. Además, tenían que decidir si hacer algo así: están hablando de dispositivos baratos y no está claro si se beneficiarán de ellos o no. Además, este dispositivo debe ser nuevo, debe hacerse, aprender a vender, comprender cómo funcionará.
El primer teléfono inteligente con Android Go apareció no hace mucho tiempo. En algún momento de abril, probablemente comenzaron las ventas, o tal vez en mayo. Este es Nokia 1, se vende en todas partes. Estoy acostada por aquí. Ahora, en mi opinión, solo hay nueve de esos teléfonos inteligentes en el mercado, pero para fin de año prometen más de cien. Y, en principio, ninguno de los principales actores como Huawei, Samsung y otros han dicho su palabra, por lo que agregarán algo más, no podrán mantenerse alejados de un mercado tan grande.
Antes del informe, fui a la página de Android Go y vi que hicieron la Edición de Android Pie Go. Pero no hicieron nada allí, simplemente redujeron la cantidad de aplicaciones instaladas y su peso por adelantado. Dijeron: "Ahora tienes el doble de espacio libre". Y las excusas estándar: corrección de errores, mejora del rendimiento, todo. Pero al menos llamaron, lo que significa que no olvidaron.
¿Cuáles son las limitaciones de estos dispositivos, específicamente? En primer lugar, tienen 512 megabytes o 1 gigabyte de RAM, 8 o 16 gigabytes de almacenamiento. Está claro que, en tales condiciones, están extremadamente inhibidos y todas las aplicaciones normales en ellos funcionarán aproximadamente de la misma manera. Para que las aplicaciones funcionen con una adecuación mínima, Google dijo: "Presentemos los siguientes requisitos". Son bastante lógicos, se deducen de lo que estaba en la diapositiva anterior.
En primer lugar, es un buen rendimiento abstracto. Su aplicación debe ejecutarse bien y rápidamente en dicho dispositivo. Somos: "Genial. Estamos trabajando ".
Además, ya hay números específicos a los que debemos corresponder. El espacio ocupado después de desempacar e instalar el APK no es más de 40 megabytes. A veces esto es un problema porque alguien y el APK pesa los 80 megabytes. Dolerá Además, esto no se puede tomar y medir adecuadamente. Es decir, no puede decir: "Sé que mi APK pesa mucho, así que después de la instalación la aplicación tomará mucho". Todo esto depende mucho del proveedor, la versión del dispositivo, Android, etc. Pero si su APK toma 10 megabytes, entonces, en principio, todo está bien y nunca excederá este número.
Y ahora el requisito más divertido y divertido: la RAM consumida mientras se trabaja con la aplicación no debe superar los 50 megabytes.
¿Quién sabe cuánta RAM toma su aplicación en promedio durante la operación? ¿Quién se ha preguntado sobre este tema? ¿Hay alguien con menos de 100 megabytes? Guapo Pero tal vez estás mintiendo. En general, en promedio, si no escribe una calculadora, un reloj despertador, etc., entonces está muy bien, bien hecho e hizo todo bien, o su aplicación toma 150-170 megabytes. Ponerlo en 50 megabytes es muy difícil. Por lo tanto, el resto del tiempo hablaremos sobre eso, discutiremos cómo poner el globo en un búho, etc.
¿Qué incluye nuestra conversación de memoria? Es directamente necesario comprender exactamente qué estamos midiendo, entonces cuál es la mejor manera de medirlo. También para los dispositivos Android Go hay una especificidad que debe tenerse en cuenta, y también hablaremos de ello. Y también le contaré algunas cosas generales, consejos generales que quizás no haya adivinado, pero que realmente pueden comer mucha memoria de usted.
En 2018, después de que Google I / O pasó, debe comenzar la historia sobre la memoria con una referencia a
este informe . ¿Quién lo vio?
Genial Las 180 personas restantes saben qué hacer en el futuro cercano. En mi opinión, este es uno de los mejores informes en Google I / O. Amigo dijo cosas increíblemente geniales. Lo contó todo en los estantes, bueno, y con muchos detalles profundos. Aquellos que lo vieron y lo recuerdan bien probablemente notarán que copié algunas cosas de allí, porque de lo contrario es imposible, él lo contó todo, así que lo repetiré.
¿Qué medimos? Había una cosa llamada PSS (Tamaño de conjunto proporcional). Es decir, la RAM en Android está representada por unos bloques de 40 kilobytes, y estos bloques pueden pertenecer por completo a la aplicación o revolver entre procesos y aplicaciones.
Y la pregunta es: ¿cómo entender exactamente con qué aplicación relacionar esta memoria compartida? Hay varios enfoques, son bastante lógicos. PSS dice que si la memoria no funciona entre N procesos, entonces asumiremos que su aplicación posee 1 / N de esa memoria. Y exactamente de la misma manera está el Tamaño de conjunto residencial y el Tamaño de conjunto único, que dice que "Ninguna de la memoria compartida me pertenece" y "Todo pertenece". En principio, PSS es el más lógico aquí.
¿Cómo se puede medir exactamente la memoria consumida? Todo es simple aquí. O es un generador de perfiles en Android Studio, o es dumpsys. Existen, por supuesto, otras herramientas. Pueden darle resultados más detallados, algo más complicado, pero el problema es que para comprender sus resultados, usarlos todo esto es muy, muy difícil. A menudo necesita una raíz o una compilación personalizada de Android. Y, en general, no los necesita, las dos primeras herramientas son suficientes.
No hablaré sobre el generador de perfiles en Android Studio, creo que mucha gente lo usó. Quien no ha usado, asegúrese de meter. En particular, proporcioné el siguiente enlace: solo un buen artículo de la documentación con video, cómo usarlo, con demostraciones. Y, en principio, todo está claro. Muestra dónde va tu memoria, lo muestra en tiempo real. Lo único que debe recordar es que, sin embargo, impone ciertos errores que surgen del hecho de que medimos constantemente esta memoria. Pero están dentro de límites aceptables.
Dumpsys es una consola simple que no requiere nada de usted, solo un teléfono conectado y adb. Y puede ejecutar este comando: llame a dumpsys meminfo, páselo y le devolverá algo como esto. Y si estamos interesados en cuánto consume nuestra aplicación, podemos ver específicamente TOTAL, que dice que "su aplicación consume aproximadamente 168 megabytes". Mucho, pero ¿qué hacer?
También le muestra un desglose de la cantidad exacta de memoria que se consume en esta memoria. Hay varias secciones aquí, son complejas, hablaremos más sobre ellas, pero por ahora podemos notar lo principal: estos son Java Heap, nuestros objetos Java, y todo lo demás es más complicado.
¿Qué más es importante? La memoria es muy sensible a todo tipo de pruebas y todo tipo de condiciones externas. Es decir, todas las pruebas que debe realizar tanto como sea posible en las mismas condiciones. Está claro que este debería ser idealmente un dispositivo, porque la memoria depende de la versión de Android. Es suficiente recordar las diferencias entre los cuatro y los cinco. Depende del tamaño o la resolución de la pantalla, porque cuanto más grande sea el tamaño de la pantalla, más contenido se filtra, más memoria necesita para dibujarlo todo. Cuanto mayor sea la resolución, más píxeles ocupará su mapa de bits y se necesitará más memoria para almacenarlos.
El escenario de la aplicación también afecta las pruebas. Puede leer el texto o puede desplazarse por la galería con un montón de imágenes. Y está claro dónde habrá más memoria.
Otra cosa importante es la carga en el dispositivo. Es decir, puede tener todo igual, pero en un caso su aplicación es la única que funciona para usted, y en el otro caso tiene un montón de aplicaciones que hacen algo en segundo plano, descargan algo, lo eliminan, funcionan en primer plano y, al mismo tiempo, su memoria simplemente se exprime, porque necesita dársela a otras aplicaciones. Por lo tanto, idealmente, es mejor tomar y eliminar todas las demás aplicaciones que funcionan, no la suya. Todo lo que puedas alcanzar, luego matar. Solo en este caso, y PSS definitivamente te lo agradecerá, porque no habrá necesidad de perder la memoria entre los procesos.
Puede, por ejemplo, tomar y ver la información actual en la memoria libre, en la memoria ocupada. Te traerá algo así como un letrero que dice: "Aquí tengo tanta memoria libre, tanta memoria en caché, tanta memoria ocupada". Y si tiene 200-250 megabytes de memoria libre para su amado allí, entonces es bueno, lo más probable es que nada afecte sus pruebas.
Quizás alguien ahora tiene la pregunta "¿Por qué necesito todo esto?" Este es un factor decisivo en el que además diré la motivación para todo esto.
En primer lugar, incluso si no vas a hacer nada con Android Go ahora y piensas que está muerto, es posible que se desarrolle, venga a ti, y en algún momento tendrás que lidiar con todo esto.
La segunda cosa que considero muy importante es que puedes hacer pruebas de regresión desde la memoria. Es decir, simplemente puede escribir una secuencia de comandos que ejecutará la aplicación, ejecutará dumpsys, tomará dichas medidas y verá cómo cambian estos indicadores entre versiones. Tal script se puede escribir en un par de horas, la infraestructura se puede configurar por más tiempo, pero me parece que es algo bueno.
Si hablamos de los detalles de Android Go, nuestro tercer punto en la lucha contra la memoria, entonces hay buenas noticias. Primero, nadie realmente requiere que sigas estas restricciones. Es decir, puede usar la aplicación tal como está, ponerla en el dispositivo con Android Go, y todo está bien. El problema es que es muy probable que el usuario lo elimine porque está ocupando mucho espacio. Además, su aplicación puede ejecutarse lentamente y tener mucha memoria, sí. Pero hasta ahora nadie lo ha prohibido, porque de lo contrario no habría habido otra aplicación que las aplicaciones de Google en Android Go. Pero si esto se desarrolla aún más, muchos se adaptarán a tales condiciones, entonces, al final, su aplicación simplemente puede reducirse en la emisión de Android Go, o puede mostrar a Alert cómo el usuario instala la aplicación en su teléfono inteligente Android Go. : "Amigo, la aplicación no funciona bien con Android Go. ¿Quizás no lo pongas? "
Hay otro punto: puede excluir manualmente los dispositivos Android Go de Google Play, es decir, que la aplicación no se puede instalar en dispositivos Android Go. Apareció no hace mucho tiempo.
Y Google también es lo suficientemente inteligente, y los 50 megabytes que sonaron en el título del informe no son un número fijo, sino que dependen de la resolución del dispositivo, del tamaño de la pantalla y, además, del tipo de aplicación. Por ejemplo, los juegos se asignan más, en mi opinión, 115 megabytes. En principio, esto es comprensible.
¿Qué pasa si hablamos directamente sobre esta prueba? Hay un punto más, que en particular nos preocupa mucho: trabajar con presets. Cuando los vendedores hacen un nuevo teléfono, a menudo ponen allí un conjunto de aplicaciones preinstaladas. En particular, estamos muy involucrados en esto, y el problema es que allí ejecutan cosas como Compatibility Test Suite. Estas son pruebas de google, las ejecutan. Y allí, si su aplicación no corresponde a estos 50 megabytes, entonces todo está mal y su aplicación no puede preinstalarse en dicho dispositivo.
Desafortunadamente, las pruebas que hace Google no son de código abierto, no puedo decirles, están bajo el NDA, pero los buenos desarrolladores de Google escribieron un artículo sobre Android Go, y allí, en principio, hay recomendaciones que son lo suficientemente buenas.
Es decir, todo es trivial. Lanzamos la aplicación. Esperamos 5 segundos para que todo se cargue. Hacemos dumpsys, escribimos el valor TOTAL, ejecutamos varias veces, obtenemos el resultado. Todo es muy simple y común.
Lo único es que no tomaron en cuenta una característica tan pequeña en su artículo o, tal vez, no hablaron sobre ello; existe la posibilidad de trabajar en otro proceso, y a menudo lo hacen para luchar, incluido el consumo de memoria.
¿Quién cree que esto es bueno para Android Go? ¿Y quién piensa que esto es malo? Valientemente
El problema es que sí, esto es malo, porque al final, la memoria de la aplicación consumida se cuenta en todos los procesos. Si hacemos un proceso tan vacío sin nada y tomamos dumpsys de este proceso en particular, veremos que toma 7 megabytes. 5-8 megabytes: esta es una sobrecarga de la creación del proceso. Por lo tanto, cuando luchamos por cada megabyte para exprimirlo todo en 50, tal cosa se nos da muy mal. En particular, digamos que Yandex tiene la biblioteca Yandex.Metrica más popular, también funciona en un proceso diferente, y esto también nos puede causar dolor.
Por lo tanto, si algunas bibliotecas externas vienen a usted, por ejemplo, simplemente puede decir: “Amigo, trabaja, por favor, en el proceso principal. Estoy de acuerdo en que esto puede ser más lento, pero no consumirá memoria innecesaria ". Entonces este también es un punto sutil.
Si hablamos sobre el consumo de memoria, pasemos a este plato, que está allí. Tomamos un proyecto vacío, y ejecutamos este dumpsys, iniciamos este negocio, y vemos que 23 megabytes de 50 ya están ocupados. Vacío "¡Hola, mundo!" sin nada, solo actívalo con el texto. Se está poniendo muy triste. Se vuelve aún más triste al darse cuenta de que podemos influir directamente en un parámetro como Java Heap, es decir, estos son directamente nuestros objetos Java que podemos rastrear explícitamente, que podemos eliminar, reducir y al menos interactuar de alguna manera.
Y es difícil interactuar normalmente con todo esto, porque este es un código de marco y directamente desde Java simplemente no tienes herramientas normales para entender cómo se usa todo esto. Pero la buena noticia es que podemos influir en todo esto indirectamente, así que hablemos de lo que hay allí.
Lo que es Java Heap es comprensible. Lo que es Native Heap también es bastante lógico de suponer. Estas son las mismas asignaciones, solo las positivas. Vienen del marco y de sus bibliotecas nativas, archivos .so y más.
El código está directamente relacionado con el almacenamiento de código. Este es el tamaño de su .dex, este es su .so, estos son los recursos, archivos mmap y todo eso. Es decir, cuanto menos código, mejor. La verdad más simple que funciona en general sobre todo.
Stack es una pila de hilos Java / C ++. Es decir, cada subproceso tiene su propia pila de llamadas, por lo que cada subproceso crea un área de memoria tan específica para almacenar todo esto.
Los gráficos son una representación de la interfaz de usuario. Hay mapas de bits parcialmente almacenados que se dibujan y lo que está conectado con ellos.
Privado otro, Sistema: esto es algo en lo que no podemos influir en absoluto y, de hecho, todo lo demás que no es muy categorizable.
Si hablamos de bibliotecas nativas, entonces, digamos que puede tomar una aplicación vacía ... puede tomar la aplicación habitual que tenemos y quitar dumpsys de ella, ver que toma 146 megabytes. Y si vas y cortas algo ... en particular, tomé y vi las dos bibliotecas nativas más grandes, que tenemos un total de 15 megabytes, y tomamos dumpsys después de eso, puedes ver fácilmente que hemos perdido el consumo del Native Heap y del código Es decir, con un gesto tan simple, nos ahorramos unos 35 megabytes. No es lo suficientemente malo.
Corrientes Hagamos la prueba más fácil. Hay una aplicación vacía, y hay la misma aplicación vacía, donde tomamos y hacemos un bucle que hará un nuevo Thread (), dormiremos en él durante cinco segundos e iniciaremos este hilo. Puede ver que en este caso, la pila se repone en gran medida. Es decir, podemos influir en todo esto, pero indirectamente, reduciendo el número de hilos en el código Java. Es decir, a través de objetos Java, incluida la influencia de todas estas ubicaciones que se encuentran en otros elementos.
Si continúa hablando de subprocesos, puede ver fácilmente lo que tiene para los subprocesos, lo que hacen en la aplicación. Hay diferentes herramientas Puede usar el mismo systrace, solo puede usar la consola para encontrar la identificación de su proceso y tomar ps por qué hilos están en el sistema.
Si lo haces bien y usas todo tipo de ThreadFactory para nombrar tus hilos, entonces puedes entender lo que deberías tener, lo que no debería ser, y así reducir todo, porque tener 100 hilos en la aplicación carece de sentido.
¿Qué más se puede hacer? Hay un conjunto conocido de consejos de acordeón de botones: esté atento a fugas, use piscinas, no cree objetos cuando no lo necesite, y todas estas tonterías, todo esto se aplica. Genial
Existe una buena correlación entre cuánto consume memoria su aplicación y qué tan grande es. Es decir, cuanto más grande sea su aplicación, más memoria consumirá, por lo tanto, de una manera simple, reduzca el peso del APK, reduzca el peso de .dex, reduzca .so, elimine todo lo que se pueda eliminar.
. , , , . , ? — — , . , , . . — .
dumpsys, , , . , , View, WebView, Assets, .
, , , , , SharedPreference SQLite - , , , .
, , Assets. , , – . 1,5 . -, , . .
— WebView. , WebView, , dumpsys, 100 , . , , - , , 300 — . , WebView , . -.
Google . . WebView, Google, - . WebView. .
Google Go, Android Go-. , - layout , . , , , Chrome Tabs, Chrome . .
Android Go, ? , Android Go, .
Hay varias formas -, , , Android Go . , , . , , , - build , - , , - . APK, , — uses-feature «low-memory», APK.
, , Android Go. Google. , , Go- .
, ? , , - , : «, - . ». . , , , , , - , , - . , , , , Google, Google , . , , , Android Go , , .
, , , -. .
, Google I/O: , - . , , , , , - , . , « , . ». . , . , .
? , . — , , 98% . , , , . . - Android Go-. , YouTube Go . YouTube , , , . No lo se , Android Go , , , — . — Facebook Lite, Twitter Lite, . Lite, - . -, , . Facebook, . , , . , — , Android Go.
?
Stack Overflow, 1000 . . , , , . , , — dumpsys.
, Android , 512 , Android 4.4.
API , .
, . , . — , .
, : « ». : «». . — , . - 170 . . - . ? , , , , - . - — . 105 . .
. build- -. densitySplit, , resConfig, . , , — . ProGuard . , ProGuard , , , , , stacktraces.
. , , Android Go- .
- 64 . : «, ». 14 , 4 , 60 . , . . , . — , , , , . , , , Android Go, . 10 , APK , , . , , .
Entonces la mejor solución es la segunda aplicación. Sin embargo, pocas personas gastarán recursos en él, mientras que el beneficio real no está claro. Quizás tu historia no sea tan triste, porque me quedaba un poco de esfuerzo, habría escalado, pero ya era insoportable. Pero tal historia. En esta nota relativamente positiva, probablemente puedas terminarlo. Gracias a todos.