মেমরি ব্যবস্থাপনার ওভারভিউ

অ্যান্ড্রয়েড রানটাইম (এআরটি) এবং ডালভিক ভার্চুয়াল মেশিন মেমরি পরিচালনা করতে পেজিং এবং মেমরি-ম্যাপিং (এমএমপিং) ব্যবহার করে। এর মানে হল যে কোনও মেমরি একটি অ্যাপ সংশোধন করে - তা নতুন অবজেক্ট বরাদ্দ করে বা ম্যাপ করা পৃষ্ঠাগুলি স্পর্শ করে - RAM-তে থাকে এবং পেজ আউট করা যায় না। একটি অ্যাপ থেকে মেমরি রিলিজ করার একমাত্র উপায় হল অ্যাপের কাছে থাকা বস্তুর রেফারেন্সগুলি প্রকাশ করা, যা মেমরিটিকে আবর্জনা সংগ্রহকারীর কাছে উপলব্ধ করে। এটি একটি ব্যতিক্রমের সাথে: সিস্টেমটি অন্য কোথাও মেমরি ব্যবহার করতে চাইলে কোনো পরিবর্তন ছাড়াই এমম্যাপ করা ফাইল, যেমন কোড, র‌্যাম থেকে পেজ আউট করা যেতে পারে।

এই পৃষ্ঠাটি ব্যাখ্যা করে যে কীভাবে অ্যান্ড্রয়েড অ্যাপ প্রক্রিয়া এবং মেমরি বরাদ্দ পরিচালনা করে। আপনার অ্যাপে কীভাবে মেমরি আরও দক্ষতার সাথে পরিচালনা করবেন সে সম্পর্কে আরও তথ্যের জন্য, আপনার অ্যাপের মেমরি পরিচালনা করুন দেখুন।

আবর্জনা সংগ্রহ

একটি পরিচালিত মেমরি পরিবেশ, যেমন ART বা Dalvik ভার্চুয়াল মেশিন, প্রতিটি মেমরি বরাদ্দের ট্র্যাক রাখে। একবার এটি নির্ধারণ করে যে মেমরির একটি টুকরো প্রোগ্রাম দ্বারা আর ব্যবহার করা হচ্ছে না, এটি প্রোগ্রামারের কোনও হস্তক্ষেপ ছাড়াই এটিকে আবার হিপে মুক্ত করে। একটি পরিচালিত মেমরি পরিবেশের মধ্যে অব্যবহৃত মেমরি পুনরুদ্ধার করার পদ্ধতিটি আবর্জনা সংগ্রহ হিসাবে পরিচিত। আবর্জনা সংগ্রহের দুটি লক্ষ্য রয়েছে: এমন একটি প্রোগ্রামে ডেটা অবজেক্ট খুঁজুন যা ভবিষ্যতে অ্যাক্সেস করা যাবে না; এবং সেই বস্তু দ্বারা ব্যবহৃত সম্পদ পুনরুদ্ধার করুন।

অ্যান্ড্রয়েডের মেমরি হিপ একটি প্রজন্মগত, যার অর্থ বরাদ্দ করা বস্তুর প্রত্যাশিত জীবন এবং আকারের উপর ভিত্তি করে এটি ট্র্যাক করে এমন বিভিন্ন বরাদ্দ রয়েছে। উদাহরণস্বরূপ, সম্প্রতি বরাদ্দ করা বস্তুগুলি তরুণ প্রজন্মের অন্তর্গত। যখন একটি বস্তু যথেষ্ট দীর্ঘ সময় সক্রিয় থাকে, তখন এটি একটি পুরানো প্রজন্মের কাছে উন্নীত হতে পারে, একটি স্থায়ী প্রজন্ম অনুসরণ করে।

প্রতিটি হিপ জেনারেশনের মেমরির পরিমাণের উপর নিজস্ব ডেডিকেটেড ঊর্ধ্ব সীমা থাকে যা সেখানে বস্তুগুলি দখল করতে পারে। যে কোন সময় একটি প্রজন্ম পূর্ণ হতে শুরু করে, সিস্টেমটি মেমরি খালি করার প্রয়াসে একটি আবর্জনা সংগ্রহের ইভেন্ট সম্পাদন করে। আবর্জনা সংগ্রহের সময়কাল নির্ভর করে এটি কোন প্রজন্মের বস্তু সংগ্রহ করছে এবং প্রতিটি প্রজন্মে কতগুলি সক্রিয় বস্তু রয়েছে তার উপর।

