全志系列开机启动优化

一、Linux 优化常见措施

1、bootLoader优化常见措施

1.1、优化usb burn key检测

        默认SDK需要打开burn_key，导致每次开机都需要检查usb是否存在，假设usb不存在，当前整usb检查过程耗时800ms，原因是检测usb的方法实现有问题，不能真正判断usb是否存在而导致了延时的存在。修复检测usb的方法后，可以优化开机启动时间800ms，也可以将sys_confg.fex的burn_key设置为0。

注：在 Tina系统的Linux‑5.4内核版本及以后，取消了sys_config.fex配置，因此原先放在sys_config.fex的配置迁移到uboot‑board.dts中。在Linux‑4.9中，部分平台也采用了这种方式

uboot目录下找到对应的设备树文件，将target节点下的burn_key的属性改成 0 即可。

T527中对应路径为：device/config/chips/t527/configs/nongji/uboot-board.dts

1.2、减少bootloader打印

        将sys_confg.fex的debug_mode改为0后，整个uboot的打印基本就没有了，主要是减少了boot0的打印，因为那会频率低，串口输出慢，开机时间节省大概130ms。Debug_mode=1 是正常的发布打印等级，如果要看到更多的ubootlog，需要设置为4，如果设置为0，则开机启动时间能减少130ms。

注：Linux 5.15 内核后在设备树中修改

2、kernel 优化常见措施

2.1、内核模块的裁剪

        指的是一些不必要的驱动模块，尤其是耗时的模块，可以通过 make menuconfig 的方法把不必要的硬件驱动去除

2.2、优化多款 sensor 启动耗时

        通过 cat /proc/bootevent 排查内核阶段 sensor 耗时情况，是否有有多个 sensor 同时启动。例如单个 sensor 超过500ms的现象，仔细阅读代码发现单个 sensor 启动耗时长的原因是因为代码里面有 msleep(500)。

2.3、提高 emmc/flash 读写性能

        全志系列部分板卡有 nand 和 emmc 两种 flash 介质，其中 emmc 还有高速模式（HS400-100MHz），通过实验发现，nand flash 介质对启动影响特别大，由于 nand 的连续读速度慢（ext4:20MB/s，squashfs：16MB/s），开机启动时间长达 60s 左右。而 emmc 即使在 SDR50 的模式下连续读（65MB/s），开机启动时间 30s 左右。当把 emmc 改为高速模式后，开机启动时间有大概2.2s 的优化，主要原因是整个启动过程读 system vendor 分区的速度快了。

在设备树中修改 emmc 为高速的模式：

2.4、文件系统的选择

        文件系统有很多种，例如squashfs和 ext4，但是 squashfs 文件系统的缺点是压缩的，每次读内容都需要解压，当然就会有所损耗，实测开机启动速度，对于 emmc 设备，有 3.5s 的影响。对于存储设备大或者没有文件系统要求的产品，可以选择 ext4 文件系统，例如车载产品。这样可以节省 3.5s 的开机启动时间。

需要在设备树中进行配置：

同步修改BoardConfig.mk文件

system：

vendor:

2.5、initcall 并行化

        目的是将 module_init 的模块并行化处理，有了多线程处理 module_init，还需要观察自己平台哪些模块可以并行处理。这个方法在 v 系列的产品中有起到一定的作用，有些平台没有得到明显的改善。通过实验发现，修改后有大概几十 ms 的优化，优化效果不明显。

举个例子

initcall 机制的实现在include/linux/init.h文件里，每一个initcall函数都通过不同的前缀加以修饰，例如：

pure_initcall
subsys_initcall
core_initcall
fs_initcall
arch_initcall
...

二、Android 优化常见措施

1、调整 IO 参数

通过开机启动的过程中适当调整 io 参数，有助于 IO 速度的提升，最终帮助开机启动速度。

在方案的 rc 文件添加下面修改：

2、使用简单的动画

        如果某些平台对开机动画没有那么强烈的要求，可以裁剪一些动画图片，甚至不启动动画服务，可以节省 1.8s 左右。

3、提前结束动画

        开机动画退出信号意味着系统开机启动的完成，所以早点结束动画能够优化启动时间，我们在 LaunchTimeLocked 阶段提前设置动画退出的属性，有利于加速 launcher 的启动。

4、异步加载不紧急的 server

        通过下面命令，可以查看开机过程中，system server 启动的详细过程，可以知道哪些服务比较耗时。

logcat | grep SystemServerTiming

可以采用的是一个 system 线程池的方法，将不紧急的任务进行异步处理

5、延迟启动不紧急的 systemui

开机启动过程中，最后环节比较耗时的就是 systemui 的启动，通过

logcat | grep SystemUIBootTiming

可查看过程。调整时注意有没有依赖关系，不然一旦调整，系统就会出现开机异常

6、 使用简单的 launcher

        原生 launcher3 比较复杂，如果针对产品不需要原生 launcher3，可以使用自己的 launcher，且可以通过设置 android:directBootAware=“true” 属性来提前启动 launcher，从而绕过 directboot 机制导致的 launcher 启动时间晚的问题。

7、 减少不必要的预装 apk

针对产品的需求来裁剪不必要的 apk，如果能裁剪掉原生大部分的 apk，能够节省 500ms。

8、删除 gms 包

        有些平台不需要过 cts 测试，应当把 gms 包删除，带有 gms 包的系统将会在包扫描以及应用启动方面增加启动时间，在 A50 的 emmc 设备上测试，如果删除 gms 包，可以节省 1.9s 的开机时间。对于盒子、车载等类似产品，如果不需要过 CTS 测试的话，不应该带有 gms 包。

应当在方案目录的方案名字的 mk 文件下删除改行。

$(call inherit-product-if-exists, vendor/google/products/gms_go-mandatory.mk)

9、 UDISK 分区的文件系统类型

        T 系列因为没有电池，关机常常不是按 power 键关机，换句话说不是走正常的 reboot/poweroff流程，而是直接掉电关机，这样会导致系统再次起来后，会在 mount 阶段多一个 check 流程，相当于修复文件系统，通过实验发现f2fs 文件系统在 check 阶段耗时 2s，相比之下 ext4 在这方面比较好，只需要 0.7s。所以，针对 T 系列的产品，建议 UDISK 使用 ext4文件系统。