没用过之前的EMUI版本。

之前用的WP。

EMUI 40，感觉很快，瞬间弹出瞬间加载。做不到WP的“丝般顺滑”，但是快啊。举个例子就是，要 2秒 的“丝般顺滑”，还是要 05秒 的“咔嗖~”。。。其实这种“不顺滑”，用惯安卓的人应该是看不出来的。

系统自带app觉得很没用的都能删，不能删的感觉都挺有用。

常用应用没发现任何兼容问题，应该是优化过的。

还有可能之前的EMUI也有的，据说是自带谷歌服务框架。反正我是直接从应用商店装了google play，再直接从google play装了ingress，然后就直接能玩了（fq什么的当然是要的，这里不提了）。

mate8的续航，买来头几天经常玩，微信qq断断续续全天都在聊，中午晚上刷半小时ingress，两天一充，充的时候还有20的电。

快充很给力，大约俩小时充满（或者不到俩小时？）

在去年微软刚发布Windows

11系统时，有多个新功能备受外界期待，其中就包括了它将会支持Android应用，想想看用电脑玩上沉浸感很强的手游或是体验上完整版的微信软件，新鲜劲十足。遗憾的是，自发布Windows

11以来的很长一段时间里，微软一直没有在正式版中正式引入这一功能，这也谗哭了不少用户。

终于，微软在近日推送的Windows

11更新版本中，正式加入了对Android应用的支持，也就是说只要你的系统是Windows 11

21H2版本或以上就可以体验了。具体为：在商店中加入Windows Subsystem for

Android的预览版、重新设计的记事本和多媒体播放器、以及任务栏的改进。这意味着，Windows 11终于可以运行Andorid app。

而且使用的方式也并不复杂，这对于大家来说肯定是好事，笔者本人也想尝尝鲜，看看基于Windows 11运行的Android子系统能带来怎样的体验。

配置要求

当然，要想使用Windows11 Android子系统，也是有电脑配置需求的，根据微软提供的资料，在Windows 11里运行Andorid app推荐使用16GB内存，8GB则是最低要求。此外，微软表示电脑要使用SSD，而不是HDD。

按照微软文档里，Windows 11硬件配置需求有关TPM

20的要求，需采用英特尔酷睿8代或以上、AMD Ryzen 2000系列或以上、以及高通Qualcomm

7和8系列的平台。不过想在Windows 11里运行Andorid app显然要求更高，众多用户使用的AMD Ryzen

2000系列处理器直接被排除在外。

而我们使用的配置是：

安装Android子系统&安装应用

这次的更新主要是微软与亚马逊合作为Windows

11引入Android应用，也可以这么认为：让用户通过微软应用商店中的亚马逊 App Store下载使用Android应用。而目前亚马逊App

Store已经在可以在Windows11的微软应用商店中下载，当然，前提是要在设置那里把地区改为美区。

想要在Windows 11中使用Android应用就需要安装Android子系统了，作用相当于系统的模拟器，而下载并安装亚马逊App Store之后，系统会自动下载安装Android子系统了。（不用管亚马逊App Store能否使用）

安装完系统会后，就需要寻找第三方应用安装器来安装APK文件，网上有许多这方面的安装教程，大家可以去了解一下。笔者也是通过教程实现了对安卓APK文件的安装，最后成功通过Windows Subsystem for Android系统用上了Android应用。

Android子系统的体验

在开启Android应用前，需要到“适用于Android的Windows子系统设置”里进行几个设置，打开“开发人员模式”后，刷新下一项的IP地址就可以使用了。

安装Android应用需要用到APK文件，但也有个一劳永逸的办法，只需要下载“应用宝”APP的APK文件并安装成功后，通过这款软件就能对各个Android应用进行下载安装了。

作为安装于电脑上的Android子系统，大家也想看看搭载电脑硬件配置的Android子系统能够在手机上常见的跑分测试软件中能跑出什么水平的成绩。我们恰好用的是高端处理器——Intel酷睿i9-11900K处理器，按理来说，吊打一众安卓旗舰处理器应该没什么难度。

跑分测试

于是通过应用宝APP下载了“安兔兔”和“鲁大师”两款手机常用跑分应用，跑分结果如下图，CPU性能方面已经达到顶级水准，吊打一众顶级安卓旗舰都没什么压力，这里我也对比了知名媒体已经公布的搭载骁龙8

Gen 1的OPPO新机Find X5

Pro的跑分，综合总分101万多分，CPU得分23万多分，Windows11的Android子系统要比它高了接近一倍。

另外，网传联发科的天玑9000处理器要比骁龙8

Gen1，但还没相关评测跑分出现，但网上出现了一款代号为PD2186X的vivo新机，其搭载了天玑9000处理器，安兔兔的跑分成绩达到107万多分，CPU性能得分接近28万分，确实要比OPPO那款高了不少，但比起Windows11的Android子系统的CPU性能，确实还差了一大截。毕竟手机的高端CPU肯定要是没法和PC的高端CPU相提并论的。

