מיתוסי האופטימיזציה הנפוצים ביותר באנדרואיד התנפלו

לפיכך, הרבה תסריטי אופטימיזציה של All-in-one משתמשים באותן שיטות, חלקן מיושנות לחלוטין או מזיקות בטווח הארוך. לסיכום, רוב תסריטי האופטימיזציה של 'הכל-אחד' אינם אלא כוונונים מומלצים, ללא מושג ברור כיצד או מדוע אופטימיזציות אלה 'פועלות - לאחר מכן משתמשים מהבהבים בתסריטים וטוענים כי הביצועים שלהם מהירים לפתע מהר יותר. ( כאשר למעשה, ככל הנראה, פעולה זו הפשוטה מאוד של אתחול המכשיר שלהם היא שגרמה לעליית ביצועים , כיוון שכול מהזיכרון RAM של המכשיר מתנקה) .

במאמר בלעדי זה ל- Appuals, נדגיש כמה מההמלצות הנפוצות ביותר ל' מיטוב ” ביצועי אנדרואיד, והאם הם פשוט מיתוס, או ציור לגיטימי לביצועי המכשיר.

לְהַחלִיף

בראש רשימת המיתוסים נמצאת החלפת האנדרואיד - וזה די אבסורדי מבחינת היותו נחשב אופטימיזציה לאנדרואיד. המטרה העיקרית של החלפות היא ליצור ולחבר את קובץ ההחלפה, אשר יפנה מקום אחסון בזיכרון. זה נשמע הגיוני על הנייר , אבל זה באמת ישים על א שרת , שכמעט ואין לו אינטראקטיביות.

כאשר אתה משתמש בהחלפה של טלפון ה- Android שלך באופן קבוע, זה יוביל לאיחור חמור שנובע מדברים שחולפים מעבר למטמון. תאר לעצמך, למשל, אם יישום מנסה להציג גרפיקה המאוחסנת בהחלפה, וכעת עליה לטעון מחדש את הדיסק לאחר פינוי מקום על ידי הצבת החלפת נתונים עם יישום אחר. זה ממש מבולגן.

כמה מחובבי האופטימיזציה יכולים לומר ש- swap לא הציע שום בעיות, אבל זה לא מחליף את ביצועי הביצועים - זה מנגנון האנדרואיד המובנה הרוג נמוכה , אשר יהרוג באופן קבוע תהליכים נפוחים ובעדיפות גבוהה שאינם בשימוש. LMK תוכנן במיוחד לטיפול בתנאים עם זיכרון נמוך, מופעל על ידי kswapd תהליך ובדרך כלל הורג תהליכי מרחב משתמשים. זה שונה מ OOMkiller (רוצח מחוץ לזיכרון), אבל זה נושא אחר לגמרי.

העניין הוא שמכשיר עם, למשל, זיכרון RAM של 1GB לעולם לא יוכל להגיע לנתוני הביצועים הדרושים בהחלפה, ולכן אין צורך להחליף באנדרואיד. היישום שלה פשוט כרוך בפיגור ומוביל לא הַשׁפָּלָה בביצועים, במקום לייעל את זה.

zRAM - מיושן ולא יעיל יותר

zRAM היא שיטה מוכחת ויעילה לאופטימיזציה של מכשירים, עבור מכשירים ישנים יותר תחשוב על התקנים מבוססי KitKat שפועלים רק בכ -512 מגה-בייט של זיכרון RAM. העובדה שחלק מהאנשים עדיין כוללים שינויי zRAM בתסריטי אופטימיזציה, או ממליצים על zRAM כשינוי של אופטימיזציה מודרנית, היא דוגמה לכך שאנשים בדרך כלל לא עוקבים אחר הפרוטוקולים התפעוליים האחרונים.

ה- zRAM נועד עבור מערכות SoC בעלות ליבות מרובות ליבות, כגון מכשירים המשתמשים בערכות שבבים MTK ו -512 מגה-בייט של זיכרון RAM. טלפונים סיניים זולים מאוד, בעצם. מה ש zRAM בעצם עושה הוא להפריד את הליבה דרך זרם ההצפנה.

