一万四千字重温 Android 四大组件

Kapaseker2025-12-18 9:02

本系列为小说《逆袭西二旗》的技术讲解，用于详细说明剧情里涉及的开发细节。

我相信各位开发者对于 Android 四大组件熟悉的不能再熟悉了。但正因如此，我们往往容易忽略它们背后的设计初衷、生命周期细节以及在现代架构中的最佳实践。

现在，来一次深入的回顾，不仅能帮我们避开隐藏的坑点，更能重新理解 Android 系统的运行逻辑，让代码更健壮、架构更清晰。

什么是 Application

在 Android 中，Application 类是用于维护应用全局状态和生命周期的基类。它充当整个应用的入口点，在任何其他组件（如 Activity、Service 或 BroadcastReceiver）初始化之前就被创建。Application 类提供了一个贯穿整个应用生命周期的 Context，因此非常适合用来初始化那些需要全局共享的资源。

面试问题

Application 类的作用是什么？

它和 Activity 在生命周期和资源管理上有何区别？

Application 的作用

Application 类的设计初衷就是保存全局状态，并执行应用范围内的初始化操作。开发者通常会继承这个类，用以设置依赖项、配置第三方库，以及管理那些需要在多个 Activity 和 Service 之间持续存在的资源。

默认情况下，每个 Android 应用都会使用系统提供的 Application 基类实现，除非你在 AndroidManifest.xml 文件中明确指定了一个自定义的子类。

Application 类中的关键方法

  1. onCreate()：当应用进程被创建时调用。这是你初始化全局依赖项（比如数据库实例、网络库或分析工具）的标准位置。在整个应用生命周期中，该方法只会被调用一次。
  2. onTerminate()：仅在模拟器环境中应用终止时调用。在真实设备的生产环境中不会被触发，因为 Android 并不保证它会被执行。
  3. onLowMemory() 与 onTrimMemory()：当系统检测到内存不足时触发。onLowMemory() 主要用于较老的 API 版本，而 onTrimMemory() 提供了更细粒度的控制，能根据应用当前的内存状态做出响应。

如何使用 Application 类

要定义一个自定义的 Application 类，你需要继承 Application，并在 AndroidManifest.xml 的 <application> 标签中声明它：

Kotlin 复制代码 
class CustomApplication : Application() {

    override fun onCreate() {
        super.onCreate()
        // 初始化全局依赖
        initializeDatabase()
        initializeAnalytics()
    }

    private fun initializeDatabase() {
        // 设置数据库实例
    }

    private fun initializeAnalytics() {
        // 配置分析追踪
    }
}
xml 复制代码 
<application
    android:name=".CustomApplication"
    ... >
    ...
</application>

适用场景

  1. 全局资源管理 ：数据库、SharedPreferences 或网络客户端等资源只需初始化一次，即可在全应用复用。
  2. 组件初始化 ：像 Firebase Analytics 、Timber 这类工具应在应用启动阶段完成初始化，以确保在整个生命周期中无缝运行。
  3. 依赖注入 ：你可以在这里初始化 Dagger 或 Hilt 等依赖注入框架，为整个应用提供统一的依赖管理。

最佳实践

  1. 避免在 onCreate() 中执行耗时操作，以免拖慢应用启动速度。
  2. 不要把 Application 类当成"杂物抽屉"。只放真正全局相关的逻辑，保持职责单一。
  3. 管理共享资源时注意线程安全，尤其是在多线程环境下访问这些资源。

总结

Application 类是整个应用中初始化和管理全局资源的核心场所。虽然它是进行全局配置的重要基础 API，但应仅用于真正需要全局处理的任务，以保持代码清晰，避免不必要的复杂性。

AndroidManifest 文件

AndroidManifest.xml 文件是 Android 项目中的一个关键配置文件，它向 Android 操作系统定义了关于应用程序的重要信息。它充当了应用程序与操作系统之间的桥梁，告知操作系统应用程序的组件、权限、硬件和软件特性等信息。

它就像一张身份证，告诉系统：我是谁、我能干啥、需要什么权限、依赖哪些硬件------没它，你的 App 连门都进不去。

面试问题

AndroidManifest 中的意图过滤器如何实现应用程序之间的交互？

如果一个 Activity 类未在 AndroidManifest 中注册会发生什么？

关键功能

  1. 应用程序组件声明 ：它注册了诸如 Activity 、Service、 BroadcastReceiver 和 ContentProvider 等基本组件， 以便 Android 系统知道如何启动或与它们交互。
  2. 权限 ：它声明了应用程序所需的权限，例如 INTERNET、ACCESS_FINE_LOCATION 或 READ_CONTACTS，这样用户就能知道应用程序将访问哪些资源，并可以授予或拒绝这些权限。
  3. 硬件和软件要求：它指定了应用程序依赖的功能，例如摄像头、GPS 或 某些屏幕尺寸，帮助应用商店过滤掉不符合这些要求的设备。
  4. 应用程序元数据：提供了应用程序的基本信息，例如包名、版本、最低和目标 API 级别、主题和样式，系统在安装和执行应用程序时会使用这些信息。
  5. 意图过滤器 ：为组件（例如 Activity）定义了 IntentFilter ，以指定它们可以响应的意图类型， 如打开链接或共享内容，从而允许其他应用程序与之交互。
  6. 应用程序配置和设置 ：包括设置主启动器 Activity、配置备份行为以及指定主题等配置， 这些有助于控制应用程序的行为和显示方式。 以下是一个 AndroidManifest.xml 文件的示例，如下所示：
xml 复制代码 
1  <manifest xmlns:android="http://schemas.android.com/apk/res/android">
2  
3      <!-- Permissions -->
4      <uses-permission android:name="android.permission.INTERNET" />
5      <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
6  
7  <application
8      android:allowBackup="true"
9      android:icon="@mipmap/ic_launcher"
10     android:label="@string/app_name"
11     android:theme="@style/AppTheme">
12 
13     <!-- Main Activity -->
14     <activity android:name=".MainActivity">
15         <intent-filter>
16             <action android:name="android.intent.action.MAIN" />
17             <category android:name="android.intent.category.LAUNCHER" />
18         </intent-filter>
19     </activity>
20 
21     <!-- Additional Components -->
22     <service android:name=".MyService" />
23     <receiver android:name=".MyBroadcastReceiver" />
24 
25 </application>
26 </manifest>

总结

