安卓手机aot怎么解除绑定

① 安卓7.1有哪些新功能 安卓7.1系统新功能介绍

1、分屏多任务

其实这个功能，之前不少厂商已经做了，而谷歌终于让7.0原生支持了它，从实际体验来看，户点击多任慧弯清务按键后，长按其中一个应用，将其拖拽到屏幕顶部或底部，然后再点击另外一个应用就可以实现分屏多任务功能。

2、“Data Saver”

这个功能简单来说就是减少App在后台流量偷跑，用户可以设置黑名单，当Data Saver开启后，这些黑名单中的App将会受到流量限制措施，同时谷歌也减少一些图像传输的分辨率，限制移动流媒体服务的码率，限制一些软件的预缓存功能（自动读取用户并未请求的数据）。

3、号码拦截

谷歌还在新系统中加入了号码拦截功能，用户可以更好拦截诈骗分子、营销电话以及其他骚扰电话，而被封杀的电话号码，将无法来电或者发送短信。

4、更便捷的通知中心

谷歌让7.0系统的通知中心变的便捷且更强大，为了让用户节省更多的时间，首先下拉通知栏中最上方加入了快捷按键控制开关，同时通知中心能显示更多的信息，其次用户可以在通知中心内快速回复消息（免去再打开相应应用的繁琐步骤了），最后就是消息的归拢（就是同一个应用的通知变成“通知组”），如当你收到4封邮件，通知中会一一为你展现，你可以挨个或者分批处理（也可以类比QQ消息），很是方便。

5、夜间模式

准确来说，这并不是一个新闹高功能，6.0预览版中有，但正式版谷歌给剔除了，现在它又回来了。跟之前不太一样的是，这次的夜间模式被放在了系统UI设置中，打开后系统会根据环境自动开启。

6、增强的Java 8语言支持

7、画中画模式

这个画中画的展现方式跟iOS 9上的基本一致，不过安卓的这个主要是针对电视平台的，当然如果用户不喜欢屏前前幕平分显示的话，可以将其中一个窗口调整到设定的最小值。

② Android7.0怎么样安卓7.0有什么新功能

1.主题皮肤管理器
在CM等一众第三方系统中，早已支持便捷地修改壁纸、图标和系统颜色。在商店和论坛中，也能找到不少优质的皮肤主题。
而当我们提到原生Android，似乎总是长着一张固定的脸。实际上，在Google自家的AOSP(即Android开源项目)中，早已内置了主题管理。
而在Android M 的开发者预览版中，也加入了主题管理器(可惜被需要Root和特定方式才能激活)。既然系统内的皮肤主题框架早已搭建好，那就只等Google在Android系统中放出啦。

2.应用程序抽屉的消失
在2月26日，Google Map的官方Twitter发布了一条介绍视频，其中的展示机Nexus 6P的系统界面中，似乎看不到底部的应用抽屉按钮了。发现问题的同学也开始集体留言质问：‘WHERE IS THE APP DRAWER?!?!’

而在之前也确实有传闻爆料：在新版Android N 中，或许会将应用抽屉的设计去除，选择采用iOS和MIUI的应用呈现方式，即全部在桌面首页中展示。
去除二级菜单的做法，会带来更加凌乱的桌面，还是更有效率的操作体验?似乎很难定论，但作为Android玩家，大可选择Nova启动器等优秀的第三方桌面，而不必担心我卓药丸。
3.夜间模式会许要来了
在Android M 的开发者预览版中，Dark Mode夜间模式曾短暂地出现过，而在正式版中又被砍去。
而最新的Android N 泄露图中，黑色背景的右图也表示着：夜间模式回归Android了。

而更加值得期待的是，Google已经放出了夜间模式的开发代码，开发者可以轻松地为自己的应用设定‘暗色主题’。也许今后只需轻按‘夜间模式’的按钮，从系统到各个应用，都能直接更换成夜间模式。

这一改变，不仅对于越来越多AMOLED屏幕手机而言，是省电的好方法。对于经常深夜玩手机的同学来说，似乎也可以和刺眼的白光说再见了。
4.分屏多任务以及平板支持
在LG和三星都推出了‘分屏模式’后，Google在Android N 中加入分屏功能也是众望所归了。同样的，在上一个版本Android M 中，分屏模式也被隐藏起来，需要特定方式才能激活。
不负众望，来自Google的Pixel C 团队在接受Reddit AMA论坛访谈时，确认了‘split screen is in the works’。

而分屏多任务，似乎在Android平板上也更加适用。值得一提的是，该团队也宣称Android系统的平板，在Android N 中将会更加好用，而不仅仅是将应用界面拉升就够了。
但对于Chrome OS的联动猜想、DPI切换和和界面的调整，似乎只能等Google I/O那
天，才知道答案。
5.支持触控笔
在三星公布的文档中，我们发现三星在Android N 中，采用了系统自带的触控笔接口，而不再使用原先的S PEN专属接口。
而在Android 5.0 (开始支持节电助手)之前，三星关闭了自家的节电模式接口。在Android 6.0 (开始支持指纹识别)之前，又关闭了自家的指纹识别接口。而在Android 7.0公布之前，三星又再一次关闭了自家的触控笔接口，这……

