Make writing a habit together! This is the 10th day of my participation in the “Gold Digging Day New Plan · April More text Challenge”. Click here for more details.

1. Non-invasive initialization of SDK and acquisition of Application

Non-intrusive initialization of the SDK and obtaining the Application means that the business side does not need to manually call the initialization function of the SDK.

This is done using one of Android’s four basic components, a ContentProvider, which is executed after the attchBaseContext() of the Application and before the onCreate() of the Application.

So we can customize a ContentProvider to complete the SDK’s automatic initialization and get the Application.

class CPDemo : ContentProvider() {
    override fun attachInfo(context: Context? , info:ProviderInfo?). {
        super.attachInfo(context, info)
        // Write the SDK initialization logic and get the Application
        valapplication = context? .applicationContext }override fun onCreate(a): Boolean = true
}
Copy the code

Simply override the ContentProvider and perform the SDK’s initialization logic at attachInfo.

The well-known memory leak detection library LeakCanary, Google’s official ProcessLifecycleOwner, uses this principle.

However, if every third party library borrows ContentProviders for non-invasive initialization, there will be too many custom ContentProviders, which directly increases the startup time:

In order to avoid the problem of too many contentProviders, Google officially provides App Startup library, which is mainly used for SDK providers to achieve non-invasive initialization:

    implementation("Androidx. Startup: startup - runtime: 1.1.1")
Copy the code

The official library consolidates all the contentProviders used for initialization into one, reducing startup time

The basic usage is as follows:

class CPDemo2 : Initializer<Unit> {
    override fun create(context: Context) {
        // Perform initialization logic
    }

    override fun dependencies(a): MutableList<Class<out Initializer<*>>> = mutableListOf()
}
Copy the code

Then register in AndroidManifest:

<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>
Copy the code

More usage can be found in Shen Guo’s article: New member of Jetpack, App Startup

2. Is it really good that the kotlin function omits the return type?

Programs that use Kotlin frequently know that kotlin functions may not display declared return value types in certain situations. This is to improve development efficiency, for example:

fun test(a) = ""
Copy the code

For simple functions, the return type of the method is String, but other methods are called. For example:

fun test(a) =  request()

// Any function that calls other functions in the body of the function
fun request(a) = otherFun()

fun otherFun(a) = "hahaha"
Copy the code

In this case, if we want to know the return type of test() method, we must first go through the request() function and then jump to otherFun to know the return type of test() method, which will reduce development efficiency for the program.

So I think the scenario where the kotlin function is used to omit the return value type should assume that the return value type of the function can be easily inferred by the program (try not to rely on other functions)

Refer to the article

New member of Jetpack, App Startup