從 Android 手機正式鋪貨的那一天起，「卡頓」「變慢」和「不跟手」等詞語便像鬼魂一樣如影隨形，出現(xiàn)在了許多普通用戶的評價和抱怨里。
為了解決這類問題，扭轉(zhuǎn)一些人的「刻板印象」，無論是谷歌自己還是稍有實力的手機廠商，都在通過各種方式優(yōu)化 Android 的性能和流暢度。作為一家以研發(fā)實力見長的科技公司，華為也在系統(tǒng)層面的優(yōu)化上投入了大量精力，這其中的一些技術(shù)甚至已經(jīng)被谷歌等采納，惠及了整個 Android 生態(tài)。
而這一次，隨著 HUAWEI P30 系列的正式發(fā)布，EMUI 9.1 也正式揭開了它的面紗。雖然表面上只多了一個小數(shù)點，但 EMUI 其實又引入了不少有針對性的「黑科技」，想在「不卡頓」這條道路上走得更遠。
「文件系統(tǒng)」并非是一個時常出現(xiàn)的名詞；但如果你格式化過 U 盤，或許會對「FAT32」、「NTFS」等英文詞語有所耳聞：對，這些都是「文件系統(tǒng)」。
文件系統(tǒng)決定了磁盤管理文件的方式——整個磁盤就好像一個偌大的圖書館，而數(shù)據(jù)就像是圖書館里的書；新進的書該如何存放，要找的舊書又插在哪個架子上，該處理掉的書要移動到哪個區(qū)域，這些都是文件系統(tǒng)所需要處理的日常。
所以文件系統(tǒng)的效率將直接影響到文件的讀取和寫入，進而影響應(yīng)用的啟動、內(nèi)容的加載、縮略圖的刷新等方方面面。
因此，文件系統(tǒng)讀寫性能的優(yōu)劣將對系統(tǒng)流暢與否起到至關(guān)重要的作用。
而在文件系統(tǒng)上下手則可以說是從根本上進行優(yōu)化了。早在 2012 年，三星等廠商就推出了 F2FS 文件系統(tǒng)，其專門為閃存芯片而設(shè)計，相較誕生于機械硬盤時代的 EXT4 文件系統(tǒng)，在隨機讀寫——尤其是寫入時，有著壓倒性的性能優(yōu)勢。對于智能手機而言，這無疑是重大利好。
可是，初期的 F2FS 還有著一些不完善的地方，所以多年以來，這一文件系統(tǒng)都沒有被廠商所大范圍接納。直到 2016 年，華為做了第一個「吃螃蟹」的人，在搭載了 EMUI 5.0 的 HUAWEI Mate 9 上首次商用了 F2FS 存儲系統(tǒng)。
F2FS 所帶來的優(yōu)勢是十分明顯的，不僅隨機讀寫更具優(yōu)勢，數(shù)據(jù)塊出現(xiàn)碎片的可能性也大幅減小，利于維持手機長時間使用的流暢性。這也是在當(dāng)時的安卓廠商里，華為敢首先打出「天生快，一生快」宣傳語的底氣所在。在華為試水成功后，其他手機廠商也開始陸續(xù)跟進，為自家的手機啟用 F2FS，谷歌去年發(fā)布的「親兒子」Pixel 3 也是其中一員。
不過，雖然對于應(yīng)用、視頻、照片等數(shù)據(jù)存儲有著優(yōu)勢，但對于系統(tǒng)本身使用的分區(qū)而言，F(xiàn)2FS 并沒有決定性的提升。出于從分區(qū)原理和使用環(huán)境的分析，以及對性能和穩(wěn)定性的平衡考量，此前大部分 Android 廠商都沒有為系統(tǒng)分區(qū)啟用 F2FS 文件系統(tǒng)。
這種在技術(shù)上的暫時妥協(xié)也帶來了問題——雖然 Android 的系統(tǒng)分區(qū)默認為只讀化處理，無法被直接進行寫入，但從嚴格意義上說，EXT4 并非是一個只讀文件系統(tǒng)，因而依然有著遭受修改的可能。
如此一來，系統(tǒng)的安全性會受到一定的威脅，同時，EXT4 本身的性能表現(xiàn)，也不足以令人滿意。
當(dāng)下已有的解決方案似乎并不能讓華為的工程師們滿意，于是，他們在 2018 年 5 月推出了一個全新的只讀文件系統(tǒng)：EROFS。
EROFS 是 Extendable Read-Only File System 的縮寫，直譯為「可擴展式只讀文件系統(tǒng)」。華為又為其取了一個非常接地氣的「昵稱」，叫做「華為超級文件系統(tǒng)」。
首先，超級文件系統(tǒng)使用了先進的壓縮算法，能在同等級的壓縮比例下，提供更佳的讀取性能；通過對輸入輸出通道的充分利用，可以降低讀放大效應(yīng)，最終實現(xiàn)多達 20% 的隨機讀取性能提升。由于壓縮后不會損失太多性能，所以系統(tǒng)分區(qū)可以放心地保持較高的壓縮比例，繼而讓留出更多空間存儲數(shù)據(jù)成為可能。
以 P30 Pro 128GB 版本為例，其系統(tǒng)占用空間相比之下少了 2GB 之多，更多的空間意味著我們可以在手機里安裝更多的應(yīng)用和游戲。
其次，提升的隨機讀取速度也讓系統(tǒng)響應(yīng)速度的提升成為了可能。在發(fā)布之初，華為的工程師就在麒麟 970 上進行過測試，測試結(jié)果顯示，相較 EXT4，超級文件系統(tǒng)能提供最多翻倍的性能優(yōu)勢；這種優(yōu)勢在小壓縮率下尤為明顯，而即便是 100% 壓縮，表現(xiàn)也有提升。
最后，超級文件系統(tǒng)從誕生之初就被設(shè)計為只讀式模式；因此，它無法被輕易地開啟寫入權(quán)限，第三方想要改寫系統(tǒng)比登天還難，系統(tǒng)的安全性自然也就得到了保障。
從以上的內(nèi)容中，我們可以一窺超級文件系統(tǒng)的先進性：不僅節(jié)省空間，同時還能提供更好的性能，系統(tǒng)本身的安全性，也將得到加固化的保障。
這一文件系統(tǒng)已經(jīng)被并入 Linux 內(nèi)核的主線，成為 Linux 開源世界的一部分，相信在不久的將來，基于 Linux 的 Android 也會對此進行跟進。而目前而言 EMUI 9.1 則可以說是有著明顯的先發(fā)優(yōu)勢。
如果你是一位老 Android 用戶，相信會對圍繞著那些第三方應(yīng)用的一些「怪問題」感同身受。
Android 2.X - 4.X 時，應(yīng)用打開速度不佳，運行起來有時還會卡頓一下；而到了 Android 5.0 — 6.0，應(yīng)用的流暢度上去了，但安裝過程卻變得無比漫長，有時候裝一個應(yīng)用要兩三分鐘，一旦遇上更新系統(tǒng)，還要花不少時間等待「優(yōu)化應(yīng)用」。
這些現(xiàn)象都是 CPU 的原理所決定的，就像我們對著不懂中文的外國人搭話時他們難以理解我們要表達的意思，CPU 也無法直接處理丟給它的英文字母碼代碼。
CPU 能看懂的，只有由無數(shù)個「0」和「1」組成的二進制代碼，也就是「機器碼」。這時，我們就需要用一些方法將應(yīng)用開發(fā)過程中所用的編程語言轉(zhuǎn)化為機器碼，「讀」給 CPU。和現(xiàn)實中的語言翻譯一樣，這樣的過程也是一種翻譯，也就是我們所說的「編譯」。
在 Android 的發(fā)展初期，Google 使用了兩種方案：第一種叫解釋執(zhí)行，也就是將代碼一句一句翻譯成機器碼；第二種叫 JIT（Just In Time），在應(yīng)用運行的同時，實時編譯出機器碼。
這兩種方案構(gòu)成了 Android 初期的應(yīng)用編譯方式。它們的優(yōu)點是對內(nèi)存和存儲空間的壓力很小，但缺點也很明顯：想象一下平時交流時，對面說一句話，中間人再翻譯一句給你聽，然后你才能明白他的意思，溝通效率無疑是較為低下的。所以那個時候 Android 應(yīng)用的執(zhí)行效率較低，卡頓、無響應(yīng)甚至死機的現(xiàn)象也時有發(fā)生。
為了解決這種「邊解釋邊執(zhí)行」帶來的效率問題，谷歌又在 Android 5.0 開始引入了新的編譯方式：AOT（Ahead Of Time），這種方式會在應(yīng)用安裝時就進行編譯，并將編譯好的機器碼儲存在設(shè)備中。
這樣每次打開應(yīng)用都會直接執(zhí)行機器碼，運行時省掉了編譯過程；不僅打開應(yīng)用的速度更快，用起來也更流暢，同時由于不需要實時編譯，運算壓力降低，還起到了省電的功效。
不過 AOT 帶來的問題也很明顯：編譯成機器碼是一項耗時的工作，而這毫無疑問地會延長安裝所需的時間。根據(jù)應(yīng)用本身的大小和復(fù)雜程度，所需要的安裝時間也會受到影響；大一些的應(yīng)用，甚至?xí)枰獢?shù)分鐘。
而且，編譯好的機器碼，本身也較為占用存儲空間；對于一些不常用的應(yīng)用，就有點顯得得不償失了。
所以，在 Android 7.0 之后，谷歌又重新引入了優(yōu)化過的 JIT 編譯模式，三種模式并存，只將一部分重要的代碼利用 AOT 編譯，其他代碼實時編譯，從而達到二者之間的平衡。
但是既然依舊保留了「邊轉(zhuǎn)化，邊執(zhí)行」的環(huán)節(jié)，在這個過程中，性能依舊不可避免地會遭受到一定損失。有沒有辦法讓系統(tǒng)更高效地運行程序呢？
華為則提出了一種新的編譯方式：在開發(fā)環(huán)境就直接一次性將機器碼編譯出來，打包在安裝包中；應(yīng)用安裝完畢就可以直接運行機器碼，不需要手機端再次負責(zé)編譯工作，實現(xiàn)運行效率的最大化提升。這一編譯方式的落地化成果，就是隨 EMUI 9.1 一道發(fā)布的「華為方舟編譯器」。
據(jù)官方提供的數(shù)據(jù)，應(yīng)用了「方舟編譯器」的 EMUI 系統(tǒng)組件，流暢度獲得了 24% 的提升；而響應(yīng)速度更是提升了 44%，獲益極為明顯。
而對于第三方應(yīng)用的適配也在緊鑼密鼓的進行中，實驗顯示采用了「方舟編譯器」的微博極速版運行速度和流暢度提升明顯。
為了一探究竟，我們下載了微博極速版進行體驗。這里需要注意的一點是，在與EMUI的開發(fā)人員溝通中得知，目前從華為應(yīng)用市場上下載的微博極速版并非是使用了「方舟編譯器」的版本，新版本正在緊張的后期測試中，用戶想要體驗還需稍等些時日。雖然如此，但我們卻發(fā)現(xiàn)即使是普通的微博極速版，在面對性能同樣優(yōu)秀的競爭對手時，EMUI在打開和加載首頁的速度上依舊略勝一籌；而在切換模塊、滾動時間流，以及加載圖片和視頻時，也有著更流暢的體驗。這其中的原因可能是「方舟編譯器」對system service也有一定程度的提升，如果應(yīng)用也采用了新的編譯機制，優(yōu)勢或許將會更明顯。
和上文中的超級文件系統(tǒng)一樣，華為依舊沒有將其保留給自己，而是決定讓更多 App 開發(fā)者和手機廠商加入，共同普及這一新的編譯方式；「方舟編譯器」將在 2019 年全面開源，憑借華為的市場占有率，手持搭載 EMUI 9.1 系統(tǒng)的手機，或許很快就能體驗到這一架構(gòu)級加速的體驗提升。
超級文件系統(tǒng)和「方舟編譯器」的推出，讓我們看到了華為的問題解決思路：如果現(xiàn)在的方案不夠好，那就自己造一個。
但與此同時，對于超級文件系統(tǒng)和方舟編譯器這樣的成果，華為也并沒有選擇封閉。在將這些創(chuàng)新回饋給開源社區(qū)后，更多的 Android 用戶其實能夠因此而受益——當(dāng)然，如果你等不及這些「黑科技」在整個 Android 生態(tài)中鋪開，也可以在搭載了 EMUI 9.1 的華為 P30 系列手機上搶先體驗。
聯(lián)系客服
