我自己觉得微内核确实是体积小了但是外面的那些驱动什么的又需要开发者去开发，这些开发者前期也就只有华为的开发人员去弄
鸿蒙独立了跑到国外谷歌全家桶又是一个不可逾越的鸿沟,GMS用不了国外就没希望，何况fuchsia这个谷歌的备用还在那摆着，所以鸿蒙切入点在国内，以万物互联为主题是最佳发展方式。
个人比较喜欢鸿蒙的一些东西，也相信它一定会成功，或许3年或许更久，但是现在取代安卓是不可能的的，不过打破垄断全新开源，重新定义5G万物互联时代，作为一个学生还是开了眼的。
2、相对与安卓来说全场景、分布式是鸿蒙OS2.0的最大优势，鸿蒙OS2.0首先在分布式能力上经行了提升分布式软总线、分布式数据管理、并提升了分布式安全能力，（手表电视 汽车 中控外加美的九阳老板电器）、EMUI11借鉴了鸿蒙的分布式技术，多屏协同。
3、GPL:谷歌曾提出影响开源世界最大的障碍就是GPL，GPL规定要求代码使用者代码衍生出来的东西永远开源。谷歌为了隔离gpl的开源，提出了Apache(阿帕奇)协议，就是我开源你随便。
谷歌把一个魔改后的linux作为内核封装起来，中间加了一层类库，让其他所有部分对内核的调用,都像是两个软件之间的调用一样，然后把所有涉及到GPL授权的代码全部替换重写，开源并以Apache协议授权。
这就导致linux社区不满，因为它违反了Linux开源精神如果非强制会导致没人愿意开源，2012年安卓在linux分支树上被永远除名
话说回来要不是Apache哪里来的EMUI Flyme Coloros,要是GPL的话那不是给人打工吗。
4、安卓的linux内核包含了权限管理，CPU指令适配、设备驱动等等
微内核简单理解就是：裁剪了一下，更小了，手机平板手表通用，手机摄像头给手表用，内核一样，手机上有摄像头的设备驱动，不同于wifi、蓝牙华为可以通过分布式软总线来实现信息的传递，这一步5G起到了关键作用。关于分布式软总线的介绍在博客最后。
优势1：灵活的全场景适用，不同屏幕大小、功耗和性能要求的设备可以灵活选择，这样一个应用就有可能在多个设备或者华为所说的全设备上运行，这对于5G万物互联来说非常方便
优势2：安全，恶意代码只能在某个模块下运行，不再是宏内核整个root权限下随便运行
5、当前鸿蒙智慧屏上鸿蒙1.0是linux 鸿蒙 liteos三核并存，因为他生存初期必须要保证鸿蒙系统的可用性，他前期要兼容安卓，一点一点替换安卓的驱动等等，开源的世界有现成的就没人会去造轮子。
6、对于鸿蒙的分布式，也就是软硬件资源共享，其实是基于微内核的，宏内核要实现ipc通信就需要用户空间进程调度到内核空间内核空间再到另一个用户进程空间实现资源传递，宏内核的内核空间是共享的，所谓的新建一个进程可以说是只是说新建了自己独立的用户空间，这里面的ipc通信效率目前来说是要比微内核的效率要高的，而华为的分布式ipc是要通过软总线来实现的，如果借助tcp来实现安全可以保证，但是协议繁琐效率降低，这对于我们物联网的交互来说是不可采取的，所以软总线相当于一个魔改的tcp。
分布式软总线将原本计算机网络通讯协议七层结构中的 表示层、会话层、传输层和网络层等协议精简为一层 ，称为 分布式软总线的极简协议 ，能提升有效载荷。
通过报文简化、包头简化、交互简化，基于应用场景的缓冲机制等方式，提升有效的传输负荷、解决传统 TCP/IP 协议过于复杂的协议层次模型、层层增加包头和解包，充分发挥物理通信通道的最大效能。
通过对协议的优化，分布式软总线无线连接、高带宽、低时延、低功耗、安全接入的优点。分布式软总线实现小于20ms的低时延，端到端时延小于20ms，有效吞吐量达到1.2Gbps，抗丢包性达到25%， 高性能IPC将进程间的通信效率提升了5倍 。
简单理解可以把它想象成优化的tcp更快实现资源共享。
对待知识领域，我们总喜欢去下一个定义。 *** 作系统是我们每天工作都要使用的东西，由于现代商业 *** 作系统的复杂性和没有统一的标准，若对一个 *** 作系统下定义并不能精确的描述 *** 作系统所属领域。根据经验我们可以认为 *** 作系统就是在整个应用系统中负责最基本功能和系统管理的那部分。包括内核、设备驱动程序、启动引导程序、命令行Shell或者GUI界面、基本文件管理工具和系统工具。
严格的来讲linux只是 *** 作系统内核本身，广义上的linux则常用来指基于linux内二的完整的 *** 作系统，它包括GUI组件和其它许多工具。
GUI其实只是 *** 作系统的表象，内核才是 *** 作系统内在的核心。系统的其它部分必须依靠内核所提供的服务，像管理硬件设备、分配系统资源等，内核有时候被称为管理者或者 *** 作系统核心。
通常一个内核由负责响应中断的中断服务程序，负责进程调度的CPU调度程序，负责管理进程地址空间的内存管理程序以及网络、进程间通信等系统服务共同组成的。
内核在有安全机制的 *** 作系统中不同于普通程序，一般处于系统态(内核态)，拥有受保护的内存空间和访问硬件设备的所有权限。这种系统状态和被保护起来的内存空间，统称为 内核空间 。
与内核空间相对的，用户所执行的应用程序在用户空间执行。用户态的应用程序只能访问允许它们使用的系统资源，并且只使用某些特定的系统功能，不能直接访问硬件，也不能访问内核划分给其它应用程序的内存空间。
应用程序通过系统调用来和内核通信，当一个应用程序发起系统调用时，内核便代其执行。在这种情况下应用程序通过系统调用在内核空间运行，而内核被称为运行在进程上下文中。应用程序通过系统调用进入内核空间时应用完成其工作的基本方式。
*** 作系统内核可分为两大阵营：单内核和微内核。
单内核是一种较为简单的设计，通常以单个静态二进制文件存储在磁盘中，整体上作为一个单独的大过程，所有的内核服务都在这样的一个大内核地址空间上运行。内核服务都处于内核态，并身处同一内核地址空间，之间可以几乎无性能损耗的相互通信。
单内核具有简单和高性能等特点。
微内核根据功能被分割成多个独立的过程，每个过程都叫做一个服务器。所有的服务器都运行在各自的地址空间上（大部分处于用户空间），只有强烈请求特权服务的服务器才运行在特权模式下。
微内核服务器之间不能直接调用函数通信，而是通过 消息传递 通信。系统采用进程间通信(IPC)机制，服务之间各自独立，通过IPC互换消息，有效的避免了服务之间的失败传染。
IPC机制的开销远高于函数调用，而且在运行时还会牵扯到内核空间和用户空间上下文切换，所以消息传递需要一些开销。所以在内核的实际实现上大部分微内核的 *** 作系统也会让大部分的服务放置与内核中，这样就可以直接调用函数，消除消息传递的开销。
windows NT和Mach(Mac OS X)都是典型的微内核，不过在实际实现上，其所有服务都运行在内核空间。
linux是一个单内核，不过linux汲取了微内核的精华，并拥有模块化设计、抢占式内核、支持内核线程以及动态装载内核模块等特性。
linux内核在设计时充分参考了已有的很多UNIX的内核实现，并且有一些创新方案。linux内核和传统的UNIX系统之间存在一些显著的差异：
本文的写作和学习中参考了以下资料
1.《Linux Kenel Development ~ Thrid Edition 》
Micro-kernel 已经失败。在商业级 *** 作系统中（包括可以用于 mission critical 的 open source *** 作系统），除了 L4 还在苦苦留有少量份额，没有任何 micro-kernel 的市场。另外，hybrid-kernel 实际就是 monolithic kernel（原因此在后面说明），所以不必把 hybrid 这个概念作为 micro-kernel 苟延残喘的证据。首先，第一代 micro-kernel —— Mach 在性能上是彻底的失败。这个网上资料很充分。
随后，L4 证明在理论上 micro-kernel 还可以达到可用的性能，但是已经无力回天。这是因为：
Monolithic kernel 并不强制 monolithic driver（也就是说 driver 的 policy 部分完全可以放到 user-land）。所以 micro-kernel 所标榜的通过隔离 driver 达到稳定性毫无意义。
正因为 monolithic kernel 不强制 monolithic driver。所以真正的 micro-kernel 必须具备两个特点：第一，强制的 user-land driver DDK（下面说明）；第二，I/O 和 memory management 必须放到 user land。对于大多数所谓 hybrid kernel，都不满足此两点，所以其实都是 monolithic kernel。
成功的经验说明，对于一个完整的 kernel，monolithic and modular 结构的 kernel 可以完全应付其复杂度。而且到了今天，kernel 的功能几乎不会增加（driver 的增加不算 kernel 本身的功能增加）。
关于 user-land driver DDK，Linux 早已经有过讨论，是维护一个稳定的 driver interface 好，还是让 driver 随着 kernel 演进好。结论是后者。当然，对于大多数商业 kernel 来说，不可能完全同意 Linux 的策略，但是这正好说明 micro-kernel 标榜的又一个优势消失了。
总之，第一代 micro-kernel 是以一个错误的方式解决了一个错误的问题。而第二代 micro-kernel 不过是以正确的方式解决了错误的问题。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）