FusedLocationProviderClient getLastLocation经过了RealtimeNanos主要是当前系统时间 [英] FusedLocationProviderClient getLastLocation elapsedRealtimeNanos mostly current system time

问题描述

我在Google I/O '18上与Google工程师进行了交谈.他告诉我，我可以信任融合的位置提供者.如果他用新的时间戳标记了最后一个已知的位置，则用户可能仍在同一位置.

I had a talk with a google engineer on Google I/O '18. He told me that I can trust the fusedLocationProvider. If he marks the last known location with a new timestamp the user is probably still at the same location.

我希望将来使用移动中的"设备进行一些测试，以证明这一说法.

I'd like to do a few tests with a "moving" device in the future to prove this statement.

我要通过getLastLocation()从FusedLocationProviderClient请求最后一个已知的位置，并想检查最后一个已知的位置是否早于5分钟以开始新的位置请求.

I'm requesting the last known location from the FusedLocationProviderClient with getLastLocation() and want to check if the last known location is older than 5 minutes to start a new location request instead.

在测试过程中，我发现位置elapsedRealtimeNanos发生奇怪的行为，该位置应用于

During my testing i discovered a weird behavior with the locations elapsedRealtimeNanos which should be used to compare.

出于测试目的，我每秒请求一个简单的Java线程中的最后一个已知位置.收到位置后，我检查elapsedRealtimeNanos并将它们与SystemClock.elapsedRealtimeNanos()进行比较.在大多数情况下，最后一个已知位置的年龄也设置为SystemClock.elapsedRealtimeNanos()，因此差值几乎为0.这意味着FusedLocationProvider告诉我，最后一个已知位置的修复程序已在进行中，因此可以进行年龄检查不可靠.

For testing purpose I'm requesting the last known location every second in a simple Java Thread. When the location is received I check the elapsedRealtimeNanos and compare them to SystemClock.elapsedRealtimeNanos(). In most cases the age of the last known location is set to SystemClock.elapsedRealtimeNanos() as well, so the difference is nearly 0. Which means, that the FusedLocationProvider tells me that the fix of the last known location was right now, which makes age checks not reliable.

这种行为很奇怪，但是越来越严重了.

This behavior is weird enough but its getting worse.

当我在测试会话中启动并行位置请求或启动Google Maps时，最后一个已知位置的elapsedRealtimeNanos停止增长，并且仅在找到真实"新位置时才更新为新的时间.这应该是我期望的默认行为.

When I start a parallel location Request during my testing sessions or launch Google Maps, the elapsedRealtimeNanos of the last known location stops growing and is only updated to a newer time when a "real" new location was found. Which should be the default behavior that I would expect.

我在HIGH_ACCURACY和SENSORS_ONLY等不同的位置设置期间观察到了这种行为.

I observed this behavior during different Location Settings like HIGH_ACCURACY and SENSORS_ONLY.

这是否意味着不可能检查最后一个已知位置的年龄?谁能解释这种行为?

Does this mean, that checking the age of the last known location is impossible? Can anyone explain the behavior?

与location.getTime()

代码段:

 @Override void getLastKnownLocation() {
    try {
        mLocationClient.getLastLocation().addOnCompleteListener(new OnCompleteListener<Location>() {
            @Override
            public void onComplete(@NonNull Task<Location> task) {
                try {
                    Location location = task.getResult();
                    if (location != null) {
                        location.getElapsedRealtimeNanos()
                        //Compare to SystemClock.elapsedRealtimeNanos();
            ...

而且(我知道它很乱)

      new Thread(){
        @Override public void run() {
            locationFinder.getLastKnownLocation();
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            run();
        }
    }.start();

位置更新请求

public PlayServicesLocationFinder(Context context){
    mLocationClient = LocationServices.getFusedLocationProviderClient(context);
}

@Override
public void getLocationUpdates() {

    LocationRequest locationRequest = LocationRequest.create();
    locationRequest.setInterval(60000); 
    locationRequest.setFastestInterval(15000);
    locationRequest.setPriority(LocationRequest.PRIORITY_HIGH_ACCURACY);

    mLocationClient.requestLocationUpdates(locationRequest, continuousUpdatesLocationListener, null);
}

推荐答案

也许我可以建议您尝试其他方法来获得新鲜"坐标，这似乎是代码的主要目标. 也许您可以尝试:

Maybe I can recommend you to try other way to get a "fresh" coordinate, which seems to be your main goal with your code. Maybe you can try:

• 首先获取 LastKnownLocation .
• 一旦您有了LastKnownLocation.您可以开始 requestLocationUpdates()，一旦有了与lastKnownLocation不同的新坐标，则该坐标就是您的新"坐标.您甚至可以实施精度控制，以获取更准确，更新鲜"的坐标.

• First get the LastKnownLocation.
• Once you have the LastKnownLocation. You can began to requestLocationUpdates() and once you have a new coordinate that is DIFFERENT from lastKnownLocation, then that one is your "fresh" coordinate. You can even implement accuracy controls in order to get "accurate and freshier" coordinates.

我使用了以前的方案，它在不验证位置GPS时间(getTime())的情况下可以完美地获取当前位置.

I´ve used the previous scheme and it works perfect in order to get the current position without validating Location GPS time (getTime()).

注意::我知道这对电池不友好，但是您可以在LocationRequest中控制更新次数，间隔时间，最大等待时间，以将电池消耗保持在最低.

NOTE: I´m aware that this is not battery friendly, but you can control the number of updates, interval time, max wait time in the LocationRequest in order to keep the battery consumption to the minimum.

这篇关于FusedLocationProviderClient getLastLocation经过了RealtimeNanos主要是当前系统时间的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！