เพิ่มประสิทธิภาพเวลาในการบูต

จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ

เอกสารนี้ให้คำแนะนำแก่พาร์ทเนอร์ในการปรับปรุงเวลาในการบูตสำหรับอุปกรณ์ Android บางรุ่น เวลาในการบูตเป็นส่วนประกอบที่สําคัญของประสิทธิภาพของระบบ เนื่องจากผู้ใช้ต้องรอให้บูตเสร็จก่อนจึงจะใช้อุปกรณ์ได้ สำหรับอุปกรณ์ เช่น รถยนต์ที่การบูตจากเครื่องเย็นเกิดขึ้นบ่อยครั้งกว่า การมีเวลาบูตที่รวดเร็วเป็นสิ่งสําคัญ (ไม่มีใครชอบรอหลายสิบวินาทีเพื่อป้อนปลายทางการนำทาง)

Android 8.0 ช่วยให้ระบบบูตได้เร็วขึ้นด้วยการรองรับการปรับปรุงหลายอย่างในคอมโพเนนต์ต่างๆ ตารางต่อไปนี้สรุปการปรับปรุงประสิทธิภาพเหล่านี้ (วัดในอุปกรณ์ Google Pixel และ Pixel XL)

เพิ่มประสิทธิภาพ Bootloader

วิธีเพิ่มประสิทธิภาพบูตโหลดเดอร์เพื่อปรับปรุงเวลาในการบูต

• สําหรับการบันทึก
  • ปิดใช้การเขียนบันทึกไปยัง UART เนื่องจากอาจใช้เวลานานเมื่อมีการบันทึกจำนวนมาก (ในอุปกรณ์ Google Pixel เราพบว่าการอัปเดตทำให้ Bootloader ช้าลง 1.5 วินาที)
  • บันทึกเฉพาะสถานการณ์ที่เกิดข้อผิดพลาด และพิจารณาจัดเก็บข้อมูลอื่นๆ ไว้ในหน่วยความจำด้วยกลไกการเรียกข้อมูลแยกต่างหาก
• สําหรับการคลายการบีบอัดเคอร์เนล ให้พิจารณาใช้ LZ4 สําหรับฮาร์ดแวร์สมัยใหม่แทน GZIP (เช่น patch) โปรดทราบว่าตัวเลือกการบีบอัดเคอร์เนลแต่ละตัวเลือกอาจมีเวลาในการโหลดและการขยายไฟล์ที่แตกต่างกัน และตัวเลือกบางรายการอาจทำงานได้ดีกว่าตัวเลือกอื่นๆ สำหรับฮาร์ดแวร์บางประเภท
• ตรวจสอบเวลารอที่ไม่จำเป็นสำหรับการป้อนข้อมูลการลบล้าง/โหมดพิเศษและลดเวลาดังกล่าว
• ส่งเวลาบูตที่ใช้ในบูตโหลดเดอร์ไปยังเคอร์เนลเป็น cmdline
• ตรวจสอบนาฬิกา CPU และพิจารณาการทํางานแบบขนาน (ต้องมีการรองรับแบบหลายแกน) สำหรับการโหลดเคอร์เนลและเริ่มต้น I/O

เพิ่มประสิทธิภาพ I/O

การปรับปรุงประสิทธิภาพ I/O มีความสำคัญอย่างยิ่งต่อการทำให้การบูตเร็วขึ้น และการอ่านข้อมูลที่ไม่จำเป็นควรเลื่อนไปไว้หลังการบูต (ใน Google Pixel ระบบจะอ่านข้อมูลประมาณ 1.2 GB เมื่อบูต)

ปรับแต่งระบบไฟล์

การอ่านล่วงหน้าของเคอร์เนล Linux จะทำงานเมื่อมีการอ่านไฟล์จากต้นหรือเมื่อมีการอ่านบล็อกตามลำดับ จึงจำเป็นต้องปรับแต่งพารามิเตอร์ตัวจัดตารางเวลา I/O โดยเฉพาะสำหรับการบูต (ซึ่งมีลักษณะเวิร์กโหลดแตกต่างจากแอปทั่วไป)

