關于 Android N 那些你不知道的事兒

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

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

假如我是產品經理

在這個『人人都是產品經理』的年代，作為程序員當然是敲得起代碼，當得起經理（。。。）。如果我是產品經理，Android N 的更新無非是以下三個點：

• 默認多窗口支持

• 強化通知，里邊有你最喜歡的直接回復

• 沒了…當然不是：Android Developer 一筆帶過的重磅 feature：允許第三方應用在快速設置中添加自己的服務

默認多窗口支持

注意『默認』二字：這很重要，這很重要，這很重要。

 

Android M 里邊，系統允許應用在啟動某 Activity（對于 PM 來說可以不嚴謹得理解成界面）時帶上特殊參數，該應用可以在最近任務窗口中和主應用分開顯示，即 multi-tasking 支持。當然，并沒有多少應用鳥這個 Android M 中為數不多的新特性之一，因為效果實在是不明顯。也有一定的原因是在這個大部分產品經理不會關注 Android Developer 的年代，這個非默認的特性實在不會引起他們的注意。

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

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

當然，這種老掉牙的特性是不會引起高冷的 PM 的注意的，只會扔給開發狗交給我們去適配。那好吧，來一個 one more thing 刺激一下你：

在 Android N 中，將支持分屏情況下 drag and drop，讓這個4.0開始就支持 faeture 煥發了新生。這也就意味著你可以將一個應用內、甚至不同應用間的分屏情況將一個分屏幕控件拖拽到另外一個分屏幕。也許可以用來拖拽圖片快速發圖，或者。。隨便你想干什么。

當然，從開發狗的角度來說，這里有一點安全隱患：如果通過拖拽將數據傳遞過來，你甚至不知道來源是什么。但是想想也是，畢竟用的和粘貼板一樣的接口，還能指望什么呢？

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

此外，給程序員朋友們幾個小貼士

• 雖然分屏狀態下兩個應用都可見，但是對于非 Focus 狀態的應用當前是處于 onStop 狀態的，也就是說，并沒有實際在運行中。原本 onStop 的時候應用應該是不可見，但是現在可見了。。。原本的一些惡心邏輯注意修改下。

• 雖然分屏狀態下的應用不會 double 內存占用，但是內存占用肯定會比正常狀態大，注意分屏模式下即時釋放內存。

• 適配好你的程序，該加 scroll 的地方加 scroll。當然，如果原本的你的程序就已經針對多尺寸屏幕有了處理，就已經完美適配了這個模式

強化通知

通知欄一直是 Android 引以為豪的方面。相對于 iOS 的通知欄來說， Android 的通知欄具有幾乎完爆的功能：自定義控件，自定義 Action，可以定義下來拓展的控件……除了快速回復。

在這之前，先上一段 Android N 新版本的通知欄和快速設置欄，至于為什么放視頻，嗯。。。因為我覺得很好看：點我看視頻

如今，這一點已經被 Google 迎頭趕上，并且體驗絕不亞于 iOS，甚至好很多。

當然，如果一次來了多條消息并且都不是一個會話中，快速回復也是毫無壓力：

這個新特性簡而言之就是滿足了快速回復的一切需求，也許從此再也不用擔心沉浸式閱讀時需要跳出回復消息這種傷害體驗的情況。

當然了，除了快速回復，還有根據應用歸檔通知，這無疑是一個大殺器：

 

 

同時，這里需要同時提醒PM和開發同學的是：如果真的需要在通知上設置自定義控件，請調用DecoratedCustomViewStyle()。它會讓你的自定義控件在通知欄顯得更加和諧。Sample:

Notification noti = new Notification.Builder()

           .setSmallIcon(R.drawable.ic_stat_player)

           .setLargeIcon(albumArtBitmap))

           .setCustomContentView(contentView);

           .setStyle(new Notification.DecoratedCustomViewStyle())

           .build();

『何必這樣，我寫一個BroadcastReceiver監聽CONNECTIVITY_ACTION然后處理不就行了，naive！』

科科。

為了防止這個沒有節操的事情發生，Google 在 Android N中拿掉了這三個廣播：

• CONNECTIVITY_ACTION：網絡變化

• ACTION_NEW_PICTURE：添加新圖片

• ACTION_NEW_VIDEO：添加新視頻

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

當然了，不允許監聽 CONNECTIVITY_ ACTION 針對的是靜態注冊的 BroadcastReceiver，如果是動態注冊的 BroadcastReceiver 則并不會受到影響。

 

Java 8支持