כאשר משתמשים ב- zRAM במכשירים ישנים יותר עם ליבה אחת , גם אם מומלץ zRAM במכשירים כאלה, כמויות גדולות של פיגורים נוטות לצוץ. זה קורה גם עם טכנולוגיית KSM ( המיזוג של אותו העמוד) המשלב דפי זיכרון זהים במטרה לפנות מקום. זה למעשה מומלץ על ידי גוגל, אך מוביל לעיכובים גדולים יותר במכשירים ישנים יותר מכיוון שראשי הליבה הפעילים כל הזמן פועלים באופן רציף מהזיכרון לחיפוש דפים כפולים. ביסודו של דבר, ניסיון להריץ את צבירת האופטימיזציה מאט את המכשיר עוד יותר, באופן אירוני.

זריעה - מיושן מאז אנדרואיד 3.0

אחד הטיפים המדובבים ביותר לאופטימיזציה בקרב מכשירי אנדרואיד הוא אֶרֶז , ואנחנו בטוחים שמישהו יכול לנסות להוכיח שאנחנו טועים בנושא זה - אבל ראשית עלינו לבחון את ההיסטוריה של הזורע.

אפליקציית זריעה לאנדרואיד

כן, יש מספר רב של דוחות שמצהירים על ביצועי Android טובים יותר לאחר ההתקנה מכשירי אנדרואיד ישנים בהרבה . עם זאת, אנשים מכל סיבה שהיא מאמינים שזה אומר שזה גם אופטימיזציה ישימה עבור מכשירי אנדרואיד מודרניים , וזה אבסורדי לחלוטין. העובדה שזרע עדיין מתוחזק ומוצע כ' מוֹדֶרנִי' כלי להפחתת פיגור הוא דוגמה למידע שגוי - אם כי זו לא אשמתו של המפתח של Seeder, שכן אפילו דף חנות Play שלהם מציין ש- Seeder פחות יעיל אחרי Android 4.0+. אולם מכל סיבה שהיא, Seeder עדיין צץ בדיוני אופטימיזציה למערכות אנדרואיד מודרניות.

מה ש Seeder בעצם עושה עבור אנדרואיד 3.0 הוא לטפל בבאג שבו זמן ריצה של Android ישתמש באופן פעיל בקובץ / dev / random / לרכישת אנטרופיה. ה- / dev / אקראי / מאגר יהפוך לא יציב, והמערכת תיחסם עד שתמלא את כמות הנתונים הנדרשת - חשוב דברים קטנים כמו החיישנים והלחצנים השונים במכשיר האנדרואיד.

מחבר הזרע לקח את השד לינוקס rngd , והורכב עבור ה- inastroil של אנדרואיד כך שהוא לקח נתונים אקראיים ממסלול הרבה יותר מהיר וצפוי / dev / urandom, וממזג אותם ל- dev / random / כל שנייה, מבלי לאפשר ל- / dev / random / להתיש. זה הביא למערכת אנדרואיד שלא חוותה חוסר אנטרופיה, וביצעה חלקה בהרבה.

גוגל ניפצה את הבאג הזה אחרי אנדרואיד 3.0, אך מסיבה כלשהי, Seeder עדיין צץ 'שינויים מומלצים' רשימות לאופטימיזציה של ביצועי אנדרואיד. יתר על כן, לאפליקציית Seeder יש כמה אנלוגים כמו sEFix הכוללים את הפונקציונליות של Seeder, בין אם משתמשים באותה rngd או האלטרנטיבה זיף , או אפילו סתם קישור סימבולי בין / dev / urandom ו- dev / random. זה בהחלט חסר טעם עבור מערכות אנדרואיד מודרניות.

הסיבה שהיא חסרת טעם היא בגלל שגרסאות אנדרואיד חדשות יותר משתמשות / dev / random / בשלושה מרכיבים עיקריים - libcrypto , להצפנת חיבורי SSL, יצירת מפתחות SSH וכו 'WPA_supplication / hostapd המייצר מפתחות WEP / WPA, ולבסוף קומץ ספריות ליצירת מזהה ביצירת מערכות קבצים EXT2 / EXT3 / EXT4.

