Android Performance Patterns: Garbage Collection in Android Google Developers English Arabic

Android Performance Patterns: Garbage Collection in AndroidYouTube↗ IA↗(long shot)
Science & Technology 28K views 321 likes 9 dislikes 11 Mar 2015

Google for Developers 2.7M subscribers United States YouTube↗

Click to Play Video

COLT MCANLIS: One important part of writing

جزء هام من كتابة تطبيقات ناجحة

successful applications is enabling the programmer

هو تمكين المبرمج أن يكون فعالاً قدر الإمكان

to be as efficient as possible so that they can focus their brain cycles on the truly important problems.

حتى يتمكنوا من تركيز تفكيرهم على المشاكل المهمة حقاً.

But sometimes this ease of development

لكن في بعض الأحيان هذه السهولة في التطوير

can create new performance problems that aren't always clear.

يمكنها أن تخلق مشاكل أداء جديدة لا تكون واضحة دائماً.

My name is Colt McAnlis.

اسمي كولت ماكانليس.

And while the Android Runtime provides lots of opportunities for programmers

على الرغم من أن بيئة عمل أندرويد توفر فرص كثيرة للمبرمجين ليكونوا أكثر كفاءة

to be more efficient, it also presents a lot of hidden pitfalls with respect to performance.

تقدم أيضاً الكثير من الأشراك الخفية فيما يتعلق بالأداء.

And the single biggest one that you need to worry about

المشكلة الوحيدة الأكبر التي يجب أن تقلق حولها

has everything to do with how you're allocating and using

تتعلق كلياً بطريقة قيامك بتخصيص واستخدام الذاكرة.

memory. See, many programming languages that are known for being "high performance," like a C and C++, usually require programmers

لاحظ أن العديد من لغات البرمجة المعروفة بكونها ذات "أداء عال" مثل C و ++C،

to manage memory themselves.

تحتاج عادةً أن يقوم المبرمجون بإدارة الذاكرة بأنفسهم.

That is, the programmer is responsible for allocating blocks of memory off of the heap during code execution,

هذا يعني، المبرمج هو المسؤول عن تخصيص كتل من الذاكرة خارج الكومة خلال تنفيذ الكود

and explicitly freeing them back to the heap once they aren't being used anymore.

وتحريرها بشكل صريح إلى الكومة بمجرد أنها لم تعد قيد الاستخدام بعد الآن.

But in a 2 million line code base, it's easy to get lost in logic flows

ولكن مع 2 مليون سطر من الكود، فإنه من السهل أن تضيع في التدفقات المنطقية

and end up not freeing allocated memory as intended.

وينتهي بك الأمر بعدم تحرير الذاكرة المخصصة على النحو المنشود.

These types of allocations are called leaks-- that is,

وتسمى هذه الأنواع من التخصيص بالتسريبات،

memory which was allocated but never freed.

وهذا يعني، بأن الذاكرة التي تم تخصيصها لم يتم تحريرها أبداً.

Now, a managed memory environment, on the other hand, removes this burden of freeing memory from the programmer's

الآن من ناحية أخرى، فإن بيئة ذاكرة مدارة، تزيل عبء تحرير الذاكرة عن المبرمج.

shoulders. See, it keeps track of each memory allocation.

لاحظ، إنها تقوم بتتبع كل تخصيص للذاكرة.

And once it determines that a piece of memory is no longer being used by the program,

وبمجرد أن تحدد أن قطعة من الذاكرة لم تعد تستخدم من قبل البرنامج،

it can free it back to the heap without any intervention

فيمكنها أن تحررها مرة أخرى إلى الكومة دون أي تدخل من المبرمج.

from the programmer. Which is great, because we can spend that extra time doing

وهو أمر ممتاز، لأنه يمكننا أن ننفق الوقت الإضافي للقيام بأشياء أخرى

other things-- like arguing about whether or not crossguards work on light sabers.

مثل مناقشة حول ما إذا كان برنامج كروسغاردز يعملون أم لا على السيوق الضوئية.

Anyhow, the process of reclaiming memory in a managed environment is known as Garbage Collection.

على أية حال، فإن عملية استعادة الذاكرة في بيئة مدارة تعرف باسم جمع القمامة.

It's a concept that was created by John McCarthy back in 1959

إنه مفهوم تم إنشاؤه من قبل جون مكارثي فيما ما مضى في 1959

to solve problems in the LISP programming language.

لحل المشاكل في لغة البرمجة ليسب.

And it generally adheres to two primary principles--

