導航地圖互動的最佳做法
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
本頁說明在應用程式中與導航地圖互動的最佳做法。
盡可能使用 SupportNavigationFragment，而非 NavigationView
SupportNavigationFragment 是 NavigationView 生命週期回呼的包裝函式，方便您處理這些回呼，不必自行管理。這個方法比較不容易出錯，是應用程式中使用 Navigation 的首選方式。使用 SupportNavigationFragment 時，請務必不要叫用 NavigationView 生命週期事件。
如果使用 NavigationView，請在叫用生命週期方法時嚴格遵守順序
NavigationView 會代管 Navigation 地圖，並密切追蹤 Android 活動和片段的生命週期事件，在叫用這些生命週期事件時採取特定動作。NavigationView 會在 NavigationView#onCreate 和 NavigationView#onStart 上執行多次初始化，並在 NavigationView#onStop 和 NavigationView#onDestroy 上執行清除作業，以及處理其他生命週期事件時執行。
NavigationView 生命週期方法的意義與 Android 活動或片段相同。舉例來說，NavigationView 的 onCreate() 大致會轉譯為 Android 活動或片段的生命週期回呼，並由這些回呼叫用。由於 NavigationView 生命週期回呼是以 Android 生命週期回呼為基礎，且呼叫順序相同，因此必須嚴格遵守這些 NavigationView 方法的順序。否則可能會發生記憶體洩漏、UI 錯誤、位置資訊未更新等問題。
如要進一步瞭解 Android 活動生命週期，請參閱 Android 開發人員說明文件中的「活動生命週期概念」一節。
下表顯示在指定生命週期方法之後，應呼叫其他生命週期方法的時間：
| 生命週期方法 |
在活動生命週期中呼叫的位置 |
在下列生命週期方法後呼叫 |
onConfigurationChanged()
|
當 UI 位於前景且設定變更時，系統會叫用此函式。
|
一律在 onStart() 之後
|
onTrimMemory()
|
活動在背景時會叫用此方法。
|
一律在 onPause() 之後
|
onSaveInstance()
|
在活動遭到刪除前呼叫。
|
一律在 onStop() 之後
|
請勿多次呼叫這些生命週期方法，但未先呼叫對應的關閉方法。此外，請注意，如果部分 Android 生命週期回呼是由應用程式本身管理，且 NavigationView 是在建立或啟動後新增至片段，應用程式應以正確順序自行呼叫特定方法，才能正確初始化 Navigation SDK。
如需使用這些方法的其他指引，請參閱 Navigation SDK 示範應用程式。
如果使用 NavigationView，請從活動或片段 (而非兩者) 叫用生命週期事件
如要維持生命週期方法的嚴格順序，請從活動或片段生命週期回呼中叫用這些事件，這些回呼會依序接收這些事件。這種做法可確保應用程式不必在片段和活動之間協調，也不會導致重複呼叫。
除非另有註明，否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權，程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間：2025-08-31 (世界標準時間)。
[null,null,["上次更新時間：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."]]