但是，相信大家也注意到了，在“适用于Android的Windows子系统设置”里我设置的GPU为“NVIDIA

RTX 3070”显卡，但在安兔兔跑分应用里，GPU却成了“Android Emulator OpenGL ES

Translator”，RTX 3070显卡并没有参与跑分测试中。

只能理解为：电脑中的GPU与CPU是分开的，因此GPU也被称为显卡，而手机上的GPU只是一颗紧挨着CPU的芯片，是没有单独出来的“显卡”的，所以在跑分时安兔兔跑分应用里参与测试的GPU只能是Windows11系统为Android子系统提供的OpenGL

ES，根据百度释义：OpenGL ES用于三维图象（二维的亦可），是个专业的图形程序接口，是一个功能强大，调用方便的底层图形库。

所以可以看到，Windows11的Android子系统无论是在安兔兔跑分还是在鲁大师的跑分测试中，采用8核16线程的酷睿i9-11900K

CPU的表现已经达到了手机版处理器没法企及的高度。而在GPU部分，由于电脑的显卡没法参与到跑分环节，因此Android子系统在此环节只能拿到一个非常低的分数。

负载均衡（LB）在微服务架构演进中具有非常重要的意义，可以说的内容有很多， 这里仅仅讨论四层和七层负载均衡的一些要点和区别 ，以便于对 ingress 的理解。所谓四层和七层负载均衡是按照网络层次OSI来划分的负载均衡类型（也可以按照其他的规则来分类，比如：应用的地理结构），简单来说： 四层负载均衡 表示负载均衡器用ip+port接收请求，再直接转发到后端对应的服务上，工作在传输层( transport layer )； 七层负载均衡 表示负载均衡器根据虚拟的url或主机名来接收请求，经过处理后再转向相应的后端服务上，工作在应用层( application layer )。

下图表示了4层和7层负载均衡在建立TCP连接上的区别，从图中可以看出，四层负载均衡需要建立的TCP连接其实之有一个，它只做一次转发，client直接和server连接；而7层负载均衡则需要建立两次TCP连接，client到LB，LB根据消息中的内容( 比如URL或者cookie中的信息 )来做出负载均衡的决定，接着建立LB到server的连接。

7层负载均衡有什么好处呢？

举个例子：

正向代理 ：在使用VPS访问 的时候，通常会使用一个本地的代理服务器，浏览器的网络包会先经过本地的代理服务器，代理服务器会通过远在异国它乡的电脑来访问 并返回消息；这就好比去附近的咖啡店要先问一下手机咖啡店在哪里一样，手机就是一个正向代理服务器。

反向代理 ：当访问的请求到达 时， 那边也设置了一个代理服务器，它通过查看请求的URL，发现是想查找视频内容，于时把消息转给了视频搜索服务器（过程是我乱说的），这就好比你去朋友家做客，开门的却是个管家，问你找谁？这时候管家就是一个反向代理了。

关于反向代理的好处这里就不多介绍，感兴趣可以看 这里

k8s 对外 暴露服务（service）主要有两种方式： NotePort , LoadBalance ， 此外 externalIPs 也可以使各类service对外提供服务，但是当集群服务很多的时候，NodePort方式最大的缺点是会占用很多集群机器的端口；LB方式最大的缺点则是每个service一个LB又有点浪费和麻烦，并且需要k8s之外的支持； 而ingress则只需要一个NodePort或者一个LB就可以满足所有 service 对外服务的需求。工作机制大致可以用下图表示：

实际上， ingress 相当于一个7层的负载均衡器，是k8s对反向代理的一个抽象。大概的工作原理也确实类似于Nginx，可以理解成在 Ingress 里建立一个个映射规则 , ingress Controller 通过监听 Ingress 这个api对象里的配置规则并转化成 Nginx 的配置（kubernetes声明式API和控制循环） , 然后对外部提供服务。ingress包括： ingress controller 和 ingress resources

ingress controller ：核心是一个deployment，实现方式有很多，比如nginx, Contour, Haproxy, trafik, Istio，需要编写的yaml有：Deployment, Service, ConfigMap, ServiceAccount（Auth），其中service的类型可以是NodePort或者LoadBalancer。

ingress resources ：这个就是一个类型为 Ingress 的k8s api对象了，这部分则是面向开发人员。

假设已经有两个服务部署在了k8s集群内部：

配置 Ingress resources，即可实现多个service对外暴露服务:

方式一：

接着在hosts文件中添加一条解析规则： ${ingress_IP} foobarcom ，这时通过 在浏览器 中访问： foobarcom/coffee 或者 foobarcom/tea 即可访问对应的后端service了。

方式二：

这时在hosts文件添加两条解析规则就可以在浏览器中访问了。此外，还可以配置TLS证书实现HTTPS访问，这里不再详述。