在 Android 中实现 App 启动库

启动时间较短的应用程序具有更好的用户体验。因此，在本文中，我们将与您讨论为什么需要 App Startup Library。最重要的是，我们将了解它解决了哪些困难，以及它如何帮助我们减少应用程序启动所需的时间。您的应用程序启动所需的时间对消费者如何看待它有很大影响。本文的主要目的是帮助您了解 App Startup 库存在的原因，而不是如何使用它。如果我们了解它所回答的必要性和挑战，一切都会变得相对简单。首先，Google 发布了 App Startup 库，这无疑将有助于改善 App Startup 时间。 Android Jetpack 包含应用启动库。我们需要掌握应用程序开发人员或库开发人员所采取的现有方法的问题，以便充分理解 App Startup 库解决的挑战并充分利用它。了解这些因素也将有助于我们适当地使用 App Startup 库。

当前方法中的问题

您可能已经观察到许多库已经停止请求应用程序的上下文，尽管上下文对于库的函数至关重要。当库过去询问应用程序的上下文时，我们曾经这样做过：

Kotlin

class GeeksforGeeksApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        SomeLibOne.doSomething(this)
        SomeLibTwo.doSomething(this)
        SomeLibThree.doSomething(this)
        SomeLibFour.doSomething(this)
        SomeLibFive.doSomething(this)
    }
}

Kotlin

class GeeksforGeeksApplication : Application() {
    override fun onCreate() {
        super.onCreate()
    }
}

Kotlin

class GfGDeubg : ContentProvider() {
    override fun onCreate(): Boolean {
        GfGDebug.initialize(context, DebugDBFactory())
        return true
    }
    // Some other code
}

当图书馆停止询问我们的背景时：

科特林

class GeeksforGeeksApplication : Application() {
    override fun onCreate() {
        super.onCreate()
    }
}

因此，库必须有一种方法来获取应用程序的上下文，而无需询问我们。实际上，所有这些库都使用了 ContentProvider，包括 Firebase、Facebook 等。让我们以我们之前创建的库为例来看看它是如何工作的：Android-Debug-Database

科特林

class GfGDeubg : ContentProvider() {
    override fun onCreate(): Boolean {
        GfGDebug.initialize(context, DebugDBFactory())
        return true
    }
    // Some other code
}

首先，我们扩展 ContentProvider：您会注意到我们能够访问应用程序的上下文并在此处初始化库。然后，在 Android Manifest 中，我们添加以下内容：

其背后的机制是什么？

当应用程序启动时，它会获取我们在 Android Manifest 中指定的所有提供程序，在我们的例子中它们实际上是 ContentProvider，并实例化所有这些提供程序，调用它们的 onCreate 方法。所有库都将以这种方式初始化。

GeekTip: All of this occurs when the app first launches. As a result, it accomplishes the same goal as if we had passed the context when initializing those libraries in our Application class.

编程需要懂一点英语

然而，当我们通过 ContentProvider 执行此操作时，会出现以下复杂情况：

创建内容提供者的成本很高：如果有多个库，则每个库都有自己的内容提供者。由于将实例化大量内容提供程序，应用程序的启动将变慢。
我们可以通过对所有库使用单一内容源来提高效率。因此，应用程序的启动时间将大大减少。
由于 Android 系统没有关于库初始化顺序的信息，因此当一个库的初始化依赖于另一个库的初始化时，可能会产生问题。它可能会导致意外行为。

因此，需要一个能够满足所有这些需求并同时强大的智能库！

使用 App 启动库开始

App Startup Library 克服了我们之前解决的两个问题。

它通过从我们这里获取以下数据来解决问题：

所有人的初始化器：如有必要，初始化并检索对象。它使用单个内容提供程序来调用所有初始化程序。
库的相互依赖关系如下：
- 它帮助库确定应该初始化库的顺序。
在我们实施之前，我们需要知道谁将负责它，因为有两种选择：
- 自有库/模块：我们可能已经开发了某些模块并使用了内容提供者策略。在这种情况下，我们需要按照 App Startup 库的说明进行操作。
- 来自第三方的其他库