SDK se inicializa sin intrusión y obtiene la aplicación

¡Acostúmbrate a escribir juntos! Este es el décimo día de mi participación en el "Nuggets Daily New Plan · April Update Challenge", haz clic para ver los detalles del evento .

1.SDK se inicializa sin intrusión y obtiene la aplicación

无侵入初始化SDK并获取ApplicationSignifica que la parte comercial no necesita llamar manualmente a la función de inicialización del SDK.

Esto tiene que usar uno de los cuatro componentes básicos de Android . El momento de ContentProvidersu ejecución se encuentra después y antes , y no hay necesidad de llamar manualmente al programa.ApplicationattchBaseContext()ApplicationonCreate()

Así podemos personalizar ContentProviderla aplicación para completar la inicialización automática del SDK y obtener la aplicación.

class CPDemo : ContentProvider() {
    override fun attachInfo(context: Context?, info: ProviderInfo?) {
        super.attachInfo(context, info)
        //编写SDK初始化逻辑，并获取Application
        val application = context?.applicationContext
    }

    override fun onCreate(): Boolean = true
}
复制代码

Simplemente reescriba ContentProvidery attachInfoejecute la lógica de inicialización del SDK.

La conocida biblioteca de detección de fugas de memoria LeakCanary, la oficial de Google ProcessLifecycleOwner, utiliza este principio.

Sin embargo, si se toman prestadas todas las bibliotecas de terceros ContentProviderpara completar la inicialización no intrusiva, inevitablemente provocará demasiada personalización ContentProvider, lo que aumenta directamente el tiempo de inicio:

Para evitar ContentProviderdemasiados problemas, Google ofrece oficialmente una App Startupbiblioteca, que utilizan principalmente los proveedores de SDK para lograr una inicialización no invasiva:

    implementation("androidx.startup:startup-runtime:1.1.1")
复制代码

该官方库会将所有用于初始化的ContentProvider合并成一个，减少启动的耗时

El uso básico es el siguiente:

class CPDemo2 : Initializer<Unit> {
    override fun create(context: Context) {
        //执行初始化逻辑
    }

    override fun dependencies(): MutableList<Class<out Initializer<*>>> = mutableListOf()
}
复制代码

Entonces AndroidManifestregístrese de nuevo:

<provider
    android:name="androidx.startup.InitializationProvider"
    android:authorities="${applicationId}.androidx-startup"
    android:exported="false"
    tools:node="merge">
    <meta-data
        android:name="com.example.gitlinux.CPDemo2"
        android:value="androidx.startup" />
</provider>
复制代码

Para obtener más información sobre el uso, consulte el artículo de Guo Shen: Nuevos miembros de Jetpack, puede comprenderlo en el inicio de una aplicación

2. ¿Es realmente bueno que las funciones de Kotlin omitan el tipo de valor de retorno?

Los programas que a menudo usan kotlin saben que, en algunos escenarios, las funciones de kotlin no necesitan declarar explícitamente el tipo de valor devuelto, que es para mejorar la eficiencia del desarrollo, como:

fun test() = ""
复制代码

Para funciones simples, aunque se omite el tipo de retorno del método, todavía podemos ver directamente que el tipo de valor de retorno de este método es String, pero se llaman otros métodos en el método, como:

fun test() =  request()

//随便一个函数，这个函数体中还会调用其他的函数
fun request() = otherFun()

fun otherFun() = "hahaha"
复制代码

En este caso, si queremos conocer test()el tipo de valor de retorno del método, primero debemos pasar la request()función y luego saltar al método otherFunpara conocer test()el tipo de valor de retorno del método, lo que reduce la eficiencia de desarrollo del programa.

Así que creo que el escenario de usar funciones de kotlin para omitir el tipo de valor devuelto debería tener una premisa:该函数的返回值类型程序能够很容易推断出来（尽量不依赖其他函数）

Artículo de referencia

Un nuevo miembro de Jetpack, puedes entenderlo en una aplicación Inicio