企业官网建设流程全解析

1. 破题：WebView 里的 H5 定位到底是什么

做混合开发的朋友肯定都体会过这种感觉：H5 页面里调用一句navigator.geolocation.getCurrentPosition()，在 PC 浏览器上一切正常，一放到 Android WebView 里就开始转圈。明明原生定位很正常，权限也申请了，可 H5 就是拿不到坐标。我最初接手这个需求时也天真地以为原生层申请一下定位权限再打开 WebView 就完事了，结果被线上用户反馈追着改了好几版。

WebView 里的 H5 定位机制，本质上不是 WebView 自己定位，而是前端 JS 发起请求，经 WebView 内核转换成系统定位能力，再一步步回传的过程。中间要打通的链路包括：原生权限、WebChromeClient 回调、H5 安全上下文、系统定位源。任何一环断了，用户端表现基本就是定位超时、拒绝或者拿到一个离谱坐标。

这篇文章不打算只贴一段 Demo，而是把链路拆开讲明白：为什么这些配置缺一不可、哪些参数会直接影响定位成功率、真机上到底会遇到什么坑。整个过程适合正在做混合应用定位需求、被 WebView 定位失败问题卡住的人参考，特别是第一次接入定位功能、对 Android 权限体系还不算熟悉的开发者。

1.1 定位链路不是只有 WebView

H5 定位在 WebView 里经过的流程大致是这样：

1. 前端执行navigator.geolocation.getCurrentPosition。
2. WebView 内核收到请求后，先判断页面是不是安全上下文。这里最重要的条件就是页面必须跑在 HTTPS 下。HTTP 页面在现代 WebView 内核里基本不会回调定位结果。
3. 内核检查完安全上下文后，会调用WebChromeClient.onGeolocationPermissionsShowPrompt，把授权决定权交给我们原生层。
4. 原生层决定允许定位后，WebView 内核再向系统 LocationManager 注册定位监听。
5. 系统拿到 GPS/基站/Wi-Fi 的结果后回调给内核，内核再把坐标翻译成 JS 回调，交给前端。

很多人误以为 WebView 自己会去访问 GPS 芯片，其实它只是个“中转站”。WebView 不是定位器，真正的定位能力来自 Android 系统服务。所以排查问题的时候，不要只盯着 WebView 配置，要看整条链路有没有打通。用一个生活化的比喻：前端开了一个“送货单”，WebView 是快递中转站，系统定位服务是配送员，卫星或基站是发货仓库。单子、中转站、配送员、仓库这四个角色缺一个，货就不可能送到用户手上。

1.2 GPS 与网络定位在 H5 侧的区别

本质上，手机定位主要区分两大来源：卫星定位和网络定位。

卫星定位，也就是大家常说的 GPS，依赖硬件和卫星信号，精度高，但冷启动慢。在室内或高楼密集区域，经常长时间拿不到锁。网络定位则靠基站、Wi-Fi 热点来推算位置，速度非常快，精度相对差一些，通常几十米到几百米。WebView 前端并不会直接选择一个定位源，而是通过enableHighAccuracy这个参数向系统提出“精度期望”。系统会根据当前定位服务的开关、可用卫星数量、网络扫描状态，自行决定用哪种 Provider，或者融合多个来源。

我在业务里发现，前端对enableHighAccuracy的直觉往往是错的。产品想要“定位精度高”，于是前端统统传true，但 GPS 冷启动需要时间，用户可能在室内，反而导致长时间不回调。如果你业务只需要确定到区、到一个商圈，用默认精度反而更快。这个决策不能只交给前端，应该由产品业务场景来决定，坐标精度不是越高越好。

1.3 为什么 WebView 定位比原生定位更“娇气”

原生定位失败时，我们至少能通过LocationListener拿到明确的错误回调。WebView 定位失败时，前端看到的往往只有三个东西：PERMISSION_DENIED、POSITION_UNAVAILABLE、TIMEOUT。

问题恰恰出在这。同一个TIMEOUT背后，可能对应完全不同的原因：