যদিও আবর্জনা সংগ্রহ বেশ দ্রুত হতে পারে, তবুও এটি আপনার অ্যাপের কর্মক্ষমতা প্রভাবিত করতে পারে। আপনার কোডের মধ্যে থেকে যখন আবর্জনা সংগ্রহের ঘটনা ঘটে তখন আপনি সাধারণত নিয়ন্ত্রণ করেন না। কখন আবর্জনা সংগ্রহ করতে হবে তা নির্ধারণের জন্য সিস্টেমের একটি চলমান মানদণ্ড রয়েছে। মানদণ্ডগুলি সন্তুষ্ট হলে, সিস্টেমটি প্রক্রিয়াটি চালানো বন্ধ করে দেয় এবং আবর্জনা সংগ্রহ শুরু করে। যদি আবর্জনা সংগ্রহ একটি অ্যানিমেশনের মতো একটি নিবিড় প্রক্রিয়াকরণ লুপের মাঝখানে বা সঙ্গীত প্লেব্যাকের সময় ঘটে তবে এটি প্রক্রিয়াকরণের সময় বাড়িয়ে দিতে পারে। এই বৃদ্ধি কার্যকর এবং মসৃণ ফ্রেম রেন্ডারিংয়ের জন্য প্রস্তাবিত 16ms থ্রেশহোল্ড অতিক্রম করে আপনার অ্যাপে কোড এক্সিকিউশনকে সম্ভাব্যভাবে ঠেলে দিতে পারে।

অতিরিক্তভাবে, আপনার কোড ফ্লো এমন ধরনের কাজ করতে পারে যা আবর্জনা সংগ্রহের ঘটনাগুলিকে আরও ঘন ঘন ঘটতে বাধ্য করে বা সেগুলিকে স্বাভাবিকের চেয়ে দীর্ঘস্থায়ী করে। উদাহরণস্বরূপ, যদি আপনি একটি আলফা মিশ্রন অ্যানিমেশনের প্রতিটি ফ্রেমের সময় একটি ফর-লুপের ভিতরের অংশে একাধিক অবজেক্ট বরাদ্দ করেন, তাহলে আপনি অনেকগুলি বস্তুর সাথে আপনার মেমরির স্তূপকে দূষিত করতে পারেন। সেই পরিস্থিতিতে, আবর্জনা সংগ্রাহক একাধিক আবর্জনা সংগ্রহের ইভেন্টগুলি চালায় এবং আপনার অ্যাপের কর্মক্ষমতা হ্রাস করতে পারে।

আবর্জনা সংগ্রহ সম্পর্কে আরও সাধারণ তথ্যের জন্য, আবর্জনা সংগ্রহ দেখুন।

মেমরি শেয়ার করুন

RAM-তে প্রয়োজনীয় সমস্ত কিছু ফিট করার জন্য, Android প্রক্রিয়াগুলি জুড়ে RAM পৃষ্ঠাগুলি ভাগ করার চেষ্টা করে৷ এটি নিম্নলিখিত উপায়ে এটি করতে পারে:

• প্রতিটি অ্যাপ প্রক্রিয়া জাইগোট নামক একটি বিদ্যমান প্রক্রিয়া থেকে ফর্ক করা হয়। জাইগোট প্রক্রিয়া শুরু হয় যখন সিস্টেম বুট করে এবং সাধারণ ফ্রেমওয়ার্ক কোড এবং সংস্থানগুলি (যেমন কার্যকলাপ থিম) লোড করে। একটি নতুন অ্যাপ প্রক্রিয়া শুরু করার জন্য, সিস্টেমটি জাইগোট প্রক্রিয়াটিকে ফর্ক করে তারপর নতুন প্রক্রিয়ায় অ্যাপের কোড লোড করে এবং চালায়। এই পদ্ধতিটি ফ্রেমওয়ার্ক কোড এবং সংস্থানগুলির জন্য বরাদ্দ করা বেশিরভাগ RAM পৃষ্ঠাগুলিকে সমস্ত অ্যাপ প্রক্রিয়া জুড়ে ভাগ করার অনুমতি দেয়।
• বেশিরভাগ স্ট্যাটিক ডেটা একটি প্রক্রিয়ার মধ্যে এমম্যাপ করা হয়। এই কৌশলটি প্রক্রিয়াগুলির মধ্যে ডেটা ভাগ করে নেওয়ার অনুমতি দেয় এবং প্রয়োজনে এটিকে পেজ আউট করার অনুমতি দেয়। স্ট্যাটিক ডেটার উদাহরণের মধ্যে রয়েছে: ডালভিক কোড (সরাসরি এমম্যাপিংয়ের জন্য এটিকে একটি প্রাক-লিঙ্ক করা .odex ফাইলে রেখে), অ্যাপ রিসোর্স (রিসোর্স টেবিলটিকে এমন একটি কাঠামো হিসাবে ডিজাইন করে যা এমম্যাপ করা যেতে পারে এবং APK এর জিপ এন্ট্রিগুলি সারিবদ্ধ করে) , এবং .so ফাইলে নেটিভ কোডের মত প্রথাগত প্রকল্প উপাদান।
• অনেক জায়গায়, অ্যান্ড্রয়েড স্পষ্টভাবে বরাদ্দ করা শেয়ার্ড মেমরি অঞ্চল (অ্যাশমেম বা গ্র্যালোক সহ) ব্যবহার করে প্রক্রিয়া জুড়ে একই গতিশীল র‌্যাম শেয়ার করে। উদাহরণস্বরূপ, উইন্ডো সারফেসগুলি অ্যাপ এবং স্ক্রিন কম্পোজিটরের মধ্যে শেয়ার করা মেমরি ব্যবহার করে এবং কার্সার বাফারগুলি সামগ্রী প্রদানকারী এবং ক্লায়েন্টের মধ্যে শেয়ার করা মেমরি ব্যবহার করে৷

শেয়ার্ড মেমরির ব্যাপক ব্যবহারের কারণে, আপনার অ্যাপ কতটা মেমরি ব্যবহার করছে তা নির্ধারণের জন্য যত্নের প্রয়োজন। আপনার অ্যাপের মেমরি ব্যবহার সঠিকভাবে নির্ধারণ করার কৌশলগুলি আপনার RAM ব্যবহারের তদন্তে আলোচনা করা হয়েছে৷

অ্যাপ মেমরি বরাদ্দ এবং পুনরুদ্ধার করুন

ডালভিক হিপ প্রতিটি অ্যাপ প্রক্রিয়ার জন্য একটি একক ভার্চুয়াল মেমরি পরিসরে সীমাবদ্ধ। এটি লজিক্যাল হিপ সাইজকে সংজ্ঞায়িত করে, যা প্রয়োজন অনুযায়ী বাড়তে পারে কিন্তু শুধুমাত্র একটি সীমা পর্যন্ত যা সিস্টেম প্রতিটি অ্যাপের জন্য সংজ্ঞায়িত করে।

স্তূপের যৌক্তিক আকার হিপ দ্বারা ব্যবহৃত শারীরিক মেমরির পরিমাণের সমান নয়। আপনার অ্যাপের স্তূপ পরিদর্শন করার সময়, অ্যান্ড্রয়েড আনুপাতিক সেট সাইজ (PSS) নামে একটি মান গণনা করে, যা নোংরা এবং পরিষ্কার উভয় পৃষ্ঠার জন্য দায়ী যা অন্যান্য প্রক্রিয়াগুলির সাথে ভাগ করা হয়-কিন্তু শুধুমাত্র সেই পরিমাণে যা কতগুলি অ্যাপ সেই RAM ভাগ করে তার সমানুপাতিক। এই (PSS) মোট যা সিস্টেমটি আপনার শারীরিক মেমরি পদচিহ্ন হিসাবে বিবেচনা করে। PSS সম্পর্কে আরও তথ্যের জন্য, আপনার RAM ব্যবহারের নির্দেশিকা তদন্ত করুন।

