从 Android 手机正式铺货的那一天起，「卡顿」「变慢」和「不跟手」等词语便像鬼魂一样如影随形，出现在了许多普通用户的评价和抱怨里。
为了解决这类问题，扭转一些人的「刻板印象」，无论是谷歌自己还是稍有实力的手机厂商，都在通过各种方式优化 Android 的性能和流畅度。作为一家以研发实力见长的科技公司，华为也在系统层面的优化上投入了大量精力，这其中的一些技术甚至已经被谷歌等采纳，惠及了整个 Android 生态。
而这一次，随着 HUAWEI P30 系列的正式发布，EMUI 9.1 也正式揭开了它的面纱。虽然表面上只多了一个小数点，但 EMUI 其实又引入了不少有针对性的「黑科技」，想在「不卡顿」这条道路上走得更远。
「文件系统」并非是一个时常出现的名词；但如果你格式化过 U 盘，或许会对「FAT32」、「NTFS」等英文词语有所耳闻：对，这些都是「文件系统」。
文件系统决定了磁盘管理文件的方式——整个磁盘就好像一个偌大的图书馆，而数据就像是图书馆里的书；新进的书该如何存放，要找的旧书又插在哪个架子上，该处理掉的书要移动到哪个区域，这些都是文件系统所需要处理的日常。
所以文件系统的效率将直接影响到文件的读取和写入，进而影响应用的启动、内容的加载、缩略图的刷新等方方面面。
因此，文件系统读写性能的优劣将对系统流畅与否起到至关重要的作用。
而在文件系统上下手则可以说是从根本上进行优化了。早在 2012 年，三星等厂商就推出了 F2FS 文件系统，其专门为闪存芯片而设计，相较诞生于机械硬盘时代的 EXT4 文件系统，在随机读写——尤其是写入时，有着压倒性的性能优势。对于智能手机而言，这无疑是重大利好。
可是，初期的 F2FS 还有着一些不完善的地方，所以多年以来，这一文件系统都没有被厂商所大范围接纳。直到 2016 年，华为做了第一个「吃螃蟹」的人，在搭载了 EMUI 5.0 的 HUAWEI Mate 9 上首次商用了 F2FS 存储系统。
F2FS 所带来的优势是十分明显的，不仅随机读写更具优势，数据块出现碎片的可能性也大幅减小，利于维持手机长时间使用的流畅性。这也是在当时的安卓厂商里，华为敢首先打出「天生快，一生快」宣传语的底气所在。在华为试水成功后，其他手机厂商也开始陆续跟进，为自家的手机启用 F2FS，谷歌去年发布的「亲儿子」Pixel 3 也是其中一员。
不过，虽然对于应用、视频、照片等数据存储有着优势，但对于系统本身使用的分区而言，F2FS 并没有决定性的提升。出于从分区原理和使用环境的分析，以及对性能和稳定性的平衡考量，此前大部分 Android 厂商都没有为系统分区启用 F2FS 文件系统。
这种在技术上的暂时妥协也带来了问题——虽然 Android 的系统分区默认为只读化处理，无法被直接进行写入，但从严格意义上说，EXT4 并非是一个只读文件系统，因而依然有着遭受修改的可能。
如此一来，系统的安全性会受到一定的威胁，同时，EXT4 本身的性能表现，也不足以令人满意。
当下已有的解决方案似乎并不能让华为的工程师们满意，于是，他们在 2018 年 5 月推出了一个全新的只读文件系统：EROFS。
EROFS 是 Extendable Read-Only File System 的缩写，直译为「可扩展式只读文件系统」。华为又为其取了一个非常接地气的「昵称」，叫做「华为超级文件系统」。
那么这个文件系统「超级」在何处呢？
首先，超级文件系统使用了先进的压缩算法，能在同等级的压缩比例下，提供更佳的读取性能；通过对输入输出通道的充分利用，可以降低读放大效应，最终实现多达 20% 的随机读取性能提升。由于压缩后不会损失太多性能，所以系统分区可以放心地保持较高的压缩比例，继而让留出更多空间存储数据成为可能。
以 P30 Pro 128GB 版本为例，其系统占用空间相比之下少了 2GB 之多，更多的空间意味着我们可以在手机里安装更多的应用和游戏。
其次，提升的随机读取速度也让系统响应速度的提升成为了可能。在发布之初，华为的工程师就在麒麟 970 上进行过测试，测试结果显示，相较 EXT4，超级文件系统能提供最多翻倍的性能优势；这种优势在小压缩率下尤为明显，而即便是 100% 压缩，表现也有提升。
最后，超级文件系统从诞生之初就被设计为只读式模式；因此，它无法被轻易地开启写入权限，第三方想要改写系统比登天还难，系统的安全性自然也就得到了保障。
从以上的内容中，我们可以一窥超级文件系统的先进性：不仅节省空间，同时还能提供更好的性能，系统本身的安全性，也将得到加固化的保障。
这一文件系统已经被并入 Linux 内核的主线，成为 Linux 开源世界的一部分，相信在不久的将来，基于 Linux 的 Android 也会对此进行跟进。而目前而言 EMUI 9.1 则可以说是有着明显的先发优势。
如果你是一位老 Android 用户，相信会对围绕着那些第三方应用的一些「怪问题」感同身受。
Android 2.X - 4.X 时，应用打开速度不佳，运行起来有时还会卡顿一下；而到了 Android 5.0 — 6.0，应用的流畅度上去了，但安装过程却变得无比漫长，有时候装一个应用要两三分钟，一旦遇上更新系统，还要花不少时间等待「优化应用」。
这些现象都是 CPU 的原理所决定的，就像我们对着不懂中文的外国人搭话时他们难以理解我们要表达的意思，CPU 也无法直接处理丢给它的英文字母码代码。
CPU 能看懂的，只有由无数个「0」和「1」组成的二进制代码，也就是「机器码」。这时，我们就需要用一些方法将应用开发过程中所用的编程语言转化为机器码，「读」给 CPU。和现实中的语言翻译一样，这样的过程也是一种翻译，也就是我们所说的「编译」。
在 Android 的发展初期，Google 使用了两种方案：第一种叫解释执行，也就是将代码一句一句翻译成机器码；第二种叫 JIT（Just In Time），在应用运行的同时，实时编译出机器码。
这两种方案构成了 Android 初期的应用编译方式。它们的优点是对内存和存储空间的压力很小，但缺点也很明显：想象一下平时交流时，对面说一句话，中间人再翻译一句给你听，然后你才能明白他的意思，沟通效率无疑是较为低下的。所以那个时候 Android 应用的执行效率较低，卡顿、无响应甚至死机的现象也时有发生。
为了解决这种「边解释边执行」带来的效率问题，谷歌又在 Android 5.0 开始引入了新的编译方式：AOT（Ahead Of Time），这种方式会在应用安装时就进行编译，并将编译好的机器码储存在设备中。
这样每次打开应用都会直接执行机器码，运行时省掉了编译过程；不仅打开应用的速度更快，用起来也更流畅，同时由于不需要实时编译，运算压力降低，还起到了省电的功效。
不过 AOT 带来的问题也很明显：编译成机器码是一项耗时的工作，而这毫无疑问地会延长安装所需的时间。根据应用本身的大小和复杂程度，所需要的安装时间也会受到影响；大一些的应用，甚至会需要数分钟。
而且，编译好的机器码，本身也较为占用存储空间；对于一些不常用的应用，就有点显得得不偿失了。
所以，在 Android 7.0 之后，谷歌又重新引入了优化过的 JIT 编译模式，三种模式并存，只将一部分重要的代码利用 AOT 编译，其他代码实时编译，从而达到二者之间的平衡。
但是既然依旧保留了「边转化，边执行」的环节，在这个过程中，性能依旧不可避免地会遭受到一定损失。有没有办法让系统更高效地运行程序呢？
华为则提出了一种新的编译方式：在开发环境就直接一次性将机器码编译出来，打包在安装包中；应用安装完毕就可以直接运行机器码，不需要手机端再次负责编译工作，实现运行效率的最大化提升。这一编译方式的落地化成果，就是随 EMUI 9.1 一道发布的「华为方舟编译器」。
据官方提供的数据，应用了「方舟编译器」的 EMUI 系统组件，流畅度获得了 24% 的提升；而响应速度更是提升了 44%，获益极为明显。
而对于第三方应用的适配也在紧锣密鼓的进行中，实验显示采用了「方舟编译器」的微博极速版运行速度和流畅度提升明显。
为了一探究竟，我们下载了微博极速版进行体验。这里需要注意的一点是，在与EMUI的开发人员沟通中得知，目前从华为应用市场上下载的微博极速版并非是使用了「方舟编译器」的版本，新版本正在紧张的后期测试中，用户想要体验还需稍等些时日。虽然如此，但我们却发现即使是普通的微博极速版，在面对性能同样优秀的竞争对手时，EMUI在打开和加载首页的速度上依旧略胜一筹；而在切换模块、滚动时间流，以及加载图片和视频时，也有着更流畅的体验。这其中的原因可能是「方舟编译器」对system service也有一定程度的提升，如果应用也采用了新的编译机制，优势或许将会更明显。
和上文中的超级文件系统一样，华为依旧没有将其保留给自己，而是决定让更多 App 开发者和手机厂商加入，共同普及这一新的编译方式；「方舟编译器」将在 2019 年全面开源，凭借华为的市场占有率，手持搭载 EMUI 9.1 系统的手机，或许很快就能体验到这一架构级加速的体验提升。
超级文件系统和「方舟编译器」的推出，让我们看到了华为的问题解决思路：如果现在的方案不够好，那就自己造一个。
但与此同时，对于超级文件系统和方舟编译器这样的成果，华为也并没有选择封闭。在将这些创新回馈给开源社区后，更多的 Android 用户其实能够因此而受益——当然，如果你等不及这些「黑科技」在整个 Android 生态中铺开，也可以在搭载了 EMUI 9.1 的华为 P30 系列手机上抢先体验。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。