前言
此前在華爲Mate X2發佈會上，華爲表示鴻蒙系統將於今年4月與你們正式見面。而就在昨天，也就是4月27號，鴻蒙系統終於推送升級了，花粉狂喜，黑粉狂噴。html
若是你問我鴻蒙系統的性能怎麼樣，我持保留意見。 若是你問我升不升級鴻蒙系統，我tm直接衝鋒 
這個開機界面仍是蠻爽的！並且把power by android去掉了。android
可是這次升級，面向的對象依然是開發者，不建議普通消費者拿主力機型冒然升級，手裏只有一臺華爲機的朋友強烈不建議。git
關於花粉和黑粉的爭論大可沒必要去在乎，由於二者的觀點都沒什麼價值，花粉只要是華爲的東西就狂吹，雖然我也站華爲，但不得不說有些吹得實在是太尬了，那種幾年趕超別人幾十年的言論真的讓我雙腳能扣出一棟別墅。至於黑粉，不是蠢就是壞要麼就是單純閒得慌，不值一提。程序員
因此我這篇文章並非要站隊，而是藉着鴻蒙系統來普及一下操做系統究竟是什麼，網上吵得翻天地覆的人百分之九十九都不知道微內核是什麼，甚至不知道操做系統內核的概念，都不知道支撐他們爭吵的基石是什麼。github
微內核
關於微內核的資源，並非不少，在實際工做和生活中，大型互聯網公司的研發都並無什麼機會接觸到微內核，更別說普通用戶了，就連不少資深程序員都不多有人能接觸到微內核的操做系統，互聯網公司廣泛使用的Linux內核是一個典型的宏內核，而Windows則是一個混合內核，若要學習微內核，還真沒有什麼好的平臺。web
Wiki是一個不錯的起始點(打不開也能夠百度百科)：https://zh.wikipedia.org/wiki/%E5%BE%AE%E5%85%A7%E6%A0%B8算法
摘錄一張經典的對比操做系統微內核和宏內核的圖示： 數據庫
收集了一個介紹Minix的PPT，感興趣的朋友能夠點擊領取，本身看一下，不過英語不過關的可能要藉助翻譯工具才能看懂，哈哈安全
幾乎全部講微內核的文章都採用以上這個圖，可是除此以外，基本就是空洞的總結了，無外乎微內核更加容易擴展，更穩定，而宏內核則性能優越之類云云。但這些並不能讓讀者體會微內核的實質，由於這些總結性的理論一般是給已經懂的人看的，它沒法給初學者帶來感官上的感覺。網絡
微內核操做系統
微內核的基本原理是：只有最基本的操做系統功能才放入內核中。非基本的服務和應用程序在內核之上構建，並在用戶模式下運行。關於什麼功能應該放入微內核，不一樣的設計有不一樣的方式，可是共同特色是許多傳統上屬於操做系統一部分的功能如今都是外部子系統，包括設備驅動程序，文件系統，虛存管理程序，窗口系統和安全服務，它們能夠和內核交互，也能夠相互交互。
微內核結構使用一個水平分層代替傳統的縱向分層，全部微內核以外的操做系統構件都被看成服務進程來實現，它們能夠經過微內核傳遞消息來實現相互之間的交互。所以，微內核還能夠驗證消息並受權訪問硬件，並且微內核還執行保護功能，阻止非法的信息等。
例如，應用程序若是要打開一個文件，則它發送消息給文件系統服務，若是他想建立一個進程或線程，則它發送消息給進程服務進程。每一個服務進程之間能夠相互通訊，並能夠調用微內核中的功能。
微內核的優勢：
提供一致的接口：微內核設計爲進程請求提供一致的接口，進程不在須要區份內核級服務仍是用戶級服務，由於都是經過消息傳遞；
可擴展性：使用微內核結構，當須要爲系統增長新的服務時，只是增長一個新的服務進程，而不是修改內核；
靈活性：能夠根據須要定製不一樣的服務進程，例如分佈式系統須要增長安全性相關的服務；
可移植性：在微內核結構中，大部分處理器專用代碼都在微內核中，若是須要移植到另外一個處理器上時，須要修改的代碼不多；
可靠性：模塊化的結構有利於增長穩定性，並且足夠小的微內核更能進行充分的測試，爲外部的系統服務提供更穩定的代碼。並且它只提供少許的API和交互方式給程序員，能夠減小組件之間的相互影響；
分佈式系統的支持：若是一個客戶往一個服務進程發送消息時，該消息包含請求服務的標識符。在分佈式系統被配置爲全部進程和服務都具備惟一的標識符，那麼實際上在微內核級別上有一個單獨的系統映像，進程能夠在不知道目標服務駐留在哪臺機器上的狀況下發送信息；
適用於面向對象設計：微內核設計和操做系統模塊化的開發均可以藉助面向對象的原理。例如，一種方式是構造組件，組件間經過組建接口交互，它們能夠經過搭積木的方式構件軟件；
微內核的性能：
經過微內核構造和發送消息，比直接進行一次系統調用發花費更多時間。一種解決方式是將一些關鍵服務和驅動程序從新放回內核中，能夠減小用戶-內核模式以及進程間的切換次數，可是這是以犧牲微內核的設計強度爲代價；另外一種解決方式是經過正確的設計，構造一個很是小的內核，能夠消除消除性能損失並提升靈活性。
微內核設計：
低級存儲器管理：微內核必須控制硬件上的地址空間，使得操做系統能夠在進程級進行保護。微內核只負責把每一個虛頁映射到一個物理頁幀，而存儲管理部分則在內核外實現，包括保護一個進程的地址空間不被其餘進程干涉，頁面替換算法以及分頁邏輯。例如，內核外的虛擬存儲器負責什麼時候把一個頁面調入存儲器或者什麼時候換出一個頁面，而內核就負責將這些頁面索引映射到物理地址。
當一個應用程序發生引用了不在主存中的一頁的時候，，內核發生缺頁錯誤並執行陷阱，內核給頁面管理器所在進程發送一條消息。頁面管理器決定裝載頁面並分配一個頁幀，頁面管理器和內核進行交互，以把頁面管理器的邏輯操做映射到物理存儲器。一旦該頁可用，頁面管理器就給應用程序發送一條中斷恢復的消息。
這種技術能夠不用調用內核操做，就將文件和數據庫映射到用戶地址空間。微內核一共提供了三個內核操做用於支持核外的分頁和虛存管理：
受權：一個地址空間的全部者能夠受權其餘進程使用它的某些頁。內核把這些頁從受權者的地址空間移出，並把它們分配給指定的進程；
映射：一個進程能夠把它的任何頁映射到另外一個進程的地址空間，使得兩個進程均可以訪問這些頁，就造成了共享內存。內核把這些頁面分配給最初的全部者，爲其餘進程 提供一個映射以便訪問它們；
刷新：進程能夠回收受權給其餘進程或者映射到另外進程的任何頁面；
進程間的通訊：微內核操做系統中，進程之間或者線程之間進行通訊的基本方式是消息。消息包括消息頭和消息體：消息頭描述了發送和接受消息的進程；消息體包含數據或者指向數據的指針。
能夠認爲進程間通訊是基於與進程相關聯的端口（某個進程的消息序列），端口能夠代表那些進程能夠與這個進程通訊。端口的標識和功能由內核維護，進程能夠給內核發送一條指明新端口功能的消息，進程能夠容許對自身受權新的訪問。
地址空間不重疊的進程間的消息傳遞涉及到存儲器到存儲器的複製，所以受限於存儲器的速度，複製的速度會遠遠低於處理器的速度。
I/O和中斷管理：在爲內核結構中，硬件中斷可能被看成消息處理。微內核能夠識別中斷可是不處理中斷，它會產生一條消息給與該中斷相關聯的用戶級線程。所以，當容許一箇中斷時，一個特定的用戶級進程被指派給這個中斷，並由內核維護這個映射。把中斷轉換爲消息的工做必須由微內核完成，可是微內核並不涉及設備專用的中斷處理。
把硬件看作一組具備惟一標識號的線程，並給用戶空間中相關的軟件線程發送消息，接受線程肯定消息是否來自一箇中斷，並肯定具體是哪一個中斷。
按照理解一個操做系統的常規步驟，首先，你要先讓一個系統跑起來再說其它，至少你要知道它長什麼樣子吧。 Minix目前有三個主要的版本：
- Minix1 https://github.com/gdevic/minix1 也就是《操做系統：設計與實現》教材的演示代碼，側重於教學和學習。年代久遠，很難編譯安裝。
- Minix 2.0.4 http://download.minix3.org/previous-versions/Intel-2.0.4/ 側重於自學的一個版本，安裝稍微麻煩，須要本身作軟盤。不過這裏有個超詳細的安裝教程， 能夠參考：https://mmmyddd.github.io/wiki/debian/minixonbochs.html 讀它的源碼感受也是不錯的。
- Minix 3.2.1 http://download.minix3.org/iso/minix_R3.2.1-972156d.iso.bz2 這是個實用版本，也就是說，它是實際可用的，有iso映像可供下載，安裝很是方便。
感興趣的朋友能夠分別去安裝測試一下，通讀一下源碼。
就寫到這吧，關於鴻蒙系統行不行的問題，支持的就去申請作用戶測試，整天在網上吹毛用沒有。不支持的就靜靜看着，若是真不行，你總有一天能夠看他起高樓，眼看他宴賓客，眼看他樓塌了，又何須着急呢
下面這幾個資源還不錯，能夠一讀：
微內核IPC/RPC等 ：https://pdfs.semanticscholar.org/1cd7/edefcdd4cec5babb6b5b2d9e6572aa27a046.pdf
微內核網絡相關 ：https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=275670
微內核IO相關 ：https://pdfs.semanticscholar.org/8559/e6c101b14511002dd5178097f7d2d2acb247.pdf
QNX體系結構 ：https://cseweb.ucsd.edu/~voelker/cse221/papers/qnx-paper92.pdf
除了這些空洞的操做系統理論概念，咱們還有一個活生生的Minix。
Minix介紹 Minix是Andrew S. Tanenbaum所著《操做系統：設計與實現》教材的示例代碼。喜歡操做系統的都應該去讀一下這本書。這本書是很是少見的以一個完整的操做系統實現來說操做系統原理的教材，風格很是不通常。
Linus的Linux內核自己就參考了Minix，若是你去看Linux 0.1/1.0等早期的代碼，就會發現它和Minix是多麼的類似，不少函數名字都是同樣的。
更多詳情，參見： Minix的Wiki頁面：https://zh.wikipedia.org/wiki/MINIX