AndroidManifest.xml 文件对每个 App 至关重要，它向 Android 操作系统提供了管理应用程序生命周期、权限和交互所需的所有细节。它本质上充当了一个定义应用程序结构和要求的蓝图。

这里给出一个较长（但还远远不够完整）的例子：

xml 复制代码 
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
  xmlns:tools="http://schemas.android.com/tools" >

  <uses-permission android:name="android.permission.INTERNET" />

  <application
    android:name=".FeedinApp"
    android:allowBackup="false"
    android:icon="@mipmap/ic_launcher"
    android:label="@string/app_name"
    android:supportsRtl="true"
    android:theme="@style/AppTheme"
    tools:ignore="AllowBackup">

    <activity
      android:name=".ui.main.MainActivity"
      android:exported="true"
      android:launchMode="singleTop">
      <intent-filter>
        <action android:name="android.intent.action.MAIN" />

        <category android:name="android.intent.category.LAUNCHER" />
      </intent-filter>
    </activity>

    <activity
      android:name=".ui.details.DetailActivity"
      android:launchMode="singleTop" />

    <provider
      android:name="androidx.startup.InitializationProvider"
      android:authorities="io.xetom.feedin.androidx-startup"
      android:exported="false"
      tools:node="merge">

      <meta-data
        android:name="io.xetom.feedin.initializer.TimberInitializer"
        android:value="androidx.startup" />
    </provider>

    <profileable
      android:shell="true"
      tools:targetApi="q" />

  </application>

</manifest>

Activity 的生命周期

Android Activity 的生命周期描述了 Activity 在其生命周期中从创建到销毁所经历的不同状态。理解这些状态对于有效管理资源、处理用户输入以及确保流畅的用户体验至关重要。

面试问题

onPause() 和 onStop() 有什么区别？

在哪些场景下应该分别用来处理耗资源的操作？

生命周期回调

以下是 Activity 生命周期的主要阶段：

  1. onCreate()：当一个 Activity 被创建时，这是第一个被调用的方法。在这里你可以初始化 Activity、设置 UI 组件，并恢复任何保存的实例状态。除非 Activity 被销毁并重新创建，否则在整个 Activity 生命周期中只会调用一次。
  2. onStart()：Activity 对用户变得可见，但尚不可交互。该方法在 onCreate() 之后和 onResume() 之前被调用。
  3. onRestart()：如果 Activity 停止后又被重新启动（例如，用户重新回到该 Activity），此方法会在 onStart 之前被调用。
  4. onResume()： Activity 处于前台，用户可以与之互动。这是恢复暂停的UI更新、动画或输入监听器的地方。
  5. onPause()：当 Activity 被另一个 Activity 部分遮挡时（例如，弹出对话框），会调用此方法。Activity 仍然可见但不在焦点上。通常用于暂停动画、传感器更新或保存数据等操作。
  6. onStop()： Activity 对用户不再可见（例如，另一个 Activity 进入前台）。你应该释放 Activity 停止期间不需要的资源，比如后台任务或大型对象。
  7. onDestroy()：在 Activity 被完全销毁并从内存中移除之前调用。这是释放所有剩余资源的最终清理方法。

总结

一个 Activity 会根据用户的操作和 Android 系统对资源的管理依次回调这些方法。开发者通过这些回调来处理界面切换、节省资源、保证用户体验流畅。

进阶：Activity 切换

关于 Activity 生命周期，一个常见的进阶问题是：

"你能描述一下依次启动 Activity A、然后 Activity B，最后返回 Activity A 时发生的生命周期变化吗？"

这个问题能很好地检验你对 Android 系统如何管理多个 Activity 状态的理解。

在两个 Activity 之间导航时（比如从 Activity A 跳到 Activity B），每个 Activity 的生命周期回调会按特定顺序触发。我们来一步步拆解这个过程：

Activity A 和 Activity B 的完整生命周期流程：

  • 初次启动 Activity A
    Activity A: onCreate() → onStart() → onResume()。这是首次创建时的标准流程。此时用户正在与 Activity A 交互。

  • 从 Activity A 跳转到 Activity B
    Activity A: onPause()。暂停 UI 更新，释放与可见性相关的轻量资源。

    Activity B: onCreate() → onStart() → onResume()。创建并进入前台，获得用户焦点。

    Activity A: onStop()。如果 Activity B 完全覆盖了 Activity A（比如是全屏页面），系统会接着调用 onStop()。这一步不是总发生，但常见于标准跳转。

  • 从 Activity B 返回 Activity A
    Activity B: onPause()。 Activity A: onRestart() → onStart() → onResume()。重新激活，回到前台继续交互。

    Activity B: onStop() → onDestroy()。若系统决定回收它（比如通过返回键退出），就会走完销毁流程。

总之：

在 Activity 切换过程中，前台的 Activity 总是先调用 onPause()，再退到后台。

新启动的 Activity 从 onCreate() 开始，一路走到 onResume()，接管用户焦点。

而当你返回之前的 Activity，它不会重新 onCreate()，而是通过 onRestart() 恢复状态。

理解这些生命周期的转换可以确保资源的正确管理和流畅的用户体验。

进阶：Activity 中的 lifecycle

每个 Activity 都与一个 Lifecycle 实例相关联，该实例提供了一种观察和响应 Activity 生命周期事件的方式。Lifecycle 是 Jetpack Lifecycle 库的一部分，它让开发人员以干净、结构化的方式管理代码，以应对 Activity 的生命周期变化。

Activity 中的 lifecycle 是 Lifecycle 类的一个实例，由所有 ComponentActivity 子类暴露出来。它表示当前 Activity 的生命周期状态，并提供了一种观察生命周期事件（如onCreate、onStart、onResume 等）的方式，而无需重写这些生命周期方法。这对于管理 UI 更新、资源清理或以生命周期感知的方式观察 LiveData 特别有用。

后续我将用 lifecycle 表示 Lifecycle 的实例（首字母小写）。

如何使用 lifecycle？

可以在 lifecycle 上添加 LifecycleObserver 或 DefaultLifecycleObserver 对象，以响应特定的生命周期事件。

例如，如果你想监听 onStart 和 onStop，可以注册一个观察者来处理这些回调：

Kotlin 复制代码 
class MyObserver : DefaultLifecycleObserver {

    override fun onStart(owner: LifecycleOwner) {
        super.onStart(owner)
    }

    override fun onStop(owner: LifecycleOwner) {
        super.onStop(owner)
    }
}

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        lifecycle.addObserver(MyObserver())
    }
}