6.更好的Doze省电模式
Doze省电模式首次出现在Android M 中，其省电原理是在设备休眠时，关闭关闭应用后台，以达到省电的效果。
在亲身体验后，Doze模式确实发挥了很好的效果，起码待机的时候不掉电了。但在目前这一功能，在操作体验和用户自定义方面，却有些过于简单了。
所以直到今天Android 6.0，我依然选择绿色守护等第三方应用，去实现控制后台应用耗电的问题。但Root终归有风险，而Android N 也有理由提供一个更好用的Doze省电模式。

7.重新设计的通知栏
在设计上，似乎能探寻的蛛丝马迹，则是一张Android N 的通知栏模拟图，国外媒体Android Police在看到开发样机图后，大致模拟出的新版界面截图。
根据爆料，左图通知栏目前已开始尝试承载更多的信息量，长按后即可查看通知详情。而在右图显示的快速设置页面，将快捷按钮铺满并支持分页，而不像之前只支持固定数量的快捷按钮。

8.更多玩法的指纹识别
随着Nexus 5X和Nexus 6P的发布，Google终于开始为Android提供指纹的支持。在Android 6.0中，关于指纹的接口也正在逐步完善。
在目前看来，似乎指纹最常用也仅限于Play Store和锁屏应用中。期待在Android N 中，能通过指纹解锁完成更多的事情，在iOS的Touch ID上，有许多值得借鉴的场景。也许之后Androidi用户能通过指纹，便捷地查看Google相册中的隐私图片，或者直接解锁启动私人应用。
9.为虚拟现实助力
我们知道，Google正尝试着于打造一款，不需要额外硬件的头戴式VR设备。
而反观目前市面上大部分VR产品，软件部分的开发似乎都与Android系统多少有些联系，也许Google自家的VR设备也需要Android的支持。

所以我们有理由相信，Google会为新版本的Android系统，在VR方向上提供更多系统层面的支持。
10.Now on Tap
Now on Tap作为Android M 的重磅功能，在去年收获了业界好评。大致功能则是基于不同情景而直接提供对应信息，通过识别你正在运行的app中的内容，提供针对性的建议和资料。
比如在网上聊天时，当聊到某部电影时，只需上滑Home键，关于电影的所有信息就能直接呈现。

而在Android N 中，我们期待它能发挥更大用处。毕竟Now on Tap中‘上下文感知’和‘基于情景’都是是人类智能的重要能力。
也许之后当我们打开相机，它就能为你找寻镜头中包含的关键信息。而不仅限于设定日历提醒，或者帮你搜索维基网络那么简单。

综上所述的大部分内容，都是我们作为Android老粉丝的期待和猜想。所有一切都要等到Google I/O 2016才会揭晓。
但不得不说的是，虽然在AppSo年度精选的Android榜中，绝大部分应用都采用了Material Design，但是直到今天，这一设计风格在动效和交互上，依然缺少一个完美的榜样。
我们不会期待Android N 完全改头换面，带来全新的界面，但在图标、按钮、交互动画和界面设计上，我们期待Google能做得更好。

③ 此时此刻，鸿蒙时刻——再说华为鸿蒙系统的那些事儿

2021年6月2日，对于华为和很多关心华为的人来说，都是一个重要的日子，因为千呼万唤的华为鸿蒙操作系统（HarmonyOS）正式发布，虽迟但到。就像HDC 2019上鸿蒙初次发布那样，准随着它的争议从未消失，且更随着手机鸿蒙系统的推出在即，有愈演愈烈之势。

在HDC 2019之后，我曾写过一篇《关于华为鸿蒙系统的那些事儿》的文章，此时此刻，我觉得是时候再说说华为鸿蒙系统那些事儿了——虽然我知道，在这个当口，写这样一篇文章很可能给我自己挖一个大坑……

不搞懂Android，你就看不懂鸿蒙

关于鸿蒙的最大争议点无非就是：“HarmonyOS是不是套壳Android？”要说不是，不服气的人肯定大把，要说是，那也一样不得了，那就一层层地说清楚。首先，让我们看看Google手中的Android操作系统是怎么回事。

回顾一下Android操作系统的起源。它是由知名IT人Andy Rubin于2003年10月成立的Android公司推出的产品，其本身是基于Linux内核开放源代码的操作系统；2005年8月，Google收购了Android公司；2007年11月，Android操作系统首次亮相，同时Google宣布以Apache免费开源许可证的授权方式，发布Android的源代码，Google牵头的OHA也正式创立（OHA，Open Handset Alliance，该组织最初由34家手机制造商、软件开发商、电信运营商以及芯片制造商共同组成）；2008年9月，Android 1.0版本正式推出，首款Android智能手机G1发布，宣告了一个新的时代开启。现在，Android操作系统已经成为智能手机市场第一大操作系统，也广泛使用在智能手机之外的很多设备上。

Android的起源和开源两个字分不开。是的，Android系统底层所使用的Linux内核，是必须遵照GPL协议进行开源传播的(GPL协议，General Public License，简称GPL，通用性公开许可证)。这个协议中的一项原则就是：确保软件自始至终都以开放源代码形式发布，保护开发成果不被窃取用作商业发售。

因此，采用Linux内核的Android操作系统，也不能违反这个协议， 前边提到的Android免费开源许可证授权，就是指Google要向使用该操作系统的智能手机厂商提供开放的源代码，即AOSP（Android Open Source Project），但这部分源代码并不代表“Android”操作系统的全部。

