不过，Android N 版本的 Java 8特性并没有支持全，不过主流的 feature 已经支持，包括：
但是现在还没有支持一个很重要的特性：Stream。但是现在还在 Preview 阶段，比如刚刚的第四条 Method Reference 就是 Preview2 支持的，可以期待下 release 中是否会支持（最新消息：已经支持 java.util.stream 接口，棒棒的！）。
此外还需要注意两点：
其他应该注意的事项
-
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 时代那个臃肿的、落后的以及。。额，难看的形象。就像这样：