ويعتمد عموماً على مبدأين رئيسيين

find data objects in a program that cannot be accessed

العثور على كائنات البيانات في برنامج ما والتي لا يمكن الوصول إليها في المستقبل،

by in the future, and reclaim the resources used by those

واستعادة الموارد المستخدمة من قبل هذه الكائنات.

الآن، فكر في الأمر.

Now, think about it. Garbage Collection can be really gnarly.

جمع القمامة يمكن أن يكون عام حقاً.

I mean, if you've got some 20,000 allocations in your program right now, which ones

أعني، أنه إذا كنت قد حصلت على 20,000 تخصيص في برنامجك في الوقت الحالي،

aren't being needed anymore?

أي منها لم يعد هناك حاجة لها بعد الآن؟

Or better yet, when should you execute a Garbage Collection

أو الأفضل من ذلك، متى يجب عليك تنفيذ عملية جمع قمامة

event to free up memory that isn't being used?

لتحرير الذاكرة التي لا يتم استخدامها؟

These are actually very difficult questions.

هذه الأسئلة في الواقع صعبة جداً.

And thankfully, we've had about 50 years worth of innovation

ولحسن الحظ، لقد كان لدينا حوالي 50 عام من الإبتكارات لاجراء تحسينات عليها.

to improve on them. Which is why the Garbage Collector in Android Runtime

وهذا هو السبب في أن جامع القمامة في بيئة تشغيل أندرويد

is quite a bit more sophisticated than McCarthy's

هو أكثر تطوراً بشكل أكبر من اقتراح مكارثي الأصلي.

original proposal. It's been built to be fast and as non-intrusive as possible.

لقد تم بناؤه ليكون سريعاً وغير فضولي قدر الإمكان.

Effectively, the memory heap in Android's Runtime

إن كومة الذاكرة في بيئة عمل أندرويد

are segmented into spaces based on the type of allocation

مجزأة بشكل فعال إلى مساحات استناداً إلى نوع من التخصيص

and how best the system can organize those allocations

وأفضل طريقة يمكن للنظام أن يقوم بتنظيم تلك المخصصات

for future GC events.

من أجل أحداث جمع القمامة في المستقبل.

As a new object is allocated, the characteristics

عندما يتم تخصيص كائن جديد، فإن الخصائص تؤخذ في الاعتبار

are taken into account to best fit what space it should be placed into,

لتناسب المساحة التي يجب أن توضع فيها بأفضل شكل،

depending on what version of the Android Runtime you're using.

اعتماداً على نسخة بيئة تشغيل أندرويد التي تستخدمها.

And here's the important part.

وهنا الجزء المهم.

Each space has a set size.

يوجد لكل مساحة حجم مخصص.

As objects are allocated, we keep track of the combined sizes.

ونقوم بتتبع الأحجام مجتمعة بينما يتم تخصيص الكائنات.

And as a space starts to grow, the system

وحينما تبدأ المساحة بالزيادة،

will need to execute a Garbage Collection event in an attempt

سيحتاج النظام إلى تنفيذ حدث جمع القمامة

to free up memory for future allocations.

في محاولة لتحرير الذاكرة لأجل عمليات تخصيص مستقبلية.

Now, it's worth pointing out that GC events will

ويجدر الإشارة الآن إلى أن أحداث جمع القمامة سوف تتصرف بشكل مختلف

behave differently depending on which Android Runtime

اعتماداً على بيئة تشغيل أندرويد التي تستخدمها.

you're using. For example, in DALVIK, many GC events are "stop the world" events.

مثلاً، في بيئة عمل دالفيك، العديد من أحداث جمع القمامة هي أحداث "توقف كل شي".

Meaning that any managed code that is running will stop until the operation completes.

وهذا يعني أن أي كود مدار يعمل في نظام التشغيل سيتوقف حتى اكتمال العملية.

Which can get very problematic when these GCs take longer than normal,

والذي يمكن أن يصبح مشكلة كبيرة عندما تأخذ أحداث جمع القمامة وقتا أطول من المعتاد

or there's a ton of them happening at once,

أو هناك كمية هائلة منها تحدث في وقت واحد،

since it's going to significantly eat

نظرا لأنها ستاخذ وقتاً كبيراً من الإطار الزمني الخاص بك.

into your frame time. Now, ART, on the other hand, extended

أما الآن، من ناحية أخرى بيئة التشغيل في أندرويد،

the functionality of a concurrent GC system, which

قامت بتوسيع وظائف نظام جمع القمامة المتزامنة،

tends to remove the larger GC pauses, but will still