在此示例中，MyObserver 类观察 MainActivity 的生命周期变化。当 Activity 进入 STARTED 或 STOPPED 状态时，相应的函数会被调用。

使用 lifecycle 的好处如下：

  1. 生命周期感知 ：使用生命周期实例可以让你的组件了解 Activity 的生命周期状态，避免在 Activity 不在期望状态时执行不必要的或错误的操作。
  2. 关注点分离 ：你可以将依赖生命周期的逻辑移出 Activity 类，从而提高可读性和可维护性。
  3. 与 Jetpack 库集成 ：像 LiveData 和 ViewModel 这样的库设计为与生命周期实例无缝协作，支持响应式编程和高效的资源管理。

总之：

Activity 上的生命周期实例是 Android 现代架构的关键组成部分，使开发人员能够以结构化和可重用的方式处理生命周期事件。通过利用 LifecycleObserver 和其他 Jetpack 组件，你可以创建更强大、更易于维护的应用程序。

Fragment 的生命周期

每个 Fragment 实例都有自己的生命周期，和它所属的 Activity 生命周期是分开的。当用户在 App 里操作时，Fragment 会随着添加、移除、上屏或下屏等动作，在不同的生命周期状态之间切换------比如创建、启动、可见、活跃，再到不再需要时的停止或销毁。

管好这些状态切换，才能让 Fragment 高效地使用资源、保持 UI 一致，并对用户操作做出流畅响应。

面试问题

onCreateView() 和 onDestroyView() 的作用是什么？

为什么在这些方法中正确处理与视图相关的资源很重要？

生命周期回调

Android 中的 Fragment 生命周期和 Activity 很像，但也有自己独有的方法和行为，更细、更灵活。

  1. onAttach()：当 Fragment 被关联到它的父 Activity 时，这是第一个被调用的回调。此时 Fragment 已经绑定，可以和 Activity 的上下文交互了。
  2. onCreate()：用于初始化 Fragment。此时 Fragment 已创建，但 UI 还没生成。通常在这里初始化核心组件或恢复之前保存的状态。
  3. onCreateView()：当 Fragment 的 UI 第一次被绘制时调用。你需要在这个方法里返回布局的根视图，也就是用 LayoutInflater 加载布局的地方。
  4. onViewStateRestored()：在 Fragment 的视图层级创建完成、且保存的状态已恢复到视图后调用。
  5. onViewCreated()：在 Fragment 的视图创建完成后触发。常用来设置 UI 组件，以及处理用户交互所需的逻辑。
  6. onStart()：Fragment 对用户可见了。这和 Activity 的 onStart() 类似------此时它已经活跃，但还没处于前台。
  7. onResume()：Fragment 完全激活并运行在前台，用户可以与之交互。当 Fragment 的 UI 可见且可操作时，会调用这个方法。
  8. onPause()：当 Fragment 不再处于前台但仍然可见时调用。它即将失去焦点，你应该暂停那些不该在后台继续运行的任务。
  9. onStop()：Fragment 不再可见。这里要停止那些不需要在屏幕外继续运行的操作。
  10. onSaveInstanceState()：在 Fragment 被销毁前调用，用来保存与 UI 相关的状态数据，以便后续能恢复。
  11. onDestroyView()：当 Fragment 的视图层级被移除时调用。你应该清理与视图相关的资源，比如清空适配器、置空引用，防止内存泄漏。
  12. onDestroy()：Fragment 本身正在被销毁。所有资源都应该在此时释放，但它仍与父 Activity 关联着。
  13. onDetach()：Fragment 从父 Activity 上解绑，不再与其关联。这是最后一个回调，标志着 Fragment 生命周期结束。

总结

理解 Fragment 的生命周期，对高效管理资源、应对配置变更、保证 Android 应用体验流畅至关重要。

进阶：childFragmentManager

在 Android 中，fragmentManager 和 childFragmentManager 都是用来管理 Fragment 的，但它们的作用不同，运行的范围也不同。

fragmentManager 与 FragmentActivity 或 Fragment 本身绑定，负责在 Activity 级别管理 Fragment。它能直接添加、替换或移除与父 Activity 关联的 Fragment。

当你在 Activity 中调用 supportFragmentManager，就是在访问这个 fragmentManager。由它管理的 Fragment 是兄弟关系，处于同一层级。

Kotlin 复制代码 
// 在 Activity 层级管理 Fragment
supportFragmentManager.beginTransaction()
    .replace(R.id.container, ExampleFragment())
    .commit()

这通常用于那些属于 Activity 主要导航或 UI 结构的 Fragment。

childFragmentManager 是某个 Fragment 专属的，用来管理它的子 Fragment。这让一个 Fragment 能嵌套其他 Fragment，形成多层结构。

使用 childFragmentManager 时，你是在父 Fragment 的生命周期内定义子 Fragment。这特别适合把 UI 和逻辑封装在某个 Fragment 内部，尤其是当它需要一组独立于 Activity 生命周期的嵌套 Fragment 时。

Kotlin 复制代码 
// 在父 Fragment 内管理子 Fragment
childFragmentManager.beginTransaction()
    .replace(R.id.child_container, ChildFragment())
    .commit()

由 childFragmentManager 管理的子 Fragment 只属于父 Fragment 的作用域------它们的生命周期和父 Fragment 绑定。比如，当父 Fragment 被销毁时，它的所有子 Fragment 也会一起被销毁。

他们之间的区别如下。

从作用范围来看：

  • fragmentManager 在 Activity 层级工作，管理直接绑定到 Activity 的 Fragment。
  • childFragmentManager 在某个 Fragment 内部运行，用于管理嵌套在父 Fragment 中的子 Fragment。

从使用场景看：

  • 当你需要管理构成 Activity 主要 UI 组件的 Fragment 时，使用 fragmentManager。
  • 当一个 Fragment 需要自己管理内部的子 Fragment 时，使用 childFragmentManager，这样可以让 UI 更模块化、更易复用。

从生命周期看：

  • 由 fragmentManager 管理的 Fragment 遵循 Activity 的生命周期。
  • 由 childFragmentManager 管理的 Fragment 则跟随其父 Fragment 的生命周期。

总之：

选择使用 fragmentManager 还是 childFragmentManager，取决于你应用 UI 的层级结构。

  • 如果是 Activity 级别的 Fragment，用 fragmentManager。
  • 如果要在某个 Fragment 内嵌套其他 Fragment，就用 childFragmentManager。

理解它们的作用域和生命周期，能让你的 Android 应用结构更清晰、组件更独立。

