今年3月，Google 破天荒提前半年發(fā)布了 Android N 開發(fā)者預覽版。當然，作為一個不合格的谷粉并沒有第一時間體驗安裝，因為至今仍然能夠回憶起來去年今日此門中（霧）興沖沖刷了 Android M Preview 的時候發(fā)現(xiàn)各種 Crash 就連微信也（不出所料得）中招時自己一臉懵逼的心情。當然，為自己的機智而慶幸并沒有過多久，很快就有微信好友（當然也是純純的谷粉）反饋微信又雙叒叕在 Android 新版本下 Crash了……好吧這次我們的時間很充裕，因為 5 個 preview 之后才會發(fā)布最終 release 版本。令人失望（咦）的是，我們的工程師在一天之內(nèi)就修復了這個 bug 并且趕在當天 6.3.15 alpha 版本發(fā)布之前修復并合入主線，辜負了 Google 的一片苦心。

痛定思痛，當天我就拎起來麒麟臂，在 Chrome 的地址欄重重得敲入：http://developer.android.com/preview/overview.html ，并且聽說Google 在北京舉辦了 Android 開發(fā)者大會的時候，屁顛屁顛得過去了。

在這個『人人都是產(chǎn)品經(jīng)理』的年代，作為程序員當然是敲得起代碼，當?shù)闷鸾?jīng)理（。。。）。如果我是產(chǎn)品經(jīng)理，Android N 的更新無非是以下三個點：
默認多窗口支持
強化通知，里邊有你最喜歡的直接回復
沒了…當然不是：Android Developer 一筆帶過的重磅 feature：允許第三方應用在快速設置中添加自己的服務

默認多窗口支持
注意『默認』二字：這很重要，這很重要，這很重要。

Android M 里邊，系統(tǒng)允許應用在啟動某 Activity（對于 PM 來說可以不嚴謹?shù)美斫獬山缑妫r帶上特殊參數(shù)，該應用可以在最近任務窗口中和主應用分開顯示，即 multi-tasking 支持。當然，并沒有多少應用鳥這個 Android M 中為數(shù)不多的新特性之一，因為效果實在是不明顯。也有一定的原因是在這個大部分產(chǎn)品經(jīng)理不會關注 Android Developer 的年代，這個非默認的特性實在不會引起他們的注意。

在 Android N 中，竟然直接支持了 multi-window！雖然這個特性并不驚艷，在 iOS 和三星的機型中早已支持，甚至在 Android M 中，也可以預埋了這個特性，并可以通過某些特殊方法開啟。然而，和 iOS 應用需要特殊聲明才能支持多窗口的特性不同，Android N竟然默認支持了多窗口。這意味著任何一個應用，無論 target-api 是否是 Android N，都支持從最近任務中長按應用標題欄進入多窗口模式。這里是個 Demo。

默認支持也就意味著除非特殊聲明，任何應用都支持前述視屏所示效果，也就是說如果應用不針對這種模式進行完美適配，或者說用了絕對布局的話，你的應用就會。。。。呵呵呵。

當然，這種老掉牙的特性是不會引起高冷的 PM 的注意的，只會扔給開發(fā)狗交給我們?nèi)ミm配。那好吧，來一個 one more thing 刺激一下你：
在 Android N 中，將支持分屏情況下 drag and drop，讓這個4.0開始就支持 faeture 煥發(fā)了新生。這也就意味著你可以將一個應用內(nèi)、甚至不同應用間的分屏情況將一個分屏幕控件拖拽到另外一個分屏幕。也許可以用來拖拽圖片快速發(fā)圖，或者。。隨便你想干什么。
當然，從開發(fā)狗的角度來說，這里有一點安全隱患：如果通過拖拽將數(shù)據(jù)傳遞過來，你甚至不知道來源是什么。但是想想也是，畢竟用的和粘貼板一樣的接口，還能指望什么呢？

另外，作為分屏的一種特殊形式，畫中畫（picture in picture）也得到了相應的支持。不過據(jù) Google 的工程師說，畫中畫模式主推 Android TV 中應用（也許 Google 認為在手持設備上場景不足）。不過 whatever，現(xiàn)在很多功能已經(jīng)可以通過浮窗接口實現(xiàn)。畫中畫對于做視頻應用或者有視頻支持功能的應用非常有幫助。

