2. 程式人生 > >Android機型適配之痛

Android機型適配之痛

阿新 • • 發佈：2019-01-07

CSDN移動將持續為您優選移動開發的精華內容，共同探討移動開發的技術熱點話題，涵蓋移動應用、開發工具、移動遊戲及引擎、智慧硬體、物聯網等方方面面。如果您想投稿、參與內容翻譯工作，或尋求近匠報道，請傳送郵件至tangxy#csdn.net（請把#改成@）。 

Android平臺的誕生為手機智慧化的普及立下汗馬功勞，但其最大的缺點也越來越凸顯，那就是碎片化嚴重：裝置繁多、品牌眾多、版本各異，晶片、攝像頭、解析度不統一等等，這些都逐漸成為Android系統發展的障礙，碎片化嚴重不僅造成Android系統混亂，也導致Android應用隱形開發成本的增多。本文中詳細介紹了Android琳琅滿目的適配問題。

一、個性化十足的Launcher

快捷方式雖然看起來只是一個很小的功能點，但是它涉及到的機型適配問題很多。

快捷方式建立程式碼：

  1. ntent addShortCut = new Intent("com.android.launcher.action.INSTALL_SHORTCUT");  
  2. addShortCut.putExtra(Intent.EXTRA_SHORTCUT_NAME, title)；  
  3. // 不允許重複建立
  4. addShortCut.putExtra("duplicate", false);  
  5. addShortCut.putExtra(Intent.EXTRA_SHORTCUT_ICON_RESOURCE, icon);  
  6. addShortCut.putExtra(Intent.EXTRA_SHORTCUT_INTENT, intent);  
  7. sendBroadcast(addShortCut);  

1. 無法建立快捷方式

越來越多的手機廠商取消了快捷方式的概念，導致我們無法通過程式碼建立一個自己真實需要的快捷方式，資料顯示，這樣的手機約佔13%。

 

2. 重複建立快捷方式

通常情況下，我們是不希望自己的快捷方式被重複建立。使用addShortCut.putExtra("duplicate", false);方法就能達到目的， 但是市面上至少有8%的手機，即使設定了duplicate為false，還是可以重複建立快捷方式。

代表手機品牌為：華為、中興、HTC。

Android Launcher原始碼：

 

2.1 重複建立快捷方式的解決方案V1.X

我們最早使用的解決快捷方式重複建立的方法是：在建立快捷方式前先執行刪除操作。這種方式其實很聰明，因為即使是在快捷方式不存在的情況下執行刪除操作也不會有任何異常。這樣看來問題解決得太輕鬆了，但是遺憾的是刪除快捷方式同樣存在適配問題，資料顯示大約21%的手機無法正常刪除快捷方式。

另外一種方法是：自行儲存快捷方式的建立記錄，通過一個欄位來記錄快捷方式是否已經建立過了，以此來決定是否建立新的快捷方式。這種做法也是因為出現快捷方式無法刪除情況後對解決方案進行了一個小的升級，雖然可以解決問題，但是如果程式被清除了資料，那麼一切都亂了，還是無法徹底的規避重複的問題。

2.2 重複建立快捷方式的解決方案V2.X

遇到難解的問題還是看看原始碼吧，Android的Launcher原始碼在建立快捷方式的時候不僅會判斷duplicate的值，還會在資料庫中查詢一下將要被建立的快捷方式是否已經存在，我們也照做就OK了。

 

此外，我們也注意到，查詢資料庫的時候訪問地址URI是一個很重要的因素，問題是資料庫的URI比較多，Android標準的URI就有3個：

  • 2.2版本以前的URI是：content://com.android.launcher.settings/favorites?notify=true
  • 2.2~4.3版本的URI是：content://com.android.launcher2.settings/favorites?notify=true
  • 4.4版本以上的目前都是：content://com.android.launcher3.settings/favorites？notify=true

不僅僅Android自己的Launcher資料庫地址眾多，廠商自己定義的地址就更加豐富多彩，如OPPO R827T的訪問URI為：content://com.oppo.launcher.settings /favorites?notify=true；HTC Z715e的訪問地址為： content://com.htc.launcher.settings/favorites?notify=true。事實上 遠遠不止這些，還有不計其數的第三方Launcher應用，很多開發者也會修改資料庫訪問地址，目前僅我們掌握的不同訪問地址就有多達40種左右。

  • 通過許可權查詢URI：

