מה לנקות מנייד גלקסי 6 שהתחיל להיות קצת איטי?

המכשיר הוא

Galaxy S6

SM-G920F

Android 7.0

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

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

תודה.

תנסה לנפח אוויר או להחליף לג'אנטים קלים יותר.

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

אני מקווה שכך יהיה גם אצלך.

תודה XVSTI.

למה בעצם הם מאיטים לקראת סוף חייהם? הרי מעבד לא מתבלה כמו רכיב מכני, למשל.

מה גורם להם להיות איטיים יותר גם לאחר הפעולה שאתה המלצת עליה? שמחזיקה כאמור זמן מואט ואז שוב המכשיר מאט?

העובדה שכל שאר הדברים נהיים כבדים יותר.

אפליקציות , אתרים ושאר הדרישות שלך מהמכשיר שגם אם אתה לא שם לב נהיות יותר גבוהות.

למה בעצם הם מאיטים לקראת סוף חייהם?

כמה דברים.

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

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

ג) ניהול לא יעיל של זיכרון ע"י מערכת הפעלה. אם כי היום אנדרואיד מסתדרת עם זה טוב.

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

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

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

ג) ניהול לא יעיל של זיכרון ע"י מערכת הפעלה. אם כי היום אנדרואיד מסתדרת עם זה טוב.

זהירות ------- חפירה -----------

שלילי - לדחוף יותר זיכרון וכח עיבוד - זה לא להסתדר יותר טוב - זה לשים פלסטר יותר גדול

כדי להבין את כל הנושא - צריך קצת להבין דרכים שונות לניהול ופינוי זיכרון.

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

בiOS עובדים עם מערכת שנקראת Reference counting - שבגדול - בסוף כל Runcycle זיכרון שלא מוגדר כ״נחוץ״ מפונה בצורה דטרמיניסטית וללא צורך בחישובים מורכבים. זה הרבה יותר מהיר. כמובן שיש Gotchas - כמו שמפתחים עלולים למצא את עצמם מחזיקים זיכרון שהם לא צריכים - אבל עם ההשתכללות של הכלי פיתוח (אפשר לקרא על ARC - Automatic reference counting) שמכניסים את הקראיות בזמן קומפילציה בצורה חכמה יחסית - זה כבר לא כזה מסובך.

בנוסף - המערכת הפעלה עצמה מתריאה לאפליקציה בכל מני מקומות לגבי מצב הזיכרון בצורה אקטיבית ויש Watchdog של המערכת הפעלה שמגביל אפליקציות מלתפוס יותר מדי זיכרון / יותר מדי מהר.

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

וד״א - שלא תחשוב שזה רק לגבי iOS - גם במק הם הציגו את זה לפני הרבה זמן - וממש הוציאו Garbage collection מהספריות שלהם לפני שלוש שנים בערך.

כמובן שזה לא פיצ׳ר של אפל ספציפית אלא פיצ׳ר של סביבה ויש מימושים דומים / זהים בהרבה שפות - כולל בWindows.

חומר קריאה מרתק:

https://en.wikipedia.org/wiki/Reference_counting

תודה, החכמתי

זהירות ------- חפירה -----------

 

שלילי - לדחוף יותר זיכרון וכח עיבוד - זה לא להסתדר יותר טוב - זה לשים פלסטר יותר גדול

 

כדי להבין את כל הנושא - צריך קצת להבין דרכים שונות לניהול ופינוי זיכרון.

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

 

בiOS עובדים עם מערכת שנקראת Reference counting - שבגדול - בסוף כל Runcycle זיכרון שלא מוגדר כ״נחוץ״ מפונה בצורה דטרמיניסטית וללא צורך בחישובים מורכבים. זה הרבה יותר מהיר. כמובן שיש Gotchas - כמו שמפתחים עלולים למצא את עצמם מחזיקים זיכרון שהם לא צריכים - אבל עם ההשתכללות של הכלי פיתוח (אפשר לקרא על ARC - Automatic reference counting) שמכניסים את הקראיות בזמן קומפילציה בצורה חכמה יחסית - זה כבר לא כזה מסובך.

 

