从上面的连接里面找到了一些资料：
如果一开始就对Android手机的硬件架构有一定的了解，设计出的应用程序通常不会成为待机电池杀手，而要设计出正确的通信机制与通信协议也并不困难。但如果不去了解而盲目设计，可就没准了。
首先Android手机有两个处理器，一个叫Application Processor（AP），一个叫Baseband Processor（BP）。AP是ARM架构的处理器，用于运行Linux+Android系统；BP用于运行实时操作系统（RTOS），通讯协议栈运行于BP的RTOS之上。非通话时间，BP的能耗基本上在5mA左右，而AP只要处于非休眠状态，能耗至少在50mA以上，执行图形运算时会更高。另外LCD工作时功耗在100mA左右，WIFI也在100mA左右。一般手机待机时，AP、LCD、WIFI均进入休眠状态，这时Android中应用程序的代码也会停止执行。
Android为了确保应用程序中关键代码的正确执行，提供了Wake Lock的API，使得应用程序有权限通过代码阻止AP进入休眠状态。但如果不领会Android设计者的意图而滥用Wake Lock API，为了自身程序在后台的正常工作而长时间阻止AP进入休眠状态，就会成为待机电池杀手。比如前段时间的某应用，比如现在仍然干着这事的某应用。
首先，完全没必要担心AP休眠会导致收不到消息推送。通讯协议栈运行于BP，一旦收到数据包，BP会将AP唤醒，唤醒的时间足够AP执行代码完成对收到的数据包的处理过程。其它的如Connectivity事件触发时AP同样会被唤醒。那么唯一的问题就是程序如何执行向服务器发送心跳包的逻辑。你显然不能靠AP来做心跳计时。Android提供的Alarm Manager就是来解决这个问题的。Alarm应该是BP计时（或其它某个带石英钟的芯片，不太确定，但绝对不是AP），触发时唤醒AP执行程序代码。那么Wake Lock API有啥用呢？比如心跳包从请求到应答，比如断线重连重新登陆这些关键逻辑的执行过程，就需要Wake Lock来保护。而一旦一个关键逻辑执行成功，就应该立即释放掉Wake Lock了。两次心跳请求间隔5到10分钟，基本不会怎么耗电。除非网络不稳定，频繁断线重连，那种情况办法不多。
网上有说使用AlarmManager，因为AlarmManager 是Android 系统封装的用于管理 RTC 的模块，RTC (Real Time Clock) 是一个独立的硬件时钟，可以在 CPU 休眠时正常运行，在预设的时间到达时，通过中断唤醒 CPU。
移动互联网应用现状
因为手机平台本身、电量、网络流量的限制，移动互联网应用在设计上跟传统 PC 上的应用很大不一样，需要根据手机本身的特点，尽量的节省电量和流量，同时又要尽可能的保证数据能及时到达客户端。
为了解决数据同步的问题，在手机平台上，常用的方法有2种。一种是定时去服务器上查询数据，也叫Polling，还有一种手机跟服务器之间维护一个 TCP 长连接，当服务器有数据时，实时推送到客户端，也就是我们说的 Push。
从耗费的电量、流量和数据送达的及时性来说，Push 都会有明显的优势，但 Push 的实现和维护成本相对较高。在移动无线网络下维护长连接，相对也有一些技术上的难度。本文试图给大家介绍一下我们在 Android 平台上是如何维护长连接。
移动无线网络的特点
因为 IP v4 的 IP 量有限，运营商分配给手机终端的 IP 是运营商内网的 IP，手机要连接 Internet，就需要通过运营商的网关做一个网络地址转换（Network Address Translation，NAT）。简单的说运营商的网关需要维护一个外网 IP、端口到内网 IP、端口的对应关系，以确保内网的手机可以跟 Internet 的服务器通讯。
图片源自 .&
NAT 功能由图中的 GGSN 模块实现。
大部分移动无线网络运营商都在链路一段时间没有数据通讯时，会淘汰 NAT 表中的对应项，造成链路中断。
Android 平台上长连接的实现
为了不让 NAT 表失效，我们需要定时的发心跳，以刷新 NAT 表项，避免被淘汰。
Android 上定时运行任务常用的方法有2种，一种方法用 Timer，另一种是AlarmManager。
Android 的 Timer 类可以用来计划需要循环执行的任务，Timer 的问题是它需要用 WakeLock 让 CPU 保持唤醒状态，这样会大量消耗手机电量，大大减短手机待机时间。这种方式不能满足我们的需求。
AlarmManager
AlarmManager 是 Android 系统封装的用于管理 RTC 的模块，RTC (Real Time Clock) 是一个独立的硬件时钟，可以在 CPU 休眠时正常运行，在预设的时间到达时，通过中断唤醒 CPU。
这意味着，如果我们用 AlarmManager 来定时执行任务，CPU 可以正常的休眠，只有在需要运行任务时醒来一段很短的时间。极光推送的 Android SDK 就是基于这种技术实现的。
服务器设计
当有大量的手机终端需要与服务器维持长连接时，对服务器的设计会是一个很大的挑战。
假设一台服务器维护10万个长连接，当有1000万用户量时，需要有多达100台的服务器来维护这些用户的长连接，这里还不算用于做备份的服务器，这将会是一个巨大的成本问题。那就需要我们尽可能提高单台服务器接入用户的量，也就是业界已经讨论很久了的 C10K 问题。
针对这个问题，我们专门成立了一个项目，命名为C2000K，顾名思义，我们的目标是单机维持200万个长连接。最终我们采用了多消息循环、异步非阻塞的模型，在一台双核、24G内存的服务器上，实现峰值维持超过300万个长连接。
/pages/viewpage.action?pageId=3309821
稳定维护长连接是推送平台的一个基础，将会在这方面长期投入，以保证用户能有效的节省电量、流量，同时数据能实时送达。
以上是极光推送官方的文章，但是看了之后不免有几个疑问。
1）他们号称最高峰值可以达到300W的长连接，但是活跃链接的处理最高是多少呢？
2）消息的平均长度和限制各是多少？
3）消息的及时性怎么样，延时是多少？
4）不知道现在，极光推送的用户大概有多少，所以这个峰值是在生产环境，还是测试环境的数值？
5）我想不通的是为什么，客户端要用AlarmManager来做推送消息的获取？这个消息获取还及时吗？鄙人结识android也有N载。
6）我感兴趣的是，不是极光方案一个月推送了几百万条数据，而是几秒钟或者一分钟可以处理多少。
Android 消息推送方案
　　当我们开发需要与服务器交互的应用程序时，基本上都需要获取服务器端的数据。要获取服务器上不定时更新的信息，一般来说有两种方法：第一种是客户端使用pull（拉）的方式，隔一段时间就去服务器上获取一下信息，看是否有更新的信息出现；第二种就是服务器使用push（推送）的方式，当服务器端有更新，则将最新的信息push到客户端上，如此以来，客户端就能自动地接收到消息。
　　虽然pull和push两种方式都能实现获取服务器端数据更新的功能，但pull方式的弊端很明显：费流量、费电，需要我们的程序不停地去监测服务器端的更新。
　　首先可以来了解一下iOS和Android平台的推送机制：
　　iOS 系统的推送（APNS，即 Apple Push Notification Service）依托一个或几个系统常驻进程运作，是全局的（接管所有应用的消息推送），所以可看作是独立于应用之外，而且是设备和苹果服务器之间的通讯，而非应用的提供商服务器。比如腾讯 QQ 的服务器（Provider）会给苹果公司对应的服务器（APNs）发出通知，然后再中转传送到你的设备（Devices）之上。当你接收到通知，打开应用，才开始从腾讯服务器接收数据，跟你之前看到通知里内容一样，但却是经由两个不同的通道而来。
　　Android的推送有两种形式，一种是后台Service，一种是GCM
　　不过这里要指出的是，Android的这种形式和传统电脑还是有区别的，电脑的后台是保持程序进程在后台运行，而Android是在程序后台Service区域添加一个新的程序专门接收数据。
　　要说的话，Android的后台推送机制更加复杂，但是因为可操控部分更多，加上GCM是在2.X之后才加上的而且有可能在系统中并不存在，所以很多软件都是使用Service这种形式。
　　本质上，APNs 与 GCM 是类似的技术实现原理：即系统层有一个常驻的 TCP 长连接，一直保持的长连接，即使手机休眠的时候也在保持的长连接。这里对于大部分人来说，最不理解的就是，休眠时候都保持在那里的&TCP&长连接，不会耗电很厉害么？
　　答案是：不会。这是手机的设计来做到的。TCP长连接有个心跳的时间，在国外可以很长比如30分钟，在国内则因为网络环境复杂一般10分钟。客户端发起的心跳，会短暂地消耗手机电能，但在这个心跳间隔期间，则消耗电能是很少的。当在心跳期间服务器端有推送信息过来时，客户端可以收到并做处理。
　　这里有篇文章以 Android 为例做原理解释：
　　/jpush_wireless_push_principle/
　　极光推送技术原理：无线网络长连接
　　再说 APNs 的设计成功处。
　　iOS 为了真正地为用户体验负责，不允许应用在后台活动。有了这个限制，但是对于终端设备，应用又是有必要&通知&到达用户的，随时与用户主动沟通起来的（典型的如聊天应用）。
　　这就是 APNs 的逻辑所在：iOS 自己做个长驻后台保持连接。所有应用，有必要（申请）并且被允许（用户可以改设置）的话，可以通过 APNs 中转到达用户。
　　Android 因为后台可以长驻，尤其是国内的 Android 的手机上 Google自家的推送服务 GCM 处于基本不可用的状态。所以，各App各显神通。聊天类应用的话，大多数直接借用 XMPP 规范里的一些成果。少量如微信有IM底子的，自己开发协议。这些在实现原理上与 APNs / GCM 没有本质的区别，但有一定的技术门槛。而大多数普遍应用，要使用推送的话，则使用轮询的方式简单实现。
　　其实，国外如 Urban Airship 自己实现了 Android 上的第三方提供的推送平台。国内如极光推送也实现了第三方的推送平台（技术与微信、GCM、APNs类似）。理论上，如果一个 Android 设备上多款应用都使用极光推送这种第三方推送平台的话，也可以如 APNs 一样达到节省电量、流量消耗的效果。
　　另可参考Android实现推送方式解决方案
在开发的过程中，我们经常用到的WIFI在休眠情况下默认是会不连接的，这个时候当我们需要保持连接时，该如何解决
&&&&&&& 不少人说可以在设置的WIFI高级选项中将连接设为休眠保持连接，这个办法的确可行，对于开发者来说很容易办到，但是对于用户来说他们一般不会知道这么设置，这个时候该怎么办呢？可以使用如下代码解决
[java]public void WifiNeverDormancy(Context mContext)&{&&&& ContentResolver resolver = mContext.getContentResolver();&&&& int value = Settings.System.getInt(resolver, Settings.System.WIFI_SLEEP_POLICY,& Settings.System.WIFI_SLEEP_POLICY_DEFAULT);&&& final SharedPreferences prefs=PreferenceManager.getDefaultSharedPreferences(mContext);&&&&&&& Editor editor = prefs.edit();&&& editor.putInt(mContext.getString(R.string.wifi_sleep_policy_default), value);&&&&& mit();&&& if(Settings.System.WIFI_SLEEP_POLICY_NEVER != value)&&& {&&&&&& Settings.System.putInt(resolver, Settings.System.WIFI_SLEEP_POLICY, Settings.System.WIFI_SLEEP_POLICY_NEVER);&&&& }&&& System.out.println("wifi value:"+value);&}&
&public void WifiNeverDormancy(Context mContext)&{&&ContentResolver resolver = mContext.getContentResolver();
&&& int value = Settings.System.getInt(resolver, Settings.System.WIFI_SLEEP_POLICY,& Settings.System.WIFI_SLEEP_POLICY_DEFAULT);&&& final SharedPreferences prefs=PreferenceManager.getDefaultSharedPreferences(mContext);&&&&&& Editor editor = prefs.edit();&&& editor.putInt(mContext.getString(R.string.wifi_sleep_policy_default), value);
&&& mit();&&& if(Settings.System.WIFI_SLEEP_POLICY_NEVER != value)&&& {&&&&&& Settings.System.putInt(resolver, Settings.System.WIFI_SLEEP_POLICY, Settings.System.WIFI_SLEEP_POLICY_NEVER);
&&& }&&& System.out.println("wifi value:"+value);&}上面这个函数，会自动修改我们WIFI设置中的高级选项，将其设置为一直保持连接。不用使用其他控件就可以解决。
需要注意的是此函数在调用时必须现在AndroidManifest.xml中声明权限
&&uses-permission android:name="android.permission.WRITE_SETTINGS"/&
在开发Android应用中，有很大一部分app是要求手机一直处于网络环境中的。在Android&设置--&&WLAN&--&点击菜单键&选择&高级&--&休眠状态下保持WLAN连接的下拉列表{始终、仅限充电时、从不(会增加数据流量)}这个设置项中，很多用户并不知道这个选项的存在，如果设置不为始终，那么我们锁屏休眠后，程序将会处于无网络状态，相应的app用户会一直处于离线模式，那么带来的效果可想而知。
那么我们开发中，应对这种情况，我们可以在程序首先开启时，读取这个值，保存起来，待程序退出时，将原先保存的值还原，这样可以很好的解决上述这个问题。
在Android&API中这样描述：
public&static&final&String&WIFI_SLEEP_POLICY
Since:&API&Level&3
The&policy&for&deciding&when&Wi-Fi&should&go&to&sleep&(which&will&in&turn&switch&to&using&the&mobile&data&as&an&Internet&connection).
Set&to&one&of&WIFI_SLEEP_POLICY_DEFAULT,&WIFI_SLEEP_POLICY_NEVER_WHILE_PLUGGED,&or&WIFI_SLEEP_POLICY_NEVER.
Constant&Value:"wifi_sleep_policy"
那么我们在开启应用时，首先取出这个值，上代码：
private&void&setWifiDormancy(){
&&&int&value&=&Settings.System.getInt(getContentResolver(),&Settings.System.WIFI_SLEEP_POLICY,&&Settings.System.WIFI_SLEEP_POLICY_DEFAULT);&&&final&SharedPreferences&prefs&=&getSharedPreferences(getString(R.string.wifi_sleep_policy),&Context.MODE_PRIVATE);&&&Editor&editor&=&prefs.edit();&&&editor.putInt(getString(R.string.wifi_sleep_policy_default),&value);&&&&mit();&&&if(Settings.System.WIFI_SLEEP_POLICY_NEVER&!=&value)&&&{&&&&&&Settings.System.putInt(getContentResolver(),&Settings.System.WIFI_SLEEP_POLICY,&WIFI_SLEEP_POLICY_NEVER);&&&}
在应用退出我们需将这个设置的值还原：
private&void&restoreWifiDormancy(){&&&final&SharedPreferences&prefs&=&getSharedPreferences(getString(R.string.wifi_sleep_policy),&Context.MODE_PRIVATE);&&&int&defaultPolicy&=&prefs.getInt(getString(R.string.wifi_sleep_policy_default),&Settings.System.WIFI_SLEEP_POLICY_DEFAULT);&&&Settings.System.putInt(getContentResolver(),&Settings.System.WIFI_SLEEP_POLICY,&defaultPolicy);}
这样初始设置，退出还原我们可以让应用一直处于wifi模式下（不过前提是有wifi网络哦）。
from：&.cn/s/blog_a85b30ff0101ahzd.html
首先看一下Android&Powermanager&Class&Overview，对Android的几种不同的休眠模式有个大致了解。
如果不进行特别的设置，Android会在一定时间后屏幕变暗，在屏幕变暗后一定时间内，约几分钟，CPU也会休眠，大多数的程序都会停止运行，从而节省电量。但你可以在代码中通过对Powmanager&API的调用来设置不同的休眠模式。
Flag&Value &&&&&&&&CPU Screen KeyboardPARTIAL_WAKE_LOCK On* Off OffSCREEN_DIM_WAKE_LOCK On Dim OffSCREEN_BRIGHT_WAKE_LOCK On Bright OffFULL_WAKE_LOCK &&&&&&&&On Bright Bright
如上表，最高等级的休眠是屏幕，键盘等，cpu都全部休眠。可以设置不同的模式，让其产生不同的休眠，比如让cpu保持运行。设置代码如下：
PowerManagerpm&=(PowerManager)getSystemService(Context.POWER_SERVICE);
PowerManager.WakeLockwl&=pm.newWakeLock(PowerManager.SCREEN_DIM_WAKE_LOCK,"My&Tag");
wl.acquire();
..screen&will&stay&on&during&thissection..
wl.release();
我曾经遇到的几个坑点及解决：
1.向服务器轮询的代码不执行。
曾经做一个应用，利用Timer和TimerTask，来设置对服务器进行定时的轮询，但是发现机器在某段时间后，轮询就不再进行了。查了很久才发 现是休眠造成的。后来解决的办法是，利用系统的AlarmService来执行轮询。因为虽然系统让机器休眠，节省电量，但并不是完全的关机，系统有一部 分优先级很高的程序还是在执行的，比如闹钟，利用AlarmService可以定时启动自己的程序，让cpu启动，执行完毕再休眠。
2.后台长连接断开。
最近遇到的问题。利用Socket长连接实现QQ类似的聊天功能，发现在屏幕熄灭一段时间后，Socket就被断开。屏幕开启的时候需进行重连，但 每次看Log的时候又发现网络是链接的，后来才发现是cpu休眠导致链接被断开，当你插上数据线看log的时候，网络cpu恢复，一看网络确实是链接的， 坑。最后使用了PARTIAL_WAKE_LOCK，保持CPU不休眠。
3.调试时是不会休眠的。让我非常郁闷的是，在调试2的时候，就发现，有时Socket会断开，有时不会断开，后来才搞明白，因为我有时是插着数据线进行调试，有时拔掉数据线，这 时Android的休眠状态是不一样的。而且不同的机器也有不同的表现，比如有的机器，插着数据线就会充电，有的不会，有的机器的设置的充电时屏幕不变暗 等等，把自己都搞晕了。其实搞明白这个休眠机制，一切都好说了。
Views(...) Comments()徘徊在安卓 7.0 的手机厂商，距离安卓 8.0 到底有多远？-ZAKER新闻
谷歌在 5 月 17 日举办 Google I/O 大会，将发布安卓 8.0 操作系统，也就是 Android O" 奥利奥 "。这一代安卓 8.0 可能会对国内手机厂商之间的竞争产生一定的影响，但考虑到安卓碎片化的问题，国内手机厂商面对安卓 8.0 的情绪会五味杂陈。安卓 8.0 可能会成为主宰 2017 年手机市场的重要砝码，因为从后台机制的改进来看，是安卓历史上的一次飞跃。一方面安卓 8.0 对于内存机制的管理和前几代产品又有改变，系统流畅度提升将是必然的。而另一方面，由于安卓碎片化的问题，很多厂商至今没有升级安卓 7.0，更没办法抽出资源来适配安卓 8.0。那么，徘徊在安卓 7.0 的手机厂商，距离安卓 8.0 到底有多远？安卓 8.0 可能会成为安卓历史上的又一个里程碑根据目前的消息来看，安卓 8.0 可能会是安卓历史上的又一个里程碑。安卓历史上的重要改进几乎都和后台机制有关。安卓 5.0 第一次加入了 ART 模式，让应用流畅度又了质的飞跃。安卓 6.0 中采用了 Doze 休眠机制，只要手动在后台删掉应用卡片，关屏后该应用就会被很快深度休眠。在安卓 7.0 上，谷歌对其进行了进一步的改善。也正是经过了这三代改进，今天的安卓和 iOS 相比，在流畅度上几乎没有太多差异。但是不可否认，安卓手机的耗电量依旧很大，一些应用会莫名占用大量资源，而且依然会发生一些幽灵般的卡顿，让人在一些场合，比如说付账时、扫别人微信时，时不时尴尬一下。在 Android 8.0 中，谷歌又加入了新的后台管理机制规定——当应用进入后台几分钟后就会进入停滞状态，虽然进程没有被杀掉，但将不再占用包括计算、内存、通信等在内的系统资源，也将不再频繁地发送和获取 GPS 位置更新，起到省电的效果。这一机制和前几次大版本更新还不一样，因为不再占用系统资源这个做法会让前台应用的流畅度得到大幅度提升，也会带来比过去更好的省电效果。特别是在这次 Google I/O 大会之前，国内一位名为陈辰臣的源码大神在他的个人论坛上称，用模拟器实测安卓 8.0 发现，后台会在 1 分钟左右后被 kill 掉。他还称，据 Google 工程师透露，Google 的目标是充满一次电，手机可用 2~3 天，这也可看到 Google 在手机续航方面的努力。由此可见，安卓 8.0 给安卓手机带来的体验将是飞跃式的，尤其是在续航以及流畅度层面上更是如此。为何大部分国产手机厂商依旧徘徊在安卓 6.0 时代安卓 8.0 改进如此之大，但真正愿意采用这一系统的手机厂商还是少数，据腾讯科技报道，今年 5 月最新数据显示，安卓 7.0/7.1 的市场占有率仅为 7.1%。反观即使是五年前诞生的 Jelly Bean 操作系统（4.1、4.2 和 4.3），现在依然手握 9.1% 的市场份额，而安卓 4.4 和安卓 6.0 则分别占有 18.8% 和 31.2% 的市场份额。排在第一的还是安卓 Lollipop（5.0 和 5.1），其市场份额高达 32%。国内大部分手机厂商依旧徘徊在安卓 5.0、6.0 时代，和安卓 7.0 无缘，即使是今年发布的新机，很多手机厂商依然还在采用安卓 6.0，而非安卓 7.0。很多国内厂商对采用最新安卓定制系统这件事并不感冒，原因主要是两点：1、采用定制操作系统的厂商很多，理论上说，那些对系统底层和 UI 修改越多、定制越多的厂商，愿意腾出开发人员去解决的就越少。像国内几乎所有手机厂商都或多或少对安卓进行了深度定制，而且新系统适配手机很多底层代码都需要重新写，很多手机厂商几乎抽不出精力来应付新系统。2、国内应用开发环境和国外大不一样，国内毒瘤应用太多，经常全家桶式的相互唤醒，造成资源消耗和卡顿。所以经常出现一台手机全装国外应用时跑的飞快，而装上国内应用则卡成 PPT 的问题。所以手机行业几乎有这样一种不成文的规律——如果说安卓最新版系统是安卓 X，那么最新发布的旗舰机永远都是安卓 X-1 系统，上一代旗舰在一年后会象征性的升级 X-1 系统。其他产品线的手机则永远与最新系统无缘。所以你会发现，安卓新系统发布时，市面上大部分手机都和最新系统相差 2 个版本号。但是要知道，在安卓 7.0 时代，华为就是最积极的厂商，去年 11 月 , 华为 Mate 9 预装 EMUI 5.0 问世，成为国内首款、同时也是全球最早一批吃上安卓 7.0 的机型，在今年 3 月，华为 P10 预装 EMUI 5.1。在 EMUI 5.0/5.1 上不仅仅是采用了安卓最新的内存管理机制，而且还用上了 Machine Learning 人工智能学习系统，更有效的提高缓存管理。华为之所以愿意投入精力去紧跟最新的安卓系统，其原因主要还是两点。1、华为本身具备很强的研发能力和适配能力，最新版安卓系统的新特性尤其是在后台机制上的新特性会给手机体验带来很大的提升。这对于提升消费者的实际体验来说帮助很大。2、华为在新版本的更新中尝到了甜头，特别是 Mate9 搭载安卓 7.0，带来了 " 极速流畅、革新体验 "，解决了安卓手机卡顿难题，在性能、交互、用户体验方面实现了大提升，也的确得到了市场的正向反馈。华为在手机操作系统领域所作的创新和努力得到了回报。安卓 8.0 可能会成为主宰 2017 年手机市场的重要砝码从目前的信息来看，安卓 8.0 可能会成为主宰 2017 年手机市场的重要砝码，因为从后台机制的改进来看，是安卓历史上的一次飞跃。笔者看来，国内手机行业可能因为安卓 8.0 带来这几点影响。1、手机厂商的产品研发、系统适配进行受到用户舆论影响当年安卓 4.4 时代向安卓 5.0 跃进的时候，也是一次历史飞跃。安卓 5.0 因为采用了 ART 模式第一次有了和 iOS 比拟流畅度的基础。当年各大手机论坛几乎都上演了同一幕——粉丝们集体询问自己的手机设备什么时候能吃上安卓 5.0，甚至又很多爱好者不断发起投票，逼宫手机厂商升级安卓 5.0。当时这一情况也影响了很多手机厂商的产品开发以及市场口碑，案例可谓数不胜数。小米当年在 MIUI6 的开发过程中没有采用安卓 5.0，结果新系统发布时依旧搭载着安卓 4.4.4，也正是在那一年 MIUI 市场口碑受到了很大的冲击。而锤子的坚果手机发布时也采用的是安卓 4.4，结果被评测圈集体吐槽。安卓大版本号的更新经常会影响到国内深度定制系统的开发进程以及新款智能手机的研发节奏。因为每一家手机厂商的用户都希望能够用上搭载安卓最新系统的旗舰机。不过事实证明，能做到这一点的手机厂商真的少之又少。2、华为去年在安卓 7.0 上的成功案例，可能会形成示范效应不过，华为去年在安卓 7.0 上的成功案例，可能会在国内手机市场形成示范效应，华为去年的旗舰机 Mate9 在搭载的 EMUI5.0 及时吃上了安卓 7.0，流畅度、续航都因此得到了提升，很受市场欢迎。这个成功案例会成为国产手机厂商的榜样，让更多手机厂商投入到安卓 8.0 的适配之中。要知道，去年华为在安卓 7.0 发布后就不断投入精力和自家硬件进行适配，目的就是为了赶上 Mate9 的发布。而在安卓 8.0 发布之际，有媒体曝出华为已在跟进安卓 8.0 做适配工作，希望在下半年的旗舰机上搭载这一系统。尽管该消息并没有得到证实，但也可以看出，今年或许会有更多手机厂商及时注意到安卓 8.0 的动向并积极跟进。3、国内安卓生态圈的碎片化效应以及无序应用开发的情况或许会有所改善华为为了让最新版本的安卓在国内能够顺利适配，也在做一些自身义务之外的事情。去年华为就联合了腾讯、阿里、百度、网易等互联网公司成立了安卓绿色联盟，试图以软硬结合的方式解决安卓系统的一些固有问题，联盟起草制定了兼容性、稳定性、性能、功耗、安全五大标准。这个做法恰恰是在敦促国内开发者按照标准开发应用，这也是为其他手机厂商铺平了道路，让其他厂商更有动力投入到安卓 8.0 的适配之中，毕竟过去谷歌的系统做的再流畅，一到国内就被 " 全家桶 " 毒瘤摧毁，手机厂商没有太多动力跟进新系统适配。这对于缓解安卓碎片化问题，提升用户体验，让安卓生态趋于统一将有很大的帮助。也会在很大程度上改变应用开发者无序开发应用的习惯，进而推动应用开发的标准化。
相关标签：
原网页已经由 ZAKER 转码排版
动点科技1小时前
砍柴网33分钟前
砍柴网19分钟前
砍柴网19分钟前
砍柴网19分钟前
砍柴网19分钟前
砍柴网47分钟前
砍柴网33分钟前
砍柴网33分钟前
砍柴网12分钟前
猎云网1小时前
亿邦动力网1小时前
亿欧网2小时前
亿欧网3小时前
36氪4小时前}