通過資料庫的讀寫許可權來查詢對應的URI相信大家也不陌生，感覺上像是找到了終極的解決方案，且看下去...

 

  1. 問題一：如果使用完整的許可權進行查詢--許可權眾多，我們目前掌握的超過50種。
  2. 問題二：如果使用不完整的許可權進行查詢（READ_SETTINGS）對應關係複雜，大約有 32% 的手機會對應兩個以上的URI。

例如：

GT-I8262D：

authority:com.sec.android.app.launcher.settings ReadPermission:com.android.launcher.permission.READ_SETTINGS 
authority:com.sec.android.app.launcher.settings.id ReadPermission:com.android.launcher.permission.READ_SETTINGS

Lenovo A278t：

authority:com.aspire.mm.Settings ReadPermission:com.aspire.mm.permission.READ_SETTINGS 
authority:com.huaqin.launcherEx.settings ReadPermission:com.huaqin.launcherEx.permission.READ_SETTINGS 
authority:com.huaqin.thememgr.Settings ReadPermission:com.huaqin.thememgr.permission.READ_SETTINGS

二、多姿多彩的Camera

1. Intent呼叫手機內相機程式

 

如果我們設定了照片的儲存路徑，那麼很可能會遇到一下三種問題：

  • 問題一：onActivityResult方法中的data返回為空（資料表明，93%的機型的data將會是Null，所以如果我們指定了路徑，就不要使用data來獲取照片，起碼在使用前要做空判斷）。
  • 問題二：照片無法儲存。

如果自定義儲存路徑是/mnt/sdcard/lowry/，而手機SD卡下在拍照前沒有名為lowry的資料夾，那麼部分手機拍照後圖片不會儲存，導致我們無法獲得照片，大多數手機的相機遇到資料夾不存在的情況都會自己創建出不存在的資料夾，而個別手機卻不會建立，其代表機型為：三星I8258、華為H30-T00、紅米等。

解決的方法就是在指定儲存路徑前先判斷路徑中的資料夾是否都存在，不存在先建立再呼叫相機。

  • 問題三：照片可以儲存，但是名字不對。

file:///mnt/sdcard/123 1.jpg，由於URI的fromFile方法會將路徑中的空格用“%20”取代。

其實對於大多數的手機這都不算事，手機在解析儲存路徑的時候都會將“%20”替換為空格，這樣實際上最終的照片名字還是我們當初指定的名字：123 1.jpg，遺憾的是個別手機（如酷派7260）系統自帶的相機沒有將“%20”讀成空格，拍照後的照片的名字是123%201.jpg，我們用路徑“file:///mnt/sdcard/123 1.jpg”能找到照片才怪！

 

 

 

總結：

（1）使用onActivityResult中的intent(data)前要做空判斷。 
（2）指定拍照路徑時，先檢查路徑中的資料夾是否都存在，不存在時先建立資料夾再呼叫   相機拍照。 
（3）指定拍照儲存路徑時，照片的命名中不要包含空格等特殊符號。

2. 通過Camera的open方法呼叫手機攝像頭

2.1 連續自動對焦crash

原因：第一次對焦未結束，應用層又發起的第二次對焦，引起對焦失敗。

 

解決方案一：傳入AutoFocusCallback；

 

解決方案二：延時操作；

解決方案三：異常捕獲。

2.2 攝像頭個數判斷錯誤

現象：當我們使用Camera.getNumberOfCameras()方法檢測攝像頭數量時返回的結果不準確，如果我們嘗試開啟一個不存在的攝像頭肯定會丟擲異常，這也提醒我們在開啟Camera攝像頭時需要加異常保護。

代表機型：聯想278T、酷派8022

 

2.3 閃光燈的判斷

我們常用的判斷手機是否有閃光燈的方法應該有以下兩種：

判斷是否支援閃光燈方法一：使用getSupportedFlashModes方法；

 

判斷是否支援閃光燈方法二：通過PackageManager判斷。

 

