背景

近期因?qū)嶋H項(xiàng)目需要，在特定操作下觸發(fā)定位請(qǐng)求，取到用戶位置及附近位置。

問(wèn)題：

經(jīng)初步選型，最終決定接入百度定位，按照百度定位SDK Android文檔，接入過(guò)程相對(duì)順利。
但隨后發(fā)現(xiàn)，在小米系列等部分機(jī)型上，進(jìn)入app后會(huì)出現(xiàn)"正在嘗試 通過(guò)網(wǎng)絡(luò)或者衛(wèi)星對(duì)您的手機(jī)進(jìn)行定位"。
很影響用戶體驗(yàn)。

解決過(guò)程：

1.Flurry的小坑

項(xiàng)目中引入了數(shù)個(gè)第三方SDK，主要包括Flurry，友盟，個(gè)推，百度定位SDK等。在App啟動(dòng)初始化及進(jìn)入到首頁(yè)的執(zhí)行流中，主要涉及到Flurry，友盟，個(gè)推。

且通過(guò)對(duì)項(xiàng)目中所有引入第三方SDK JAR包中逐一搜索LocationManager,發(fā)現(xiàn)僅有Flurry和百度定位中含有。于是，初步定位到Flurry。去掉Flurry后，發(fā)現(xiàn)在此類機(jī)型上一進(jìn)入app就出現(xiàn)定位請(qǐng)求彈框現(xiàn)場(chǎng)確實(shí)消失。

在Flurry官方文檔上終于找到相應(yīng)的開(kāi)關(guān)接口：FlurryAgent.setReportLocation(boolean);此方法直接決定了Flurry是否上報(bào)用戶地址位置信息，且其默認(rèn)值為true。

于是，在對(duì)Flurry進(jìn)行init后，直接調(diào)用FlurryAgent.setReportLocation(false); 再次測(cè)試，上述必現(xiàn)問(wèn)題解決。

 2.友盟的善良

本以為問(wèn)題至此已經(jīng)結(jié)束，不想在隨后的使用過(guò)程中，在小米系列等機(jī)型上會(huì)不定期出現(xiàn)位置請(qǐng)求彈出框，且經(jīng)過(guò)仔細(xì)核驗(yàn)，此時(shí)也并未觸發(fā)app內(nèi)自身的定位請(qǐng)求，且主要問(wèn)題是：不定期出現(xiàn)，太詭異了！

網(wǎng)上查閱了一些資料，沒(méi)有較好頭緒。不過(guò)上面的Flurry解決過(guò)程給了一些思路，既然Flurry在有定位權(quán)限的情況下默認(rèn)會(huì)獲取地理位置信息，那么其他SDK會(huì)不會(huì)也類似呢？抱著好奇心態(tài)，看了下友盟的class文件，

發(fā)現(xiàn)了其中有一個(gè)方法setAutoLocation(boolean)，哈，這不是跟Flurry如出一轍嘛。但是，發(fā)現(xiàn)一個(gè)奇怪的現(xiàn)象，友盟中setAutoLocation方法已經(jīng)廢棄。

public class MobclickAgent {
  private static final String a = "input map is null";
  private static final d b = new d();

  public MobclickAgent() {
  
  }

  /** @deprecated */
  public static void setAutoLocation(boolean var0) {
  
  }
  
  ...
  
}

已經(jīng)廢棄，且變成了一個(gè)空方法，那會(huì)不會(huì)就是友盟的霸道，在偷偷獲取地理位置信息的時(shí)候甚至不給app提供開(kāi)關(guān)接口呢？

此開(kāi)關(guān)方法已經(jīng)廢棄，必有原因，終于找到了老版的此方法沒(méi)有廢棄的友盟SDK，比較下class文件，發(fā)現(xiàn)老版的友盟SDK中存在LocationManager方法，但新版已經(jīng)沒(méi)有了。且友盟論壇上也有人說(shuō)到了此問(wèn)題，且去掉友盟后，

大量測(cè)試后發(fā)現(xiàn)此問(wèn)題確實(shí)存在，看樣子友盟還是很善良的，直接去掉了獲取用戶定位信息，所以此開(kāi)關(guān)方法當(dāng)然廢棄了。

 3.百度定位的疑惑

百度定位SDK文檔中要求具有定位權(quán)限

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

實(shí)際上，具有ACCESS_FINE_LOCATION權(quán)限也就具有了ACCESS_COARSE_LOCATION權(quán)限。大量測(cè)試結(jié)果表明，當(dāng)手機(jī)上GPS開(kāi)啟時(shí)，定位彈出框出現(xiàn)概率較大，且百度定位是采用混合定位方式，項(xiàng)目中的實(shí)際需求無(wú)需精確定位，

粗略定位已經(jīng)可以滿足需求，那么會(huì)不會(huì)跟權(quán)限有些關(guān)系，于是將ACCESS_FINE_LOCATION改成ACCESS_COARSE_LOCATION，且通過(guò)與其他app反解后橫向?qū)Ρ?，發(fā)現(xiàn)其他使用百度定位的app也只是使用了粗略定位權(quán)限，果斷改之。

改后發(fā)現(xiàn)定位彈框不定期出現(xiàn)概率果然降低。

百度定位配置中還有如下Service配置

<!--百度定位服務(wù)-->
 <service
  android:name="com.baidu.location.f"
   android:enabled="true"
   android:process=":remote" >
 </service>

實(shí)際測(cè)試中，發(fā)現(xiàn)如果權(quán)限是ACCESS_FINE_LOCATION，此處Service配置上加上android:exported="false"也一定程度上使得定位彈框出現(xiàn)概率降低，

此處果斷加上。

<!--百度定位服務(wù)-->
<service
  android:name="com.baidu.location.f"
  android:enabled="true"
  android:exported="false"
  android:process=":remote" >
</service>

4.個(gè)推的坑貨

上述修改后，不定期出現(xiàn)位置請(qǐng)求彈框概率相對(duì)已經(jīng)較小。在長(zhǎng)時(shí)間使用中偶有一次。那這定位請(qǐng)求到底是誰(shuí)觸發(fā)的呢？大量測(cè)試下，發(fā)現(xiàn)當(dāng)修改系統(tǒng)時(shí)間后，此問(wèn)題變成必現(xiàn)。

既然找到了一個(gè)蹊蹺的必現(xiàn)路徑，就好定位了許多。果斷去掉百度定位，友盟及Flurry。但保留定位權(quán)限，此問(wèn)題在上述必現(xiàn)路徑下依然必現(xiàn)。

去掉個(gè)推初始化等相關(guān)，此問(wèn)題在上述必現(xiàn)路徑下果斷消失。發(fā)現(xiàn)就你了，個(gè)推?。?/p>

本以為有些善良的你應(yīng)該和Flurry及老版本的友盟一樣，提供開(kāi)關(guān)接口，但失望了！

聯(lián)系個(gè)推所謂的技術(shù)支持，對(duì)方肯定了個(gè)推在有定位權(quán)限情況先獲取位置信息的同時(shí)，但針對(duì)開(kāi)關(guān)接口問(wèn)題回答瀟灑！

但這確實(shí)影響到了用戶體驗(yàn)?。?/p>

至此，困惑多日的問(wèn)題終于找到原因。以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。