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

低電耗模式

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

后臺(tái)優(yōu)化

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

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

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

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

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

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

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

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

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

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

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

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

解決 Android N 上 安裝Apk時(shí)報(bào)錯(cuò)：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í)訪問(wèn)權(quán)限
exported：必須是false
resource：中的@xml/file_paths是我們接下來(lái)要添加的文件

在res目錄下新建一個(gè)xml文件夾，并且新建一個(gè)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)訪問(wèn)的路徑（.代表所有路徑）
name：就是你給這個(gè)訪問(wèn)路徑起個(gè)名字

最后修改代碼:

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)建出一個(gè)Uri,現(xiàn)在我們使用FileProvider.getUriForFile(context, BuildConfig.APPLICATION_ID + ".fileProvider", apkFile); //BuildConfig.APPLICATION_ID直接是應(yīng)用的包名

屏幕縮放

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

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

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

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

① 在屏幕寬度為 sw320dp 的設(shè)備上測(cè)試你的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ù)對(duì)應(yīng)的屏幕尺寸或像素密度。保存這些元數(shù)據(jù)便于你在Config變更后決定是否需要刷新緩存數(shù)據(jù)。

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

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

NDK平臺(tái)庫(kù)

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

如,UnsatisfiedLinkError

典型修復(fù)方法：

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

注解保留

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

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

其他重要說(shuō)明

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

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

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

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

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

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

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

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

7. 如果Android 7.0上有DELETE_PACKAGES權(quán)限的應(yīng)用嘗試刪除一個(gè)軟件包，但另一項(xiàng)應(yīng)用已經(jīng)安裝了這個(gè)軟件包，則系統(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)試技巧與常見(jiàn)問(wèn)題解決方法匯總》、《Android基本組件用法總結(jié)》、《Android視圖View技巧總結(jié)》、《Android布局layout技巧總結(jié)》及《Android控件用法總結(jié)》

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

最新評(píng)論