一、前言
如果你英文不错建议你去官网看，官网底部也有翻译语言选择。
官网地址:http://developer.android.com/preview/api-overview.html#android_for_work
当然一切的前提是你的电脑能访问外网。。。。天朝你懂的。。。。机智的我所以早早就给你们准备了高级上网工具。
ytb加速器:https://www.ytbyjs.com/
如果你不想这么麻烦，那就看我翻译的版本吧。。。。
1.多窗口MultiWindow
多窗口MultiWindow，这是Android N里对开发者影响比较大的特性，也是大家疑问比较多的地方。站在开发者的角度其实不必太担心这个特性会导致我们需要修改很多代码来适配系统。Google的工程师们也不希望这个特性导致很多应用出现问题，他们更希望的是让应用都能无缝过度到Android N。据他们测试，目前Google市场中Top 200的应用只有极少数会出现在Android N上因为多窗口导致不能正常使用的情况。退一步讲，即使你的应用在Android N的多窗口模式下不能正常运行，可以在manifest中设置resizeableActivity为false，即可禁用多窗口模式，当然在Android N上这个值默认是true.
应用如要支持多窗口，也有一些需要注意的地方，最主要的是分辨率的适配。在多窗口模式下，应用的显示比例不一定是手机屏幕的比例。这里可能会影响到一些代码，比如有的应用一启动就全局存储屏幕的宽高，这在Android N下可能就有问题了，需要开发者做相应的修改。多窗口带来的另外一个问题是对onStart()和onStop()的处理，在多窗口模式下，Activity的生命周期是不受影响的。但是原来进入onStop()后Activity就不可见了，在Android N中却还是可见的，这一点在开发的时候需要考虑到。对于音视频的应用，应该把停止声音播放的代码从onPause()移到onStop()里，在onPause()的时候，由于整个应用对用户仍然可见，音视频播放不应该暂停。
另外值得一提的是画中画功能，画中画按照Google工程师的说法是专门为Android TV设计的。画中画可以使一个Activity在播放视频的同时，在另外一个中Activity进行其它操作。因为很多视频应用都需要做小窗播放的功能，目前的做法基本都是用Window Manager实现一个全局浮窗实现的。为此我和另外一个视频应用的开发者向他们反馈其实在非Android TV平台也很需要这个功能，Window Manager自身也有许多缺点，比如OEM厂商会加入人为的限制，导致浮窗弹不出来，WindowManager只能加入最顶层的RootView。Google工程师回复使用这种方式实现画中画功能其实是对系统的一种Hack，即并非标准的手段，而画中画功能可以提供比较清晰的API，并且他们认为我们提的这点确实是一个问题，他们会把这点反馈到开发团队。
2.对Notification的改进
通知消息分组：比较好理解，同一个组的消息在UI展示上归类到一起；
添加快速回复功能：通知在预览的时候可以直接回复，系统通知栏提供了一个简单的输入区域；
可以选择是否隐藏时间：之前的通知栏都是带时间的，现在可由App自己控制是否需要展现通知消息右下角的时间。
3.省电相关 - Doze和后台任务优化
先说后台任务优化，不知道大家在开发中没有自己去接收过ConnectivityManager这个系统服务的connectivity_change广播，这个广播是用的最广泛的，同时也是最容易被滥用的。如果应用中没有设计一个统一的地方接收系统广播然后在应用内分发，在单个应用内就会有多个监听的情况。由于是系统广播，如果用户打开的App较多，网络发生变化时，系统要唤起App来执行一段代码。但是这时候应用其实不可见的，这里浪费了较多的电量。
类似的场景还有很多，比如使用系统相机拍照后系统会发出NEW_VIDEO或者NEW_PHOTO的广播，如果你的应用现在处于后台，那么接收此类广播其实是无意义的，只会浪费电量而已。
在Android N中，这类广播被取消了！实际上所有的隐式广播(Implicit Broadcast)将来都会逐步取消，在Android N中会先从上文提到的几个广播开始。取而代之的是JobScheduler，JobScheduler是大家把自己关注的事件和对应的操作注册进来，系统会按优先级去调用。如果你的应用在前台，那么你的任务会被运行，如果是后台，那么系统就不会跑你的代码了。这里说的比较通俗，实际系统会制定一定的策略来评估此类情况，更多关于这类广播的信息，可以查看Google的官方说明。
再说说Doze，Doze在Android N上是老树开新花，因为Doze在Android M上就已经有了。Android M上，在系统屏幕关闭且静止不动一段时间后，手机会进入Doze模式，只有极少数服务如GCM和加入了白名单的服务，可以保持运行，其它服务，每隔9分钟会有一个时间窗来执行代码。举个例子，如果你是一个闹铃应用，在不加入白名单的情况下。10:00进入Doze模式，如果闹钟设置在10:09，那么可以响，如果在10:08，对不起，闹钟就不能响了。在Android文档上提到可以用以下方式来申请Alarm不被Doze冻结，不过估计要系统签名的App才会生效，普通App应该是没用的。
注意，在Android M上Doze的触发条件是关屏且静止一段时间。在Android N上把Doze的应用范围扩大了，只要关屏就进入Doze模式，据Google工程师测试这样可以节省电量30%，这个改动对需要在后台做大量工作的应用影响不小。官方给出的解决方案是走Google官方的GCM通道，这个服务有特权不受Doze的影响，但在目前国内环境下这个方案用不了。Google的人说他们会推OEM厂商推出类似GCM的方案。App侧能做的就是提示用户把应用加入白名单，这个方案的成本很高。预计OEM厂商会提供类似手电筒那样的快捷开关，在需要的时候可以把Doze很方便的关闭掉。
Google还开发了battery-historian工具，可以根据系统生成的bug report，分析出详尽的耗电情况，测试同学又多了一个利器。
现场的效果图，用此工具分析进入Doze模式后，电量消耗马上变慢了（黑色曲线）。
4.运行时权限
这个功能并不陌生，国内OEM的系统很多已经做了此功能。Android N这次加上去的是SD卡中内容的权限提示。比如你只需要访问某一个特定的文件夹，在此之前你要申请整个SD卡的读/写权限，据统计会有20%的用户会因此放弃安装你的App. Android N之后，你可以在App运行的过程中申请针对某一个目录的权限。在提问环节，有同学提出只是为了获取IMEI，Android对这个权限的提醒是读取手机的状态，这个权限提醒的太吓人，Google工程师说会把这个意见反馈上去，不过看样子大概率不会修改这里。
5.NDK的改动
NDK的编译也要抛弃Makefile转而采用Gradle；
NDK受限API采用更改Namespace的方式限制第三方调用，调用受限API会导致应用Crash.