此外，給程序員朋友們幾個小貼士
雖然分屏狀態(tài)下兩個應用都可見，但是對于非 Focus 狀態(tài)的應用當前是處于 onStop 狀態(tài)的，也就是說，并沒有實際在運行中。原本 onStop 的時候應用應該是不可見，但是現(xiàn)在可見了。。。原本的一些惡心邏輯注意修改下。
雖然分屏狀態(tài)下的應用不會 double 內(nèi)存占用，但是內(nèi)存占用肯定會比正常狀態(tài)大，注意分屏模式下即時釋放內(nèi)存。
適配好你的程序，該加 scroll 的地方加 scroll。當然，如果原本的你的程序就已經(jīng)針對多尺寸屏幕有了處理，就已經(jīng)完美適配了這個模式

通知欄一直是 Android 引以為豪的方面。相對于 iOS 的通知欄來說， Android 的通知欄具有幾乎完爆的功能：自定義控件，自定義 Action，可以定義下來拓展的控件……除了快速回復。
在這之前，先上一段 Android N 新版本的通知欄和快速設置欄，至于為什么放視頻，嗯。。。因為我覺得很好看：點我看視頻

如今，這一點已經(jīng)被 Google 迎頭趕上，并且體驗絕不亞于 iOS，甚至好很多。
當然，如果一次來了多條消息并且都不是一個會話中，快速回復也是毫無壓力：
這個新特性簡而言之就是滿足了快速回復的一切需求，也許從此再也不用擔心沉浸式閱讀時需要跳出回復消息這種傷害體驗的情況。
當然了，除了快速回復，還有根據(jù)應用歸檔通知，這無疑是一個大殺器：

同時，這里需要同時提醒PM和開發(fā)同學的是：如果真的需要在通知上設置自定義控件，請調(diào)用DecoratedCustomViewStyle()。它會讓你的自定義控件在通知欄顯得更加和諧。Sample:
[Java] 純文本查看 復制代碼
?
1
2
3
4
5
6
Notification noti = new Notification.Builder()

       .setSmallIcon(R.drawable.ic_stat_player)
       .setLargeIcon(albumArtBitmap))
       .setCustomContentView(contentView);
       .setStyle(new Notification.DecoratedCustomViewStyle())
       .build();

『何必這樣，我寫一個BroadcastReceiver監(jiān)聽CONNECTIVITY_ACTION然后處理不就行了，naive！』
科科。
為了防止這個沒有節(jié)操的事情發(fā)生，Google 在 Android N中拿掉了這三個廣播：
CONNECTIVITY_ACTION：網(wǎng)絡變化
ACTION_NEW_PICTURE：添加新圖片
ACTION_NEW_VIDEO：添加新視頻

這也是我非常佩服 Google 的一個點，敢于做減法。當然，留下的坑就多了，比如 CONNECTIVITY_ ACTION，很多應用（包括微信）都會監(jiān)聽。今后需要使用 JobScheduler 實現(xiàn)相同的邏輯了。JobScheduler 有非常多的好處，他會根據(jù)用戶當前設備的情況，比如當前 RAM、電量、模式、是否應用在前臺等等，決定是否執(zhí)行該邏輯。你也不希望自己的程序變成用戶手機變卡的罪魁禍首，從而讓用戶怒刪，對吧？

當然了，不允許監(jiān)聽 CONNECTIVITY_ ACTION 針對的是靜態(tài)注冊的 BroadcastReceiver，如果是動態(tài)注冊的 BroadcastReceiver 則并不會受到影響。