ולכן כאשר זוֹרֵעַ שיפורים מבוססי זרע כלולים בסקריפטים אופטימיזציית אופטימיזציה מודרניים לאנדרואיד, מה שבסופו של דבר קורה הַשׁפָּלָה בביצועי המכשיר, כי rngd יעיר כל הזמן את המכשיר ויגרום לעלייה בתדירות המעבד, מה שכמובן משפיע לרעה על צריכת הסוללה.

אודקס

קושחת המניות במכשירי Android כמעט תמיד אודקס. המשמעות היא שלצד החבילה הסטנדרטית לאפליקציות אנדרואיד בפורמט APK, שנמצא ב- / system / app / and / system / priv-app /, הם מאותם שמות קבצים עם סיומת .odex. קבצי ה- odex מכילים יישומי אופטימיזציה של bytecode שכבר עברו דרך המאמת והמכונה הווירטואלית של האופטימיזציה, ואז הוקלטו בקובץ נפרד תוך שימוש במשהו כמו dexopt כְּלִי.

כך שקבצי odex נועדו להוריד מכונה וירטואלית ולהציע הפעלה מזורזת של היישום odexed - בצד החיסרון, קבצי ODEX מונעים שינויים בקושחה, ויוצרים בעיות בעדכונים, כך שמסיבה זו מופצים הרבה ROMים מותאמים אישית כמו LineageOS ללא ODEX .

יצירת קבצי ODEX נעשית במספר דרכים, כמו שימוש בכלי Odexer - הבעיה היא שזה אפקט פלצבו בלבד. כאשר מערכת אנדרואיד מודרנית אינה מוצאת קבצי odex בספריית / system, המערכת תיצור אותם למעשה ותציב אותם בספריה / system / dalvik-cache /. זה בדיוק מה שקורה כאשר, למשל, אתה מהבהב גרסת אנדרואיד חדשה והיא נותנת את ההודעה 'תפוס, מייעל יישומים' לזמן מה.

Tweaks של הרפתקאות נמוכות

ריבוי משימות באנדרואיד שונה ממערכות הפעלה סלולריות אחרות במובן זה שהוא מבוסס על מודל קלאסי שבו יישומים עובדים בשקט ברקע, ואין הגבלות על מספר אפליקציות הרקע ( אלא אם כן מוגדר אפשרות באפשרויות המפתחים, אך בדרך כלל זה מומלץ נגד) - יתר על כן, הפונקציונליות של מעבר לביצוע רקע אינה נעצרת, אם כי המערכת שומרת לעצמה את הזכות להרוג אפליקציות רקע במצבי זיכרון דלים ( ראה היכן דיברנו על הרוצח נמוך זכרון ורוצח מחוץ לזיכרון מוקדם יותר במדריך זה) .

לחזור אל הרוג נמוכה מנגנון, אנדרואיד יכול להמשיך לפעול עם כמות מוגבלת של זיכרון וחוסר מחיצת החלפה. המשתמש יכול להמשיך להפעיל יישומים ולעבור ביניהם, והמערכת תהרוג בשקט אפליקציות רקע שלא היו בשימוש כדי לנסות לפנות זיכרון למשימות פעילות.

זה היה מאוד שימושי עבור Android בימים הראשונים, אם כי משום מה זה הפך פופולרי בצורה של אפליקציות להרוג משימות, שבדרך כלל מזיקות יותר מועילות. אפליקציות להרוג משימות מתעוררות במרווחי זמן מוגדרים, או מנוהלות על ידי המשתמש, ונראה כי הן מפנות כמויות גדולות של זיכרון RAM, מה שנראה כחיובי - יותר זיכרון RAM חינם פירושו מכשיר מהיר יותר, נכון? זה לא בדיוק המקרה עם אנדרואיד.

למעשה, בעל כמות גדולה של זיכרון RAM בחינם עלול להזיק לביצועי המכשיר ולחיי הסוללה. כאשר יישומים מאוחסנים בזיכרון ה- RAM של אנדרואיד, הרבה יותר קל לקרוא אותם, להפעיל אותם וכו '. מערכת אנדרואיד לא צריכה להקדיש הרבה משאבים למעבר לאפליקציה, כי היא כבר נמצאת בזיכרון.