Google当初看上Android，可不是想要将这个开源系统作为一个免费的“慈善”项目来推动，而是在意Android这个平台的商业化潜力。于是，在收购了Android系统之后，Google就按自己的设想打造Android系统，即在开源代码的部分之外，基于自家在移动互联网上强大的控制力，把Gmail、Maps、Google Play、YouTube、Chrome这些我们耳熟能详的应用服务整合为GMS（Google Mobile Services）服务包植入，从而形成了这个系统的核心竞争力—— 简单理解Android系统的本质，就是AOSP+GMS的合体。

换句话说，智能手机厂商可以自由使用AOSP提供的免费源代码进行自家操作系统的开发，但想要卖得好，拥有更多的用户，却离不开GMS包含的应用，在Android的商业模式中，Google有一套严格的机制在免费开源与付费授权之间取得平衡的。

之前有数据显示，从2008年~2016年间，Android操作系统为Google供贡献了高达310亿美元的营收，而利润更是高达220亿美元，也就是说，数以亿计的搭载Android操作系列和GMS服务包的智能硬件们，都成为了Google帝国的现金奶牛。

只是，Google这个庞大的商业帝国，却总有不能企及的地方——中国大陆。早年因为不愿意服从法律监管，Google几乎将整个互联网服务都移出了中国大陆市场，但是Android操作系统却随着移动互联网和智能手机的发展，在中国市场壮大。

这里有一个非常有意思的现象：因为Google不能在中国提供服务，中国的智能手机厂商们，早就习惯了自主开发没有GMS，但又包含完整本地化服务的自主UI，但因为要面向全球市场，所以又会在自主UI中保留Google GMS框架，这样就可以在海外市场很方便地接入GMS并激活一系列的服务。

因为GMS服务不能进入中国大陆市场，手机厂商们会在这个基础上接入很多自己的服务，比如应用商店、主题商店、内容、支付、推送等，可是没有Google Play的应用审核机制，国内的软件生态是啥样大家都看到的，到最后手机厂商自己都受不了了，才有了“统一推送联盟”、“软件绿色联盟”之类的组织，且随着国家监管力度的加强，现在已经好多了。

随着Android的市场地位越来越强，Google也开始做一些小动作——毕竟这家公司的口号在2015年就从“Do not be evil”变成了“Do the right thing”。如将一些关键特性和重要代码的更新放入GMS包的版本迭代中，比如部分组件、驱动等，有意拉开Android与AOSP的代数差距，从而凸显自己的地位，进一步强化对Android生态的控制力。所以，为了能让自家的UI能有更强的市场竞争力，智能手机厂商们对Android的魔改从来就没有停止过。

回到华为。2019年5月16日，华为被美国商务部列入实体清单，被视为美国对华为终极打压的开始，首当其冲的就是销往全球的华为新款手机不能再使用Android系统。

是的，华为的确是不能使用Google的Android操作系统了，但更具体的描述应该是： “华为不能在自家手机新品中内置GMS服务，但AOSP源代码的使用丝毫不受影响”， 而非那段时间盛传的华为手机从此变砖。但是，无法内置GMS，对于华为手机在全球市场的销售影响是实实在在的，但好在对于系统本身进化影响并不大——现在让我们来到第二个话题：“华为掏空Android。”

华为真的掏空了Android？

华为是否掏空了安卓？这应该是每过一段时间就会被拉出来遛一圈儿的问题。其实在我看来， 答案：是也不是。为什么说不是？因为AOSP还在呢，华为从来没有说过要排斥这个开源项目的，毕竟在这个软件生态上运行着数以百万计的应用，真要把这个掏了，难不成华为要自己做一个全新的软件生态，脑子抽了还差不多。为什么说是？因为华为对Android操作系统的改变也是真实的，很多谷歌做的东西，很多都被华为自己的东西替代了。

这个涉及一个主角， 即EMUI，华为自主开发的UI，或者说两个主角也行，EMUI+HMS。 在这其中，现任华为消费者BG软件部总裁王成录王博带领的EMUI团队显得尤其重要，从他2016年加入这个团队之后，EMUI的根本性改变就发生了，用他的话说：“EMUI不仅仅是一个UI，而是一个平台。”EMUI是如何从UI变为平台的呢？简单梳理一下：

-EMUI 4.X时代，主要的变化还只是TEE OS（即用于指纹的TustZone）以及SensorHub这样基于硬件功能的模块上；

-EMUI 5.X时代，这是一个战略级别的关键版本。解耦Android底层组件，精简各子模块。虚拟机在这个版本也得到了优化，特别涉及了垃圾回收机制（GC）、AOT（运行前编译）、数据库优化（IO并行）等。在这个版本，新的文件系统F2FS（针对闪存推出，大幅度减少文件碎片），还有UltraMemory（即4GB运存达到友商6GB运存效果）的推出，通过对各个Android底层技术模块的深度开发，让EMUI团队敢于将“十八月不卡顿”放到了公众面前，没记错这就是EMUI第一个大争议点出现；

-EMUI 8.X时代，人工智能技术加入系统，iAware借着算力，整个系统的后台管理模式更合理，图形引擎得到升级，即半路加入的GPU Turbo，这是EMUI对Android系统全栈图形模块修改的开始，EROFS超级文件系统也在此期间亮相开源社区；