进阶：Fragment 中的 viewLifecycleOwner

在 Android 开发中，一个 Fragment 有自己的生命周期，它和宿主 Activity 绑定。但 Fragment 也有自己独立的生命周期。这个区别在管理像 LiveData 这样的生命周期感知数据源时特别重要。

viewLifecycleOwner 实例就是用来帮你搞清楚这层关系、避免出问题的。

viewLifecycleOwner 是一个与 Fragment 视图关联的 LifecycleOwner。它代表的是 View 的生命周期------从 onCreateView() 被调用开始，到 onDestroyView() 被调用结束。

这意味着你可以把 UI 相关的数据或资源，绑定到 View 的生命周期上，而不是整个 Fragment。这样能更精准地控制资源，防止内存泄漏这类问题。

Fragment 的视图生命周期比 Fragment 自身短。

如果你用 Fragment 的生命周期（比如 lifecycleOwner）来观察数据或处理事件，一旦 View 被销毁了，你可能还在试图访问它，结果就是崩溃或异常行为。

而使用 viewLifecycleOwner，就能确保所有观察者或生命周期感知组件都只在 View 存在时生效。当 View 被销毁时，更新会自动停止，干净又卫生...哦，不对，是干净又安全。

下面是一个在 Fragment 中观察 LiveData 并避免内存泄漏甚至崩溃的例子：

Kotlin 复制代码 
class MyFragment : Fragment(R.layout.fragment_example) {

    private val viewModel: MyViewModel by viewModel()

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)

        // 使用 viewLifecycleOwner 观察 LiveData
        viewModel.data.observe(viewLifecycleOwner) { data ->
            // 用新数据更新 UI
            textView.text = data
        }
    }
}

在这个例子中，viewLifecycleOwner 确保了当 Fragment 的 View 被销毁时，观察者会被自动移除------即使 Fragment 本身还活着，也不会继续接收数据，避免了内存泄漏。

lifecycleOwner 和 viewLifecycleOwner 的区别：

  • lifecycleOwner（Fragment 的生命周期）：代表整个 Fragment 的生命周期，持续时间更长，与宿主 Activity 绑定。
  • viewLifecycleOwner（Fragment 的 View 生命周期）：代表 Fragment 中 View 的生命周期，从 onCreateView 开始，到 onDestroyView 结束。

总之：

使用 viewLifecycleOwner 在 UI 相关任务中特别有用，尤其是在必须尊重 View 生命周期的场景下，比如观察 LiveData 或管理与 View 关联的资源。这样能避免内存泄漏，确保更新在 View 销毁时自动停止。

Service

Service 是一个后台组件，可以让应用在不依赖用户交互的情况下执行长时间运行的操作。

与 Activity 不同，Service 没有用户界面，即使应用不在前台，它也能继续运行。通常用于下载文件、播放音乐、同步数据或处理网络请求等后台任务。

面试问题

Android 中，started service 和 bound service 有什么区别？分别在什么场景下使用？

启动型 Service

当某个应用组件调用 startService() 时，Service 就会被启动。它会在后台持续运行，直到自己调用 stopSelf() 或被外部通过 stopService() 明确停止。

使用场景：

  • 播放背景音乐。
  • 上传或下载文件。
Kotlin 复制代码 
class MyService : Service() {
    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
        // 在后台执行长时间任务
        return START_STICKY
    }

    override fun onBind(intent: Intent?): IBinder? = null
}

绑定型 Service

其他组件通过 bindService() 来绑定 Service，并与它建立连接。只要还有组件绑定着它，Service 就会保持活跃；当所有客户端都断开连接后，它会自动停止。

使用场景：

  • 从服务器获取数据（指长时间需要通过 Service 来获取数据）。
  • 管理后台蓝牙连接。
Kotlin 复制代码 
class BoundService : Service() {
    private val binder = LocalBinder()

    inner class LocalBinder : Binder() {
        fun getService(): BoundService = this@BoundService
    }

    override fun onBind(intent: Intent?): IBinder = binder
}

前台 Service

前台 Service 是一种特殊的 Service，它在运行时会显示一个持续的通知。这种服务适用于需要用户持续感知的任务，比如播放音乐、导航或位置追踪。

Kotlin 复制代码 
class ForegroundService : Service() {
    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
        val notification = createNotification()
        startForeground(1, notification)
        return START_STICKY
    }

    private fun createNotification(): Notification {
        return NotificationCompat.Builder(this, "channel_id")
            .setContentTitle("Foreground Service")
            .setContentText("Running...")
            .setSmallIcon(R.drawable.ic_notification)
            .build()
    }
}

各类 Service 的关键区别

Service 类型 是否在后台运行 是否自动停止 是否需要 UI 通知
Started Service ✅ 是 ❌ 否 ❌ 否
Bound Service ✅ 是 ✅ 是（当所有客户端解绑后） ❌ 否
Foreground Service ✅ 是 ❌ 否 ✅ 是

最佳实践

  • 对于不需要立即执行的后台任务，优先使用 Jetpack WorkManager 而不是 Service。
  • 任务完成后及时停止 Service，避免不必要的资源消耗。
  • 合理使用前台 Service，提供清晰的通知，保证透明性。
  • 正确处理生命周期变化（如 Service 的生命周期），防止内存泄漏。

总结

Service 让应用能在无用户交互的情况下进行后台处理。

  • Started Service 会一直运行，直到手动停止；
  • Bound Service 用于与其他组件通信；
  • Foreground Service 通过持续通知保持活跃。

合理管理 Service，才能保证系统资源高效利用，同时带来流畅的用户体验。

进阶：如何处理前台 Service

前台 Service 是一种特殊类型的 Service，用于执行用户能明显感知的任务。它会在通知栏显示一个持续的通知，确保用户知道它的运行状态。这类服务常用于高优先级任务，比如媒体播放、位置追踪或文件上传。

与普通 Service 的关键区别在于：前台 Service 必须在启动时立即调用 startForeground() 并展示通知，否则系统会强制终止它：

