เพิ่มประสิทธิภาพการใช้ตำแหน่งเพื่อยืดอายุการใช้งานแบตเตอรี่
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
ดำเนินการต่อไปนี้เพื่อปรับปรุงผลกระทบของแอปต่ออายุการใช้งานแบตเตอรี่ของอุปกรณ์เมื่อใช้บริการตำแหน่ง
นำการอัปเดตตำแหน่งออก
สาเหตุที่พบบ่อยของการสิ้นเปลืองแบตเตอรี่โดยไม่จำเป็นคือการไม่นำการอัปเดตตำแหน่งออกเมื่อไม่จำเป็นต้องใช้แล้ว
กรณีนี้อาจเกิดขึ้นเมื่อเมธอดวงจรชีวิตของ onStart() หรือ onResume() ของกิจกรรมมีการเรียกใช้ requestlocationUpdates() โดยไม่เรียกใช้ removeLocationUpdates() ที่สอดคล้องกันในเมธอดวงจรชีวิตของ onPause() หรือ onStop()
คุณสามารถใช้คอมโพเนนต์ที่รับรู้วงจรเพื่อจัดการวงจรของกิจกรรมในแอปได้ดียิ่งขึ้น ดูข้อมูลเพิ่มเติมได้ที่การจัดการวงจรด้วยคอมโพเนนต์ที่รับรู้วงจร
ตั้งค่าการหมดเวลา
ตั้งค่าการหมดเวลาที่เหมาะสมเมื่อการอัปเดตตำแหน่งควรหยุดเพื่อไม่ให้แบตเตอรี่หมด การหมดเวลาช่วยให้มั่นใจได้ว่าการอัปเดตจะไม่ดำเนินต่อไปอย่างไม่มีกำหนด และช่วยปกป้องแอปในสถานการณ์ที่ระบบขอการอัปเดตแต่ไม่ได้นําออก (เช่น เนื่องจากข้อบกพร่องในโค้ด)
สําหรับคําขอผู้ให้บริการตําแหน่งแบบรวม ให้เพิ่มการหมดเวลาโดยเรียกใช้ setDurationMillis() ซึ่งจะรับพารามิเตอร์ที่แสดงเวลาเป็นมิลลิวินาทีนับตั้งแต่มีการเรียกใช้เมธอดครั้งล่าสุด นอกจากนี้ คุณยังใช้วิธีนี้เพื่อแสดงเวลาหมดอายุในแง่ของระยะเวลาได้ด้วย
หากต้องการเพิ่มการหมดเวลาลงในคําขอตําแหน่งเขตพื้นที่เสมือน ให้เรียกใช้เมธอด setExpirationDuration()
คำขอแบบเป็นกลุ่ม
สำหรับกรณีการใช้งานที่ไม่ใช่เบื้องหน้าทั้งหมด ให้ส่งคำขอหลายรายการพร้อมกันเป็นกลุ่ม ใช้เมธอด setIntervalMillis() เพื่อระบุช่วงเวลาที่คุณต้องการให้คำนวณตำแหน่ง จากนั้นใช้เมธอด setMaxUpdateDelayMillis() เพื่อกำหนดช่วงเวลาที่ส่งตำแหน่งไปยังแอปของคุณ ส่งค่าไปยังเมธอด setMaxUpdateDelayMillis() ที่เป็นจำนวนที่คูณกับค่าที่ส่งไปยังเมธอด setIntervalMillis() ตัวอย่างเช่น ลองพิจารณาคำขอตำแหน่งต่อไปนี้
Kotlin
val request = LocationRequest.Builder(Priority.PRIORITY_HIGH_ACCURACY, 10 * 60 * 1000)
.setMaxUpdateDelayMillis(60 * 60 * 1000)
.build()
Java
LocationRequest request = new LocationRequest.Builder(Priority.PRIORITY_HIGH_ACCURACY, 10 * 60 * 1000)
.setMaxUpdateDelayMillis(60 * 60 * 1000)
.build();
ในกรณีนี้ ระบบจะคํานวณตําแหน่งทุกๆ 10 นาทีโดยประมาณ และส่งจุดข้อมูลตําแหน่งประมาณ 6 จุดเป็นกลุ่มทุกๆ 1 ชั่วโมงโดยประมาณ แม้ว่าคุณจะยังได้รับการอัปเดตตำแหน่งทุกๆ 10 นาที แต่ก็จะประหยัดแบตเตอรี่ได้เนื่องจากอุปกรณ์จะตื่นขึ้นทุกๆ ชั่วโมงเท่านั้น
ใช้การอัปเดตตำแหน่งแบบไม่ระบุแหล่งที่มา
ใน Use Case เบื้องหลัง เราขอแนะนำให้จำกัดการอัปเดตตำแหน่ง Android 8.0 (API ระดับ 26) จำกัดการใช้งานตามแนวทางนี้ แต่แอปที่ทำงานในอุปกรณ์ที่ต่ำกว่าควรพยายามจำกัดตำแหน่งในเบื้องหลังให้มากที่สุด
เป็นไปได้ว่าขณะที่แอปของคุณทำงานอยู่เบื้องหลัง แอปอื่นอาจขอการอัปเดตตำแหน่งบ่อยครั้งในเบื้องหน้า บริการตำแหน่งทำให้การอัปเดตเหล่านี้พร้อมใช้งานสำหรับแอปของคุณ โปรดพิจารณาคำขอตำแหน่งต่อไปนี้ ซึ่งจะใช้ข้อมูลตำแหน่งเมื่อมีโอกาส
Kotlin
val request = LocationRequest.Builder(Priority.PRIORITY_HIGH_ACCURACY, 15 * 60 * 1000)
.setMinUpdateIntervalMillis(2 * 60 * 1000)
.build()
Java
LocationRequest request = new LocationRequest.Builder(Priority.PRIORITY_HIGH_ACCURACY, 15 * 60 * 1000)
.setMinUpdateIntervalMillis(2 * 60 * 1000)
.build();
ในตัวอย่างที่แล้ว ตำแหน่งของแอปจะคำนวณทุกๆ 15 นาทีโดยประมาณ
หากแอปอื่นๆ ขอตำแหน่ง แอปจะได้รับข้อมูลเป็นช่วงๆ สูงสุด 2 นาที
แม้ว่าการใช้ตำแหน่งแบบพาสซีฟจะไม่ทำให้แบตเตอรี่หมด แต่โปรดระมัดระวังเป็นพิเศษในกรณีที่การรับข้อมูลตำแหน่งทริกเกอร์การดำเนินการ CPU หรือ I/O ที่สิ้นเปลืองพลังงาน ช่วงเวลาที่ระบุใน setMinUpdateIntervalMillis() ไม่ควรสั้นเกินไปเพื่อลดค่าใช้จ่ายของแบตเตอรี่
ตัวอย่างเนื้อหาและโค้ดในหน้าเว็บนี้ขึ้นอยู่กับใบอนุญาตที่อธิบายไว้ในใบอนุญาตการใช้เนื้อหา Java และ OpenJDK เป็นเครื่องหมายการค้าหรือเครื่องหมายการค้าจดทะเบียนของ Oracle และ/หรือบริษัทในเครือ
อัปเดตล่าสุด 2025-07-27 UTC
[[["เข้าใจง่าย","easyToUnderstand","thumb-up"],["แก้ปัญหาของฉันได้","solvedMyProblem","thumb-up"],["อื่นๆ","otherUp","thumb-up"]],[["ไม่มีข้อมูลที่ฉันต้องการ","missingTheInformationINeed","thumb-down"],["ซับซ้อนเกินไป/มีหลายขั้นตอนมากเกินไป","tooComplicatedTooManySteps","thumb-down"],["ล้าสมัย","outOfDate","thumb-down"],["ปัญหาเกี่ยวกับการแปล","translationIssue","thumb-down"],["ตัวอย่าง/ปัญหาเกี่ยวกับโค้ด","samplesCodeIssue","thumb-down"],["อื่นๆ","otherDown","thumb-down"]],["อัปเดตล่าสุด 2025-07-27 UTC"],[],[],null,["# Optimize location use for battery life\n\nTake the following actions to [improve your app's\nimpact on a device's battery life](/develop/sensors-and-location/location/battery) when using location services.\n\nRemove location updates\n-----------------------\n\nA common source of unnecessary battery drain is the failure to remove location\nupdates when they are no longer needed.\n\nThis can happen when an activity's [`onStart()`](/reference/android/app/Activity#onStart()) or [`onResume()`](/reference/android/app/Activity#onResume())\nlifecycle methods contain a call to [`requestlocationUpdates()`](https://developers.google.com/android/reference/com/google/android/gms/location/FusedLocationProviderClient#requestLocationUpdates(com.google.android.gms.location.LocationRequest,%20android.app.PendingIntent)) without a\ncorresponding call to [`removeLocationUpdates()`](https://developers.google.com/android/reference/com/google/android/gms/location/FusedLocationProviderClient.html#removeLocationUpdates(com.google.android.gms.location.LocationCallback)) in the [`onPause()`](/reference/android/app/Activity#onPause()) or\n[`onStop()`](/reference/android/app/Activity#onStop()) lifecycle methods.\n\nYou can use lifecycle-aware components to better manage the lifecycle of the\nactivities in your app. For more information, see [Handling Lifecycles with\nLifecycle-Aware Components](/topic/libraries/architecture/lifecycle).\n\nSet timeouts\n------------\n\nTo guard against battery drain, set a reasonable timeout when location updates\nshould stop. The timeout ensures that updates don't continue indefinitely, and\nit protects the app in scenarios where updates are requested but not removed\n(for example, because of a bug in the code).\n\nFor a fused location provider request, add a timeout by calling\n[`setDurationMillis()`](https://developers.google.com/android/reference/com/google/android/gms/location/LocationRequest.Builder#setDurationMillis(long)), which receives a parameter that represents the\ntime in milliseconds since the method was last called. You can also use the\nmethod to express the expiration time in terms of duration.\n\nTo add a timeout to a geofence location request, call the\n[`setExpirationDuration()`](https://developers.google.com/android/reference/com/google/android/gms/location/Geofence.Builder.html#setExpirationDuration(long)) method.\n\nBatch requests\n--------------\n\nFor all non-foreground use cases, batch multiple requests together. Use the\n[`setIntervalMillis()`](https://developers.google.com/android/reference/com/google/android/gms/location/LocationRequest.Builder#setIntervalMillis(long)) method to specify the interval at which you would like\nlocation to be computed. Then, use the [`setMaxUpdateDelayMillis()`](https://developers.google.com/android/reference/com/google/android/gms/location/LocationRequest.Builder#setMaxUpdateDelayMillis(long)) method to set\nthe interval at which location is *delivered* to your app. Pass a value to the\n`setMaxUpdateDelayMillis()` method that is a multiple of the value passed to the\n`setIntervalMillis()` method. For example, consider the following location request: \n\n### Kotlin\n\n val request = LocationRequest.Builder(Priority.PRIORITY_HIGH_ACCURACY, 10 * 60 * 1000)\n .setMaxUpdateDelayMillis(60 * 60 * 1000)\n .build()\n\n### Java\n\n LocationRequest request = new LocationRequest.Builder(Priority.PRIORITY_HIGH_ACCURACY, 10 * 60 * 1000)\n .setMaxUpdateDelayMillis(60 * 60 * 1000)\n .build();\n\nIn this case, the system computes location roughly every ten minutes and\ndelivers approximately six location data points in a batch approximately every\nhour. While you still get location updates every ten minutes or so, you conserve\nbattery because your device wakes up only every hour or so.\n\nUse passive location updates\n----------------------------\n\nIn background use cases, it is a good idea to throttle location updates. Android\n8.0 (API level 26) limits enforce this practice, but apps running on lower\ndevices should strive to limit background location as much as possible.\n\nIt is likely that while your app is in the background, another app may be\nfrequently requesting location updates in the foreground. Location services\nmakes these updates available to your app. Consider the following location\nrequest, which opportunistically consumes location data: \n\n### Kotlin\n\n val request = LocationRequest.Builder(Priority.PRIORITY_HIGH_ACCURACY, 15 * 60 * 1000)\n .setMinUpdateIntervalMillis(2 * 60 * 1000)\n .build()\n\n### Java\n\n LocationRequest request = new LocationRequest.Builder(Priority.PRIORITY_HIGH_ACCURACY, 15 * 60 * 1000)\n .setMinUpdateIntervalMillis(2 * 60 * 1000)\n .build();\n\nIn the previous example, the app's location computes roughly every 15 minutes.\nIf other apps request location, the app receives the data at a maximum interval\nof two minutes.\n\nWhile consuming location passively incurs no battery drain, take extra care in\ncases where the receipt of location data triggers expensive CPU or I/O\noperations. To minimize battery costs, the interval specified in\n[`setMinUpdateIntervalMillis()`](https://developers.google.com/android/reference/com/google/android/gms/location/LocationRequest.Builder#public-locationrequest.builder-setmaxupdateagemillis-long-maxupdateagemillis(long)) shouldn't be too small."]]