方法一有3.7%的機器結果錯誤，無法準確地判斷出手機是否有閃光燈，主要的品牌包含：酷派、天語、聯想、三星等。方法二有9.7%的機器結果錯誤，主要品牌包含：VIVO、金立、酷派、天語、朵唯、三星等。

我們建議在判斷手機是否有閃光燈的時候將這兩種方法聯合使用，出現錯誤的概率將大大降低。

2.4 常亮狀態與其他狀態間的切換

前提條件是我們設定閃光燈為常亮（Parameters.FLASH_MODE_TORCH），並且閃光燈成功常亮。此時我們在設定閃光燈模式為Parameters.FLASH_MODE_AUTO後閃光燈依然常亮，這樣的機型約佔熱門機型的12%。遇到這種情況我們需要先設定閃光燈模式為Parameters.FLASH_MODE_OFF關閉閃光燈後再設定其他模式。

2.5 釋放Camera後閃光燈依舊閃亮

既然開了，我們就要負責關，說實話，以前這個問題根本不在我的考慮範內，因為我們在使用Camera的時候都會在Activity被銷燬或者暫停時釋放Camera。這個時候無論閃光燈是什麼狀態，都會隨著Camera的釋放而關閉。直到我遇見了OPPO R815T，我的世界觀發生了變化，這貨如果設定了閃光燈常亮，即使釋放了Camera閃光燈依舊穩穩地亮著。

而且由於Camera被釋放掉了，你再也沒辦法關閉閃光燈了，關閉App、解除安裝App，你還是扣電池關機吧.....所以，如果你的程式中有設定閃光燈為常亮狀態的操作，建議在釋放Camera前先將閃光燈設定為關閉（Parameters.FLASH_MODE_OFF）狀態。

2.6 CameraInfo的另類情況

官方文件中有關於調整相機預覽角度的例子：

 

在這個例子中CameraInfo非常重要，最終的角度計算就是根據CameraInfo中orientation值得到的，所以如果這個值不準確的話，那麼我們的角度就有可能出現錯誤。

VIVO V1手機第一次獲取CameraInfo的orientation值是90，而當執行了mCamera = Camera.open();之後再獲取CameraInfo的orientation值就是0，而且以後獲取的都是 0 ，除非重啟手機。

無論是這款手機上的哪個應用，只要執行了一次Camera.open()之後，其他所有程式中獲取CameraInfo的orientation都是是0。

手機自帶的相機卻能很好的使用反編譯系統相機後果然發現系統相機並沒有像官方給出的例子來進行角度的矯正。

 

 

 

 

解決方案：

  1. 按照此手機系統相機的做；
  2. 對該手機CameraInfo的orientation值寫死為90。

三、不止是2的雙卡

雙卡的問題解決的基本思路：

  1. 推斷：手機內建的系統APP都可以正常使用這些功能，因此肯定存在廠商自定義API來實現這些功能；
  2. 反編譯：Framework、系統App、系統資料庫；
  3. 定位：TelephoneManager擴充套件、SMSManager擴充套件、電話服務擴充套件、簡訊服務擴充套件、資料庫欄位擴充套件。

四、UI適配

說到UI適配其實很是讓人頭疼，下面的圖片是某個產品為了進行UI適配所做的工作，可以看出相當繁瑣。

 

除了解析度的適配，有時候佈局檔案中的某個標籤還會引起一些問題，我們先看下面一段佈局程式碼：

 

正確結果：

 

錯誤結果：

 

這就是因為Android 3.0以下版本在FrameLayout中使用layout_marginTo標籤，必須要設定gravity才能生效。

那麼如何解決這個問題呢？在設定android:layout_marginTop的元件中再設定一下 android:layout_gravity="top"即可。

五、還有更奇葩的

1. 廠商的抽象方法

如果你需要實現InputConnection介面，那麼你一定要注意下面這個很奇葩的異常：

 

 

反編譯了下此款手機的Framework，發現廠商在InputConnection介面中增加了一個抽象方法performYLPrivateCommand。


2. 距離感測器


2.1 不同手機event.values[0]值簡直是千變萬化

簡單說幾個有代表性的：

  1. 一部分手機比較正常，靠近時為0遠離時為1（0，1）；
  2. 有點小個性的手機數值將變大，比如（0，100），（3，5），（3，100）等等；
  3. 213手機的數值就比較莫名其妙，（1.001，5.003），你是表明精確度高？

