导航地图互动最佳实践
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
本页介绍了在应用中与导航地图互动的最佳实践。
尽可能使用 SupportNavigationFragment 而不是 NavigationView
SupportNavigationFragment 是一个封装容器，可方便地处理 NavigationView 生命周期回调，因此您无需自行管理这些回调。此方法不易出错，是应用中使用 Navigation 的首选方式。使用 SupportNavigationFragment 时，请务必不要调用 NavigationView 生命周期事件。
如果使用 NavigationView，请在调用生命周期方法时严格遵循顺序
NavigationView 托管导航地图，并密切关注 Android activity 和 fragment 的生命周期事件，在这些生命周期事件被调用时采取特定操作。NavigationView 在 NavigationView#onCreate 和 NavigationView#onStart 上执行多次初始化，在 NavigationView#onStop 和 NavigationView#onDestroy 上执行清理，以及在处理其他生命周期事件时执行清理。
NavigationView 生命周期方法的含义与 Android activity 或 fragment 的相同。例如，NavigationView 的 onCreate() 大致相当于 Android activity 或 fragment 的生命周期回调，并且应由这些回调来调用。由于 NavigationView 生命周期回调基于 Android 生命周期回调，并且以相同的顺序调用，因此必须严格按照顺序调用这些 NavigationView 方法。否则，您可能会遇到内存泄漏、界面错误、位置信息未更新等问题。
如需详细了解 Android activity 生命周期，请参阅 Android 开发者文档中的activity 生命周期概念部分。
下表显示了在指定生命周期方法之后，应何时调用其他生命周期方法：
| 生命周期方法 |
在 activity 生命周期的哪个阶段调用 |
在哪个生命周期方法之后调用 |
onConfigurationChanged()
|
当界面位于前台且配置发生更改时调用。
|
始终在 onStart() 之后
|
onTrimMemory()
|
当 activity 处于后台时调用。
|
始终在 onPause() 之后
|
onSaveInstance()
|
在销毁 activity 之前调用。
|
始终在 onStop()之后
|
请勿在未先调用相应关闭方法的情况下多次调用这些生命周期方法。此外，请注意，如果这些 Android 生命周期回调中的某些回调由应用本身管理，并且在创建或启动后将 NavigationView 添加到 fragment，则应用应按正确的顺序自行调用特定方法，以便正确初始化 Navigation SDK。
如需有关如何使用这些方法的更多指导，请参阅 Navigation SDK 演示应用。
如果使用 NavigationView，请从 activity 或 fragment（而非两者）调用生命周期事件
为了保持生命周期方法的严格顺序，请从 activity 或 fragment 生命周期回调中调用这些事件，这些回调会按顺序接收这些事件。这种方法可确保应用无需在 fragment 和 activity 之间进行协调，也不会导致重复调用。
如未另行说明，那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可，并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情，请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC)：2025-08-31。
[null,null,["最后更新时间 (UTC)：2025-08-31。"],[[["\u003cp\u003ePrioritize using \u003ccode\u003eSupportNavigationFragment\u003c/code\u003e over \u003ccode\u003eNavigationView\u003c/code\u003e for simplified lifecycle management and error reduction.\u003c/p\u003e\n"],["\u003cp\u003eWhen using \u003ccode\u003eNavigationView\u003c/code\u003e directly, ensure strict adherence to the Android lifecycle order when invoking its lifecycle methods to prevent issues like memory leaks and UI errors.\u003c/p\u003e\n"],["\u003cp\u003eInvoke \u003ccode\u003eNavigationView\u003c/code\u003e lifecycle events exclusively from either the activity or the fragment to maintain order and avoid duplicate calls.\u003c/p\u003e\n"]]],[],null,["# Navigation map interaction best practices\n\nThis page explains best practices for interacting with the Navigation map in\nyour app.\n\nUse `SupportNavigationFragment` instead of `NavigationView`, whenever possible\n------------------------------------------------------------------------------\n\n`SupportNavigationFragment` is a wrapper for the convenience of handling the\n`NavigationView` lifecycle callbacks, so you don't need to manage these\ncallbacks themselves. This method is less error-prone and the preferred way to\nuse Navigation in your app. When using `SupportNavigationFragment`, be sure not\nto invoke `NavigationView` lifecycle events.\n\nIf using `NavigationView`, use strict ordering when invoking lifecycle methods\n------------------------------------------------------------------------------\n\n`NavigationView` hosts the Navigation map and closely follows the lifecycle\nevents as Android activities and fragments, taking specific actions when these\nlifecycle events are invoked. `NavigationView` executes multiple initializations\non `NavigationView#onCreate` and `NavigationView#onStart`, and cleanups on\n`NavigationView#onStop` and `NavigationView#onDestroy`, as well as when other\nlifecycle events are processed.\n\n`NavigationView` lifecycle methods have the same meaning as they do for Android\nactivities or fragments. For example, `onCreate()` of `NavigationView` roughly\ntranslates to and should be invoked by lifecycle callbacks from the Android\nactivity or fragment. Since the `NavigationView` lifecycle callbacks are based\non and invoked in the same order as the Android lifecycle callbacks, strong\nordering of these NavigationView methods is required. Otherwise, you may\nexperience [memory\nleaks](/maps/documentation/navigation/android-sdk/memory-best-practices), UI\nerrors, location not being updated, and other issues.\n\nFor more information about the Android activity lifecycle, see the\n[Activity-lifecycle concepts](https://developer.android.com/guide/components/activities/activity-lifecycle#alc)\nsection in the Android developer documentation.\n\nThe following table shows when other lifecycle methods should be invoked, after\nspecified lifecycle methods:\n\n| Lifecycle method | Invoked where in the activity lifecycle | Invoked after which lifecycle method |\n|----------------------------|-------------------------------------------------------------------------|--------------------------------------|\n| `onConfigurationChanged()` | Invoked when the UI is in the foreground and the configuration changes. | Always after `onStart()` |\n| `onTrimMemory()` | Invoked when an activity is in the background. | Always after `onPause()` |\n| `onSaveInstance()` | Invoked before an activity is destroyed. | Always after` onStop()` |\n\nDon't call these lifecycle methods multiple times without calling the\ncorresponding closing method first. In addition, keep in mind that if some of\nthese Android lifecycle callbacks are managed by the app itself, and the\n`NavigationView` is added to the fragment after creation or start, the app\nshould call the specific methods themselves in proper order in order to\ncorrectly initialize the Navigation SDK.\n\nFor additional guidance on using these methods, see the [Navigation SDK demo\napp](https://github.com/googlemaps-samples/android-navigation-samples/blob/4afba69715ebf6c176a2eb438f86d06c23065e7f/navigation-sample/app/src/main/java/com/example/navigationapidemo/NavViewActivity.kt#L279).\n\nIf using `NavigationView`, invoke lifecycle events from the activity or fragment, not both\n------------------------------------------------------------------------------------------\n\nTo keep the strict ordering of the lifecycle methods, invoke these events from\neither the activity or fragment lifecycle callbacks, which receive these events\nin order. This approach ensures that apps don't need to coordinate between\nfragments and activities and cause duplicate calls."]]