早在前年開始研究 Annotation 的時候，就在感慨為什么 Android 一直不支持 Java 8，即使現(xiàn)在 Java 9 都快出了。終于的終于，Android從N 版本開始支持 Java 8的編譯，前提是要在 Gradle 文件中顯式聲明使用 Jack 編譯器。
這個 Jack 是什么鬼呢？簡單來說，傳統(tǒng)的編譯工具鏈是將 java 代碼通過 javac 編譯成.class 文件，再通過 dx 編譯成 .dex。也就是醬紫的：
[Java] 純文本查看 復制代碼
?
1
javac (.java --> .class) --> dx (.class --> .dex)
而 Jack 則是一條龍服務，中間不需要經(jīng)過其他工具或者命令，一條命令就可以將.java 文件編譯成.jack 從而編程.dex：
[Java] 純文本查看 復制代碼
?
1
ack (.java --> .jack --> .dex)
使用 jack 非常簡單，gradle 配置即可
[Java] 純文本查看 復制代碼
?
01
02
03
04
05
06
07
08
09
10
11
12
13
android {
...
defaultConfig {

...
jackOptions {
  enabled true
 }

}
compileOptions {

sourceCompatibility JavaVersion.VERSION_1_8
targetCompatibility JavaVersion.VERSION_1_8

}
}
不過，Android N 版本的 Java 8特性并沒有支持全，不過主流的 feature 已經(jīng)支持，包括：
定義接口默認實現(xiàn)方法
Lamda 表達式支持（喜歡語法糖的同學的福利）
Repeatable annotations。這個已經(jīng)可以說的內(nèi)容很多，改天有空給大家慢慢介紹。
Method Reference。這個實話實說我并不是太了解，也是語法糖一種。感興趣的同學可以看看這個鏈接：https://docs.oracle.com/javase/tutorial/java/javaOO/methodreferences.html

但是現(xiàn)在還沒有支持一個很重要的特性：Stream。但是現(xiàn)在還在 Preview 階段，比如剛剛的第四條 Method Reference 就是 Preview2 支持的，可以期待下 release 中是否會支持（最新消息：已經(jīng)支持 java.util.stream 接口，棒棒的！）。

此外還需要注意兩點：
Lamda 表達式本質(zhì)上回生成匿名類，在性能敏感的模塊慎用
由于 Jack 編譯器不會產(chǎn)生.class 中間文件，因此在.class 上做 trick 的一些庫或者項目可能就會失效或者出問題。因此在使用之前，一定要好好測試。

Data Saver：乍看上去是一個數(shù)據(jù)存儲的 API，感覺很興奮，結(jié)果點開一看是流量節(jié)省。。。好吧，博大精深的英文。從 Android N 開始，系統(tǒng)層級支持用戶針對每一個應用添加自己的流量控制限制。今后開發(fā)的時候需要先通過 ConnectivityManager.getRestrictBackgroundStatus() 接口獲取本應用流量控制情況。
Key Attestation：對于絕大部分應用并不需要仔細研究的 feature，甚至可以當做不存在，但是對于我個人所做的生物認證項目來說，可謂是非常重要的 feature。
針對文件目錄或類型申請權限：實話實說，這個也算是一個很重要的 feature。從 Android 6.0 開始，如果需要使用存儲空間，包括讀寫，需要動態(tài)申請權限。然而對于大部分應用來說，都需要申請這個權限，而且一旦用戶允許，應用就可以為所欲為。因此，Android N 中允許應用聲明僅僅授權某個文件夾或者文件類型的存儲。

這一點 Android Developer 沒有講，至少暫時沒有講
還記得之前我說的微信升級到 N 會 Crash 么？實際上就是這個原因。

自 Android N 開始，系統(tǒng)將禁止第三方應用 so 文件鏈接系統(tǒng) lib 庫，包括并不限于 libcrypto.so，libandroidruntime.so，libicu.so，libbinder.so。動態(tài)鏈接上述庫輕則彈 Toast 提示，重則直接 crash。Android 此舉原因大家可以討論，但是事實已然如此，盡管對于大多數(shù)應用而言并無妨礙，但是對于類似微信這種在底層做了大量優(yōu)化和調(diào)用的應用來說還是很傷腦筋的。至于解決方法。。。暫時只想到了改用靜態(tài)鏈接，對于包的大小增加并不會太大。如果有更好的方法，歡迎大家討論。
實話實說，這次 Android N 的更新對于我們程序員來說還是干貨滿滿，滿到我有些話想說。