早在前年開始研究 Annotation 的時候，就在感慨為什么 Android 一直不支持 Java 8，即使現在 Java 9 都快出了。終于的終于，Android從N 版本開始支持 Java 8的編譯，前提是要在 Gradle 文件中顯式聲明使用 Jack 編譯器。

這個 Jack 是什么鬼呢？簡單來說，傳統的編譯工具鏈是將 java 代碼通過 javac 編譯成.class 文件，再通過 dx 編譯成 .dex。也就是醬紫的：

javac (.java --> .class) --> dx (.class --> .dex)

而 Jack 則是一條龍服務，中間不需要經過其他工具或者命令，一條命令就可以將.java 文件編譯成.jack 從而編程.dex：

ack (.java --> .jack --> .dex)

使用 jack 非常簡單，gradle 配置即可

android {

  ...

  defaultConfig {

    ...

    jackOptions {

      enabled true

     }

   }

   compileOptions {

    sourceCompatibility JavaVersion.VERSION_1_8

    targetCompatibility JavaVersion.VERSION_1_8

  }

}

不過，Android N 版本的 Java 8特性并沒有支持全，不過主流的 feature 已經支持，包括：

• 定義接口默認實現方法

• Lamda 表達式支持（喜歡語法糖的同學的福利）

• Repeatable annotations。這個已經可以說的內容很多，改天有空給大家慢慢介紹。

• Method Reference。這個實話實說我并不是太了解，也是語法糖一種。感興趣的同學可以看看這個鏈接：https://docs.oracle.com/javase/tutorial/java/javaOO/methodreferences.html

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

此外還需要注意兩點：

• Lamda 表達式本質上回生成匿名類，在性能敏感的模塊慎用

• 由于 Jack 編譯器不會產生.class 中間文件，因此在.class 上做 trick 的一些庫或者項目可能就會失效或者出問題。因此在使用之前，一定要好好測試。

其他應該注意的事項

• Data Saver：乍看上去是一個數據存儲的 API，感覺很興奮，結果點開一看是流量節省。。。好吧，博大精深的英文。從 Android N 開始，系統層級支持用戶針對每一個應用添加自己的流量控制限制。今后開發的時候需要先通過 ConnectivityManager.getRestrictBackgroundStatus() 接口獲取本應用流量控制情況。

• Key Attestation：對于絕大部分應用并不需要仔細研究的 feature，甚至可以當做不存在，但是對于我個人所做的生物認證項目來說，可謂是非常重要的 feature。

• 針對文件目錄或類型申請權限：實話實說，這個也算是一個很重要的 feature。從 Android 6.0 開始，如果需要使用存儲空間，包括讀寫，需要動態申請權限。然而對于大部分應用來說，都需要申請這個權限，而且一旦用戶允許，應用就可以為所欲為。因此，Android N 中允許應用聲明僅僅授權某個文件夾或者文件類型的存儲。

禁止 Native 動態鏈接系統庫

這一點 Android Developer 沒有講，至少暫時沒有講

還記得之前我說的微信升級到 N 會 Crash 么？實際上就是這個原因。

 

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

實話實說，這次 Android N 的更新對于我們程序員來說還是干貨滿滿，滿到我有些話想說。

 

扯淡

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

 

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

 

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

 

個人認為比 Apple 的設計。。。（為了防止引戰）至少并不差吧。

其實，這里說了這么多，精通讀心術的我也能想到大家心中的疑問：碎片化如此的 Android 市場，我們就算是適配了 N 的特性，大家也沒有這么快用上，還是歇著吧。嗯，關于碎片化，首先，Android 目前版本分布是醬紫的（來自 Google 官方，鏈接 http://developer.android.com/about/dashboards/index.html）

也就是說，至少截止到今天，接近40%的人的設備已經是 Android 5.0 以及以上，按照如今廠商發貨的速度，目測一兩個月內比例就會過半。平心而論，針對這半數用戶，有幾家應用做到了完美支持？無論是 UI 還是具體功能，大部分應用應該都是在4.x，甚至2.x版本的基礎上填坑，fix 新版本上的 crash，有幾家用到了新的特性，新的 feature 呢？而大家以為占主流的2.3系統，實際上已經不足3%，是不是仍然有很多應用的 target api 仍然是 4.x 以下？

而且 Google 現在很雞賊啊（這一點謝老大提醒），一年發布一個大版本，前年5.0，去年6.0，今年 7.0，你說 Google 都到 7.0 了你還好意思連 5.0 都不上？這一點實際上對于解決碎片化是非常有幫助的。

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

感謝！

來自：http://www.cnblogs.com/bugly/p/5449705.html