ডালভিক হিপ স্তূপের লজিক্যাল সাইজকে কমপ্যাক্ট করে না, যার মানে অ্যান্ড্রয়েড স্পেস বন্ধ করার জন্য হিপটিকে ডিফ্র্যাগমেন্ট করে না। অ্যান্ড্রয়েড শুধুমাত্র লজিক্যাল হিপের আকার সঙ্কুচিত করতে পারে যখন হিপের শেষে অব্যবহৃত স্থান থাকে। যাইহোক, সিস্টেম এখনও গাদা দ্বারা ব্যবহৃত শারীরিক মেমরি কমাতে পারে. আবর্জনা সংগ্রহের পর, ডালভিক স্তূপে হেঁটে যান এবং অব্যবহৃত পৃষ্ঠাগুলি খুঁজে পান, তারপর ম্যাডভিস ব্যবহার করে সেই পৃষ্ঠাগুলি কার্নেলে ফিরিয়ে দেন। সুতরাং, বড় অংশের জোড়া বরাদ্দ এবং ডিললোকেশনের ফলে ব্যবহৃত শারীরিক মেমরি সমস্ত (বা প্রায় সমস্ত) পুনরুদ্ধার করা উচিত। যাইহোক, ছোট বরাদ্দ থেকে মেমরি পুনরুদ্ধার করা অনেক কম কার্যকরী হতে পারে কারণ একটি ছোট বরাদ্দের জন্য ব্যবহৃত পৃষ্ঠাটি এখনও অন্য কিছুর সাথে ভাগ করা হতে পারে যা এখনও মুক্ত করা হয়নি।

অ্যাপ মেমরি সীমাবদ্ধ করুন

একটি কার্যকরী মাল্টি-টাস্কিং পরিবেশ বজায় রাখতে, অ্যান্ড্রয়েড প্রতিটি অ্যাপের জন্য হিপ সাইজের একটি কঠিন সীমা সেট করে। ডিভাইসটিতে সামগ্রিকভাবে কতটা RAM উপলব্ধ রয়েছে তার উপর ভিত্তি করে ডিভাইসগুলির মধ্যে সঠিক হিপ আকারের সীমা পরিবর্তিত হয়। যদি আপনার অ্যাপ হিপ ক্ষমতায় পৌঁছে যায় এবং আরও মেমরি বরাদ্দ করার চেষ্টা করে, তাহলে এটি একটি OutOfMemoryError পেতে পারে।

কিছু ক্ষেত্রে, আপনি বর্তমান ডিভাইসে ঠিক কতটা হিপ স্পেস উপলব্ধ আছে তা নির্ধারণ করতে সিস্টেমকে জিজ্ঞাসা করতে চাইতে পারেন—উদাহরণস্বরূপ, একটি ক্যাশে রাখা কতটা ডেটা নিরাপদ তা নির্ধারণ করতে। আপনি getMemoryClass() কল করে এই চিত্রটির জন্য সিস্টেমটি জিজ্ঞাসা করতে পারেন। এই পদ্ধতিটি আপনার অ্যাপের হিপের জন্য উপলব্ধ মেগাবাইটের সংখ্যা নির্দেশ করে একটি পূর্ণসংখ্যা প্রদান করে।

অ্যাপ পাল্টান

যখন ব্যবহারকারীরা অ্যাপগুলির মধ্যে স্যুইচ করেন, তখন Android সেই অ্যাপগুলিকে রাখে যা ফোরগ্রাউন্ড নয়—অর্থাৎ ব্যবহারকারীর কাছে দৃশ্যমান নয় বা মিউজিক প্লেব্যাকের মতো ফোরগ্রাউন্ড পরিষেবা চালাচ্ছে— একটি ক্যাশে। উদাহরণস্বরূপ, যখন একজন ব্যবহারকারী প্রথম একটি অ্যাপ চালু করেন, তখন তার জন্য একটি প্রক্রিয়া তৈরি করা হয়; কিন্তু যখন ব্যবহারকারী অ্যাপটি ছেড়ে যায়, সেই প্রক্রিয়াটি প্রস্থান করে না । সিস্টেম প্রক্রিয়াটি ক্যাশে রাখে। ব্যবহারকারী যদি পরে অ্যাপে ফিরে আসেন, তাহলে সিস্টেমটি প্রক্রিয়াটি পুনরায় ব্যবহার করে, যার ফলে অ্যাপটি দ্রুত পরিবর্তন হয়।