อุปกรณ์ที่รองรับการอัปเดตแบบราบรื่น (A/B) จะได้ประโยชน์อย่างมากจากการปรับแต่งระบบไฟล์ในการบูตครั้งแรก (เช่น 20 วินาทีใน Google Pixel) ตัวอย่างเช่น เราได้ปรับแต่งพารามิเตอร์ต่อไปนี้สําหรับ Google Pixel

on late-fs
  # boot time fs tune
    # boot time fs tune
    write /sys/block/sda/queue/iostats 0
    write /sys/block/sda/queue/scheduler cfq
    write /sys/block/sda/queue/iosched/slice_idle 0
    write /sys/block/sda/queue/read_ahead_kb 2048
    write /sys/block/sda/queue/nr_requests 256
    write /sys/block/dm-0/queue/read_ahead_kb 2048
    write /sys/block/dm-1/queue/read_ahead_kb 2048

on property:sys.boot_completed=1
    # end boot time fs tune
    write /sys/block/sda/queue/read_ahead_kb 512
    ...

เบ็ดเตล็ด

• เปิดขนาดการเรียกข้อมูลล่วงหน้าแฮช dm-verity โดยใช้การกำหนดค่าเคอร์เนล DM_VERITY_HASH_PREFETCH_MIN_SIZE (ขนาดเริ่มต้นคือ 128)
• หากต้องการให้ระบบไฟล์มีความเสถียรมากขึ้นและยกเลิกการตรวจสอบแบบบังคับที่เกิดขึ้นทุกครั้งที่บูต ให้ใช้เครื่องมือการสร้าง ext4 ใหม่โดยตั้งค่า TARGET_USES_MKE2FS ใน BoardConfig.mk

วิเคราะห์ I/O

หากต้องการทำความเข้าใจกิจกรรม I/O ระหว่างการบูต ให้ใช้ข้อมูล ftrace ของเคอร์เนล (ซึ่งใช้โดย systrace ด้วย)

trace_event=block,ext4 in BOARD_KERNEL_CMDLINE

หากต้องการแจกแจงการเข้าถึงไฟล์สำหรับแต่ละไฟล์ ให้ทำการเปลี่ยนแปลงต่อไปนี้ในเคอร์เนล (เคอร์เนลสำหรับการพัฒนาเท่านั้น อย่าใช้ในเคอร์เนลสำหรับใช้งานจริง)

diff --git a/fs/open.c b/fs/open.c
index 1651f35..a808093 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -981,6 +981,25 @@
 }
 EXPORT_SYMBOL(file_open_root);
 