-EMUI 9.X时代，也是“Turbo”的时代，GPU Turbo 2.0、CPU Turbo、LinkTurbo都是在这一代出现的，系统性能继续优化，EROFS正式加入，连接能力得到强化。2019年MWC上，华为“1+8+N”智慧全场景战略首次浮出水面，在这背后，鸿蒙的研发其实已经悄悄进行了不短的时间了；

-EMUI 10.X时代，分布式技术、软总线、超级终端这一系列的概念出现了，它在HDC 2019上推出，伴随着它一起发布的就是鸿蒙1.0，其时还是一个半成品，只能叫操作系统内核。只是因为2019年5月16日的事件，它不得不作为战略产品提前亮相，在推出的时候，鸿蒙就直接宣布将会开源；

-EMUI 11.X时代，鸿蒙来到了2.0版本，但HDC 2020的主角是HMS和AppGallery，不但前边提到的一系列系统底层的能力变化全部被涵盖其中，连Google最引以自傲的营收来源GMS服务、Google Play也被替代了。

看完上边这个简单的梳理，你是不是对本章节开头的那个问题概念更明晰了？ 如果说华为掏空了Android，没错，华为EMUI团队觉得Google做得不好的地方，要么魔改，要么就干脆换掉，比如底层连接协议。 特别是在2019年5月16日之后，即EMUI10和11两代，这样的动作愈加突出，幅度也越来越大。

要说华为没有掏空Android，也没错， 因为现在华为完全自主运营的AppGallery应用商店，里边的应用都是基于AOSP规范开发，但又置入了HMS服务的华为版，目的就是为了解决这些应用在没有GMS支持下的消费者体验问题。 毕竟在全球范围内，华为已经积累了7亿多终端用户，在他们换机或是华为解决手机硬件产品问题之前，用户还是要继续使用这些华为手机和软件服务的。

到这里，为什么会有鸿蒙这个东西了应该也有答案了。 “低情商”的说法，它有点像是华为在EMUI进化过程中，用来解决多设备连接协作问题中的“副产品”；“高情商”的说法，它是包涵底层互联协议、芯片能力调用、多设备协同过程中交互界面等全方位解决方案的集合体，高效率的连接（HiLink）、低时延（HiLink）以及微内核（比如LiteOS）是它的三大特点，所以，从软硬件一体化的整体度来说，鸿蒙肯定就是一个全新的操作系统。

因为华为的工程师认为，当前物联网的连接协议太过碎片化，从业厂商开发理解能力参差不齐，所以最后出来的产品也就五花八门，这样的情况，将会严重影响华为“1+8+N”战略的推进效果，“1+8”都是华为自己的好说，“N”怎么办呢？那就交给鸿蒙来解决吧。

这是发布会后宣布的消息：2020年和2021年，华为按计划分两次把HarmonyOS的核心基础能力全部捐献给开放原子开源基金会，由开放原子开源基金会整合其他参与者的贡献，形成 OpenHarmony 开源项目——这和AOSP是不是差不多？这就是为了能让其他有兴趣加入华为“1+8+N”战略的设备制造和服务提供商能更好的理解这个生态系统。在2021年5月18日上海的华为HarmonyOS Connect伙伴峰会上，华为消费者业务AI与智慧全场景业务部副总裁杨海松还提到了鸿蒙的商业模式，包括免费认证服务这些内容，我有整理专访，大家有兴趣也可以了解一下。

在2019年发布鸿蒙1.0的时候，华为的确是没有那么快的计划将它放在智能手机上。HDC 2019之后对余承东的专访中，他是这样说的：“如果我们确认谷歌不再为华为提供操作系统，那么，我们可以在一夜之间通过升级，将所有的华为手机操作系统的内核更换为鸿蒙，但是我们现在并不打算这么做，因为我们还是希望可以让合作伙伴（主要是指美国公司）的利益最大化。”

但同时，他也说了三个“Ready”，意即华为是可以随时这么做，而在6月2日的发布会上，华为手机的鸿蒙升级计划是何等规模大家也看到了。同样的问题王博早些时候的回答也是：“做操作系统并没有难度，关键是商业模式的问题。”

时间来到2020年5月16日，美国针对华为的终极制裁到来，手机SoC芯片断供，蓬勃发展的华为手机业务随时面临停摆的问题。虽然现在看，华为还可以通过购买第三方公司的芯片，在全球继续推出4G手机产品，但GMS同样不能使用，出货量也会从过去的亿级下降到千万级，决定华为消费者业务未来的“1+8+N”也随之面临巨大的挑战。两年前还是商业模式的问题瞬间就变成生死存亡的关键，HarmonyOS变得意义更加重大，不得不发。

并肩前行的OpenHarmony和HarmonyOS

我相信有了前边两个部分的铺垫，再进入第三个部分，很多人的困惑应该会少很多。华为目前对鸿蒙这个操作系统的定义是： “HarmonyOS是新一代智能终端操作系统，为不同设备的智能化、互联与协同提供了统一的语言” ，它与我们使用的Android这种宏内核系统在思路上有着本质的区别。

