Fuchsia操作系統號稱谷歌的“三兒子”，前兩個是Android和Chrome OS。Android和Chrome OS的內核都是Linux，不同的是Chrome OS是針對PC的，核心功能基于Chrome瀏覽器，一切都在瀏覽器中使用，數據都在云上，更適合上網筆記本的使用，一個大的弊端是沒有桌面程序，這還怎么用？Android大家都知道針對的是移動設備，最常見的手機就是。但是安卓有很多技術弊端，例如內存碎片化、安全性、HAL層雞肋、對硬件渲染支持等缺點，后續會進行說明。所以需要一個新的OS。

隨著各種設備例如手機、平板、PC、物聯網設備等各種智能設備的普及，谷歌就想做一個統一的OS，而且要脫離Linux的魔爪，在2016年 8 Fuchsia正式推出，Fuchsia的說明是“Pink（粉紅）+Purple（紫色）=Fuchsia。它不再基于 Linux 內核，而是基于名為Zircon的微內核，并且是一個開源的實時操作系統，并使用Dart和Flutter打造全新的 UI。這下可炸鍋了，大家一看谷歌還能這么玩，各個頭部公司就紛紛入局。

更多了解參考Fuchsia中文社區：https://fuchsia-china.com/

鴻蒙 Harmony OS與Fuchsia OS

Fuchsia在2016年就開始起步了，但是幾年沒有一個對外的版本，華為的HarmoneyOS雖然在2019 年8 月華為開發者大會正式發布，但是進展神速。在手機還有各種家用電器物聯網領域HarmoneyOS的裝機量據說明年就要突破10億臺了。谷歌可以說“起了個大早，趕了個晚集”，一方面有自家的安卓，改革的動力不足。另一方面是不是因為“互聯網基因”，但是安卓系統都也維護的好好的，技術應該也沒問題，底層技術應該也很有功底，也可能是“目標太宏大，什么都想支持”所以有點難產，換句話說就是先進的思想太多了，啥都想要，最后非常多的代碼搞的沉重難行。

不得不說Fuchsia真是個好東西，里面有很多先進的技術值得去分析和學習，但是谷歌就這么開源了，可能就是現在的新玩法：不怕別人抄，重要的獲得市場，讓更多的設備用起來，相對于競爭者，更多的是愿意不付錢合作的客戶。只要領先，別人會一直在追趕但是超越不了，真是這么霸氣?；叵胂庐斈臧沧亢腿嗟亩窢幘褪且粋€活生生的例子，攪局者也許真能獲得勝利。

2020 年谷歌再次推動宣傳，Fuchsia開始二次發育，希望通過平臺開放為其吸引更多軟件開發支持者。2021 年初，先是項目的 F1 分支，之后又有 F3 分支，隨著一個個重要代碼開發步驟的落地，Fuchsia 的面貌及發展方向也開始愈發清晰。具體其官網文檔介紹網址：

雖然華為目前鴻蒙的裝機量和技術發展的很好，但是谷歌老大的地位還是不可撼動，搖旗一呼，小弟們就乖乖的歸位了，目前三星、索尼、聯發科、小米、華為、OPPO、ViVo、高通等公司已經在參與Fuchsia 項目。眾所周知，華為的風格一向比較霸道，動不動就世界第一，遙遙領先，愿意合作的商家比較少，怕被搶了飯碗。但是國家還是力挺華為，鹿死誰手，還是將來見分曉，至少：

華為現在有跟谷歌剛的資格了。

2. 揮淚拋棄Linux

Linux一直是開源軟件的領頭羊，但是我們的世界還是由商業組成的，沒有利益就沒有動力啊。Linux內核是基于GPL協議的，GPL協議意味著對源碼的任何修改與引用都必須開源，Android底層采用的Linux 內核，所以Android是開源的，而硬件廠商給Android開發的驅動是不可能開源的.

當初Google為了解決這個問題，找到了一個解決辦法，底層Linux內核做了修改，但是把驅動程序放在了Linux內核上層跑，而且特意搞了一個隔離層叫HAL，即Hardware Abstraction Layer，硬件抽象層，所以，Android 系統架構中的HAL層本質是為了規避 GPL 協議而生的，這事在當時還蠻有爭議的，但是不得不說，Google 的這種思路徹底解決了問題，既保護了「不想開源」的硬件廠商的利益，又解決了「軟硬件兼容」，既利用出色而現成的 Linux Kernel 又防止了被 Linux Kernel 傳染上GPL 后遺癥。

單一的開源協議還是生命力不那么旺盛，Fuchsia就采用了綜合的開源協議(包括BSD、 MIT 和 Apache許可證) ，任何人都可以在 Google 的公共 Git 倉庫中查看和下載。所有的代碼模塊化，其他廠商想開源就開源，隨意集成，不用擔心很多法律問題，特別是進行代碼修改后的OTA相關操作。

