本文總結(jié)分析了Android7.0版本影響開發(fā)的改進(jìn)。分享給大家供大家參考，具體如下：

低電耗模式

會對鬧鈴、GPS 和 Wi-Fi 掃描 產(chǎn)生限制.
可參考Optimizing for Doze and App Standby
使用GCM來發(fā)送和接受消息

后臺優(yōu)化

Android N 刪除了三項(xiàng)隱式廣播,隱式廣播會在后臺頻繁啟動已注冊偵聽這些廣播的應(yīng)用。 刪除這些廣播可以顯著提升設(shè)備性能和用戶體驗(yàn).

偵聽網(wǎng)絡(luò)變化的主線程廣播改為: CONNECTIVITY_CHANGE。
對所有應(yīng)用都無法 發(fā)送和接受 ACTION_NEW_PICTURE 或 ACTION_NEW_VIDEO .

可以使用JobScheduler API ,更多參考后臺優(yōu)化

系統(tǒng)權(quán)限更改

為了提高私有文件的安全性，面向 Android 7.0或更高版本的App私有目錄被限制訪問(0700)。此設(shè)置可防止私有文件的元數(shù)據(jù)泄漏，如它們的大小或是否存在（狀態(tài)）。此權(quán)限策略的更改有多重副作用：

私有文件的文件權(quán)限不應(yīng)再由所有者放寬，為使用MODE_WORLD_READABLE和MODE_WORLD_WRITEABLE而進(jìn)行的此類嘗試將觸發(fā)SecurityException，會導(dǎo)致App崩潰的。

注：迄今為止，這種限制還不能完全執(zhí)行。App仍可能使用原生API或File API來修改它們的私有目錄權(quán)限。但是Google強(qiáng)烈反對放寬私有目錄的權(quán)限。

傳遞軟件包網(wǎng)域外的 file://URI可能給接收器留下無法訪問的路徑。因此傳遞file://URI會觸發(fā) FileUriExposedException。分享私有文件內(nèi)容的推薦方法是使用FileProvider。

DownloadManager不再按文件名分享私人存儲的文件。老的App在訪問COLUMN_LOCAL_FILENAME時(shí)可能出現(xiàn)無法訪問的路徑。針對Android 7.0或更高版本開發(fā)的應(yīng)用在嘗試訪問COLUMN_LOCAL_FILENAME時(shí)會觸發(fā) SecurityException。通過使用DownloadManager.Request.setDestinationInExternalFilesDir())或DownloadManager.Request.setDestinationInExternalPublicDir())將下載位置設(shè)置為公共位置的老App仍可以訪問COLUMN_LOCAL_FILENAME中的路徑，但是Google還是強(qiáng)烈反對使用這種方法。訪問由DownloadManager公開的文件的首選方式是使用ContentResolver.openFileDescriptor())。

應(yīng)用間共享文件

對于針對Android 7.0的應(yīng)用，Android framework執(zhí)行的StrictMode API禁止向你的App外公開file://URI。如果一個包含文件URI的Intent發(fā)送到你的應(yīng)用之外，App會發(fā)生FileUriExposedException異常。

若要在應(yīng)用間共享文件，您應(yīng)發(fā)送一項(xiàng)content://URI，并授予URI臨時(shí)訪問權(quán)限。進(jìn)行此授權(quán)的最簡單方式是使用FileProvider類。如需有關(guān)權(quán)限和共享文件的更多信息，請參閱共享文件。

解決 Android N 上 安裝Apk時(shí)報(bào)錯：android.os.FileUriExposedException:

在AndroidManifest.xml中添加如下代碼

<provider
  android:name="android.support.v4.content.FileProvider"
  android:authorities="app的包名.fileProvider"
  android:grantUriPermissions="true"
  android:exported="false">
  <meta-data
    android:name="android.support.FILE_PROVIDER_PATHS"
    android:resource="@xml/file_paths" />
</provider> 

注意：

authorities：app的包名.fileProvider
grantUriPermissions：必須是true，表示授予 URI 臨時(shí)訪問權(quán)限
exported：必須是false
resource：中的@xml/file_paths是我們接下來要添加的文件

在res目錄下新建一個xml文件夾，并且新建一個file_paths的xml文件（如下圖）

輸入以下內(nèi)容

<?xml version="1.0" encoding="utf-8"?>
<paths>
  <external-path path="Android/data/app的包名/" name="files_root" />
  <external-path path="." name="external_storage_root" />
</paths>

path：需要臨時(shí)授權(quán)訪問的路徑（.代表所有路徑）
name：就是你給這個訪問路徑起個名字