宏内核操作系统我们用得很多，电脑上的Windows、手机上Android都是，它最大的特点是设备要装载这个操作系统，就得所有的系统组件全部加包一起装载，不管用不用得着，同时在运行时，系统也会依据内存大小，自动加载组件，响应速度是提升了，但会消耗极大的系统资源。

到2021年我们已经能见到最高达18GB RAM的安卓手机了，而在当前主流的Android 11系统描述中写到：“设备最小运行内存为512MB”。如果设备的运行内存小于512MB，要到不能用最新版本的Android系统，要么就只能用老版本——这也是为什么我们能看到有些车机还在跑Android 4.4版本……

但是鸿蒙的设想就恰恰是反过来，它从架构设计上就进行了全栈解耦，将庞大的操作系统打散，拆解成很小的颗粒，不同能力的设备只需要按自己的要求来选择相应的模块能力加载即可， 比如鸿蒙系统的前身LiteOS，它最小的体积只有10KB，你能相信它是操作系统么？可它就是！华为认为这是未来物联网时代和必然趋势，巧的是Google也同样这样认为，所以，足足被其孕育了5年的微内核操作系统Fuchsia，刚刚于近日才正式推送，它的目标就是替代Android和ChromeOS，从而更好地适应物联网时代的多样终端和生态。

为了更好地让合作伙伴与开发者适配设备与系统的能力，华为将采用鸿蒙系统的设备从L0~L5做了6个分级，其中从L0~L2这三个级别的设备，要么没有交互界面，要么交互和功能都非常简单，家电、手环就算这种设备，运行内存也非常小，甚至低到KB级，其被定义为瘦终端，它们采用的鸿蒙系统，代码百分之百来自华为，不包含AOSP的任何部分；而L3~L5这三个级别的设备，有交互界面，可应用扩展，手机、平板、笔记本电脑、车机、VR/AR等这些设备就属于富终端的类别，它们采用的鸿蒙系统，就会引用AOSP的部分代码。在这其中，手机无疑是功能最复杂的核心设备，会跑最多的应用，它引用AOSP顺理成章。

所以，这次发布的HarmonyOS是何物就好解释了。 华为软件团队开发出的OpenHarmony开源项目用来构建“1+8+N”生态的基础，在这个基础上，华为手机终端团队加入HMS服务包，提供全套华为服务和连接能力，包括嵌入HMS服务的华为版应用，再加上部分AOSP开源代码，支持Android广泛的应用生态，保证消费者可以继续无障碍地使用已有的应用 ，这就是今天发布的HarmonyOS。看到这里，是不是有人感觉眼熟？

没错，苹果现在M1平台的MacBook就差不多是类似的情况，它既可以运行macOS应用，又可以运行iOS应用，而HarmonyOS呢，既可以运行原来的Android（APK）应用，又可以运行鸿蒙平台开发的应用（APK）。所以，6月2日发布会王博演讲的最后一个环节的话不晓得各位注意到没有： “HarmonyOS是基于OpenHarmony的第一个公开发行版” ，也算是把两者的关系做了一个比较明确的定义了。

关于鸿蒙系统是否是完全自主开发，要是没记错，华为自己是从来没有说过这样的话，但“我们要站在巨人的肩膀上”之类的话倒是看到过不少， 这个巨人放在HarmonyOS上，就是AOSP。至于有人说到的鸿蒙上使用的代码老旧，经过前边两个章节的介绍你应该明白，这对现在的华为和EMUI来说并不太重要，因为Android操作系统最核心的模块，华为早就已经是脱离谷歌自己在做更新，包括HMS加入后，连应用验证都自己在做，依赖度已经非常低了。

所以，现在EMUI 11还只基于Android 10版本的AOSP代码，但其对比采用Android 11版本的友商系统体验如何，相信大家心里是有数的。只是因为环境的关系， 本来应该“慢工出细活”的事情，全部被按下了快进键，很多还没来得做的事情，也都因为时间不够没有完成，比如代码替换等，相信今年的HDC 2021上华为软工团队会有更多新消息放出。

选择在现在推出HarmonyOS，对于华为也是有风险的，早年阿里YunOS与Android商业生态的冲突让我们第一次理解到了Google对“开放”的态度。现在，HarmonyOS可能面临的情况也差不多，但好在华为有HMS和初具规模的AppGallery可以进行一些对冲。

但对比这样的风险，真正的风险还是时间。从2020年5月16日算起，到现在已经过去了一年，消费者的换机周期是28个月左右，留给华为以手机产品为中心推进“1+8+N”战略的时间并不多，在余下的短短1~2年时间里，华为除了继续保留尽可能多的存量用户，还需要完成去手机中心化的“1+8+N”战略，还需要团结尽可能多的手机厂商来形成新的中心，从之前与杨海松的对话来看，新战略中的“1”，很有可能就是App了。

但另一方面，杨海松也说过： “华为擅长做产品而不擅长做生态”，这也是一个现实的问题，以前华为做产品，秉持的是“进入一个行业，就一定要做到世界第一”的“霸道”原则，现在做生态，华为应该想的是如何交到更多朋友，合作共赢，姿态非常重要……

写在最后

