按照發布會的PPT來看，鴻蒙OS有三層架構，第一層是微內核，第二層是基礎服務，第三層是程序框架。所謂的第二層基礎服務應該就是那些從內核態空間移到用戶態空間的基礎服務程序。當然，也可能部分還是運行的內核態，更像是混合內核。

當下的鴻蒙OS依然是基于開源框架，只是關鍵模塊自我研發，也就是說，和各大手機廠商使用Android開源系統實現各自的定制系統大概是一個意思。鴻蒙OS的愿景是2020年實現內核和應用框架自研，2021年實現軟硬件協同優化。這里的軟硬件協同優化，應該是要解決進程間通信(Inter-process communication, IPC)的性能問題，這個后面會詳細說一下。

關于鴻蒙OS不過多評價，時間是檢驗真理的唯一標準。接下來主要聊一聊微內核的概念。

微內核(Microkernel or μ-kernel)，這個概念其實是相對于宏內核(Monolithic kernel)而言的。

宏內核與微內核對比圖

我們常說的Linux/UNIX就是基于宏內核的，內核提供了相當多的功能，包括驅動，調度器，地址空間管理，進程間通信，文件系統，虛擬文件系統，系統調用等，以Linux為例，其宏內核的代碼量高達2700萬行。

宏內核系統架構

而微內核僅提供調度器，地址空間管理以及進程間通信等最基礎的功能，MINIX 3的微內核僅1.2萬行代碼。

微內核架構

宏內核與微內核代碼量為什么會有這么大的區別呢？德國計算機科學家Jochen Liedtke提出的微內核最小化原則，簡單的講就是，宏內核所提供的所有功能，可以扔到用戶態實現的，就一律扔到用戶態，內核僅保留絕對必要的功能。這有點像奧卡姆剃刀原理，如非必須，勿增實體。也就是說，宏內核提供了大量的冗余功能，兼容了太多的硬件，代碼量自然就大。而微內核甚至把硬件的驅動程序從內核剝離出去，使其運行在用戶態。

早期的宏內核，其實很像我們今天所說的微內核。早期設備本身的內存空間有限，外設也極少，內核需要支持的特性也很有限。但是隨著硬件的飛速發展，內核需要支持更多的特性和更多的外設，宏內核架構的復雜性和代碼規模也就飛速增加起來了，內核程序間的耦合度也越來越大。當然，CPU速度的提升以及內存空間的增加，讓我們基本上可以無視內核對性能的消耗。但是5G時代，一個萬物互聯(Internet of Things, IoT)的時代，將有更多的小型智能設備接入互聯網，低功耗、低內存、安全性成為了新的要求，在這些設備上跑宏內核的系統絕對不是好的選擇，由此，微內核的熱度又起來了。

早在上個世紀八九十年代，微內核一度被炒的熱火朝天。但是一直因為性能問題而沒有得到廣泛應用。直到今天，微內核在學界的熱度也遠超工業界。每一次發展微內核，都大致經歷這樣的過程：把內核的某些功能剝離出內核，然后爆發性能問題，然后再把一部分功能移回到內核。這樣就出現了很多介于宏內核和微內核之間的內核形態，一般統稱為混合內核。我們常見的Mac OS、Windows NT等用的就是這種混合內核的架構。

混合內核

近幾年谷歌一直在研發Fuchsia系統，使用的Zircon內核，才算是真正意義上的微內核。

那么，微內核到底有什么優點呢？

分布式支持：微內核各模塊采用IPC傳遞信息，對于IPC而言，無論是在本機，還是局域網或者廣域網，只要賦予進程和設備唯一的標識符，微內核的設計幾乎是天然支持分布式系統的。

模塊化、低耦合：由于大部分服務程序被轉移到用戶態空間，系統就可以按需啟動這些服務，按需接入外設。用戶態的進程各自獨立，系統耦合度大大降低。

組件故障不會導致系統重啟，內核只需要重啟故障組件就可以恢復正常，系統穩定性可以大大提高。熟悉Linux內核編程的人都知道，內核代碼出問題，往往會導致整個系統崩潰。而用戶態程序不僅不會導致系統崩潰，而且易于調試。

微內核系統功能升級也更容易，由于宏內核的很多功能都是運行在內核，跟隨系統一起啟動。雖然可以使用補丁實現故障修復和功能升級，但是依然有很多問題無法通過補丁解決，還是要依賴版本更換和重啟整個系統。而微內核只需要替換相關組件，然后重啟組件即可。

內核代碼零缺陷：由于微內核代碼量極少，可以從數學角度進行形式化驗證，從而保證內核代碼完全沒有缺陷，也就是所謂的Bug free。但是這并不是說整個系統沒有缺陷，系統本身還包括用戶態的服務程序，說白了，只是把缺陷轉移到相對安全的用戶態罷了。

那為什么微內核直到今天也沒廣泛應用呢？

原因前面已經說了，微內核的低效率是硬傷。微內核依賴IPC實現通信，宏內核的IPC效率就很不盡人意，微內核則把IPC的低效率進一步放大了。相對而言，宏內核的文件系統，驅動等以線程的方式工作在內核空間，它們之間的通信可以都在內核完成，不需要上下文切換，可以直接訪問共享資源，甚至可以直接相互調用接口達到通信的目的。而微內核則需要通過IPC通信，觸發系統調用，內存拷貝(異步通信需要拷貝兩次)，運行上下文切換，阻塞進程，這些操作開銷都很大。

Jochen Liedtke創造的L4 microkernel把IPC的系統開銷降低了一個數量級。如何實現呢？

首先，直接棄用異步IPC，所有通信均使用同步的方式。

然后把通信數據盡可能直接使用寄存器傳遞(這個涉及CPU指令集，有機會再細說)，這樣可以減少數據拷貝、內存尋址、調度器切換運行上下文的開銷。

最后為了解決同步通信造成進程阻塞的問題，引入了進程直接切換的概念，即當有數據發送時，當發送端發完數據時，直接將上下文切換到接收進程，迅速完成數據傳遞和接收。

除此之外，微內核效率差的另一個原因則是每指令的存儲器周期比宏內核要長很多，這個就需要減少微內核的緩存工作集來解決問題了。

微內核效率差的原因除了IPC、指令存儲周期長外，還有一個觀念上的問題。華為鴻蒙OS的愿景是支持多終端，統一開發流程，也就是讓一個微內核支持所有的應用場景。而提高微內核效率的一個解決方案卻是，設計單一目的(Single-purpose)、專用的微內核。不知道華為鴻蒙OS是怎么解決這個問題的，還有點小期待呢。

編輯：hfy