最后修改代碼:

Intent intent = new Intent(Intent.ACTION_VIEW);
//判斷是否是AndroidN以及更高的版本
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.N) {
  intent.setFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);
  Uri contentUri = FileProvider.getUriForFile(context, BuildConfig.APPLICATION_ID + ".fileProvider", apkFile);
  intent.setDataAndType(contentUri, "application/vnd.android.package-archive");
} else {
  intent.setDataAndType(Uri.fromFile(apkFile), "application/vnd.android.package-archive");
  intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
}
startActivity(intent);
//以前我們直接 Uri.fromFile(apkFile)構(gòu)建出一個Uri,現(xiàn)在我們使用FileProvider.getUriForFile(context, BuildConfig.APPLICATION_ID + ".fileProvider", apkFile); //BuildConfig.APPLICATION_ID直接是應(yīng)用的包名

屏幕縮放

Android 7.0支持用戶設(shè)置顯示尺寸，以放大或縮小屏幕上的所有元素，從而提升設(shè)備對視力不佳用戶的可訪問性。用戶無法將屏幕縮放至低于最小屏幕寬度sw320dp，該寬度是Nexus 4的寬度，也是常規(guī)中等大小手機(jī)的寬度。

當(dāng)設(shè)備密度發(fā)生更改時(shí)，系統(tǒng)會以如下方式通知正在運(yùn)行的應(yīng)用：

1. 如果是面向API leve 23或更低版本系統(tǒng)的應(yīng)用，系統(tǒng)會自動終止其所有后臺進(jìn)程。也就是說如果用戶切換后離開你的App，打開“Settings”更改Display size設(shè)置，則系統(tǒng)會像處理內(nèi)存不足的情況一樣終止該應(yīng)用。如果應(yīng)用具有任何前臺進(jìn)程，則系統(tǒng)會如處理運(yùn)行時(shí)變更中所述將配置變更通知給這些進(jìn)程，就像對待設(shè)備屏幕方向變更一樣，具體大家可以再看看這個超鏈接。

2. 如果是針對Android 7.0的App，則其所有進(jìn)程（前臺和后臺）都會收到有關(guān)配置變更的通知，如處理運(yùn)行時(shí)變更中所講的那樣。 大多數(shù)App并不需要進(jìn)行任何更改即可支持此功能，不過前提是這些應(yīng)用遵循Android最佳實(shí)踐。具體要檢查的事項(xiàng)：

① 在屏幕寬度為 sw320dp 的設(shè)備上測試你的App，并確保其正常運(yùn)行。

② 當(dāng)設(shè)備Config發(fā)生變更時(shí)，更新任何與密度相關(guān)的緩存信息，例如緩存位圖或從網(wǎng)絡(luò)加載的資源。當(dāng)應(yīng)用從暫停狀態(tài)恢復(fù)運(yùn)行時(shí)，檢查Config的變化。
注：如果你要緩存與配置相關(guān)的數(shù)據(jù)，則最好也包括相關(guān)元數(shù)據(jù)，例如該數(shù)據(jù)對應(yīng)的屏幕尺寸或像素密度。保存這些元數(shù)據(jù)便于你在Config變更后決定是否需要刷新緩存數(shù)據(jù)。

③ 避免用像素單位指定尺寸，因?yàn)橄袼夭粫S屏幕密度縮放。應(yīng)改為使用dp等單位。

用戶可以在設(shè)置-顯示-顯示大小修改屏幕寬度，也可以在設(shè)置-開發(fā)人員選項(xiàng)-最小寬度隨意設(shè)置指定寬度，開發(fā)人員特別需要注意適配

NDK平臺庫

Android N 做了一些命名空間更改,阻止加載非公開API,會出現(xiàn)一些常見錯誤

如,UnsatisfiedLinkError

典型修復(fù)方法：

1. 使用標(biāo)準(zhǔn) JNI 函數(shù)來替代使用 libandroid_runtime.so 中的 getJavaVM 和 getJNIEnv
2. 使用公開 alternative __system_property_get 來替代使用 libcutils.so 中的 property_get 符號
3. 使用應(yīng)用本地版本來替代使用 libcrypto.so 中的 SSL_ctrl 符號

注解保留

Android 7.0在注解可見性被忽略時(shí)修復(fù)錯誤。這種問題將啟用本不應(yīng)被允許的運(yùn)行時(shí)訪問注解。 這些注解包括：