“华为推出HarmonyOS，中国骄傲”，发布会之后，以此为主题，各种各样的鸡血文章、小视频又出现在各大内容平台上，好一场流量盛宴。类似的场景也出现在一年前，在他们口中，似乎华为能以一己之力，一夜之间厘清中国整个芯片产业的 历史 欠账。华为人并非没有看到这些，但现在的他们，哪里有功夫去理会这些论调，有太多事要做了。虽然这篇长文，也许看到的人和看完的人有限，但我觉得能把那些关于HarmonyOS的事儿解释清楚，足矣。

④ 安卓art虚拟机在什么位置

一、概述
我们知道Android的程序虽然也是使用Java/Kotlin语言编码，并生成.class字节码，但并不能直接运行在JVM上，而是运行在自己的VM上。而Android程序之所以不能在JVM上运行的根本原因是.class字节码文件并不是Android的最终可执行文件(执行颂唤首效率问题)，而是一个过渡产物，最终会生成dex文件在Android VM上执行。

1.1 Android虚拟机分类：
Android VM大体分为两种： Dalvik 虚拟机和 ART虚拟机。

Dilvik 虚拟机：Android 5.0 版本之前。
ART虚拟机：Android 5.0 版本全面使用。
1.2 虚拟机的演变及优化：
Android 1.0，使用Dalvik作为Android虚拟机运行环境，此时的虚拟机是一个解释执行器。
Android 2.2，Android 虚拟机中加入了JIT编译器（Just-In-Time Compiler）。
Android 4.4，全新的ART虚拟机运行环境诞生，此时ART和Dalvik是共存的，用户可以在两者之间进行选择。
Android 5.0，ART全面取代了Dalvik成为了Android虚拟机运行环境，并使用AOT预编译技术在安装Apk时全量预编译 。
Android 7.0，ART虚拟机采用 JIT/AOT混合编译模式。
二、Dalvik
Dalvik是Google公司自己设计用于Android平台的虚拟机，它是Android平台的重要组成部分，支持dex格式（Dalvik Executable）的Java应用程序的运行。dex格式是专门为Dalvik设计的一种压缩格式，适合内存和处理器速度有限的系统。Google对其进行了特定的优化，经过优化的Dalvik，具有高效、简洁、节省资源的特点，同时还允许在有限的内存中同时运行多个虚拟机的实例，并且每一个Dalvik 应用作为一个独立的Linux进程执行。独立的进程可以防止在虚拟机崩溃的时候所有程序都被关闭。
2.1 Dalvik和JVM的区别
Dalvik 基于寄存器，而 JVM 基于栈。
指令数量：基于寄存器的操作指令，会增加操作数的大小(劣势)，但是会大大减少操作指令的数量(优势)
操作效率：基于寄存器(CPU上)的指令操作速度比基于操作数栈(主存)的速度快。
移植性：基于寄存器执行效率好，但是可移植性差，难跨平台。
Dalvik虚拟机有共享机制，不同应用之间在运行时可以共享相同的类，拥有更高的效率。
2.2 JIT（Just-In-Time Compile）
Android 2.2之前，Dalvik虚拟机是通过解释器 (解释器逐条读入字节码 -> 逐条翻译成机器码 -> 执行机器码)来执行程序的，效率低。针对这个问题，引进了JIT（即时编译器）技术。它是一种优化手段。

JIT技术：将解释过的机器码缓存起来，下次再执行时到这个方法的时候，则直接从缓存里面取出机器码来执行。减少了读取字节码和翻译字节码的操作。以此来提高效率。JIT技术的引入使得Dalvik的性能提升了3~6倍。

注意： 并不是所有执行过的代码对应的机器码都会被缓存起来。而是只有被认定为热点代码（Hot Spot Code） 的代码才会。这里所指的热点代码主要有两类，包括：
被多次调用的方法
被多次执行的循环体（虽然只是循环体被多次执行，但仍是将整个方法的机器码缓存起来）。

缺点： JIT技术的缺点：
每次重新启动引用都需要重新编译。
运行时比较耗电。
三、ART 虚拟机
ART虚拟机在Android 5.0开始替换Dalvik虚拟机，其处理应用程序执行的方式不同于Dalvik虚拟机，它不使用JIT而是使用了AOT（Ahead-Of-Time），也就是链伏提前编译技术。并对垃圾收集器也进行了改进和优化。

预先编译机制(AOT)可提高应用的性能。同时ART 还具有比 Dalvik 更严格的安装时验证。

3.1 AOT（Ahead-Of-Time）预先编译技术
AOT(提前编译技术)： 简单来说就是提前将字节码转换成本地机器码，然后野数存储在本地磁盘上，运行时可以直接执行，避免了Dalvik时期的应用运行时再来解释字节码。运行时效率大大提高。

在Android 7.0 之前，Android系统安装Apk时，会进行一次全量预编译，将字节码预先编译成本地机器码，生成 oat文件，并存储在本地磁盘上。这样在App每次运行时就不需要重新编译，可以直接使用编译好本地机器码，运行效率大大提升。但是这也使得安装应用的时间大大增加，于是在Android7.0及之后，又重新引进了JIT技术，形成JIT/AOT混合编译模式。

混合编译的特点：

