במסמך הזה מפורטות הנחיות לשותפים לשיפור זמני ההפעלה של מכשירי Android זמן האתחול הוא מרכיב חשוב בביצועי המערכת המשתמשים חייבים להמתין לסיום ההפעלה לפני שיוכלו להשתמש במכשיר. למכשירים כמו מכוניות שבהן האתחול במצב התחלתי (cold start) קורה בתדירות גבוהה יותר, לאחר הפעלה מהירה הזמן הוא קריטי (אף אחד לא אוהב להמתין עשרות שניות רק כדי להזין יעד ניווט).
מערכת Android 8.0 מאפשרת לקצר את זמני האתחול על ידי תמיכה בכמה שיפורים במגוון רכיבים. הטבלה הבאה מסכמת את הביצועים האלה שיפורים (כפי שנמדדו במכשירי Google Pixel ו-Pixel XL).
| רכיב | שיפור |
|---|---|
| תוכנת אתחול |
|
| הליבה של המכשיר |
|
| כוונון קלט/פלט |
|
| init.*.rc |
|
| אנימציית האתחול |
|
| מדיניות SELinux | חיסכון של 0.2 שניות על ידי genfscon |
אופטימיזציה של תוכנת האתחול
כדי לבצע אופטימיזציה של תוכנת האתחול לזמני אתחול משופרים:
- לרישום ביומן:
- להשבית את כתיבת היומנים ב-UART כי זה יכול לקחת הרבה זמן עם הרבה רישום ביומן. (במכשירי Google Pixel, גילינו שהיא מאטה את תוכנת האתחול בגרסה 1.5).
- כדאי לרשום רק מצבי שגיאה ולשקול לשמור פרטים אחרים בזיכרון עם מנגנון נפרד לאחזור.
- לביטול דחיסה של הליבה, כדאי להשתמש ב-LZ4 לחומרה עכשווית במקום GZIP (לדוגמה patch). חשוב לזכור אפשרויות שונות של דחיסת ליבה עשויות להכיל טעינה שונה לפריסת דחיסה, ואפשרויות מסוימות עשויות לפעול טוב יותר מאחרות לחומרה ספציפית.
- יש לבדוק זמני המתנה מיותרים כדי לבטל עזיבה מהדף הראשון או להיכנס למצב מיוחד, ולמזער אותם.
- העברת זמן האתחול בתוכנת האתחול לליבה כ-cmdline.
- בדיקת שעון המעבד (CPU) ואפשרות להשתמש במקבילות (נדרשת תמיכה עם מספר ליבות) לטעינה של ליבה (kernel) ולאתחול קלט/פלט (I/O).
אופטימיזציה של יעילות הקלט/פלט
שיפור יעילות הקלט/פלט חיוני להאצה של זמן האתחול דבר שאינו הכרחי, עד לאחר האתחול (ב-Google Pixel, כ-1.2GB של נתונים נקראים בזמן האתחול).
כוונון מערכת הקבצים
ליבת ה-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 של ליבה (kernel) (גם משמשת systrace):
trace_event=block,ext4 in BOARD_KERNEL_CMDLINE
כדי לקבל פירוט של הגישה לקובץ של כל קובץ, מבצעים את השינויים הבאים בליבה (kernel) (ליבה (kernel) של פיתוח בלבד; אין להשתמש בליבה (kernel) של ייצור):
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 הוא הגשר מהליבה עד להקמת המסגרת, בדרך כלל, מכשירים מבלים כמה שניות בשלבים שונים.
הרצת משימות במקביל
האתחול הנוכחי של Android הוא יותר או פחות תהליך עם שרשור אחד, אבל עדיין יוכל לבצע חלק מהמשימות במקביל.
- להריץ פקודות איטיות בשירות סקריפט של מעטפת ולהצטרף אליהן מאוחר יותר באמצעות
בהמתנה לנכס ספציפי. מערכת Android 8.0 תומכת בתרחיש לדוגמה הזה עם
הפקודה
wait_for_property. - זהו פעולות איטיות באתחול. המערכת רושמת ביומן את פקודת האתחול
exec/wait_for_PRO או כל פעולה שנמשכת זמן רב (ב-Android 8.0, כל פקודה שהיא
נמשך יותר מ-50 אלפיות השנייה). מוצרים לדוגמה:
init: Command 'wait_for_coldboot_done' action=wait_for_coldboot_done returned 0 took 585.012ms
בדיקת היומן הזה עשויה להצביע על הזדמנויות לשיפור.
- הפעלת השירותים והפעלת ציוד היקפי בנתיב קריטי. עבור לדוגמה, בחלק מהרשתות החברתיות נדרשת הפעלה של שירותי אבטחה לפני שמתחילים SurfaceFlinger. לבדוק את יומן המערכת כש-ServiceManager מחזיר את ההודעה "wait for" "service" – בדרך כלל זה סימן לכך שצריך להתחיל שירות תלוי קודם.
- מסירים שירותים ופקודות שלא בשימוש ב-init.*.rc. כל מה שלא נעשה בו שימוש ב- יש לדחות את האתחול עד שהאתחול הושלם.
הערה: שירות הנכס הוא חלק מתהליך ראשוני, לכן
setproperty במהלך האתחול יכול לגרום לעיכוב ארוך אם יש עומס באתחול
של פקודות מובנות.
שימוש בכוונון של מתזמן
שימוש בכוונון של לוח הזמנים להפעלה מוקדמת. דוגמה מ-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
...
התחלת זיגוטה מוקדם
מכשירים עם הצפנה מבוססת-קבצים יכולים להתחיל בזיגוטה בשלב מוקדם יותר (כברירת מחדל, זיגוטה מופעלת במחלקה הראשית, מאוחר יותר בהרבה זיגוטה-התחלה). במהלך הפעולה, הקפידו לאפשר זיגוטה לרוץ בכל המעבדים (CPU), הגדרת ה-cpuset שגויה עלולה לאלץ זיגוטה לרוץ במעבדי 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 אפשר להתחיל את אנימציית האתחול בשלב מוקדם, לפני שטוענים את נתוני המשתמשים מחיצה. עם זאת, גם כשמשתמשים בשרשרת הכלים החדשה ext4 ב-Android 8.0, fsck עדיין מופעלת מדי פעם מטעמי בטיחות, ולכן יש עיכוב בהפעלת שירות האתחול.
כדי שהאתחול יתחיל מוקדם, צריך לפצל את טעינת fstab לשני שלבים:
- בשלב המוקדם, יש לטעון רק את המחיצות (למשל
system/ו-vendor/) שלא מחייבים הרצה ולאחר מכן להפעיל את שירותי אנימציית האתחול ואת יחסי התלות שלהם (למשל servicemanager ו-screenfling). - בשלב השני, התקנת מחיצות (כמו
data/) דורשות בדיקות הרצה.
אנימציית האתחול תתחיל מהר יותר (ובזמן קבוע), ללא קשר fsck.
סיום הניקיון
לאחר קבלת אות היציאה, האתחול הוא החלק האחרון, אורך מה שעלול להאט את זמן האתחול. כאשר מפעילים את האתחול במהירות אין צורך בפעולות אנימציות שיסתירו ביעילות את השיפורים שבוצעו. ההמלצות שלנו להפוך את הלולאה החוזרת וגם את הסוף לקצר.
אופטימיזציה של SELinux
היעזרו בטיפים הבאים כדי לבצע אופטימיזציה של SELinux לשיפור זמני האתחול.
- שימוש בביטויים רגולריים נקיים (regex). ביטוי רגולרי (regex) שהפורמט שלו שגוי
עלולה להוביל לתקורה רבה כשמבצעים התאמה למדיניות SELinux עבור
sys/devicesבfile_contexts. לדוגמה, הביטוי הרגולרי (regex)/sys/devices/.*abc.*(/.*)?כופה בטעות סריקה של כל הפריטים/sys/devicesספריות משנה שמכילות את "abc", מה שמאפשר התאמות ל-/sys/devices/abcוגם ל-/sys/devices/xyz/abc. שיפור הביטוי הרגולרי ל-/sys/devices/[^/]*abc[^/]*(/.*)?יוביל להפעיל התאמה רק עבור/sys/devices/abc. - מעבירים תוויות אל genfscon. התכונה הקיימת של SELinux מעבירה קידומות להתאמת קבצים אל הליבה ב- בקובץ הבינארי SELinux, שבו הליבה (kernel) מחילה אותן על ליבה (kernel) מערכות קבצים. הפעולה הזו גם עוזרת לתקן קבצים שנוצרו באמצעות ליבה (kernel) שלא מסומנים בתווית, וכך מרוץ תהליכים שעלול להתרחש בין תהליכים במרחב המשתמשים שמנסים לגשת לפני שהתיוג מחדש יתבצע.
כלים ושיטות
אפשר להשתמש בכלים הבאים כדי לאסוף נתונים עבור יעדי אופטימיזציה.
תרשים אתחול
תרשים האתחול מספק פירוט של עומסי המעבד (CPU) והקלט/פלט (I/O) של כל התהליכים כולו המערכת. לא נדרשת בנייה מחדש של תמונת המערכת ואפשר להשתמש בה לבצע בדיקת שגרה לפני שממשיכים למערכת.
כדי להפעיל תרשים אתחול:
adb shell 'touch /data/bootchart/enabled'adb reboot
לאחר האתחול, מאחזרים את תרשים האתחול:
$ANDROID_BUILD_TOP/system/core/init/grab-bootchart.sh
בסיום, צריך למחוק את /data/bootchart/enabled כדי למנוע איסוף
את הנתונים בכל פעם.
bootchart.png לא קיים,
הבאים:
- מריצים את הפקודות הבאות:
sudo apt install python-is-python3cd ~/Documentsgit clone https://github.com/xrmx/bootchart.gitcd bootchart/pybootchartguimv main.py.in main.py - לעדכון
$ANDROID_BUILD_TOP/system/core/init/grab-bootchart.shכדי להצביע לעותק המקומי שלpybootchartgui(נמצא ב-~/Documents/bootchart/pybootchartgui.py)
מערכת
Systrace מאפשרת לאסוף גם ליבה (kernel) וגם מעקבי Android במהלך האתחול. תצוגה חזותית של מערכת הפעלה יכולה לעזור בניתוח בעיה ספציפית במהלך או אתחול. (עם זאת, כדי לבדוק את המספר הממוצע או את המספר שהצטבר במהלך את כל ההפעלה, קל יותר לבדוק ישירות את מעקב הליבה).
כדי להפעיל מערכת 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
- בקובץ
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_traceadb pull /data/local/tmp/boot_trace$ANDROID_BUILD_TOP/external/chromium-trace/systrace.py --from-file=boot_trace
כך יתאפשר מעקב (שמושבת כברירת מחדל).
כדי לבצע ניתוח קלט/פלט מפורט, כדאי להוסיף גם בלוקים, ext4 ו-f2fs.