Kotlin 复制代码 
class ForegroundService : Service() {
    override fun onCreate() {
        super.onCreate()
        // 初始化资源
    }

    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
        val notification = createNotification()
        startForeground(1, notification) // 以前台方式启动服务
        // 执行任务
        return START_STICKY
    }

    private fun createNotification(): Notification {
        val notificationChannelId = "ForegroundServiceChannel"
        val channel = NotificationChannel(
            notificationChannelId,
            "Foreground Service",
            NotificationManager.IMPORTANCE_DEFAULT
        )
        getSystemService(NotificationManager::class.java).createNotificationChannel(channel)
        return NotificationCompat.Builder(this, notificationChannelId)
            .setContentTitle("Foreground Service")
            .setContentText("Running in the foreground")
            .setSmallIcon(R.drawable.ic_notification)
            .build()
    }

    override fun onDestroy() {
        super.onDestroy()
        // 清理资源
    }

    override fun onBind(intent: Intent?): IBinder? = null
}

Service 和 Foreground Service 的关键区别在于：

  1. 用户感知 ：普通 Service 可以在后台默默运行，用户无感；而 Foreground Service 必须显示通知，让用户清楚知道它正在运行。
  2. 优先级 ：Foreground Service 优先级更高，在内存紧张时更不容易被系统杀死。
  3. 使用场景 ：普通 Service 适合轻量级后台任务；Foreground Service 更适合持续、用户可见的任务，比如播放音乐或上传文件。

那么，使用 Service 有哪些建议呢？

  1. 任务完成后一定要及时停止 Service，避免浪费系统资源。
  2. 对于不需要立即执行的后台任务，优先使用 WorkManager。
  3. 使用前台 Service 时，确保通知简洁友好、信息明确，保持透明度。

总之：

Android 的 Service 能高效执行后台任务，而 Foreground Service 则适用于需要持续运行且用户可见的场景。两者都对构建资源管理合理、体验流畅的应用至关重要。

进阶：Service 的生命周期

正如你之前所学，一个 Service 可以以两种模式运行：

  1. 通过 startService() 启动：会一直运行，直到被明确调用 stopSelf() 或 stopService() 停止。
  2. 通过 bindService() 与一个或多个组件绑定：只要还有组件绑定着它，它就会持续存在。

它的生命周期通过 onCreate()、onStartCommand()、onBind() 和 onDestroy() 等方法进行管理。

当 startService()：

  1. onCreate()：当 Service 首次创建时调用。用于初始化 Service 所需的资源。
  2. onStartCommand()：当通过 startService() 启动 Service 时触发。该方法负责执行实际任务，并通过返回值（如 START_STICKY、START_NOT_STICKY）决定服务被杀死后是否重启。
  3. onDestroy()：当使用 stopSelf() 或 stopService() 停止 Service 时调用。用于执行清理操作，比如释放资源或停止线程。
Kotlin 复制代码 
class SimpleStartedService : Service() {
    override fun onCreate() {
        super.onCreate()
        // 初始化资源
    }

    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
        // 执行长时间任务
        return START_STICKY // 如果服务被杀死，系统会尝试重启它
    }

    override fun onDestroy() {
        super.onDestroy()
        // 清理资源
    }

    override fun onBind(intent: Intent?): IBinder? = null // 启动型服务不使用绑定
}

当 bindService()：

  1. onCreate()：与启动型服务类似，当 Service 创建时调用，用于初始化所需资源。
  2. onBind()：当某个组件通过 bindService() 绑定到该服务时触发。此方法返回一个接口（IBinder），供客户端与服务通信。
  3. onUnbind()：当最后一个客户端从服务解绑时调用。这里是清理与绑定客户端相关资源的地方。
  4. onDestroy()：当服务被终止时调用，负责释放资源并停止正在进行的操作。
Kotlin 复制代码 
class SimpleBoundService : Service() {
    private val binder = LocalBinder()

    override fun onCreate() {
        super.onCreate()
        // 初始化资源
    }

    override fun onBind(intent: Intent?): IBinder {
        return binder // 返回绑定服务的接口
    }

    override fun onUnbind(intent: Intent?): Boolean {
        // 当没有客户端绑定时进行清理
        return super.onUnbind(intent)
    }

    override fun onDestroy() {
        super.onDestroy()
        // 清理资源
    }

    inner class LocalBinder : Binder() {
        fun getService(): SimpleBoundService = this@SimpleBoundService
    }
}

启动型与绑定型 Service 生命周期的关键区别在于：

  1. Started Service：独立于任何组件运行，直到被明确停止才会结束。
  2. Bound Service：仅在至少有一个客户端绑定时才存在，一旦所有客户端解绑，服务就会终止。

总之：

理解 Service 的生命周期，对实现高效、可靠的后台任务至关重要。

启动型服务执行独立任务，持续运行直到被停止；而绑定型服务为客户端提供交互接口，一旦解绑即终止。

正确管理这些生命周期，能确保资源使用最优，并避免内存泄漏。

BroadcastReceiver

BroadcastReceiver 是一个组件，它让你的 App 能够监听并响应系统级广播消息或应用自定义的广播。这些广播通常由系统或其他应用触发，用于通知各种事件，比如电池状态变化、网络连接更新，或者 App 内部发送的自定义 Intent。

BroadcastReceiver 是构建响应式应用的重要机制，能让你的程序对动态的系统或应用级事件做出及时反应。

BroadcastReceiver 正确的中文翻译是广播接收器，而广播应该是 Broadcast，但是开发者不会区分这么细。当你着重发送的时候，我们指的是广播，而着重接收的时候，我们指的是广播接收器。后续将会沿用这种习惯。

面试问题

广播有哪些不同类型？

系统广播与自定义广播在功能和用途上有什么区别？

BroadcastReceiver 的作用

BroadcastReceiver 用来处理那些不直接与 Activity 或 Service 生命周期相关的事件。

它相当于一个消息系统，让你的 App 能在不需要一直后台运行的情况下，对系统变化做出响应，从而节省资源。

广播的类型

  1. 系统广播：由 Android 操作系统发出，用于通知应用系统事件，比如电池电量变化、时区更新或网络连接状态改变。
  2. 自定义广播：由应用自身发出，用于在应用内部或不同应用之间传递特定信息或事件。

声明一个 BroadcastReceiver

要创建一个 BroadcastReceiver，你需要继承 BroadcastReceiver 类，并重写 onReceive 方法，在其中定义处理广播的逻辑。

Kotlin 复制代码 
class MyBroadcastReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        val action = intent.action
        if (action == Intent.ACTION_BATTERY_LOW) {
            // 处理低电量事件
            Log.d("MyBroadcastReceiver", "Battery is low!")
        }
    }
}

注册 BroadcastReceiver

你可以通过两种方式注册 BroadcastReceiver：

  1. 静态注册 ：适用于即使应用未运行也需要处理的事件。在 AndroidManifest.xml 文件中添加 <intent-filter>。