• 原生层没申请定位权限。
• Android 12 之后只申请了精确权限却漏了大致权限。
• WebView 没有设置setGeolocationEnabled(true)。
• onGeolocationPermissionsShowPrompt没有覆写，导致授权回调永远没人处理。
• H5 页面是 HTTP，被当作非安全上下文直接拒绝。
• 系统定位服务关闭了，GPS 和网络定位都不可用。
• 手机厂商的省电策略拦截了系统定位服务。
• 用户拒绝后，WebView 内部记忆了拒绝状态，第二次不再弹窗。

原生定位也有相同的问题，但原生代码里每一个环节都是显式的，而 WebView 把它们全都藏在了内核和回调机制里。这也是我写这篇内容的直接原因：把那些“看不见的环节”一个个翻出来。

2. 权限、配置与回调：三个最容易挡路的环节

我见过很多项目，H5 定位失败时，第一反应是去改前端代码，或者在 WebView 里加各种奇怪的注入。其实 90% 的问题出在原生层三个环节：原生权限没给全、WebView 自身开关没开、WebChromeClient回调没处理。

2.1 第一步：原生权限必须给全

先检查 AndroidManifest.xml。一个正常使用 WebView 定位的 App，至少需要这三个权限。

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

INTERNET很容易被忽略。WebView 加载页面需要它，系统网络定位也需要它。如果应用恰好没有申请网络权限，页面能加载吗？不能。所以默认 Android 项目模板里都有，但有时候从某个组件库集合过来的工程，权限清单可能被覆盖，建议确认一遍。

ACCESS_COARSE_LOCATION和ACCESS_FINE_LOCATION缺一不可。即便你的业务只需要网络定位，也建议把 Fine 权限一起加上。原因很简单：很多 ROM 的定位策略是“有精确权限时才愿意返回高质量结果”，只有 Coarse 权限时，WebView 内核的定位成功率会低很多。

另外，Android 6.0 以上还需要运行时动态申请，不能只声明不申请。代码里正常的动态权限请求大概是这个样子。

private static final int REQUEST_LOCATION_PERMISSION = 1001; private void checkLocationPermission() { if (checkSelfPermission(Manifest.permission.ACCESS_FINE_LOCATION) != PackageManager.PERMISSION_GRANTED) { requestPermissions(new String[]{ Manifest.permission.ACCESS_FINE_LOCATION, Manifest.permission.ACCESS_COARSE_LOCATION }, REQUEST_LOCATION_PERMISSION); } else { initWebView(); } }

需要注意：如果你的应用 targetSdk 是 Android 12（API 31）或以上，而你又确实需要精确定位，那么系统强制要求在一次请求中同时包含精确位置和大致位置权限。只申请ACCESS_FINE_LOCATION，系统会忽略并直接拒绝授权。这也是很多新项目在 Android 12 手机上第一次点“允许”却拿不到位置的常见原因。

2.2 第二步：WebView 自身开关不能漏

动态权限拿到手之后，要确认 WebView 配置。我见过有人在原生权限全部通过的情况下，H5 还是拿不到位置，最后发现仅仅是漏了setGeolocationEnabled(true)。

WebSettings webSettings = webView.getSettings(); webSettings.setJavaScriptEnabled(true); webSettings.setGeolocationEnabled(true); // 兼容老版本系统，新版本即使方法标记废弃也没有副作用 webSettings.setGeolocationDatabasePath( getApplicationContext().getDir("geolocation", Context.MODE_PRIVATE).getPath() );

setJavaScriptEnabled(true)是 H5 运行的基础，这个一般不会有人忘。setGeolocationEnabled(true)才是定位相关的关键开关。它代表 WebView 允许页面使用地理位置能力。如果你没有开启，页面调用navigator.geolocation会直接失败，而且不会有太明显的报错。

setGeolocationDatabasePath在 Android 5/6 时代比较重要，是用来存放 WebView 地理位置授权记录的目录。新版本 WebView 基本不再依赖它，但保留设置不会出问题。如果你在编译时看到 deprecated 警告，不用紧张，留着对老设备更友好。

还要注意，setJavaScriptEnabled和setGeolocationEnabled应该写在loadUrl之前。如果页面加载过程中再来设置，也有可能错过 WebView 初始化窗口，导致首次定位请求没生效。

2.3 第三步：onGeolocationPermissionsShowPrompt 必须处理