扯淡
前面說的都是 Android N，現(xiàn)在終于開始講扯淡了。實際上，從 Android L 開始，Google 就已經(jīng)開始反省自己過分開放的策略。原本后臺任務滿天飛的系統(tǒng)，現(xiàn)在漸漸地被控制得有序起來。比如 Android L 發(fā)布的 JobScheduler，Android M 發(fā)布的 Doze 模式和 APP Standby，Android N 的 Doze 加強以及瘦身計劃，無一不是在限制系統(tǒng)的后臺任務數(shù)量以及計算強度。亡羊補牢，不知是否為時未晚。

同時，關于設計方面，Material Design 推出已經(jīng)接近兩年，盡管有很多應用已經(jīng)適配，但是包括微信、Facebook、Twitter 在內(nèi)的很多主流應用仍然在堅持使用自己的設計語言。誠然，這里有可以理解的風格統(tǒng)一之考慮， MD 本身也有很多缺陷，但是我們很高興能看到的是 MD 自身在不斷的調(diào)整優(yōu)化，越來越成為一個漂亮的并且優(yōu)秀的設計，其層次感以及靈動性無處不撩撥著用戶的神經(jīng)。所以，是不是仍有很多人抱著 2.3 混亂局面或者 4.0 不那么優(yōu)秀的 Android Design 來臆測 Android 的設計風格？也許用著 iOS 的諸位對于 Android 的印象依然是 2.x 時代那個臃腫的、落后的以及。。額，難看的形象。就像這樣：

這是2011年左右，畢竟是5年前，那時 iPhone 上的應用也并不好看，不過還是比 Android 要強很多。但是現(xiàn)在 Android 應用已經(jīng)長這樣了（系統(tǒng)自帶應用）:

個人認為比 Apple 的設計。。。（為了防止引戰(zhàn)）至少并不差吧。
其實，這里說了這么多，精通讀心術的我也能想到大家心中的疑問：碎片化如此的 Android 市場，我們就算是適配了 N 的特性，大家也沒有這么快用上，還是歇著吧。嗯，關于碎片化，首先，Android 目前版本分布是醬紫的（來自 Google 官方，鏈接 http://developer.android.com/about/dashboards/index.html）

也就是說，至少截止到今天，接近40%的人的設備已經(jīng)是 Android 5.0 以及以上，按照如今廠商發(fā)貨的速度，目測一兩個月內(nèi)比例就會過半。平心而論，針對這半數(shù)用戶，有幾家應用做到了完美支持？無論是 UI 還是具體功能，大部分應用應該都是在4.x，甚至2.x版本的基礎上填坑，fix 新版本上的 crash，有幾家用到了新的特性，新的 feature 呢？而大家以為占主流的2.3系統(tǒng)，實際上已經(jīng)不足3%，是不是仍然有很多應用的 target api 仍然是 4.x 以下？
而且 Google 現(xiàn)在很雞賊啊（這一點謝老大提醒），一年發(fā)布一個大版本，前年5.0，去年6.0，今年 7.0，你說 Google 都到 7.0 了你還好意思連 5.0 都不上？這一點實際上對于解決碎片化是非常有幫助的。

面對占市場份額近 7 成的 Android 設備本身并不需要救助，一直都沒有放棄發(fā)展，欣欣向榮。相反，需要救助的是我們在 Android 上的應用，低質(zhì)量的應用實現(xiàn)已經(jīng)威脅到了我們自身。不僅僅是要依靠產(chǎn)品經(jīng)理，作為程序員，我們也要學會自救。
感謝！

如果你覺得內(nèi)容意猶未盡，如果你想了解更多相關信息，請掃描以下二維碼，關注我們的公眾賬號，可以獲取更多技術類干貨，還有精彩活動與你分享~

騰訊 Bugly是一款專為移動開發(fā)者打造的質(zhì)量監(jiān)控工具，幫助開發(fā)者快速，便捷的定位線上應用崩潰的情況以及解決方案。智能合并功能幫助開發(fā)同學把每天上報的數(shù)千條 Crash 根據(jù)根因合并分類，每日日報會列出影響用戶數(shù)最多的崩潰，精準定位功能幫助開發(fā)同學定位到出問題的代碼行，實時上報可以在發(fā)布后快速的了解應用的質(zhì)量情況，適配最新的 iOS, Android 官方操作系統(tǒng)，鵝廠的工程師都在使用，快來加入我們吧！