যদি আপনার অ্যাপের একটি ক্যাশেড প্রক্রিয়া থাকে এবং এটি এমন সংস্থানগুলিকে ধরে রাখে যা এটির বর্তমানে প্রয়োজন নেই, তাহলে আপনার অ্যাপ-এমনকি ব্যবহারকারী এটি ব্যবহার না করলেও- সিস্টেমের সামগ্রিক কর্মক্ষমতা প্রভাবিত করে। যেহেতু সিস্টেমটি মেমরির মতো সংস্থানগুলিতে কম চালায়, এটি ক্যাশে প্রক্রিয়াগুলিকে মেরে ফেলে। সিস্টেমটি এমন প্রক্রিয়াগুলির জন্যও অ্যাকাউন্ট করে যা সর্বাধিক মেমরি ধরে রাখে এবং RAM খালি করার জন্য সেগুলিকে শেষ করতে পারে।

দ্রষ্টব্য: ক্যাশে থাকাকালীন আপনার অ্যাপটি যত কম মেমরি ব্যবহার করে, ততই ভাল এর সম্ভাবনা নষ্ট হয়ে যায় এবং দ্রুত পুনরায় শুরু করতে সক্ষম হয়। যাইহোক, তাত্ক্ষণিক সিস্টেমের প্রয়োজনীয়তার উপর নির্ভর করে, ক্যাশে করা প্রক্রিয়াগুলি যে কোনও সময় তাদের সম্পদের ব্যবহার নির্বিশেষে বন্ধ করা সম্ভব।

ফোরগ্রাউন্ডে না চলাকালীন প্রক্রিয়াগুলি কীভাবে ক্যাশে করা হয় এবং কোনটি মেরে ফেলা যেতে পারে তা Android কীভাবে সিদ্ধান্ত নেয় সে সম্পর্কে আরও তথ্যের জন্য, প্রসেস এবং থ্রেড গাইড দেখুন৷

মেমরি স্ট্রেস পরীক্ষা

যদিও মেমরির চাপের সমস্যাগুলি উচ্চ-সম্পন্ন ডিভাইসগুলিতে কম সাধারণ, তবুও তারা কম-র্যাম ডিভাইসের ব্যবহারকারীদের জন্য সমস্যা সৃষ্টি করতে পারে, যেমন Android (Go সংস্করণ) চলছে। এই মেমরি-চাপযুক্ত পরিবেশটি চেষ্টা করা এবং পুনরুত্পাদন করা গুরুত্বপূর্ণ যাতে আপনি অ্যাপ আচরণ যাচাই করতে এবং কম-মেমরি ডিভাইসগুলিতে আপনার ব্যবহারকারীদের জন্য অভিজ্ঞতা উন্নত করতে ইন্সট্রুমেন্টেশন পরীক্ষা লিখতে পারেন।

স্ট্রেসফুল অ্যাপ্লিকেশন পরীক্ষা

    adb push stressapptest /data/local/tmp/
    adb shell chmod 777 /data/local/tmp/stressapptest
    adb shell /data/local/tmp/stressapptest -s 20 -M 990

  

স্ট্রেসঅ্যাপটেস্টের উপর পর্যবেক্ষণ

• SIGABRT: ফ্রি মেমরির চেয়ে বড় আকারের বরাদ্দের অনুরোধ করার কারণে এটি আপনার প্রক্রিয়ার জন্য একটি মারাত্মক, নেটিভ ক্র্যাশ, যখন সিস্টেম ইতিমধ্যেই মেমরির চাপে রয়েছে।
• SIGQUIT : একটি মূল মেমরি ডাম্প তৈরি করে এবং আপনার ইন্সট্রুমেন্টেশন পরীক্ষার দ্বারা সনাক্ত করা হলে প্রক্রিয়াটি বন্ধ করে দেয়।
• TRIM_MEMORY_EVENTS : এই কলব্যাকগুলি Android 4.1 (API স্তর 16) এবং উচ্চতর সংস্করণে উপলব্ধ, এবং আপনার প্রক্রিয়ার জন্য বিস্তারিত মেমরি সতর্কতা প্রদান করে৷