应用在安装的时候，不进行AOT预编译。
应用运行时直接通过解释器翻译字节码为机器码然后执行。（在应用运行期间使用了JIT技术）并同时记录热点代码信息到profile文件中。
手机进入空闲或充电状态的时候，系统会扫描APP目录下的profile文件，并通过AOT对热点代码进行编译。
下一次启动时，会根据profile文件来运行已编译好的机器码，避免在运行时对已经转换为机器码的方法又进行了JIT编译。
应用运行期间会持续对热点代码进行记录，以方便在空闲或充电时进行AOT，以此循环。
使用JIT编译器来对AOT编译器进行补充，降低了Apk安装的时间，提升了运行时性能，节省了存储空间，加快应用运行速度。

小结：
Android 7.0以前，采用AOT全量预编译，Apk安装时预编译dex生成对应的机器码文件。但预编译量大导致Apk安装时间长。
Android 7.0及之后，采用JIT/AOT混合编译模式，根据对应的profile在空闲时进行AOT预编译。

参考： 实现 ART 即时 (JIT) 编译器

3.2 Dalvik与ART虚拟机的区别
Dalvik每次都要编译再运行，Art只会安装时启动编译(7.0之前全量预编译)。
Art占用空间比Dalvik大（原生代码占用的存储空间更大），就是用“空间换时间”。
Art减少编译，减少了CPU使用频率，使用明显改善电池续航。
Art应用启动更快、运行更快、体验更流畅、触感反馈更及时。
3.3 Interpreter解释器、JIT、AOT的在ART上的使用
解释器： 逐条读入字节码 -> 逐条翻译成机器码 -> 执行机器码，重复执行同一代码时需要重新翻译执行。
JIT编译器： 对运行时的热点代码(热点代码)进行编译，且缓存在内存中，当下次继续执行时，直接从内存中获取，减少重复编译。
AOT编译器： 在运行前将字节码转换为机器码，在运行时直接运行转换后的机器码。

在这里插入图片描述

3.4 垃圾回收方面的优化
Android虚拟机（Dalvik && ART）学习

四、Android中的几种文件
4.1 Apk文件
APK 文件其实是 zip 格式，在Window平台上可以直接将后缀格式改为zip进行解压。解压后的目录如下图所示：
在这里插入图片描述

文件名 说明
META-INF/ 信息描述，签名等用途。编译生成一个apk包时，会对所有要打包的文件做一个校验计算，并把计算结果放在META-INF目录下。而在Android手机上安装apk包时，应用管理器会按照同样的算法对包里的文件做校验，如果校验结果与META-INF下的内容不一致，系统就不会安装这个apk。这就保证了apk包里的文件不能被随意替换
res/ 存放资源文件
libs/ 存放的是 ndk 编出来的 so 库
AndroidManifest.xml 程序全局清单文件
classes.dex dalvik 字节码
resources.ars 编译后的二进制资源文件，主要是对应的索引
assets/ 保留工程中assets目录，其他工程下的、jar包中的assets也会合并到该assets目录下。
4.2 dex文件
dex 文件是可被Dalvik虚拟机识别并执行的文件， Dalvik 会执行 .dex 文件中的 dalvik 字节码，但一般Dalvik在执行dex优化后的文件(即odex文件)。

dex文件特点：

dex文件是Android系统中的一种文件，是一种特殊的数据格式，和Apk、jar等格式文件类似。
文件更加紧凑：dex文件是能够被DVM识别，加载并执行的文件格式。相比于Jar文件，dex会把所有包含的信息整合在一起，减少冗余信息，从而降低了加载文件时的I/O耗时，提高类的查找速度。
dex文件包含应用程序的全部操作指令和运行时数据。
相对于PC上的JVM能运行 .class文件，Android上的Dalvik虚拟机能运行 .dex 文件。
.dex文件和 .class文件的格式对照：
在这里插入图片描述
dex 文件结构：
在这里插入图片描述

4.3 引起dex文件65535问题的原因
当Android系统启动一个Apk时，会通过 dexopt 工具对dex进行优化。dexopt 的执行过程是在第一次加载dex文件的时候执行的。这个过程会生成一个odex文件，即Optimised Dex (执行odex的效率会比直接执行Dex文件的效率要高很多)。但早期Android系统中， dexopt 有一个问题(即65535问题)。dexopt会把每一个类的方法id检索起来，存在一个链表结构里面。但是这个链表的长度是用一个 short类型(2^16=65536)来保存的，导致了方法id的数目不能够超过65536个。
4.4 odex文件 (Optimized DEX)
背景： 对Android dex文件进行优化来说，需要注意的一点是dex文件的结构是紧凑的，但是我们还是要想方设法进行运行速度的提高，因此我们仍然需要对dex文件进一步优化。
odex文件的使用场景：

安装阶段： Apk在安装时，系统会进行验证和优化，目的是为了校验代码合法性及优化代码执行速度。当验证和优化后，系统会从Apk中提取dex文件进行优化，并将优化后的产物(odex文件)保存到 data/dalvik-cache 目录下。
运行阶段： 当运行Apk的时候，会直接加载odex文件，避免重复验证和优化，加快了Apk的响应时间。
odex 文件的生成过程：

Android 5.0之前：Dalvik虚拟机

Dalvik虚拟机会在执行dex文件前对dex文件做优化，生成可执行文件odex，保存到 data/dalvik-cache 目录，最后把Apk文件中的dex文件删除。