xml 复制代码 
<receiver android:name=".MyBroadcastReceiver">
    <intent-filter>
        <action android:name="android.intent.action.BATTERY_LOW" />
    </intent-filter>
</receiver>
  1. 动态注册 ：适用于仅在应用处于活跃状态或特定场景下才需要处理的事件。
Kotlin 复制代码 
val receiver = MyBroadcastReceiver()
val intentFilter = IntentFilter(Intent.ACTION_BATTERY_LOW)
registerReceiver(receiver, intentFilter)

注意事项

  • 生命周期管理 ：如果使用动态注册，务必在适当时候调用 unregisterReceiver 取消注册，避免内存泄漏。
  • 后台限制 ：从 Android 8.0（API 级别 26）开始，后台应用接收广播受到限制，不能在 AndroidManifest 中为隐式广播注册 BroadcastReceiver，除非该广播是专门发送给它们的。建议使用 Context.registerReceiver 或 JobScheduler 来处理这类场景。
  • 安全问题：如果广播包含敏感信息，应通过权限保护，防止未经授权的访问。

广播的典型用例

  • 监听网络连接状态的变化。
  • 响应短信或电话事件。
  • 根据系统事件（如充电状态）更新 UI。
  • 使用自定义广播来调度任务或闹钟。

总结

BroadcastReceiver 是构建响应式应用程序的关键组件，尤其适用于与操作系统交互。它们使您的应用能够高效地监听并响应系统或应用事件。正确使用 BroadcastReceiver，特别是结合生命周期感知的注册方式，并遵守较新 Android 版本的限制要求，可确保您的应用保持稳定且资源高效。

ContentProvider

ContentProvider 是一种管理对结构化数据集访问的组件，并为应用程序间的数据共享提供标准化接口。它作为一个中央存储库，供其他应用或组件查询、插入、更新或删除数据，从而确保跨应用的数据共享既安全又一致。

ContentProvider 在多个应用需要访问相同数据，或希望在不暴露数据库或内部存储结构的情况下向其他应用提供数据时尤其有用。

面试问题

ContentProvider URI 的关键组成部分有哪些？

ContentResolver 如何与 ContentProvider 交互以查询或修改数据？

作用

ContentProvider 的主要目的是封装数据访问逻辑，使跨应用共享数据更加简单和安全。它抽象了底层数据源（可以是 SQLite 数据库、文件系统，甚至是基于网络的数据），并提供一个统一的接口来与数据进行交互。

关键组成部分

ContentProvider 使用 URI （统一资源标识符）作为其数据访问地址。URI 由以下部分组成：

  1. Authority（权限） ：标识 ContentProvider（例如：com.example.myapp.provider）。
  2. Path（路径） ：指定数据类型（例如：/users 或 /products）。
  3. ID（可选） ：指向数据集中某个特定项目。

实现一个 ContentProvider

要创建一个 ContentProvider，必须继承 ContentProvider 类并实现以下方法：

  • onCreate()：初始化 ContentProvider。
  • query()：获取数据。
  • insert()：添加新数据。
  • update()：修改现有数据。
  • delete()：删除数据。
  • getType()：返回数据的 MIME 类型。
Kotlin 复制代码 
class MyContentProvider : ContentProvider() {
    private lateinit var database: SQLiteDatabase

    override fun onCreate(): Boolean {
        database = MyDatabaseHelper(context!!).writableDatabase
        return true
    }

    override fun query(
        uri: Uri,
        projection: Array<String>?,
        selection: String?,
        selectionArgs: Array<String>?,
        sortOrder: String?
    ): Cursor? {
        return database.query("users", projection, selection, selectionArgs, null, null, sortOrder)
    }

    override fun insert(uri: Uri, values: ContentValues?): Uri? {
        val id = database.insert("users", null, values)
        return ContentUris.withAppendedId(uri, id)
    }

    override fun update(uri: Uri, values: ContentValues?, selection: String?, selectionArgs: Array<String>?): Int {
        return database.update("users", values, selection, selectionArgs)
    }

    override fun delete(uri: Uri, selection: String?, selectionArgs: Array<String>?): Int {
        return database.delete("users", selection, selectionArgs)
    }

    override fun getType(uri: Uri): String? {
        return "vnd.android.cursor.dir/vnd.com.example.myapp.users"
    }
}

注册 ContentProvider

为了让其他应用程序能够访问你的 ContentProvider，你必须在 AndroidManifest.xml 文件中对其进行声明。其中 android:authority 属性用于唯一标识你的 ContentProvider。

xml 复制代码 
<provider
    android:name=".MyContentProvider"
    android:authorities="com.example.myapp.provider"
    android:exported="true"
    android:grantUriPermissions="true" />

从 ContentProvider 访问数据

你可以使用 ContentResolver 类从另一个应用程序与 ContentProvider 进行交互。ContentResolver 提供了查询、插入、更新或删除数据的方法。

Kotlin 复制代码 
val contentResolver = context.contentResolver

// 查询数据
val cursor = contentResolver.query(
    Uri.parse("content://com.example.myapp.provider/users"),
    null,
    null,
    null,
    null
)

// 插入数据
val values = ContentValues().apply {
    put("name", "John Doe")
    put("email", "johndoe@example.com")
}
contentResolver.insert(Uri.parse("content://com.example.myapp.provider/users"), values)

ContentProvider 的使用场景

  • 在不同应用程序之间共享数据。
  • 在应用启动过程中初始化组件或资源。
  • 提供对结构化数据的访问，例如联系人、媒体文件或应用特定数据。
  • 实现与 Android 系统功能的集成，例如联系人应用或文件选择器。
  • 允许通过细粒度的安全控制进行数据访问。

总结

ContentProvider 是在应用程序之间安全、高效地共享结构化数据的关键组件。它为数据访问提供了标准化接口，同时抽象了底层的数据存储机制。正确的实现和注册可以确保数据完整性、安全性，并与 Android 系统功能保持兼容。

进阶：使用 ContentProvider 初始化资源

ContentProvider 的另一个重要用途是：在应用启动时初始化资源或配置。

通常，资源或库的初始化是在 Application 类中完成的。但你可以将这部分逻辑封装到一个独立的 ContentProvider 中，以实现更好的职责分离。通过创建一个自定义的 ContentProvider 并在 AndroidManifest.xml 中注册它，可以高效地委托初始化任务。