+static void _trace_do_sys_open(struct file *filp, int flags, int mode, long fd)
+{
+       char *buf;
+       char *fname;
+
+       buf = kzalloc(PAGE_SIZE, GFP_KERNEL);
+       if (!buf)
+               return;
+       fname = d_path(&filp-<f_path, buf, PAGE_SIZE);
+
+       if (IS_ERR(fname))
+               goto out;
+
+       trace_printk("%s: open(\"%s\", %d, %d) fd = %ld, inode = %ld\n",
+                     current-<comm, fname, flags, mode, fd, filp-<f_inode-<i_ino);
+out:
+       kfree(buf);
+}
+
long do_sys_open(int dfd, const char __user *filename, int flags, umode_t mode)
 {
 	struct open_flags op;
@@ -1003,6 +1022,7 @@
 		} else {
 			fsnotify_open(f);
 			fd_install(fd, f);
+			_trace_do_sys_open(f, flags, mode, fd);

ใช้สคริปต์ต่อไปนี้เพื่อช่วยในการวิเคราะห์ประสิทธิภาพการบูต

• system/extras/boottime_tools/bootanalyze/bootanalyze.py วัดเวลาในการบูตพร้อมรายละเอียดขั้นตอนสำคัญในกระบวนการบูต
• system/extras/boottime_tools/io_analysis/check_file_read.py boot_trace ให้ข้อมูลการเข้าถึงสำหรับไฟล์แต่ละไฟล์
• system/extras/boottime_tools/io_analysis/check_io_trace_all.py boot_trace แสดงรายละเอียดระดับระบบ

เพิ่มประสิทธิภาพ init.*.rc

Init เป็นบริดจ์จากเคอร์เนลจนกว่าเฟรมเวิร์กจะสร้างขึ้น และโดยปกติแล้วอุปกรณ์จะใช้เวลา 2-3 วินาทีในขั้นตอนการเริ่มต้นต่างๆ

เรียกใช้งานพร้อมกัน

แม้ว่า init ของ Android ปัจจุบันจะเป็นกระบวนการแบบเธรดเดียว แต่คุณยังคงทำงานบางอย่างพร้อมกันได้

• เรียกใช้คำสั่งที่ทำงานช้าในบริการสคริปต์เชลล์และเข้าร่วมในภายหลังโดยรอพร็อพเพอร์ตี้ที่เฉพาะเจาะจง Android 8.0 รองรับกรณีการใช้งานนี้ด้วยคำสั่ง wait_for_property ใหม่
• ระบุการดำเนินการที่ช้าใน init ระบบจะบันทึกคําสั่ง init/exec/wait_for_prop หรือการดำเนินการใดๆ ที่ใช้เวลานาน (ใน Android 8.0 คําสั่งใดๆ ที่ใช้เวลานานกว่า 50 มิลลิวินาที) เช่น

  init: Command 'wait_for_coldboot_done' action=wait_for_coldboot_done returned 0 took 585.012ms

  การตรวจสอบบันทึกนี้อาจบ่งบอกถึงโอกาสในการปรับปรุง

• เริ่มบริการและเปิดใช้อุปกรณ์ต่อพ่วงในเส้นทางที่สำคัญตั้งแต่เนิ่นๆ เช่น SOC บางแห่งกำหนดให้ต้องเริ่มบริการที่เกี่ยวข้องกับการรักษาความปลอดภัยก่อนเริ่ม SurfaceFlinger ตรวจสอบบันทึกของระบบเมื่อ ServiceManager แสดงผล "รอบริการ" ซึ่งมักเป็นสัญญาณว่าต้องเริ่มบริการที่เกี่ยวข้องก่อน
• นำบริการและคำสั่งที่ไม่ได้ใช้ใน init.*.rc ออก ทุกอย่างที่ไม่ได้ใช้ในการจัดเตรียมระยะแรกควรเลื่อนไปจนกว่าระบบจะบูตเสร็จ

หมายเหตุ: บริการพร็อพเพอร์ตี้เป็นส่วนหนึ่งของกระบวนการ init ดังนั้นการเรียกใช้ setproperty ระหว่างการบูตอาจทำให้เกิดความล่าช้าเป็นเวลานานหาก init กำลังยุ่งอยู่กับคำสั่งในตัว

ใช้การปรับแต่งตัวจัดตารางเวลา

ใช้การปรับแต่งตัวจัดตารางเวลาสำหรับการบูตเครื่องตั้งแต่เนิ่นๆ ตัวอย่างจาก Google Pixel

on init
    # boottime stune
    write /dev/stune/schedtune.prefer_idle 1
    write /dev/stune/schedtune.boost 100
    on property:sys.boot_completed=1
    # reset stune
    write /dev/stune/schedtune.prefer_idle 0
    write /dev/stune/schedtune.boost 0

    # or just disable EAS during boot
    on init
    write /sys/kernel/debug/sched_features NO_ENERGY_AWARE
    on property:sys.boot_completed=1
    write /sys/kernel/debug/sched_features ENERGY_AWARE

บริการบางอย่างอาจต้องเพิ่มลำดับความสำคัญระหว่างการบูต ตัวอย่าง

init.zygote64.rc:
service zygote /system/bin/app_process64 -Xzygote /system/bin --zygote --start-system-server
    class main
    priority -20
    user root
...

เริ่มใช้ zygote ตั้งแต่เนิ่นๆ

อุปกรณ์ที่มีการเข้ารหัสตามไฟล์สามารถเริ่ม zygote ได้เร็วขึ้นที่ทริกเกอร์ zygote-start (โดยค่าเริ่มต้น zygote จะเปิดที่ class main ซึ่งช้ากว่า zygote-start มาก) เมื่อดำเนินการนี้ โปรดตรวจสอบว่าได้อนุญาตให้ zygote ทำงานใน CPU ทั้งหมด (เนื่องจากการตั้งค่า cpuset ที่ไม่ถูกต้องอาจบังคับให้ zygote ทำงานใน CPU บางรายการ)

ปิดใช้โหมดประหยัดพลังงาน

ในระหว่างการบูตอุปกรณ์ คุณสามารถปิดใช้การตั้งค่าการประหยัดพลังงานสำหรับคอมโพเนนต์ต่างๆ เช่น UFS และ/หรือตัวควบคุม CPU ได้

ข้อควรระวัง: คุณควรเปิดใช้การประหยัดพลังงานในโหมดที่ชาร์จเพื่อประสิทธิภาพ

on init
    # Disable UFS powersaving
    write /sys/devices/soc/${ro.boot.bootdevice}/clkscale_enable 0
    write /sys/devices/soc/${ro.boot.bootdevice}/clkgate_enable 0
    write /sys/devices/soc/${ro.boot.bootdevice}/hibern8_on_idle_enable 0
    write /sys/module/lpm_levels/parameters/sleep_disabled Y
on property:sys.boot_completed=1
    # Enable UFS powersaving
    write /sys/devices/soc/${ro.boot.bootdevice}/clkscale_enable 1
    write /sys/devices/soc/${ro.boot.bootdevice}/clkgate_enable 1
    write /sys/devices/soc/${ro.boot.bootdevice}/hibern8_on_idle_enable 1
    write /sys/module/lpm_levels/parameters/sleep_disabled N
on charger
    # Enable UFS powersaving
    write /sys/devices/soc/${ro.boot.bootdevice}/clkscale_enable 1
    write /sys/devices/soc/${ro.boot.bootdevice}/clkgate_enable 1
    write /sys/devices/soc/${ro.boot.bootdevice}/hibern8_on_idle_enable 1
    write /sys/class/typec/port0/port_type sink
    write /sys/module/lpm_levels/parameters/sleep_disabled N

เลื่อนเวลาการเริ่มต้นที่ไม่สําคัญ

การเริ่มต้นที่ไม่สำคัญ เช่น ZRAM สามารถเลื่อนไปไว้ที่ boot_complete

on property:sys.boot_completed=1
   # Enable ZRAM on boot_complete
   swapon_all /vendor/etc/fstab.${ro.hardware}

เพิ่มประสิทธิภาพภาพเคลื่อนไหวในการบูต

ใช้เคล็ดลับต่อไปนี้เพื่อเพิ่มประสิทธิภาพภาพเคลื่อนไหวในการบูต

กำหนดค่าการเริ่มต้นก่อนเวลา

Android 8.0 เปิดใช้ภาพเคลื่อนไหวการบูตตั้งแต่เนิ่นๆ ก่อนการต่อเชื่อมพาร์ติชัน userdata อย่างไรก็ตาม แม้จะใช้เชนเครื่องมือ ext4 ใหม่ใน Android 8.0 แต่ fsck จะยังคงทริกเกอร์เป็นระยะๆ เพื่อความปลอดภัย ซึ่งทำให้การเริ่มบริการภาพเคลื่อนไหวในบูตล่าช้า

หากต้องการให้ภาพเคลื่อนไหวในบูตเริ่มทำงานเร็วขึ้น ให้แบ่งการต่อเชื่อม fstab เป็น 2 ช่วง ดังนี้

• ในระยะเริ่มต้น ให้ต่อเชื่อมเฉพาะพาร์ติชัน (เช่น system/ และ vendor/) ที่ไม่ต้องมีการตรวจสอบการเรียกใช้ จากนั้นเริ่มบริการภาพเคลื่อนไหวในการบูตและทรัพยากร Dependency ของบริการดังกล่าว (เช่น servicemanager และ surfaceflinger)
• ในเฟสที่ 2 ให้ต่อเชื่อมพาร์ติชัน (เช่น data/) ที่จำเป็นต้องเรียกใช้การตรวจสอบ

ภาพเคลื่อนไหวในการบูตจะเริ่มต้นเร็วขึ้นมาก (และใช้เวลาคงที่) ไม่ว่าจะใช้หรือไม่ใช้ ฟีเจอร์ FSCk

ทำความสะอาดให้เสร็จสิ้น

หลังจากได้รับสัญญาณออกแล้ว ภาพเคลื่อนไหวการบูตจะเล่นส่วนสุดท้าย ซึ่งความยาวของภาพเคลื่อนไหวอาจทำให้เวลาในการบูตช้าลง ระบบที่บูตได้อย่างรวดเร็วไม่จำเป็นต้องมีภาพเคลื่อนไหวที่ยาวนานซึ่งอาจซ่อนการปรับปรุงที่ทำไว้ เราขอแนะนำให้ทำทั้งท่อนวนซ้ำและท่อนสุดท้ายให้สั้น

เพิ่มประสิทธิภาพ SELinux

ใช้เคล็ดลับต่อไปนี้เพื่อเพิ่มประสิทธิภาพ SELinux เพื่อปรับปรุงเวลาในการบูต

• ใช้นิพจน์ทั่วไป (นิพจน์ทั่วไป) ที่ชัดเจน นิพจน์ทั่วไปที่มีรูปแบบไม่ถูกต้องอาจทําให้เกิดความล่าช้ามากเมื่อจับคู่นโยบาย SELinux สําหรับ sys/devices ใน file_contexts เช่น นิพจน์ทั่วไป /sys/devices/.*abc.*(/.*)? บังคับให้สแกนไดเรกทอรีย่อยทั้งหมดของ /sys/devices ที่มี "abc" โดยไม่ได้ตั้งใจ ซึ่งทำให้จับคู่ได้ทั้ง /sys/devices/abc และ /sys/devices/xyz/abc การปรับปรุงนิพจน์ทั่วไปนี้เป็น /sys/devices/[^/]*abc[^/]*(/.*)? จะทําให้จับคู่ได้เฉพาะกับ /sys/devices/abc เท่านั้น
• ย้ายป้ายกำกับไปยัง genfscon ฟีเจอร์ SELinux ที่มีอยู่นี้จะส่งคำนำหน้าการจับคู่ไฟล์ไปยังเคอร์เนลในไบนารี SELinux ซึ่งเคอร์เนลจะใช้คำนำหน้าดังกล่าวกับระบบไฟล์ที่สร้างขึ้นโดยเคอร์เนล นอกจากนี้ ยังช่วยแก้ไขไฟล์ที่สร้างโดยเคอร์เนลที่ติดป้ายกำกับไม่ถูกต้อง ซึ่งจะช่วยป้องกันเงื่อนไขการแข่งขันที่อาจเกิดขึ้นระหว่างกระบวนการในพื้นที่ผู้ใช้ที่พยายามเข้าถึงไฟล์เหล่านี้ก่อนที่จะมีการติดป้ายกำกับใหม่

เครื่องมือและวิธีการ

ใช้เครื่องมือต่อไปนี้เพื่อช่วยรวบรวมข้อมูลสําหรับเป้าหมายการเพิ่มประสิทธิภาพ

Bootchart

Bootchart จะแสดงรายละเอียดภาระงาน CPU และ I/O ของกระบวนการทั้งหมดสำหรับทั้งระบบ โดยไม่จำเป็นต้องสร้างอิมเมจระบบใหม่และสามารถใช้เป็นการตรวจสอบความถูกต้องอย่างรวดเร็วก่อนที่จะเจาะลึกใน systrace

วิธีเปิดใช้ Bootchart

adb shell 'touch /data/bootchart/enabled'
adb reboot

หลังจากเปิดเครื่อง ให้ดึงข้อมูลแผนภูมิการบูตโดยทำดังนี้

$ANDROID_BUILD_TOP/system/core/init/grab-bootchart.sh

เมื่อเสร็จแล้ว ให้ลบ /data/bootchart/enabled เพื่อป้องกันไม่ให้ระบบรวบรวมข้อมูลทุกครั้ง

1. เรียกใช้คำสั่งต่อไปนี้

         sudo apt install python-is-python3
         cd ~/Documents
         git clone https://github.com/xrmx/bootchart.git
         cd bootchart/pybootchartgui
         mv main.py.in main.py
       

2. อัปเดต $ANDROID_BUILD_TOP/system/core/init/grab-bootchart.sh ให้ชี้ไปยังสำเนา pybootchartgui ที่อยู่ในเครื่อง (อยู่ที่ ~/Documents/bootchart/pybootchartgui.py)

Systrace

Systrace ช่วยให้รวบรวมทั้งร่องรอยเคอร์เนลและ Android ในระหว่างการบูตได้ ภาพแสดงข้อมูล systrace ช่วยในการวิเคราะห์ปัญหาที่เฉพาะเจาะจงระหว่างการบูตได้ (แต่หากต้องการตรวจสอบจำนวนโดยเฉลี่ยหรือจำนวนสะสมระหว่างการบูตทั้งหมด คุณดูการติดตามเคอร์เนลโดยตรงได้ง่ายกว่า)

วิธีเปิดใช้ Systrace ขณะบูต

• ใน frameworks/native/cmds/atrace/atrace.rc ให้เปลี่ยนข้อมูลต่อไปนี้

    write /sys/kernel/debug/tracing/tracing_on 0
    write /sys/kernel/tracing/tracing_on 0

  โดยทำดังนี้

    #    write /sys/kernel/debug/tracing/tracing_on 0
    #    write /sys/kernel/tracing/tracing_on 0

ซึ่งจะเปิดใช้การติดตาม (ซึ่งปิดอยู่โดยค่าเริ่มต้น)

• ในไฟล์ device.mk ให้เพิ่มบรรทัดต่อไปนี้

  PRODUCT_PROPERTY_OVERRIDES +=    debug.atrace.tags.enableflags=802922
  PRODUCT_PROPERTY_OVERRIDES +=    persist.traced.enable=0

• ในไฟล์ BoardConfig.mk ของอุปกรณ์ ให้เพิ่มข้อมูลต่อไปนี้

  BOARD_KERNEL_CMDLINE := ... trace_buf_size=64M trace_event=sched_wakeup,sched_switch,sched_blocked_reason,sched_cpu_hotplug

หากต้องการการวิเคราะห์ I/O โดยละเอียด ให้เพิ่มบล็อกและ ext4 และ f2fs ด้วย

• ในไฟล์ init.rc สำหรับอุปกรณ์ที่เฉพาะเจาะจง ให้เพิ่มข้อมูลต่อไปนี้

  on property:sys.boot_completed=1          // This stops tracing on boot complete
  write /d/tracing/tracing_on 0
  write /d/tracing/events/ext4/enable 0
  write /d/tracing/events/f2fs/enable 0
  write /d/tracing/events/block/enable 0

• หลังจากบูตเครื่อง ให้ดึงข้อมูลการติดตาม

  adb root && adb shell atrace --async_stop -z -c -o /data/local/tmp/boot_trace
  adb pull /data/local/tmp/boot_trace
  $ANDROID_BUILD_TOP/external/chromium-trace/systrace.py --from-file=boot_trace