注意： 此时生成的odex文件后缀依然是dex ，它是一个dex文件，里面仍然是字节码，而不是本地机器码。
Android5.0 <= Version < Android 8.0 (Android O)：ART虚拟机

Android5.0之后使用ART虚拟机，ART虚拟机使用AOT预编译生成oat文件。oat文件是ART虚拟机运行的文件，是ELF格式二进制文件。oat文件包含dex和编译的本地机器指令，因此比Android5.0之前的odex文件更大。

oat文件生成过程：
App在首次安装的时候，dex2oat 工具默认会把 dex文件翻译成本地机器指令，生成ELF格式的OAT文件，并将其放在了 /data/dalvik-cache 或 /data/app/packagename/ 目录下，此时oat文件后缀格式为odex。
ART加载oat文件后不需要经过处理就可以直接运行，它在编译时就从字节码装换成机器码了，因此运行速度更快。
Dalvik虚拟机执行程序dex文件前，系统会对dex文件做优化，生成可执行文件odex，保存到 data/dalvik-cache 目录，最后把apk文件中的dex文件删除。 (注意：此时生成的odex文件后缀依然是dex ，它是一个dex文件，里面仍然还是字节码，而不是本地机器码。)

注意： Android5.0及之后版本生成的 oat文件后缀还是odex，但是已经不是android5.0 及之前版本的文件格式，而是ELF格式封装的本地机器码。可以认为oat在dex上加了一层壳，可以从oat里提取出dex。
Android O及之后(>=Android 8.0)：ART虚拟机

Android 8.0及之后版本，dex2oat会直接生成两个oat文件 (即vdex文件 和 odex文件)。其中 odex 文件是从vdex 文件中提取了部分模块生成的一个新的可执行二进制码文件，odex 从vdex 中提取后，vdex 的大小就减少了。

文件生成过程：
App在首次安装的时候，odex 文件就会生成在 /system/app/<packagename>/oat/ 下。
在系统运行过程中，虚拟机将其 从/system/app 下 到 /data/davilk-cache/ 下。
odex + vdex = Apk 的全部源码 （vdex 并不是独立于odex 的，文件 odex + vdex 才代表一个Apk ）。
odex 的优点和缺点：

优点：
启动快： 省去了系统第一次启动应用时从Apk文件中读取dex文件，并对dex文件做优化的过程。和
对RAM的占用（Apk文件中的dex如果不删除，同一个应用就会存在两个dex文件：apk中和 data/dalvik-cache 目录下）。
安全性：防止第三方用户反编译系统的软件（odex文件是跟随系统环境变化的，改变环境会无法运行；而apk文件中又不包含dex文件，无法独立运行）
劣势：
优化后的odex文件大小通常是原dex文件的1~4倍 (空间换时间)。
4.5 vdex文件
vdex文件是 Android O (Android 8.0) 新增的格式包，其目的是为了降低dex2oat时间。

dex2oat的触发场景：

当系统OTA (系统升级) 后，用户自己安装的应用是不会发生任何变化的，但 framework 代码已经发生了变化，因此就需要重新对这些应用也做dex2oat。如果没有vdex文件，则需要重新校验Apk里dex文件合法性；如果存在vdex文件，就可以省略校验的过程，节省一部分时间。
当App的 JIT Profile 信息变化时，background dexopt会在后台重新做dex2oat，因为有了vdex，这个时候也可以直接跳过dex文件的校验流程。
dex 文件直接转化的可执行二进制码文件：

App在首次安装的时候，vdex文件就会生成在 /system/app/<packagename>/oat/下。
在系统运行过程中，虚拟机将其从 /system/app 下 到 /data/davilk-cache/ 下。
4.6 art文件
art文件是由虚拟机执行odex文件后，记录虚拟机执行Apk启动的常用函数地址信息后生成出来的文件(记录函数地址信息方便寻址)，目的 是用于加快应用启动速度。通常会在data/dalvik-cache/ 目录中保存常用的jar包的相关地址记录。

第一次开机不会生成在 /system/app/<packagename>/oat/ 下，以后也不会。
odex 文件在运行时，虚拟机会计算函数调用频率，进行函数地址的修改。
最后在 /data/davilk-cache/ 由虚拟机生成 art文件(art文件生成)。
生成 art文件后，/system/app 下的odex 和 vdex 会无效，即使你删除，apk也会正常运行。
push 一个新的apk file 覆盖之前 /system/app 下Apk file ，会触发 PMS 扫描时下发 force_dex 的flag ，强行生成新的vdex 文件 ，覆盖之前的vdex 文件，由于某种机制，这个新vdex 文件会到 /data/dalvik-cache/ 下，于是 art 文件也变化了。
4.7 oat文件
ART虚拟机运行的是oat文件，oat文件是一种Android私有ELF文件格式，oat文件包含有从dex文件翻译而来的本地机器指令，还包含有原来的dex文件内容(如下图所示)，因此oat文件比odex文件更大。APK在安装的过程中，会通过dex2oat工具生成一个OAT文件(文件后缀还是odex)。对于apk来说，oat文件实际上就是对odex文件的包装，即oat=odex。

注意： Android5.0 及之后的版本，oat文件的后缀还是odex，但是已经不是android5.0 之前的文件格式，而是ELF格式封装的本地机器码。可以认为oat在dex上加了一层壳，可以从oat里提取出dex。