2.2 數值與遠近關係不統一

既然我們是通過數值來判斷當前是否出於近耳狀態，那麼是不是應該這個數值的大小是有說道的？靠近時的數值小一點，遠離時的數值大一些，起碼我見過的99%的手機是這樣子的。但是就有幾款神經病手機（100W）偏偏是靠近時的數值比遠離時的數值大，這是個坑，開發者要注意~~！！

2.3 getMaximumRange方法返回值不對

有一句API：SensorManager.getDefaultSensor(Sensor.TYPE_PROXIMITY).getMaximumRange()， 文件解釋這個應該獲取的是感測器數值變化的最大範圍，比如如果靠近時的值是0，遠離時的值是1。那麼getMaximumRange()的值應該是1才不會影響我們的判斷，我這裡僅僅是從API角度和我們日常的使用習慣來說的，如果不是這樣的規律，就會對我們的程式設計造成麻煩。


相關推薦

Android機型適配之痛[乾貨分享]

Android平臺的誕生為手機智慧化的普及立下汗馬功勞，但其最大的缺點也越來越凸顯，那就是碎片化嚴重：裝置繁多、品牌眾多、版本各異，晶片、攝像頭、解析度不統一等等，這些都逐漸成為Android系統發展的障礙，碎片化嚴重不僅造成Android系統混亂，也導致Android應用隱

騰訊Bugly乾貨分享：Android機型適配之痛

