“智能终端产品的灵魂是它所依赖的软件平台以及与之相匹配的服务和生态”华为讲师方卫庆在安卓绿色联盟开发者大会中讲到。

华为如何打造智能终端的有趣灵魂系列分为(上)（下）两个篇章，本篇将对华为天生快·一生快技术产生的背景和一系列技术组合拳的打法进行详细解读。

每⼀次体验提升都是复杂系统⼯程

端侧的用户体验是一项非常复杂的系统性功能整合。上图右侧是安卓原生系统架构示意图，左侧是EMUI架构图，每一次系统侧的改进都是从底层贯穿到上层的全面提升，具体架构从下往上包括：

芯片层，由CPU、GPU、DSP、NPU、基带、传感器、多媒体器件等组成；

内核层包括驱动层、硬件抽象层。其中硬件抽象层又包括进程管理、内存管理、文件系统、网络管理等组件；

中间件主要包括大量的C和C++库，以及Java虚拟机；

再往上是跟开发者息息相关的框架层，这一层提供了大量的基础核心功能，并为上层应用提供API接口；

最上层是应用层，包括安卓的原生应用、EMUI应用、开发者第三方应用。

天生快·一生快

1.安卓系统卡顿的原因：

①安卓系统管理松散

应用缺少约束，应用质量参差不齐。

②系统资源不足

应用没有优先级，应用链加剧资源消耗。

③存储空间碎片化

经常保存、删除文件，导致存储空间碎片化，存取文件速度下降。

④数据日益庞大

图片、联系人等数据量越来越大，数据库查询、搜索速度缓慢。

2.一系列技术的组合

针对四个主要问题，通过一系列的技术组合拳，达成天生快·一生快解决方案。

F2FS新型文件系统

F2FS是为闪存设计的文件系统，相比原有的EXT4文件系统，F2FS的随机写入优化效率提升60%，磁片碎片化的情况也大大改善。

F2FS的关键技术：

①数据分配管理算法

上图中，数据管理分为两个区域，元数据区域和数据区域。

元数据区域主要写入的是SIT、NAT等，采用的是就地写入的方案。

数据区采用的是异地写入的方案，节点信息和真正的数据信息都被写入数据区域，同时由于在数据区域使用异地写入，所以会引入SSR和LFS多点写入技术。

a.SSR和LFS协同配合技术

传统的SSR异地写入方式随机写入效率比较低，所以引入了新的LFS技术，它把原来的数据块标为“脏”的同时并不需要直接做垃圾回收，而是直接在“脏”的数据块上写数据。之所以不直接全都采用SSR技术是因为大量的使用SSR会造成磁盘碎片的密集。

所以这是一个协同技术，在空闲块少的情况下采用SSR技术；空闲块多，大于5%的情况下使用LFS技术，这样可以在寿命和性能之间达成很好的平衡。

b.多点写入技术

数据区采用多点写入的方式，这种方式的优点是将不同类型、不同热度的数据写入不同的段，提高垃圾回收效率。

②引入NAT

此技术的英文全称是Node Address Table，它是一个映射表。

传统的LFS文件系统会带来一个非常有趣的现象——滚雪球效应。首先，一旦改变了任何一个数据，它便会连续不断的递归到树状结果根部，引起间接索引点、直接索引点以及Checkpoint的改变，带来大量资源的浪费，引起后期垃圾回收效率降低。所以引入索引表最大的目的是为了减少这些节点。

建立映射表后，只需更改数据文件、直接节点信息、NAT和CheckPoint就可以完成工作，而不需要占用大量磁盘空间，大大减轻GC的负担。但是这种二级指针的结构会造成一个问题：NAT的寻址比较慢。

所以通过将NAT信息写到原数据区，很大程度上缓解寻址效率底的问题。

③其他关键技术

a.垃圾回收算法

对于F-GC直接使⽤ Greedy回收策略，选出需要回收的段 ；对于B-GC，如果空闲空间少，也会直接使用Greedy回收策略，而如果空闲空间多，则会使用CB策略。

b.异常掉电保护

使用Checkpoint机制来保证文件系统的一致性。F2FS维护了两份检查点：一个是稳定的，⼀个是正在使用。在恢复过程中，使用的是稳定版本。

3.FSTRIM上的优化解决原有设计的不足

FSTRIM是用户态触发的垃圾回收方案。它的触发机制是这样的：凌晨3点以后，设备充电并待机70分钟以上，就会触发垃圾回收的行为。

但有一个问题，比如有些中老年用户喜欢晚上关机充电，有些人喜欢白天充电，可能无法触发FSTRIM，磁盘碎片得不到清理，怎么解决这个问题？ EMUI工程师调整了策略，在晚上11点之后，用户充电的同时待机半小时以上，就开始触发FSTRIM。

另外，针对习惯白天充电的用户，设计了另外一条机制：当手机72小时没有进行FSTRIM时，如果用户插上电源，待机半小时便开始FSTRIM。

而且工程师设计了实时可打断的机制，实现方式为：在Framework 层监控用户屏幕事件，一旦有屏幕idle结束，就会触发Stoptrim命令到Vold，然后Vold 发送Signal interrupt信号给trimtask来请求结束Trim，最后在kernel 层确认pending。

更精细的TRIM优化