ContentProvider 的 onCreate() 方法会在 Application.onCreate() 之前被调用，因此是一个非常理想的早期初始化入口点。例如，Firebase SDK 就使用了一个自定义的 ContentProvider 来自动初始化 Firebase SDK 。这种方式避免了在 Application 类中手动调用 FirebaseApp.initializeApp(this)。

以下是 Firebase 提供的一个示例实现：

Kotlin 复制代码 
public class FirebaseInitProvider extends ContentProvider {
    /** 在 {@link Application#onCreate()} 之前被调用。 */
    @Override
    public boolean onCreate() {
        try {
            currentlyInitializing.set(true);
            if (FirebaseApp.initializeApp(getContext()) == null) {
                Log.i(TAG, "FirebaseApp initialization unsuccessful");
            } else {
                Log.i(TAG, "FirebaseApp initialization successful");
            }
            return false;
        } finally {
            currentlyInitializing.set(false);
        }
    }
}

FirebaseInitProvider 在其 XML 文件中的注册方式如下所示：

xml 复制代码 
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools">
    <!-- 虽然 SDK 版本信息在 Gradle 构建文件中已捕获，但非 Gradle 构建仍需此配置 -->
    <!-- <uses-sdk android:minSdkVersion="21"/> -->
    <application>

        <provider
            android:name="com.google.firebase.provider.FirebaseInitProvider"
            android:authorities="${applicationId}.firebaseinitprovider"
            android:directBootAware="true"
            android:exported="false"
            android:initOrder="100" />

    </application>
</manifest>

这种模式确保了关键资源或库能够在应用生命周期的早期自动完成初始化，从而实现更清晰、更模块化的设计。

另一个值得注意的 ContentProvider 用例是 Jetpack App Startup 库，它提供了一种简单高效的方式来在应用启动时初始化组件。其内部实现使用了一个名为 InitializationProvider 的类，该类利用 ContentProvider 来初始化所有实现了 Initializer 接口的预定义类。这确保了初始化逻辑在 Application.onCreate() 方法被调用之前就已经完成。

以下是 InitializationProvider 的内部实现，它是 Jetpack App Startup 库的核心组件：

Java 复制代码 
/**
 * The {@link ContentProvider} which discovers {@link Initializer}s in an application and    
 * initializes them before {@link Application#onCreate()}.
 */
public class InitializationProvider extends ContentProvider {

    @Override
    public final boolean onCreate() {
        Context context = getContext();
        if (context != null) {
            Context applicationContext = context.getApplicationContext();
            if (applicationContext != null) {
                // Initialize all registered Initializer classes.
                AppInitializer.getInstance(context).discoverAndInitialize(getClass());
            } else {
                StartupLogger.w("Deferring initialization because `applicationContext` is null.");
            }
        } else {
            throw new StartupException("Context cannot be null");
        }
        return true;
    }
}

该实现中的 onCreate() 方法会调用 AppInitializer.getInstance(context).discoverAndInitialize(getClass())，

它会自动发现并初始化所有已注册的 Initializer 实现类，在应用生命周期开始之前完成 。

这确保了应用组件可以在不污染 Application.onCreate() 方法的情况下被高效地初始化。

如何处理配置变更

处理配置变更对于保持流畅的用户体验至关重要，尤其是在屏幕旋转、语言切换、深色/浅色模式切换，以及字体大小或粗细调整等场景中。默认情况下，当这些变更发生时，Android 系统会重启 Activity，这可能导致临时 UI 状态的丢失。

面试问题

处理配置变更有哪些不同的策略？

ViewModel 在此类事件中如何帮助保存与 UI 相关的数据？

AndroidManifest.xml 中的 android:configChanges 属性如何影响 Activity 的生命周期行为？

在哪些场景下应使用 onConfigurationChanged() 方法，而不是依赖 Activity 的重建？

实战

为了有效应对这些变化，可以考虑以下策略：

  1. 保存和恢复 UI 状态 ：实现 onSaveInstanceState() 和 onRestoreInstanceState() 方法，以在 Activity 重建期间保存和恢复 UI 状态。这可以确保用户在配置变更后返回到相同的状态。
  2. 使用 ViewModel ：利用 ViewModel 类来存储与 UI 相关的数据，这些数据可以在配置变更时存活。ViewModel 对象的设计目标是跨越 Activity 重建而存在，因此非常适合在这些事件中管理数据。
  3. 手动处理配置变更 ：如果您的应用不需要在特定配置变更时更新资源，并且希望避免 Activity 重启，可以在 AndroidManifest.xml 中使用 android:configChanges 属性声明您的 Activity 所处理的配置变更。然后，重写 onConfigurationChanged() 方法以手动管理这些变更。
  4. 在 Jetpack Compose 中使用 rememberSaveable ：在 Jetpack Compose 中，可以使用 rememberSaveable 来跨配置变更保存 UI 状态。它的工作方式类似于 onSaveInstanceState()，但专为 Compose 设计，有助于保持可组合函数状态的一致性。这块内容后续会讲到。

额外提示

  • 导航与返回栈的保留 ：使用 Navigation 组件可以在配置变更时保留导航返回栈。
  • 避免存储与配置相关的数据 ：尽可能避免在 UI 层直接存储依赖于配置的值。建议使用 ViewModel 等替代方案，它专门设计用于在配置变更期间处理数据。

总结

正确处理配置变更对于提升用户体验至关重要，可以确保用户数据不会因意外情况而丢失。

内存泄漏

Android 通过一种垃圾回收（garbage collection）机制来管理内存，该机制会自动回收未使用的内存，从而确保活跃应用和服务的内存分配高效。它依赖于托管内存环境，这意味着开发者无需像在 C++ 等语言中那样手动分配和释放内存。

Dalvik 或 ART 运行时会监控内存使用情况，清理不再被引用的对象，并防止过度的内存消耗。

当系统内存不足时，Android 会使用一个称为 低内存杀手（low-memory killer） 的机制来终止后台进程，以优先保证前台应用的流畅运行。开发者必须确保自己的应用能够高效地利用资源，以最小化对系统性能的影响。

面试问题

应用程序中内存泄漏的常见原因有哪些？开发者如何预防它们？

Android 的垃圾回收机制是如何工作的？开发者可以使用哪些工具来检测和修复应用中的内存泄漏？

如何避免内存泄漏

内存泄漏发生在应用程序持有对不再需要的对象的引用时，这会阻止垃圾回收器回收内存。常见原因包括：生命周期管理不当、静态引用，或长时间持有对 Context 的引用。