一、個性化十足的Launcher 快捷方式雖然看起來只是一個很小的功能點，但是它涉及到的機型適配問題很多。 快捷方式建立程式碼： ntent addShortCut = new Intent("com.android.launcher.action.I

Android機型適配之痛

CSDN移動將持續為您優選移動開發的精華內容，共同探討移動開發的技術熱點話題，涵蓋移動應用、開發工具、移動遊戲及引擎、智慧硬體、物聯網等方方面面。如果您想投稿、參與內容翻譯工作，或尋求近匠報道，請傳送郵件至tangxy#csdn.net（請把#改成@）。  Andr

Android面試題-機型適配之痛，例如三星、小米、華為、魅族等。

原始碼分析相關面試題 Activity相關面試題 Service相關面試題 與XMPP相關面試題 與效能優化相關面試題 與登入相關面試題 與開發相關面試題 與人事相關面試題 由於開源三方定製

Android 螢幕適配之 dimens 適配

相信做手機端的 App 的小夥伴，只要是產品稍微大一點，就會面臨螢幕適配的問題，對於適配這個問題，網上眾說紛紜，以前雖然有零零散散的看過，但是沒有實踐過，也是在最近遇到這個需求的情況下才研究了一下，現在做個記錄。 1 參考連結 http://blog.csdn.net/qq_341

Android螢幕適配之dp分包法

  前言 網上關於螢幕適配的文章已經鋪天蓋地了，為什麼我還要講？因為網上現在基本都是使用px適配，即每種螢幕解析度的裝置需要定義一套dimens.xml檔案。再加上有些手機還有虛擬按鍵（例如華為），這樣就還需要每個有虛擬按鍵的裝置加多一套dimens.xml檔案，再加上平板那些你會

Android 螢幕適配之weight的使用

1. 要點：必須在LinearLayout的佈局內使用才有效果 2. 計算公式： 控制元件寬度=控制元件原始寬度+權重比例xLinearLayout剩餘寬度。 3. 實踐： <?xml version="1.0" encoding="utf-8"?> <LinearLa

android螢幕適配之精準適配

（[email protected]）（android精準適配工具）最近這段時間專案要做適配，在網上方便的方法。後來根據http://blog.csdn.net/jdsjlzx/article/details/45891551文章最後提出的適配思路，進行了總結優化

Android 機型適配問題整理

Androi問題機型適配問題都是老生常談的話題了，其一出生就註定了成為開發人員心中的疼，隨著安卓手機品牌發展眾多，一款產品應用釋出沒有經歷過充分的機型適配就上線，接下來的一幕就是開發人員收到了滿屏的錯誤日誌發來，這個是某某統計軟體蒐集到的應用崩潰日誌，趕緊適配，

android 手機適配之values適配dimen值

android 適配螢幕的方式有很多,最方便最直接的無非就是適配values裡的dimens檔案值來進行適配. 張鴻洋大神已經寫過一篇適配的文章,很詳細 但是我在閱讀的時候還是有點疑問,這個values-1920x1080到底是dp值還是手機解析度,因為我在

Android 螢幕適配之如何確定裝置的res dpi

目的 不同裝置系統識別的res-dpi資料夾不同，如果我們在放入資原始檔如圖片位置錯誤，則會導致螢幕適配困難，故我們需要先識別目標裝置系統識別的資原始檔夾是哪一個，所以有以下資訊獲取函式。 目標裝置res-dpi資訊獲取方法： /**

Android螢幕適配之佈局設定(二)

書接上回，我們已經瞭解了一些關於適配的一些相關概念，接下來我們會了解一下，在設定佈局時我們應該注意的地方。 儘量不去設定具體的尺寸值。 為了確保佈局適應各種尺寸的螢幕，在保證功能實現的前提下，最好不要寫死一些尺寸，這樣的硬編碼，我們最好使用“match_

Android螢幕適配之動態設定單個控制元件的寬高比例

前言：這個問題出現在我做平板專案的時候，需要橫排顯示一張圖片以及其他控制元件，如下圖：要求圖、文各佔一半大小，圖片的寬高比例目測是1：2。這種情況不適合把高度寫死，因為iPad的螢幕大小差異有些大，高度寫死圖片hin容易變形，因此我們就需要動態去設定這個圖片的寬高。正題：首先

Android之機型適配

Android中的機型適配 在軟體開發的過程中,為了讓軟體在不同的場景下都可以使用,所以機型適配是不可或缺並且非常重要耗時的一個環節. 一:機型適配需要考慮的幾個方面: 1,Android的版本 2.手機廠商 3.螢幕的尺寸 4.網路的制式 5

全面認識Android手機（MIUI ROM適配之旅第四天——移植MIUI Framework）

1. 為什麼使用程式碼插樁 首先我們來回顧第一章中的Android軟體架構圖，這個圖中框架層的程式碼完全是由Java語言編寫的，對於這兩層的程式碼，在沒有原始碼的情況下我們可以採取程式碼插樁的方式來注入我們的程式碼。但是對於下面幾層的程式碼幾乎都是以機器碼的形式存在，機器碼

android 多解析度機型適配資料夾命名規則

假設有如下解析度機器： 800 x 480 1024 x 600 1024 x 768 1280 x 800 1920 x 1200 2048 x 1536 總共六種類解析度機器，如果按照dp為單位來細分可以分為幾種呢？ 首先通過context.getRe

僅僅是個人記錄：Android 的機型適配： 螢幕適配(包括dpi,dp,sp的概念) 版本適配 硬體適配。 以及如何和美工配合

最重要的適配就是尺寸適配，我們可以有兩種方案： 第一種方案，以某一個尺寸，例如1920*1080為基準的，在檔案中修改 http://blog.csdn.net/lmj623565791/article/details/45460089         int baseW

Android開發中的機型適配和國際化適配的實現；

關於Android螢幕的一些基本概念知識，自行充電。。在此只介紹實際開發過程中的使用 　　1、說到Android的螢幕適配，首當其衝的就是圖片的適配 　　　　圖片適配遵循兩個原則： ①儘量使用9.path圖來自動適應螢幕 ②儘量使用最少的圖片資源 　　　　關於第一點使用9.path圖片：比如topBar、底

Android開發 螢幕適配之畫素密度適配

由於市場上採用Android系統的裝置種類繁多，迫使Andriod開發人員不得不做煩人的適配工作。 適配工作包括對安裝不同Android版本的裝置進行適配，對不同螢幕的裝置進行適配等。 而螢幕適配又包括： 螢幕尺寸（small,normal,large,xlarge , 這

Android適配之百分比佈局

一概述 安卓開發過程中一直比較無賴適配的問題，感到比較迷茫，一般的手機開發佈局只是做到簡單的適配，有的時候我們覺得網頁的適配為什麼簡單，其實有了解過的小盆友知道，網頁的介面使用百分比計算的，那麼這樣的