בנוסף - המערכת הפעלה עצמה מתריאה לאפליקציה בכל מני מקומות לגבי מצב הזיכרון בצורה אקטיבית ויש Watchdog של המערכת הפעלה שמגביל אפליקציות מלתפוס יותר מדי זיכרון / יותר מדי מהר.

 

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

 

וד״א - שלא תחשוב שזה רק לגבי iOS - גם במק הם הציגו את זה לפני הרבה זמן - וממש הוציאו Garbage collection מהספריות שלהם לפני שלוש שנים בערך.

 

כמובן שזה לא פיצ׳ר של אפל ספציפית אלא פיצ׳ר של סביבה ויש מימושים דומים / זהים בהרבה שפות - כולל בWindows.

חומר קריאה מרתק:

https://en.wikipedia.org/wiki/Reference_counting

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

בכל אופן, אין קשר בין זה לבין האטה של מכשירים "קשישים", כי בין כה וכה מדובר רק על ניהול RAM, שום דבר פרסיסטנטי.

חפש ב xda-developers קושחה (ROM) בלי כל ה-bloatware של סמסונג.

תתפלא כמה המכשיר ירגיש לך זריז לאחר מכן.

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

 

בכל אופן, אין קשר בין זה לבין האטה של מכשירים "קשישים", כי בין כה וכה מדובר רק על ניהול RAM, שום דבר פרסיסטנטי.

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

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

עם Automatic reference counting רוב החסרונות בקטע של כתיבה כבר לא רלוונטי - ARC נכנס בiOS 4.2.1 והחל מiOS 4.3 קיים בצורה שתומכת בצורה מלאה ובטוחה בעוד כמה פיצ׳רים, וכשאתה עובר לSwift אפילו פחות - זה כבר תיאורטי לגמרי - כי אין שם ניהול זיכרון ידני (יש Owned / unowned כדי לנהל Retain cycles לדוגמא - אבל אין שם אפילו את הפקודות של Retain/release).

אף אחד לא כותב יותר קוד עם Reference counting ידני - עד שאתה לא יורד לרמת CoreGraphics / quartz וכו (ואז זה קוד שהמקביל שלו לא נכתב בג׳אווה גם באנדרואיד). זה מאוד לא נפוץ.

מה שAutomatic reference counting עושה זה בשלב של הקומפילציה הוא מוסיף את כל הקריאות האלו לקוד הבינארי. והוא עושה עבודה מ א ו ד טובה בזה.

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

GC לא מבוסס על Reference counting בצורה שהוא ממומש באנדרואיד - אלא על Memory mapping וPaging:

https://developer.android.com/topic/performance/memory-overview

ההבדל בין ניהול מפות זיכרון בצורה הזו לבין בדיקה של Integer אם הוא חיובי או לא (שזה מה שReference counting אומר דה פאקטו) הוא עצום.

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

בימינו - במיוחד בSwift (אבל גם בObjecgive C אלא אם עשית סלטות כדי לרוץ בניהול זיכרון ידני) יש בדיוק 2 טריידאופים:

1. Retain cycles - שבאמת בימינו יחסית קל להימנע מהם וגם הStatic code analyzer והRuntime analyzer עולים על זה דיי בקלות.

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

חפש ב xda-developers קושחה (ROM) בלי כל ה-bloatware של סמסונג.

תתפלא כמה המכשיר ירגיש לך זריז לאחר מכן.

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

לא הייתי ממליץ להחליף רומים לאדם לא טכני, או אחד שחייב/רוצה מכשיר אמין, או מישהו שאבטחת מידע חשובה לו.

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

תודה Vadim.

אבל אין לי את אף אחת מהן. לא פייסבוק ולא כל השאר