【Bugly乾貨】關於 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:

[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監聽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。也就是醬紫的：

[Java]  純文本查看 複製代碼

?

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

而 Jack 則是一條龍服務，中間不須要通過其餘工具或者命令，一條命令就能夠將.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 已經支持，包括：

• 定義接口默認實現方法
• 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 推出已經接近兩年，儘管有不少應用已經適配，可是包括微信、Facebook、Twitter 在內的不少主流應用仍然在堅持使用本身的設計語言。誠然，這裏有能夠理解的風格統一之考慮， 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 上的應用，低質量的應用實現已經威脅到了咱們自身。不只僅是要依靠產品經理，做爲程序員，咱們也要學會自救。

感謝！

 

若是你以爲內容意猶未盡，若是你想了解更多相關信息，請掃描如下二維碼，關注咱們的公衆帳號，能夠獲取更多技術類乾貨，還有精彩活動與你分享~

 

 

騰訊 Bugly是一款專爲移動開發者打造的 質量監控工具，幫助開發者快速，便捷的定位線上 應用崩潰的狀況以及解決方案。智能合併功能幫助開發同窗把天天上報的數千條 Crash 根據根因合併分類，每日日報會列出影響用戶數最多的 崩潰，精準定位功能幫助開發同窗定位到出問題的代碼行，實時上報能夠在發佈後快速的瞭解應用的質量狀況，適配最新的 iOS, Android 官方操做系統，鵝廠的工程師都在使用，快來加入咱們吧！