3.Zircon微內核歷史

Fuchsia早期是一個研究型的項目，感覺這點跟國內的不太一樣，應該是外國有錢的公司會搞一個研究所，招一些高學歷、行業內厲害的人物，隨意發揮的搞研究，偶爾會有能商用的東西就可以了，想想真是下血本搞創新啊。國內的大公司目前也開始這么搞了，可以說是暫時養了一堆高薪水的閑人，給他們自由，來搞研究，甚至能發論文就是成果。牛人就喜歡這類工作，不是做產品，出版本，上線設備維護，處理客戶需求等低級勞動。

下面介紹一個牛人TravisGeiselbrecht，其個人主頁：http://tkgeisel.com/

網頁翻譯后，如下：

感覺這也是一個老外的傳統，我見過一些教授會把自己的研究成果，學習工作經歷，甚至旅游或者生活的照片都放到個人主頁上，然后就是個人愛好，真是彰顯的個性十足，估計以后死了別人看這些資料也能了解他的一生。

Little Kernel是Travis Geiselbrecht 寫的一個針對 ARM的嵌入式開源操作系統，https://github.com/littlekernel/lk 。另外他還搞過IOS等其他OS。

然后介紹另外一個牛人Brian Swetland，他是安卓初創團體的成員，谷歌另外一個項目Magenta是從 LK 出發，提供多進程、安全空間等支持的，針對大型機（有很多 RAM，接口豐富）的內核。然后， LK for embedded + Magenta 就算是 Fuchisa OS 系統了。

4.Fuchsia與VR/AR技術領域

對于Android和Chrome OS的技術短板，Fuchsia當然是重點發力的地方，有兩個新的點就是硬實時和基于物理硬件的渲染，結合起來有一個很適合的領域就是VR/AR，Facebook都開始發力元宇宙了，大家可以看一個電影《頭號玩家》里面對虛擬現實的描述還是有那么會事?？梢姽雀柘碌氖且槐P大棋。

5.多語言應用支持和模塊化

在編碼領域，為一種新的語言，某個應用要“重復造輪子”幾乎是不可能的，例如用java寫了一個應用，再用C++寫一遍，基本很難。目前市場上的安卓程序員用java做的安卓應用還需要在IPone上用object-c再寫一遍，還要在網頁上再實現一遍，還要在小程序上再實現一遍，真是要了老命了。這個角度新的OS都是在搶應用，就是要支撐各種語言平臺的應用都可以在自己的OS上運行，來增強自己的生命力。Fuchsia已經超越平臺的角度，站在了語言的角度來支撐應用了。

原生前端應用程序是在Dart/Flutter中開發的，這將極大地促進從Android平臺到Fuchsia的遷移。同時支撐C，C++，Rust，Go和Dart等語言程序的應用。

Fuchsia，被設計成一個完全模塊化的系統，允許其庫和應用程序完全刪除，更新和添加，而不會影響系統。除了確保系統完整性之外，這還使其更加安全，例如可以使用簡單的軟件包輕松獲得安全補丁更新，而不會影響用戶數據或其他應用程序。

個語言優缺點詳細參考：

https://blog.csdn.net/weixin_39658118/article/details/104530466?spm=1001.2101.3001.6650.8&utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7EESLANDING%7Edefault-8-104530466-blog-84035260.pc_relevant_landingrelevant&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7EESLANDING%7Edefault-8-104530466-blog-84035260.pc_relevant_landingrelevant&utm_relevant_index=9

6.架構介紹

本部分參考官網文檔：

https://fuchsia.dev/fuchsia-src/get-started/sdk/learn/intro?hl=en

最小特權原則：

該系統的核心是Zircon，用于處理系統啟動和引導的內核和庫集合。所有其他系統組件都在用戶空間中實現并相互隔離，強化了最小特權原則。這包括：設備驅動程序、文件系統、網絡堆棧。

簡而言之，這要求在操作系統環境的抽象層中，每個模塊（例如進程，用戶或應用程序）只能訪問其執行所需的信息和資源。

模塊化/包容性和可升級：

模塊化意味著系統與語言無關。由于它被設計為可擴展的，并允許集成用多種語言和運行時編寫的軟件，因此您可以使用C，C++，Rust，Go，Python或Dart /Flutter進行開發。

可升級意味著Fuchsia軟件包被設計為獨立更新，甚至是即時交付，或Enphemery，這意味著軟件包被設計為解耦，因此根據需要從設備隨意添加刪除更新，并且系統始終保持最新狀態。

內核：

系統核心是Zircon，它是具有一組庫的內核，用于管理系統的啟動和引導。內核之外的所有系統組件都是在所謂的用戶空間中實現的，并且與系統的關鍵層完全隔離 - 正如我們已經在這里討論的那樣，加強了最小特權的原則 - 所以即使是設備驅動程序也在用戶空間中隔離。