والذي يميل إلى إزالة توقفات جمع القمامة الأكبر،

incur a small pause at the end of important GC events.

ولكن سيبقى يستهلك توقف صغير في نهاية أحداث جمع القمامة الهامة.

And to be clear, our engineers have spent a lot of time

ولكي نكون واضحين، فقد قضى مهندسينا الكثير من الوقت

making sure that these events are as fast as possible to reduce interruptions.

في التأكد من أن تكون هذه الأحداث سريعة قدر الإمكان للحد من الإنقطاعات.

That being said, this can still cause your application some performance headaches.

ويذكر بأن هذا لا يزال يمكن أن يسبب لتطبيقك بعض مشاكل الأداء.

Firstly, understand that the more time your app

أولاً، عليك أن تفهم أنه كلما زاد الوقت الذي يصرفه تطبيقك

is spending doing GCs in a given frame,

للقيام بعمليات جمع القمامة ضمن إطار زمني معين،

the less time it's got for the rest of the logic

كلما كان الوقت أقل لبقية العمليات المنطقية الضرورية

needed to keep you under the 16 millisecond barrier

لكي تبقك تحت حاجز 16 ميلي ثانية لعملية المعالجة الرسومية.

for rendering. So if you've got a lot of GCs, or some long ones

لذلك إذا كان لديك أحداث جمع القمامة عديدة أو بعض منها طويلة الزمن تتبع بعضها البعض،

right after each other, it might push your frame processing time over the 16 millisecond barrier, which

فقد يدفع ذلك وقت إطار المعالجة لديك فوق حاجز 16 ميلي ثانية،

can cause a visible hitching or jink for your users.

والذي يمكن أن يسبب توقف مرئي أو زوغان للمستخدمين.

Secondly, understand that your code flow

ثانياً، نفهّم أن تدفق كودك قد يكون يسبب ذلك النوع من العمل

may be doing the kinds of work that force GCs to occur more often or making them last longer

الذي يجبر عمليات جمع القمامة أن تحدث أكثر أو جعلها تستمر لفترة أطول من الفترات الطبيعية.

than normal durations. For example, if you're allocating a horde worth of objects in the innermost part of a loop

على سبيل المثال، إذا كنت تقوم بتخصيص كمية كبيرة من الكائنات

that runs for a really long time,

في الجزء الأعمق من حلقة والتي تُنفذ لفترة طويلة جداً،

then you're going to be polluting your memory heap with a lot of objects.

عندئذ أنت تقوم بتلويث كومة الذاكرة بالكثير من الكائنات.

And you'll end up kicking off a lot of GC events quickly due to this additional memory pressure.

وستقوم بإطلاق الكثير من أحداث جمع القمامة بشكل سريع نتيجة لضغط الذاكرة الإضافي هذا.

And these types of programming patterns are easier to run into

هذه الأنواع من أنماط البرمجة أسهل للاستخدام أكثر مما تعتقد.

than you'd think. So thankfully, the Android SDK has a set of powerful tools at your disposal.

لذلك لحسن الحظ، فإن أندرويد SDK تملك مجموعة من الأدوات القوية تحت تصرفك.

For example, you can get a high-level view of how your application is managing memory using

مثلاً، يمكنك الحصول على عرض رفيع المستوى عن كيفية ادارة تطبيقك للذاكرة

the Memory Monitor tool inside of Android Studio.

باستخدام أداة مراقبة الذاكرة داخل أندرويد استوديو.

Every time you see a dip in the allocated memory,

وفي كل مرة تلحظ تراجع في الذاكرة المخصصة،

that's a GC event occurring.

يكون هذا حدث جمع قمامة قيد التنفيذ.

Lots of dips in a short time could signal a performance problem.

حدوث الكثير من الانخفاضات في وقت قصير قد يكون مؤشراً على مشكلة في الأداء.

And you can see what objects are active in your heap, and what parts of your code are allocating them,

ويمكنك أن ترى الكائنات النشطة في الكومة، وأجزاء كودك التي تقوم بتخصيصها،

with the Heap and Allocation Tracker tools as well.

مع أدوات الكومة وتعقب التخصيص كذلك.

But wrangling memory into performant uses is easier said than done.

لكن نقاش الذاكرة حول الاستخدام الفعال لها أسهل نظرياً من التطبيق العملي.

Which is why you need to check out the rest of our Android

وهذا هو سبب أنك تحتاج إلى التحقق من بقية محتوى أنماط أداء أندرويد لدينا

Performance Patterns content for other great ways

