הדרך הפשוטה להזרמת וידיאו באנדרואיד

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

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

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

על מנת להשתמש בספרייה עבור H.264 ו-AAC, עליכם לבצע זאת:

אתחלו אובייקט Session בשיטת onCrease של הפעילות העיקרית שלכם. אובייקטי session שכאלה מייצגים זרימת מדיה לעמית:

התחילו את ה-Session:

ובסיום – עצרו אותו:

חשוב לראות את הדברים כהווייתם: הזרמת וידיאו בזמן אמת היא מבולגנת באופייה ו-LibStreaming לא נפטרת מהסיבוכיות הזו. אולם, הוא עושה עבודה טובה בהסתרתה מכם במרבית הזמן. במקרים מסוימים, יהיה עליכם להתמודד עם הסיבוכיות, כמו בבחירת מדיניות איתות לעמית, בחירת קידוד מצלמה (לרוב תרצו להשתמש ב-MediaCodec/Surface-to-buffer) או התמודדות עם Packetization.
בנוסף, תגלו שהחבר'ה הטובים שמאחורי LibStreaming הפעילו ראש גדול במיזוג הסיבוכיויות הללו באופן חלק אל תוך ממשק תכנות אפליקציות קל לשימוש.

LibStreaming תומכת במרבית המקדדים המשמשים אפליקציות אנדוראיד, כולל H.262 ,H.263 ,ACC ו-AMR. קצרתי איתה הצלחות רבות ואחדות מאפליקציות הזרימה הפופולריות ביותר משתמשות בה כחלק מהתשתית שלהן. אם אי פעם אתם נתקלים בצורך להשתמש בספרייה מעין זו, LibStreaming תהפוך את חוויית זרימת המדיה שלכם לחלקה הרבה יותר.

LeakCanary: גילוי זליגות זיכרון בשורת קוד אחת

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

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

מדוע? מפני שאובייקט View מכיל בתוכו רפרנס ל-Activity שבתוכו הוא מוכל. כל זמן שהפנייה ל-View זה נשמרת, ה-Activity המכיל, יחד עם כל מה שבתוכו – לרבות Drawables, היררכיית Views ומשאבים – לא יוכל לרדת מהזיכרון בריצת ה-GC (ר"ת Garbage Collector) הבאה.

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

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

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

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

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

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

על מנת להשתמש בו, פשוט הפעילו את leakCanary עם אובייקט האפליקציה שלכם onCreate():

LeakCanary יפקח על דליפות זיכרון וישלח הודעות במקרים של גילוי. הספרייה הזאת עושה את הקסם הזה על ידי הזרקה אוטומטית של אובייקט הקרוי ActivityRefWatcher אל תוך הזיכרונות שלכם ומנטרת את ה-Ref count שלהם לאחר הקריאה ל-onDestroy(). יצוין כי Ref count עם A > 0 בפעילות מושמדת משמעו דליפה בלבד.

חשוב לציין שזיהוי זליגה עובד רק באפליקציות במצב Debug. אין לבצע בדיקת זליגות – לפחות לא באמצעות LeakCanary – ב-APK של Release mode.

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

הוא יכול לשמש לאיתור זליגות במשתנים שבקרוב ירדו מהזיכרון (GC-reclaimed). ליתר דיוק, משתנים שאמורים לרדת מהזיכרון. על מנת לעשות זאת, הפעילו קריאה זו:

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

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

הכותב הינו מפתח אנדרואיד עצמאי ומנכ"ל Mobile edge software solutions.