Zircon帶來了我們通過微內核了解的架構和許多概念。這種架構使Fuchsia能夠盡可能地減少信任代碼的數量，從而限制內存管理，調度和IPC（進程間通信）。

因此，我們遇到了一個可能的問題：如果系統的整個核心與用戶空間隔離，我們如何開發需要信息甚至與系統“對話”的應用程序？

我們的代碼執行交互，例如：手動內存管理，系統任務或進程，IPC，設備I / O等;我們可以使用系統調用。這些執行系統調用的進程由VDSO（虛擬動態共享對象 — libzircon.so）庫執行，該庫讀取生成的內核映像，而不是直接讀取內核中的文件。

用戶空間進程通過訪問系統調用libzircon.so- 一個虛擬動態共享對象(vDSO)。Zircon vDSO 是一個ELF格式的共享庫，內核將其映射到每個新進程的地址空間。這個庫被認為是“虛擬的”，因為它直接由內核映像公開，而不是從文件加載。

Zircon 公開了三個用于運行代碼的主要內核對象：

線程：給定地址空間內的執行線程。

進程：在私有、隔離的地址空間中運行的一組可執行指令。

作業：一組相關的流程和作業。所有作業形成一個單根樹。

流程構成了系統功能的基礎。每個進程都通過它持有的各種句柄被授予一組能力。

Fuchsia 軟件可能會也可能不會在單個進程的范圍內運行。作業允許將由多個進程組成的“應用程序”作為單個實體進行控制。

進程間通信：

Zircon通道是Fuchsia接口定義語言(FIDL)描述的服務級IPC 協議的基礎 . FIDL協議是Fuchsia 程序使用的主要IPC方法。

Zircon 包含以下用于進程間通信 (IPC) 的內核對象類型：Event、Socket、Stream、Channel、FIFO，在這些對象中，通道特別適合協助啟動新進程，因為它們能夠將句柄（以及功能）轉移到另一個進程。

通道恰好有兩個端點句柄，每個句柄都由一個單獨的進程擁有。只有所有者可以讀取或寫入消息，但端點的所有權可以從一個進程轉移到另一個進程。當句柄寫入通道時，它們將從發送進程中刪除。當從通道中讀取帶有句柄的消息時，會將句柄添加到接收進程。

這里跟seL4很像，基于能力權限的通信，也是最小化權限原則的體現，就是把需要的權限都定義出來，不大片的賦予權限。

組件管理器：

組件框架的核心是組件管理器。它負責協調所有組件實例的執行，為它們提供功能，并在組件之間建立中介連接。

組件可以顯式啟動（例如，從 URL）或從對特定功能的請求中隱式啟動。組件管理器執行必要的決議以確定是啟動新組件還是將請求路由到現有實例。為了進行這種路由，每個組件都必須聲明它提供給系統的任何功能以及它使用的任何功能。組件通過capabilities獲得訪問更廣泛系統的各個部分的權限。

組件的組織：

7． 代碼下載編譯運行

參考官網說明：

https://fuchsia.dev/fuchsia-src/development?hl=en

官網說的很詳細，這里不展開說明了，需要了自己查看。

直接查看源代碼的網址：

https://cs.opensource.google/fuchsia/fuchsia

下載的代碼目錄：

zircon: 操作系統內核主體代碼，bootloader, 內核的進程，內存管理，內核對象，arch相關代碼; 以及運行在用戶態的系統核心進程，系統調用和library都在這里

garnet: 基礎軟件層的主體代碼，主要是屬于garnet層的bin文件代碼，

topaz：應用層，最關鍵的是dart,flutter的runtime

src：操作系統的基礎代碼模塊，應該來說很多屬于garnet層，這里有camera,網絡connectivity,graphics,media,security, storage

build基本上是gni文件，構建需要的

sdk構建sdk/ddk所需要的配置和腳本

boards全部是gni文件，和板子相關的編譯配置

tools本地pc機上運行的工具，比如fidl的工具

third_party從外部引入的庫，比如flatbuffers,go,dart,ssl,iperf,libpng,protobuf等等

examples一些c/c++/rust/go的是示例代碼，可以學習在fuchsia上怎么開發

bootloader:Gigaboot引導加載程序。Gigaboot引導加載程序是一個針對Zircon的UEFI引導加載程序，可以通過鏈接從iPXE、UEFI可訪問的文件系統或本地磁盤分區加載圖像。

kernel內核主體部分，進程調度，內存管理 內核對象object等

system運行在用戶態的核心系統進程，bootsvc,devmgr,svchost等，這個后面細細的品；一些基礎的library ulib和基礎的工具uapp

vdso偏底層的系統調用相關的fidl文件

在vituralbox的ubuntu上運行：fx qemu -N

審核編輯 ：李倩