لإيجاد طرق أخرى جيدة لتحسين الأداء.

to improve performance. And don't forget to join our Google+ community for excellent

و لا تنسى للانضمام الى منتدانا على +Google للحصول على معلومات ممتازة أيضاً.

info as well. So keep calm, profile your code, and always remember, Perf matters. [MUSIC PLAYING]

لذلك حافظ على هدوئك واكتب كودك، وتذكر دائماً، الأداء مهم.

Similar videos:

Android Performance Patterns: Performance Cost of Memory Leaks
Google for Developers
24.9K views 251 likes 4 dislikes 11 Mar 201577% match

Android Performance Patterns: Memory Performance 101
Google for Developers
20.3K views 153 likes 4 dislikes 11 Mar 201570% match

Android Performance Patterns: Android UI and the GPU
Google for Developers
31.6K views 294 likes 8 dislikes 06 Jan 201548% match

Android Performance Patterns: Rendering Performance 101
Google for Developers
65.2K views 490 likes 6 dislikes 06 Jan 201543% match

Android Performance Patterns: Why 60fps?
Google for Developers
52.5K views 562 likes 22 dislikes 06 Jan 201542% match

Android Performance Patterns: Invalidations, Layouts, and Performance
Google for Developers
42.7K views 312 likes 6 dislikes 06 Jan 201542% match

Android Performance Patterns: Understanding VSYNC
Google for Developers
31.6K views 317 likes 3 dislikes 06 Jan 201541% match

Android Performance Patterns: Tool - Memory Monitor
Google for Developers
34.9K views 210 likes 10 dislikes 06 Jan 201541% match

Battery Drain and Networking (Android Performance Patterns Season 2 ep1)
Google for Developers
41.9K views 314 likes 7 dislikes 23 Apr 201541% match

To Index or Iterate? (Android Performance Patterns Season 2 ep6)
Google for Developers
28.1K views 515 likes 11 dislikes 26 May 201541% match

Android Performance Patterns: Understanding Overdraw
Google for Developers
26.6K views 255 likes 2 dislikes 06 Jan 201541% match

Android Performance Patterns: Battery Drain and WakeLocks
Google for Developers
40.3K views 390 likes 36 dislikes 06 Jan 201537% match

Android Performance Patterns: Tool - Profile GPU Rendering
Google for Developers
65.2K views 627 likes 26 dislikes 06 Jan 201536% match

Debugging and testing in Android Studio (Ep 4, Android Studio)
Google for Developers
67.5K views 367 likes 14 dislikes 01 May 201530% match

Android Support Library: Consistent Design with AppCompat
Google for Developers
61.8K views 852 likes 8 dislikes 21 Apr 201529% match

The Magic of LRU Cache (100 Days of Google Dev)
Google for Developers
74.2K views 952 likes 20 dislikes 02 Jun 201529% match

Introducing Gradle (Ep 2, Android Studio)
Google for Developers
88.5K views 585 likes 19 dislikes 13 Mar 201525% match

Layout Editor (Ep 3, Android Studio)
Google for Developers
53.6K views 293 likes 9 dislikes 25 Mar 201525% match

Introduction to Android Studio
Google for Developers
133.7K views 1K likes 16 dislikes 23 Feb 201525% match

DevBytes - Your App, At Scale with Google App Engine
Google for Developers
103.5K views 237 likes 4 dislikes 24 Mar 201425% match

Getting started with Firebase and Android - Firecasts #1
Google for Developers
113.8K views 1.1K likes 19 dislikes 16 Feb 201624% match

An Introduction to Android Wear
Google for Developers
251.3K views 1.3K likes 86 dislikes 18 Jun 201424% match

DevBytes: Android L Developer Preview
Google for Developers
46.3K views 801 likes 13 dislikes 18 Jul 201424% match

DevBytes: What's new in Android 5.0 Lollipop
Google for Developers
129.1K views 1.5K likes 37 dislikes 17 Oct 201424% match

DevBytes: Android Vector Graphics
Google for Developers
60.9K views 640 likes 13 dislikes 17 Dec 201424% match

Google Cast: Introduction to the SDK
Google for Developers
47K views 141 likes 7 dislikes 10 Dec 201423% match

DevBytes: Google Fit APIs for Android - Setup and Sensors
Google for Developers
49.3K views 184 likes 21 dislikes 28 Oct 201422% match

SMS Verification Codes made Easy on Android!
Google for Developers
148.6K views 1.2K likes 121 dislikes 02 Aug 201722% match

Settings Privacy About Contact Donate