最佳实践

  1. 使用生命周期感知组件 ：利用 ViewModel、Flow 配合 collectAsStateWithLifecycle 或 LiveData 等生命周期感知组件，可确保在相关生命周期结束时资源被正确释放。这些组件会在关联的生命周期不再活跃或进入特定状态时自动管理清理工作。
  2. 避免持有 Context 的引用 ：避免在静态字段或单例等长生命周期对象中保留对 Activity 或 Context 的引用。应尽可能使用 ApplicationContext，因为它不与 Activity 或 Fragment 的生命周期绑定。
  3. 注销监听器和回调 ：始终在适当的生命周期方法中注销监听器、观察者或回调。例如，在 onPause() 或 onStop() 中注销 BroadcastReceiver。
  4. 对非关键对象使用弱引用（WeakReference） ：对于不需要强引用的对象，使用 WeakReference。这允许垃圾回收器在需要内存时回收这些对象。
  5. 使用工具检测内存泄漏 ：使用如 LeakCanary 这类工具在开发过程中识别并修复内存泄漏。该工具能揭示哪些对象导致了内存泄漏以及如何解决。此外，你还可以使用 Android Studio 中的 Memory Profiler 来帮助识别可能导致卡顿、冻结甚至应用崩溃的内存泄漏和内存抖动问题。
  6. 避免对 View 的静态引用 ：不应将 View 存储在静态字段中，因为这会通过持有 Activity 的上下文而导致内存泄漏。
  7. 及时关闭资源：当资源不再需要时，务必显式释放文件流、游标或数据库连接等资源。例如，在数据库查询后应关闭游标。
  8. 合理使用 Fragment 和 Activity ：避免过度使用 Fragment 或在它们之间错误地持有引用。应在 onDestroyView() 或 onDetach() 中清理 Fragment 的引用。

总结

Android 的内存管理机制高效，但要求开发者遵循最佳实践以防止内存泄漏。使用生命周期感知组件、避免对 Context 或 View 的静态引用，并借助如 LeakCanary 等工具，可以显著降低内存泄漏的风险。在适当的生命周期事件中进行资源管理和清理，有助于确保应用性能更流畅、用户体验更佳。

难搞的 ANR

ANR （Application Not Responding，应用无响应）是 Android 中的一种错误，当应用程序的主线程（即 UI 线程）被阻塞超过一定时间（通常为5秒或更长 ）时就会发生。当出现 ANR 时，Android 会提示用户选择关闭应用或等待其响应。ANR 会严重影响用户体验，其常见原因包括：

  • 在主线程上执行耗时超过5秒 的复杂计算（即阻塞主线程5秒）；
  • 执行长时间的网络或数据库操作；
  • 阻塞 UI 操作（例如，在 UI 线程上执行同步操作）。

面试问题

如何检测和诊断 ANR？

如何优化应用性能以改善用户体验？

如何防止 ANR

要防止 ANR，关键在于保持主线程的响应性，通过将耗时或计算密集型任务移出主线程来实现。以下是一些最佳实践：

  1. 将耗时任务移出主线程 ：使用后台线程（如 AsyncTask、Executors 或 Thread）处理文件 I/O、网络请求或数据库操作等任务。对于更现代且安全的方法，建议使用 Kotlin 协程配合 Dispatchers.IO 来高效管理后台任务。
  2. 使用 WorkManager 处理持久性任务 ：对于需要在后台运行的任务（如数据同步），使用 WorkManager。该 API 可确保任务在主线程之外被调度和执行。
  3. 优化数据获取：实现分页机制，以高效处理大型数据集，每次只获取小块可管理的数据，避免 UI 过载并提升性能。
  4. 减少配置变更期间的 UI 操作 ：利用 ViewModel 保存与 UI 相关的数据，避免在屏幕旋转等配置变更时发生不必要的 UI 重新加载。
  5. 使用 Android Studio 进行监控和性能分析 ：借助 Android Studio Profiler 工具监控 CPU、内存和网络使用情况。这些工具有助于识别和解决可能导致 ANR 的性能瓶颈。
  6. 避免阻塞调用：防止在主线程上执行长时间循环、睡眠调用或同步网络请求，以确保应用运行流畅。
  7. 使用 Handler 实现短延迟 ：使用 Handler.postDelayed() 而不是 Thread.sleep() 来引入短暂延迟，从而避免阻塞主线程，保持应用响应性。

总结

ANR 是 Android 中的一种错误，当应用的主线程（UI 线程）被阻塞超过5秒或更长时间 时就会发生，这会降低用户体验并丢失当前用户状态。为防止 ANR ，应通过将耗时工作移至后台线程（如网络请求、数据库查询和复杂计算）来保持主线程轻量。同时，可以优化数据操作，并使用 Android Studio Profiler 对应用进行性能分析。

相关推荐
2501_915918418 小时前
提升 iOS 应用安全审核通过率的一种思路，把容易被拒的点先处理
android·安全·ios·小程序·uni-app·iphone·webview
00后程序员张8 小时前
APP如何快速上架Apple Store：完整上架流程与常见问题解析
android·小程序·https·uni-app·iphone·webview
傻啦嘿哟8 小时前
Appium实现Android应用数据爬取：从环境搭建到实战优化
android·appium
我爱烤冷面8 小时前
kotlin项目实现Java doc的方案：使用Dokka
java·开发语言·kotlin·dokka
jian110588 小时前
android java转kotlin，kotlin转java
android·java·kotlin
俩个逗号。。8 小时前
android 后台应用申请音频焦点失败
android·音视频
summerkissyou19878 小时前
Android-车机高通蓝牙电话-音频收发流程
android·音视频
TheNextByte18 小时前
如何导入和导出Android联系人（4 种可行方法）
android·gitee
晚霞的不甘8 小时前
C语言利用数组处理批量数据详解
android·c语言·开发语言
热门推荐
01GitHub 镜像站点02UV安装并设置国内源03Linux下V2Ray安装配置指南04在VSCode配置Java开发环境的保姆级教程（适配各类AI编程IDE）05Neo4j（一） - Neo4j安装教程（Windows）06【AutoGLM部署】本地私有化部署AI手机Agent07Cursor 又偷偷更新，这个功能太实用：Visual Editor for Cursor Browser08Open-AutoGLM Windows 安装部署教程09安娜的档案(Anna’s Archive) 镜像网站/国内最新可访问入口（持续更新）10BongoCat - 跨平台键盘猫动画工具