这是 WebView 定位里最容易踩坑的部分。很多人的 WebChromeClient 里只重写了onProgressChanged和onReceivedTitle，完全没有处理定位授权回调。结果就是 WebView 内核发起定位授权时，没有人响应，前端拿不到任何结果。

标准的处理方式是在WebChromeClient里重写onGeolocationPermissionsShowPrompt。

webView.setWebChromeClient(new WebChromeClient() { @Override public void onGeolocationPermissionsShowPrompt(String origin, GeolocationPermissions.Callback callback) { // 这里可以按业务决定是否放行 boolean allow = origin.startsWith("https://yourdomain.com"); callback.invoke(origin, allow, true); } });

origin是页面的协议加域名，比如https://yourdomain.com。GeolocationPermissions.Callback.invoke有三个参数：第一个是 origin；第二个是是否授权；第三个是是否记住本次授权结果。如果retain传true，WebView 会记录下这次选择，下次同一域名再请求时，不再触发onGeolocationPermissionsShowPrompt，直接沿用上次结果。

如果retain传false，每次定位都会触发回调，用户侧就会频繁感受弹窗或者授权处理。对于绝大多数业务，建议统一retain=true。但前提是，你在代码里有意识地管理授权结果，而不是让用户一直做抉择。

看到这里有人会问：那我是不是应该在这个回调里弹一个原生对话框？说实话，WebView 定位授权只是“允许这个域名使用手机定位能力”的开关，并不是“是否允许 App 使用定位”的系统权限弹窗。系统权限弹窗在原生层由requestPermissions触发，WebView 的这个回调更多是业务层控制。所以如果你没有自定义说明需求，直接在回调里放行即可。

2.4 注意 Android 12 的精确/大致位置权限变化

Android 12 开始，系统权限文案里会出现“精确”和“大致”两个选项。用户如果选择“大致位置”，App 拿到的是模糊位置，这个变化对 WebView 定位影响很大。

如果你的产品必须拿到精确位置，不能只检查有没有ACCESS_FINE_LOCATION。在实际代码里，需要在授权回调里动态判断当前精确权限是否还在。

private boolean hasPreciseLocationPermission() { return checkSelfPermission(Manifest.permission.ACCESS_FINE_LOCATION) == PackageManager.PERMISSION_GRANTED; }

如果用户给了精确位置，就直接放行 WebView 定位。如果只给大致位置，你需要在产品策略里决定：是接受模糊结果，还是引导用户去系统设置里把定位权限改为精确位置。很多地图类 App 的逻辑是，如果用户选择大致位置，进入功能页时再次要求修改为精确位置，并把用户引导到系统设置页。

这里有一个细节：WebView 定位授权回调里，callback.invoke(origin, true, true)只是代表 WebView 层放行，不代表系统位置服务一定能返回精确坐标。最终精度还是取决于你的原生权限有没有拿到 Fine 权限、系统定位服务里的 GPS/Wi-Fi 开关是否打开。权限链上的任何一个 Provider 没有被授权，结果都会降级。

3. 实战：从零搭一套可用的 WebView H5 定位

说完了原理和配置，下面是一套我实际用过的完整落地流程。这个流程的核心思想是：权限在页面加载前到位、WebView 配置在 loadUrl 前完成、H5 侧负责参数和回调、原生侧负责兜底。

3.1 环境准备与代码骨架

一个比较稳妥的 Activity 骨架是这样的：

public class WebViewLocationActivity extends AppCompatActivity { private WebView webView; private static final int REQ_CODE_LOCATION = 1001; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_webview); webView = findViewById(R.id.web_view); if (checkSelfPermission(Manifest.permission.ACCESS_FINE_LOCATION) != PackageManager.PERMISSION_GRANTED) { requestPermissions(new String[]{ Manifest.permission.ACCESS_FINE_LOCATION, Manifest.permission.ACCESS_COARSE_LOCATION }, REQ_CODE_LOCATION); } else { initWebView(); } } @Override public void onRequestPermissionsResult(int requestCode, @NonNull String[] permissions, @NonNull int[] grantResults) { super.onRequestPermissionsResult(requestCode, permissions, grantResults); if (requestCode == REQ_CODE_LOCATION) { boolean granted = grantResults.length > 0 && grantResults[0] == PackageManager.PERMISSION_GRANTED; if (granted) { initWebView(); } else { // 提示用户授权失败，或引导到设置页 } } } private void initWebView() { WebSettings settings = webView.getSettings(); settings.setJavaScriptEnabled(true); settings.setGeolocationEnabled(true); webView.setWebChromeClient(new WebChromeClient() { @Override public void onGeolocationPermissionsShowPrompt(String origin, GeolocationPermissions.Callback callback) { boolean allowed = checkSelfPermission( Manifest.permission.ACCESS_FINE_LOCATION) == PackageManager.PERMISSION_GRANTED; callback.invoke(origin, allowed, true); } @Override public void onGeolocationPermissionsHidePrompt() { // 可选，用于收起自定义 loading } }); webView.loadUrl("https://yourdomain.com/location.html"); } }

注意，requestPermissions是异步的，结果回调之前不要急着loadUrl。如果页面先加载，H5 可能已经执行了定位请求，但 WebView 权限还处在中间状态，很容易出现首屏定位失败。最稳妥的做法是用户确认授权后，再让 WebView 加载定位页面。

这里也回答一个常见疑问：为什么不能在onGeolocationPermissionsShowPrompt里直接调requestPermissions？理论上可以，但逻辑会很乱。因为requestPermissions是 Activity 级别的，而onGeolocationPermissionsShowPrompt来自 WebView 内部线程，你还需要把授权结果回传到 callback 里，时机很容易出现错位。与其在回调里处理嵌套，不如把原生权限请求提前到页面加载之前。

3.2 前端 H5 侧的定位调用与参数

前端部分的代码不算复杂，难点在参数。一个常见的调用方式如下：

function requestLocation() { if (!navigator.geolocation) { // 可触发原生兜底逻辑 console.error('当前浏览器不支持定位'); return; } navigator.geolocation.getCurrentPosition( function (position) { const coords = position.coords; console.log('latitude:', coords.latitude); console.log('longitude:', coords.longitude); console.log('accuracy:', coords.accuracy); }, function (error) { console.error('code:', error.code, 'message:', error.message); }, { enableHighAccuracy: true, timeout: 15000, maximumAge: 0 } ); }

enableHighAccuracy刚才讲过，要根据业务精度需求来。timeout表示允许定位请求等待的最长时间。GPS 冷启动经常超过 5 秒，如果把timeout设成 3000，几乎等于直接放弃。我常用 10000~15000 毫秒。maximumAge表示允许使用多久之前的缓存位置。为追求最新坐标，可以设 0；如果业务可以接受“最近 30 秒内”的位置，设 30000 会更稳定也更快。

getCurrentPosition的失败回调里，error.code是一个数字，1 表示用户拒绝授权，2 表示无法获取当前位置，3 表示超时。做排查时，三个错误码对应的处理策略并不一样，后面会展开说。

顺带提一句 HTTPS 问题：Android WebView 只有在页面是安全上下文时才会完整支持navigator.geolocation。所谓安全上下文，简单说就是页面必须是https://。如果是http://或者直接用file://打开本地 HTML，很多新版 WebView 内核根本不会成功回调。开发调试时用file://会经常踩坑，建议先部署到 HTTPS 测试环境再联调。

3.3 原生兜底方案：定位失败后把坐标注入页面

即使前面都配置到位，线上还是会有各种意外，比如系统定位服务关闭、GPS 长时间无法锁定、WebView 内核异常。这时候如果前端能退到“原生兜底”逻辑，体验会好很多。

思路是：前端定义好一个全局回调函数，当navigator.geolocation失败时，调用这个函数告诉原生“我需要你帮我定位”。原生拿到系统最后一次有效位置后，再通过evaluateJavascript注入回页面。

前端的约定如下：

window.__nativeLocationCallback = function (latitude, longitude, accuracy) { console.log('native fallback location:', latitude, longitude, accuracy); }; function requestLocation() { navigator.geolocation.getCurrentPosition( function (position) { // 正常定位成功 }, function (error) { // 通知原生层启动兜底定位 if (window.AndroidLocationBridge) { window.AndroidLocationBridge.requestNativeLocation(); } }, { enableHighAccuracy: false, timeout: 12000, maximumAge: 0 } ); }

原生侧在onGeolocationPermissionsShowPrompt允许之后，再注册一个 JavaScriptInterface，用来接收前端的兜底请求。

webView.addJavascriptInterface(new Object() { @JavascriptInterface public void requestNativeLocation() { LocationManager locationManager = (LocationManager) getSystemService(Context.LOCATION_SERVICE); Location bestLocation = null; for (String provider : locationManager.getProviders(true)) { Location location = locationManager.getLastKnownLocation(provider); if (location != null) { if (bestLocation == null || location.getAccuracy() < bestLocation.getAccuracy()) { bestLocation = location; } } } if (bestLocation != null) { injectLocation(bestLocation); } } }, "AndroidLocationBridge");

注入代码：

private void injectLocation(Location location) { String js = String.format( "window.__nativeNativeLocationCallback && window.__nativeNativeLocationCallback(%f, %f, %f);", location.getLatitude(), location.getLongitude(), location.getAccuracy()); webView.post(new Runnable() { @Override public void run() { webView.evaluateJavascript(js, null); } }); }

这个兜底方案不能滥用。getLastKnownLocation有可能是 10 分钟前的旧位置，所以注入时最好把location.getTime()一起带过去，让前端自己判断是否过期。兜底的价值是“用户至少能拿到一个位置，不用因为定位失败全程卡壳”，而不是保证精度。

3.4 体验细节：权限时机与页面加载顺序

这个细节容易被忽视：到底先请求原生权限，还是先加载 WebView？

我的经验是：如果页面核心功能依赖定位，就先申请权限再加载页面。用户一进页面就看到完整内容，然后定位转圈，比看到一个空页面再等待授权要舒服得多。

还要处理好用户拒绝权限后的状态。拒绝一次之后，第二次再调用requestPermissions不会重新弹系统弹窗。这时候要提供一个“去设置开启权限”的引导按钮，跳转到 App 详情页，让用户手动打开定位权限后再回到 WebView 重新触发定位。

Intent intent = new Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS, Uri.parse("package:" + getPackageName())); startActivity(intent);

跳转设置页后，用户返回 App，需要在 Activity 的onResume里重新检查权限状态，并刷新 WebView 页面，否则 H5 里的失败状态不会自动恢复。

4. 常见问题与排查技巧实录

这一节整理了我实际遇到的、以及社区里高频出现的定位问题。每一条背后几乎都有一个真实的线上工单。

4.1 getCurrentPosition 一直不回调

症状：H5 调用了getCurrentPosition，既没走成功回调，也没走失败回调，转了十几秒后没有任何动静。

排查顺序：

1. 确认页面是 HTTPS。
2. 在原生onGeolocationPermissionsShowPrompt里加日志，看是否被触发。
3. 如果没触发，检查 WebView 是否设置了setGeolocationEnabled(true)，以及原生权限是否授权。
4. 如果触发了，但前端还是没回调，检查系统定位服务是否开启。尤其是 GPS 开关和“Wi-Fi 扫描”开关。GPS 关闭时，H5 的enableHighAccuracy=true会一直等待卫星锁，特别容易超时。
5. 用真机测试，不要依赖模拟器。模拟器经常没有真实 GPS 信号，网络定位环境也不完整，会出现“代码完全没问题，但就是不回调”的假象。

我做过一个快速定位的小技巧：在onGeolocationPermissionsShowPrompt里打日志，然后主动在前端触发定位。如果日志出现代表 WebView 授权链路没问题，问题基本在系统定位源；如果日志没出现，说明原生权限、WebView 开关或者页面安全上下文有问题。这一步能把排查范围缩小一大半。

4.2 拿到的经纬度在地图上偏移

症状：通过 WebView 拿到了经纬度，但在地图上展示时，点跑偏了几百米甚至几公里。

大部分情况不是定位不准，而是坐标系不一致。H5 标准定位返回的坐标体系通常是国际通用的 WGS-84。而国内很多地图 SDK 默认使用 GCJ-02（国测局坐标）。直接把 WGS-84 坐标放到 GCJ-02 地图上，偏移量就会很大。

解决思路：把坐标交给地图 SDK 自己处理，或者在前后端做一次符合地图要求的坐标系转换。最忌讳的是“随手写一个偏移公式”，因为不同地区偏移量非线性，路边这种经验公式很容易在部分城市变成灾难。正确做法是优先使用地图 SDK 自带的坐标转换能力。

还有一种可能：如果用户只给了“大致位置”权限，系统返回的accuracy会很大，可能几百米甚至上千米，这也会让人感觉是“偏移”。要区分清楚是坐标体系问题还是权限精度问题。判断方式是看返回值里的accuracy字段：如果 accuracy 只有几十米但地图偏了几百米，那就是坐标系问题；如果 accuracy 本身就有几百米，那是权限降级或网络定位精度上限问题。

4.3 权限弹窗只出现一次，拒绝后无法再次触发

症状：第一次进入页面时，WebView 的定位授权流程被触发，但用户拒绝了。之后无论怎么重新加载页面，都不再出现授权提示，定位永远返回PERMISSION_DENIED。

这是因为 WebView 按 origin 存储了授权结果，而且存的是“拒绝”状态。如果我们在callback.invoke(origin, false, true)时把 retain 设成了 true，就等于告诉 WebView“记住这个拒绝决定”。以后同一域名的页面再次请求定位，WebView 会直接沿用拒绝结果，不再询问。

解决办法是清除 WebView 对该 origin 的授权记录。

GeolocationPermissions.getInstance().clear(origin); // 或者更暴力一点，清掉所有记录 GeolocationPermissions.getInstance().clearAll();

清除之后，重新加载 WebView 页面，onGeolocationPermissionsShowPrompt就会再次触发。

这里要反过来提醒：如果你的产品不希望用户拒绝一次后永远无法恢复，可以考虑在onGeolocationPermissionsShowPrompt里统一用retain=false，每次都经过你的授权策略。但这意味着用户每次都要经历一次判断，交互成本会高。折中方案是：第一次总是弹业务说明弹窗，再由代码决定是否放行并 retain。这样既可控，体验也不突兀。

4.4 部分机型定位失败，原生却正常

症状：同一套 WebView 代码，在 A 机型正常，在 B 机型上定位失败，但 B 机型上用原生定位 Demo 却能拿到坐标。

这种“一半正常一半失败”的情况，首先怀疑两个方向。

方向一：不同 ROM 对“网络定位”的支持方式不一样。很多国内 ROM 把“Wi-Fi 扫描”和“蓝牙扫描”单独做成开关，如果用户关闭了 Wi-Fi 扫描，系统网络定位精度就会严重下降，甚至直接定位失败。在系统设置里打开“Wi-Fi 扫描”后，问题往往会消失。

方向二：省电策略或者后台进程限制。个别手机厂商的省电模式会杀掉 WebView 的子进程，或者限制系统定位服务在应用后台运行。如果用户在定位还没完成时切到后台，再回到 App，进程可能已经被回收了。这种情况下 H5 拿不到任何回调，原生 Demo 因为是前台操作，所以表现正常。

还有一个隐蔽的原因：WebChromeClient 被覆盖。如果工程里为了处理文件选择、视频播放等问题，自己封装了一个 WebChromeClient，而新的封装没有覆写onGeolocationPermissionsShowPrompt，那之前配置的授权逻辑就全部失效了。我排查过好几个“新版本定位突然挂了”的 case，最终都定位到开发者在改版时换了一个基类 WebChromeClient，导致方法被吃掉了。

5. 最佳实践与性能调优

定位功能不止是“能拿到坐标”，还要考虑速度、功耗、权限合规、可维护性。下面这些经验是我在几个线上项目里慢慢沉淀下来的。

5.1 定位策略：getCurrentPosition 还是 watchPosition

如果页面只是进入时取一次位置，用getCurrentPosition就够了。如果用watchPosition持续监听，一定要在页面退出或者活动结束时调用clearWatch，否则 WebView 会一直持有定位监听，非常耗电。

let watchId = null; function startWatchPosition() { watchId = navigator.geolocation.watchPosition( successCallback, errorCallback, { enableHighAccuracy: false, timeout: 15000, maximumAge: 5000 } ); } function stopWatchPosition() { if (watchId !== null) { navigator.geolocation.clearWatch(watchId); watchId = null; } }

我建议业务上优先使用“一次性定位 + 手动刷新”模型。比如用户点击“重新定位”按钮才重新调用getCurrentPosition。只有需要持续展示当前位置的页面，比如地图上的实时轨迹、跑步记录，才考虑watchPosition。

5.2 缓存复用：maximumAge、lastKnownLocation 怎么搭配

定位不是每次都必须请求新位置。对于很多场景，比如“获取当前位置所在城市”“推荐附近的店铺”，30 秒前的位置完全够用。前端设置maximumAge: 30000，可以让系统直接复用近 30 秒内的缓存。

原生兜底时也一样。getLastKnownLocation返回的位置可能很旧，所以在注入前要判断新鲜度。

private boolean isFresh(Location location, long maxAgeMillis) { return location != null && System.currentTimeMillis() - location.getTime() <= maxAgeMillis; }

实践中，如果业务只是要城市级别，兜底缓存允许 5 分钟内；如果要精确到门店附近，兜底缓存尽量控制在 1 分钟内，超过阈值就提示用户打开定位服务再重试。

5.3 统一封装：在混合容器里收敛定位逻辑

如果你的 App 里有大量以 WebView 承载的页面，每个 Activity 都复制粘贴一份 WebChromeClient 逻辑，后续维护一定是灾难。更好的做法是抽取一个公共的LocationAwareWebChromeClient。

public abstract class LocationAwareWebChromeClient extends WebChromeClient { protected abstract boolean isLocationAllowed(String origin); @Override public void onGeolocationPermissionsShowPrompt(String origin, GeolocationPermissions.Callback callback) { callback.invoke(origin, isLocationAllowed(origin), true); } }

这样，所有业务 Activity 只需要关心isLocationAllowed的返回值，权限申请、WebView 开关、兜底逻辑全部收口到一个原生模块里。长期来看，这比每个页面各自为战要稳得多。

如果团队用的是某跨端容器或混合开发框架，也建议把定位能力封装成原生桥接模块，而不是让前端每个页面各自去处理权限。因为权限管理是原生能力，前端处理不得要领时，很容易出现行为不一致。

5.4 隐私合规与权限引导

位置信息属于敏感个人信息。在功能上，定位应遵循“最小必要”原则：能不用精确定位就不用，能只在用户触发时定位就不要进页面就定位，更不能在后台持续收集。

实际落地时，我建议做到三点：

1. 进入定位功能前，先用业务弹窗说明“为什么需要位置”，再触发系统权限弹窗，提升用户同意率。
2. 不申请ACCESS_BACKGROUND_LOCATION后台定位权限。WebView 定位只需要前台位置，申请后台权限会让应用合规风险变高，而且用户也不信任。
3. 处理坐标为具体地址时，如果使用地图 SDK 的逆地理编码，统一由原生侧或服务端承接，不要让前端频繁请求，容易触发频率限制，也容易产生不必要的经纬度日志收集。

还有一个容易被忽略的点：H5 页面在请求定位时，前端代码本身也可能被第三方 SDK 采集。所以如果你的业务对用户隐私特别敏感，尽量让前端只拿“脱敏后的位置级别”，而不是把完整的坐标暴露给页面里不可控的第三方逻辑。

6. 写在最后：一点个人体会

真机适配没有捷径。我在交付最后一个版本前，拿了几台不同配置的真机，把定位开关、Wi-Fi 扫描、权限状态各种组合都过了一遍，才敢说基本稳定。最让我意外的不是代码写错，而是某些 ROM 的默认省电策略会直接限制 WebView 后台定位，让原本正常的页面在用户切到设置页再回来时无法恢复。所以我后来都在onResume里重新检查一次权限，并主动刷新定位数据，而不是冷冰冰地等待 H5 内部逻辑自我修复。

另一条体会是：WebView 定位这个功能，表面上是前端一行 API，实际上拼的是对整个 Android 权限体系和系统定位服务的理解。不要觉得“反正最后都能拿到坐标”就忽略链路细节。等到线上用户反馈定位失败、需要真机远程日志排查的时候，你会感谢当初多写的每一个日志和多做的每一层兜底。希望这篇整理能帮你少踩几个坑，也欢迎在实际项目里用这些方法跑通后，再回头验证一下哪些环节最容易踩雷。