VISIBILITY_BUILD：僅應(yīng)編譯時(shí)可見。
VISIBILITY_SYSTEM：運(yùn)行時(shí)應(yīng)可見，但僅限基本系統(tǒng)。 如果你的App依賴這種行為，請?jiān)谧⒔庵刑砑右豁?xiàng)運(yùn)行時(shí)必須可用的保留政策。你可通過使用@Retention(RetentionPolicy.RUNTIME) 這樣做。

其他重要說明

1. 如果一個針對較低API級別開發(fā)的App在Android 7.0上運(yùn)行，那么在用戶更改顯示尺寸時(shí)，系統(tǒng)將終止此App進(jìn)程。App必須能夠正常處理此情景。否則，當(dāng)用戶從最近使用記錄中恢復(fù)運(yùn)行App時(shí)，App將會出現(xiàn)崩潰現(xiàn)象。您應(yīng)測試應(yīng)用以確保不會發(fā)生此行為。要進(jìn)行此測試，您可以通過DDMS手動終止應(yīng)用，可以造成相同的崩潰現(xiàn)象。在屏幕密度發(fā)生更改時(shí)，系統(tǒng)不會自動終止針對Android 7.0及更高版本開發(fā)的App；不過這些App仍可能對配置變更做出不良響應(yīng)。

2. Android 7.0上的應(yīng)用應(yīng)能夠正常處理配置變更，并且在后續(xù)啟動時(shí)不會出現(xiàn)崩潰現(xiàn)象。你可以通過更改字體大小 (Setting > Display > Font size) 并隨后從最近使用記錄中恢復(fù)運(yùn)行應(yīng)用，來驗(yàn)證App行為。

3. 由于之前的Android版本中的一項(xiàng)錯誤，系統(tǒng)沒有對主線程上的一個TCP Socket的寫入操作嚴(yán)格檢查。Android 7.0修復(fù)了這個系統(tǒng)錯誤。之前有這種行為的App將會引發(fā)android.os.NetworkOnMainThreadException。一般情況下，不建議在主線程上執(zhí)行網(wǎng)絡(luò)操作，因?yàn)檫@些操作通常都有可能導(dǎo)致ANR和卡頓，這個應(yīng)該是中所周知的，大家一般不會犯。

4. Debug.startMethodTracing()方法族現(xiàn)在默認(rèn)在你的共享的存儲空間上的軟件包特定目錄中存儲輸出，而非 SD卡頂級。這意味著應(yīng)用不再需要請求WRITE_EXTERNAL_STORAGE權(quán)限就可以使用這些API。

5. 許多平臺API現(xiàn)在開始檢查在Binder事務(wù)間發(fā)送的大負(fù)載，系統(tǒng)現(xiàn)在會將TransactionTooLargeExceptions再次作為RuntimeExceptions引發(fā)，而不再只是默默記錄或不拋出這個錯誤。一個常見例子是在Activity.onSaveInstanceState())上存儲過多數(shù)據(jù)，導(dǎo)致ActivityThread.StopInfo在你的App面向 Android 7.0時(shí)引發(fā)RuntimeException。

6. 如果應(yīng)用向View post Runnable任務(wù)，并且View未附加到窗口，系統(tǒng)會用View為Runnable任務(wù)排隊(duì)；在 View附加到窗口之前，Runnable任務(wù)不會執(zhí)行。 此行為會修復(fù)以下錯誤：

① 如果一個App是從并非預(yù)期Window UI線程的其他線程發(fā)布到View，則Runnable可能會因此運(yùn)行錯誤。

② 如果Runnable任務(wù)是從并非looper thread的其他線程發(fā)布，則應(yīng)用可能會曝光Runnable任務(wù)。

7. 如果Android 7.0上有DELETE_PACKAGES權(quán)限的應(yīng)用嘗試刪除一個軟件包，但另一項(xiàng)應(yīng)用已經(jīng)安裝了這個軟件包，則系統(tǒng)可能要求用戶確認(rèn)。在這種情況下，應(yīng)用在調(diào)用PackageInstaller.uninstall()) 時(shí)的返回狀態(tài)應(yīng)為STATUS_PENDING_USER_ACTION。

更多關(guān)于Android相關(guān)內(nèi)容感興趣的讀者可查看本站專題：《Android開發(fā)入門與進(jìn)階教程》、《Android調(diào)試技巧與常見問題解決方法匯總》、《Android基本組件用法總結(jié)》、《Android視圖View技巧總結(jié)》、《Android布局layout技巧總結(jié)》及《Android控件用法總結(jié)》

希望本文所述對大家Android程序設(shè)計(jì)有所幫助。

最新評論