מסיבה זו, רוצחי המשימות אינם באמת פופולריים כמו פעם, אם כי טירוני אנדרואיד עדיין נוטים לסמוך עליהם משום מה ( חוסר מידע, לצערנו) . למרבה הצער, מגמה חדשה החליפה את רוצחי המשימות, המגמה של הרוג נמוכה כוונון מנגנון. זה יהיה למשל MinFreeManager האפליקציה, והרעיון העיקרי הוא להגדיל את תקרת ה- RAM לפני שהמערכת מתחילה להרוג אפליקציות רקע.

כך לדוגמא, ה- RAM הסטנדרטי פועל בגבולות - 4, 8, 12, 24, 32 ו- 40 Mb, וכאשר ממלא מקום האחסון החינמי של 40 MB, אחת האפליקציות במטמון הנטענות בזיכרון. אבל לא רץ יופסק.

אז בעצם, לאנדרואיד תמיד יהיה לפחות 40 מגה-בייט של זיכרון זמין, וזה מספיק כדי להכיל יישום אחד נוסף לפני כן הרוג נמוכה מתחיל בתהליך הניקוי שלו - מה שאומר שאנדרואיד תמיד תעשה כמיטב יכולתה להשתמש בכמות המרבית של זיכרון RAM מבלי להפריע לחוויית המשתמש.

למרבה הצער, מה שחלק מחובבי הבישול הביתי המליץ ​​עליו המומלץ הוא שהערך יעלה ל 100 MB לפני ש- LMK ייכנס פנימה. כעת המשתמש באמת לאבד זיכרון RAM (100 - 40 = 60), כך שבמקום להשתמש במרחב זה לאחסון אפליקציות עורפיות, המערכת תשמור על כמות הזיכרון הזו חינם , ללא שום מטרה לכך.

כוונון LKM יכול להיות שימושי למכשירים ישנים בהרבה עם 512 זיכרון RAM, אבל מי הבעלים של אותם כבר? 2GB הוא ה'טווח התקציבי 'המודרני, אפילו מכשירי זיכרון RAM בנפח 4GB רואים בימינו' טווח בינוני ', כך ששינויים ב- LMK באמת מיושנים וחסרי תועלת.

התאמות קלט / פלט

בהרבה סקריפטים של אופטימיזציה לאנדרואיד תמצאו לעיתים קרובות שינויים המתייחסים לתת מערכת הקלט / פלט. לדוגמה, בואו נסתכל על ה- חֲזִיז! סקריפט המכיל שורות אלה:

הד 0> $ i / תור / סיבוב; הד 1024> $ i / queue / nr_requests;

השורה הראשונה תתן הוראות מתזמן הקלט / פלט בהתמודדות עם SSD, והשנייה מגדילה את הגודל המקסימלי של קלט / פלט התור מ- 128 ל -1024 - מכיוון שהמשתנה $ i מכיל נתיב לעץ מכשירי החסימה ב- / sys, והתסריט פועל בלולאה.

לאחר מכן, תמצא שורה הקשורה למתזמן ה- CFQ:

הד 1> $ i / תור / iosched / back_seek_penalty; הד 1> $ i / תור / iosched / low_latency; הד 1> $ i / תור / iosched / slice_idle;

לאחר מכן שורות נוספות השייכות למתכננים אחרים, אך בסופו של דבר, שתי הפקודות הראשונות אינן חסרות טעם מכיוון:

גרעין לינוקס מודרני מסוגל להבין עם איזה סוג אמצעי אחסון הוא עובד כברירת מחדל.

תור קלט-פלט ארוך ( כגון 1024) הוא חסר תועלת במכשיר אנדרואיד מודרני, למעשה הוא חסר משמעות אפילו בשולחן העבודה - הוא באמת מומלץ רק על שרתים כבדים . הטלפון שלך אינו שרת לינוקס כבד.

עבור מכשיר אנדרואיד, כמעט ואין יישומים בעדיפות גבוהה בקלט הקלט ואין מנהל התקן מכני, ולכן המתכנן הטוב ביותר הוא התור noop / FIFO, כך שמתזמן מסוג זה ' לִצבּוֹט' אינו עושה דבר מיוחד או משמעותי למערכת המשנה / פלט. למעשה, כל פקודות רשימות המסך המרובות האלה מוחלפות טוב יותר במחזור פשוט:

עבור i in / sys / block / mmc *; לעשות הד noop> $ i / תור / מתזמן הד 0> $ i / תור / iostats נעשה

זה יאפשר את מתזמן ה- noop עבור כל הכוננים מהצטברות סטטיסטיקה של קלט / פלט, שאמורה להשפיע לטובה על הביצועים, אם כי מאוד זעיר וכמעט זניח לחלוטין.

צירוף קלט / פלט נוסף וחסר תועלת שנמצא לעתים קרובות בסקריפטים של ביצועים הוא ערכי הקריאה המוגברים עבור כרטיסי SD עד 2MB. מנגנון קריאה מוקדמת מיועד לקריאת נתונים מוקדמת מהמדיה, לפני שהאפליקציה מבקשת גישה לנתונים אלה. כך שבעצם, הליבה תנסה להבין אילו נתונים יהיה צורך בעתיד, ותטען אותם מראש ב- RAM, וכך אמור להפחית את זמן ההחזרה. זה נשמע נהדר על הנייר, אך האלגוריתם לקריאה נמצא לעתים קרובות יותר לא נכון , מה שמוביל לפעולות מיותרות לחלוטין של קלט-פלט, שלא לדבר על צריכת RAM גבוהה.

ערכי קריאה גבוהים בין 1-8 מגהבייט מומלצים במערכי RAID, אך עבור מכשירי אנדרואיד, עדיף להשאיר את ערך ברירת המחדל של 128 קילו-בתים.

מערכת ניהול זיכרון וירטואלי מתאימה

טכניקה נפוצה נוספת של 'אופטימיזציה' היא כוונון תת-המערכת לניהול זיכרון וירטואלי. זה בדרך כלל מכוון רק לשני משתני גרעין, vm.dirty_background_ratio ו- vm.dirty_ratio, המיועדים להתאמת גודל המאגר לאחסון נתונים 'מלוכלכים'. מְלוּכלָך נתונים הם בדרך כלל נתונים שנכתבו לדיסק, אך יש יותר בזיכרון ומחכה שייכתב לדיסק.

ערכי טוויק אופייניים הן בהפצות לינוקס והן באנדרואיס למערכת המשנה לניהול VM יהיו כמו:

vm.dirty_background_ratio = 10 vm.dirty_ratio = 20

אז מה שזה מנסה לעשות הוא שכאשר מאגר הנתונים המלוכלך הוא 10% מכמות ה- RAM הכוללת, הוא מתעורר pdflush זורם ומתחיל לכתוב נתונים לדיסק - אם פעולת הקלטת הנתונים בדיסק תהיה אינטנסיבי מדי , המאגר ימשיך לגדול, וכאשר הוא יגיע ל -20% מה- RAM הזמין, המערכת תעבור לפעולת הכתיבה הבאה במצב סינכרוני - ללא מאגר מראש. פירוש הדבר שעבודת הכתיבה ליישום הדיסק תהיה חסום, עד שנכתבים הנתונים לדיסק (AKA 'לג').

מה שאתה צריך להבין הוא שגם אם גודל החיץ לא מגיע ל -10% , המערכת תבעט אוטומטית ב- pdflush לאחר 30 שניות. שילוב של 10/20 הוא די סביר, למשל במכשיר עם זיכרון RAM בנפח 1GB זה יהיה שווה ל- 100 / 200MB זיכרון RAM, וזה די והותר במונחים של רשומות פרץ כאשר המהירות לרוב נמוכה משיא המהירות במערכת NAND זיכרון, או כרטיס SD, כגון בעת ​​התקנת אפליקציות או העתקת קבצים מהמחשב.

משום מה, כותבי תסריטים מנסים לדחוף את הערך הזה עוד יותר גבוה, לשיעורים אבסורדיים. לדוגמא אנו יכולים למצוא את אקספליקס סקריפט אופטימיזציה בשיעור של עד 50/90.

sysctl -w vm.dirty_background_ratio = 50 sysctl -w vm.dirty_ratio = 90

במכשיר עם זיכרון של 1 ג'יגה-בייט, זה מגדיר חיץ מלוכלך ל- 500/900 מגהבייט, שהוא חסר תועלת לחלוטין עבור מכשיר אנדרואיד, מכיוון שהוא יעבוד רק תחת הקלטה מתמדת על הדיסק - משהו שקורה רק בשרת לינוקס כבד.

חֲזִיז! סקריפט משתמש בערך סביר יותר, אך בסך הכל, עדיין חסר משמעות למדי:

אם ['$ mem' -lt 524288]; אז sysctl -w vm.dirty_background_ratio = 15; sysctl -w vm.dirty_ratio = 30; elif ['$ mem' -lt 1049776]; ואז sysctl -w vm.dirty_background_ratio = 10; sysctl -w vm.dirty_ratio = 20; אחרת sysctl -w vm.dirty_background_ratio = 5; sysctl -w vm.dirty_ratio = 10; fi;

שתי הפקודות הראשונות מופעלות בסמארטפונים עם זיכרון RAM של 512 מגהבייט, השנייה - עם 1 ג'יגה בייט ואחרים - עם יותר מ -1 GB. אך למעשה יש רק סיבה אחת לשנות את הגדרות ברירת המחדל - מכשיר עם זיכרון פנימי איטי מאוד או כרטיס זיכרון. במקרה זה סביר להפיץ את ערכי המשתנים, כלומר להכין דבר כזה:

sysctl -w vm.dirty_background_ratio = 10 sysctl -w vm.dirty_ratio = 60

ואז, כאשר מערכת נחשול כותבת פעולות, מבלי שתצטרך להקליט נתונים בדיסק, עד האחרונה לא תעבור למצב סינכרוני, מה שיאפשר ליישומים להקטין את השהיה בעת ההקלטה.

שינויים נוספים וכוונון ביצועים חסרי תועלת

יש שם הרבה יותר 'אופטימיזציות' שבאמת לא עושות כלום. לרובם פשוט אין השפעה כלשהי, בעוד שאחרים עשויים להשתפר כמה היבט של ביצועים, תוך השפלת המכשיר בדרכים אחרות ( בדרך כלל זה מסתכם בביצועים לעומת ניקוז הסוללה) .

להלן מספר אופטימיזציות פופולריות נוספות שעשויות להיות שימושיות, או תלויות במערכת Android ובמכשיר.

• תאוצה - התאוצה הקטנה לשיפור ביצועים ומתח נמוך - חוסכת מעט סוללה.
• מיטוב מסדי נתונים - בתיאוריה זה צריך נותנים שיפור בביצועי המכשיר, אך ספק אם זה.
• Zipalign - למרבה האירוניה, למרות יישור תכני ה- SDK המובנה ב- Android SDK בתוך קובץ ה- APK בחנות, תוכלו למצוא הרבה תוכנות שלא מועברות באמצעות zipalign.
• השבת שירותי מערכת מיותרים, הסר מערכות שאינן בשימוש ויישומי צד שלישי הנמצאים בשימוש נדיר. בעיקרון, הסרת התקנת bloatware.
• גרעין מותאם אישית עם אופטימיזציות למכשיר ספציפי (שוב, לא כל הגרעינים טובים באותה מידה).
• תיארתי כבר noop מתזמן קלט / פלט.
• אלגוריתם הרוויה TCP Westwood - נעשה שימוש יעיל יותר ברירת המחדל של Android Cubic עבור רשתות אלחוטיות, זמין בגרעינים מותאמים אישית.

הגדרות חסרות תועלת build.prop

LaraCraft304 מ- XDA Developers forum ערך מחקר ומצא שמספר מרשים של הגדרות /system/build.prop המומלצות לשימוש 'מומחים' אינן קיימות במקור AOSP וב- CyanogenMod. הנה הרשימה:

ro.ril.disable.power.collapse ro.mot.eri.losalert.delay ro.config.hw_fast_dormancy ro.config.hw_power_saving windowsmgr.max_events_per_sec persist.cust.tel.eons ro.max.fling_velocity ro.min.fling_velocity ro. kernel.checkjni dalvik.vm.verify-bytecode debug.performance.tuning video.accelerate.hw ro.media.dec.jpeg.memcap ro.config.nocheckin profiler.force_disable_ulog profiler.force_disable_err_rpt ersist.sys.shutdownMode ro.Home