প্রক্রিয়া এবং অ্যাপ জীবনচক্র

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

অ্যান্ড্রয়েডের একটি অস্বাভাবিক এবং মৌলিক বৈশিষ্ট্য হল যে একটি অ্যাপ্লিকেশন প্রক্রিয়ার জীবনকাল সরাসরি অ্যাপ্লিকেশন দ্বারা নিয়ন্ত্রিত হয় না । পরিবর্তে, এটি সিস্টেম দ্বারা নির্ধারিত হয় অ্যাপ্লিকেশনটির অংশগুলির সংমিশ্রণের মাধ্যমে যা সিস্টেমটি জানে যেগুলি চলছে, এই জিনিসগুলি ব্যবহারকারীর জন্য কতটা গুরুত্বপূর্ণ এবং সিস্টেমে কতটা সামগ্রিক মেমরি উপলব্ধ।

এটি গুরুত্বপূর্ণ যে অ্যাপ্লিকেশন বিকাশকারীরা বুঝতে পারে যে কীভাবে বিভিন্ন অ্যাপ্লিকেশন উপাদানগুলি (বিশেষত Activity , Service এবং BroadcastReceiver ) অ্যাপ্লিকেশনটির প্রক্রিয়াটির জীবনকালকে প্রভাবিত করে৷ এই উপাদানগুলি সঠিকভাবে ব্যবহার না করার ফলে সিস্টেমটি গুরুত্বপূর্ণ কাজ করার সময় অ্যাপ্লিকেশনটির প্রক্রিয়াটিকে মেরে ফেলতে পারে।

একটি প্রসেস লাইফসাইকেল বাগের একটি সাধারণ উদাহরণ হল একটি BroadcastReceiver যেটি একটি থ্রেড শুরু করে যখন এটি তার BroadcastReceiver.onReceive() পদ্ধতিতে একটি Intent গ্রহণ করে এবং তারপরে ফাংশন থেকে ফিরে আসে। এটি ফিরে আসার পরে, সিস্টেমটি বিবেচনা করে যে BroadcastReceiver আর সক্রিয় থাকবে না, এবং এর হোস্টিং প্রক্রিয়াটির আর প্রয়োজন হবে না, যদি না অন্যান্য অ্যাপ্লিকেশন উপাদান এতে সক্রিয় থাকে।

সুতরাং, সিস্টেম মেমরি পুনরুদ্ধার করার জন্য যে কোনও সময় প্রক্রিয়াটিকে মেরে ফেলতে পারে এবং এটি করার ফলে, এটি প্রক্রিয়ায় চলমান থ্রেডটি বন্ধ করে দেয়। এই সমস্যার সমাধান হল সাধারণত BroadcastReceiver থেকে একটি JobService নির্ধারণ করা যাতে সিস্টেমটি জানে যে প্রক্রিয়াটিতে সক্রিয় কাজ হচ্ছে।

মেমরি কম থাকলে কোন প্রক্রিয়াগুলিকে মেরে ফেলতে হবে তা নির্ধারণ করতে, অ্যান্ড্রয়েড প্রতিটি প্রক্রিয়াকে তাদের মধ্যে চলমান উপাদান এবং সেই উপাদানগুলির অবস্থার উপর ভিত্তি করে একটি গুরুত্বপূর্ণ অনুক্রমের মধ্যে রাখে। গুরুত্ব অনুসারে, এই প্রক্রিয়ার প্রকারগুলি হল:

  1. একটি ফোরগ্রাউন্ড প্রক্রিয়া এমন একটি যা ব্যবহারকারী বর্তমানে যা করছে তার জন্য প্রয়োজনীয়। বিভিন্ন অ্যাপ্লিকেশন উপাদানগুলি এর ধারণ প্রক্রিয়াটিকে বিভিন্ন উপায়ে অগ্রভাগে বিবেচনা করতে পারে। একটি প্রক্রিয়া অগ্রভাগে বিবেচনা করা হয় যদি নিম্নলিখিত শর্তগুলির মধ্যে কোনটি থাকে:
    • এটি স্ক্রিনের শীর্ষে একটি Activity চালাচ্ছে যার সাথে ব্যবহারকারী ইন্টারঅ্যাক্ট করছে (এর onResume() পদ্ধতি বলা হয়েছে)।
    • এটিতে একটি BroadcastReceiver রয়েছে যা বর্তমানে চলছে (এর BroadcastReceiver.onReceive() পদ্ধতি কার্যকর হচ্ছে)।
    • এটির একটি Service রয়েছে যা বর্তমানে এটির একটি কলব্যাক ( Service.onCreate() , Service.onStart() , বা Service.onDestroy() ) এ কোড নির্বাহ করছে৷

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

  2. একটি দৃশ্যমান প্রক্রিয়া কাজ করছে যা ব্যবহারকারী বর্তমানে সচেতন, তাই এটিকে হত্যা করা ব্যবহারকারীর অভিজ্ঞতার উপর একটি লক্ষণীয় নেতিবাচক প্রভাব ফেলে। একটি প্রক্রিয়া নিম্নলিখিত অবস্থার মধ্যে দৃশ্যমান বলে মনে করা হয়:
    • এটি এমন একটি Activity চালাচ্ছে যা অন-স্ক্রীন ব্যবহারকারীর কাছে দৃশ্যমান কিন্তু অগ্রভাগে নয় (এর onPause() পদ্ধতি বলা হয়েছে)৷ এটি ঘটতে পারে, উদাহরণস্বরূপ, যদি ফোরগ্রাউন্ড Activity একটি ডায়ালগ হিসাবে প্রদর্শিত হয় যা পূর্ববর্তী Activity এর পিছনে দেখতে দেয়।
    • এটির একটি Service রয়েছে যা একটি ফোরগ্রাউন্ড পরিষেবা হিসাবে চলছে, Service.startForeground() এর মাধ্যমে (যা সিস্টেমকে পরিষেবাটিকে এমন কিছু হিসাবে বিবেচনা করতে বলে যা ব্যবহারকারী সচেতন, বা মূলত এটি দৃশ্যমান ছিল)৷
    • এটি এমন একটি পরিষেবা হোস্ট করছে যা সিস্টেম একটি নির্দিষ্ট বৈশিষ্ট্যের জন্য ব্যবহার করছে যা ব্যবহারকারী সচেতন, যেমন একটি লাইভ ওয়ালপেপার বা একটি ইনপুট পদ্ধতি পরিষেবা৷

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

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

    যে পরিষেবাগুলি দীর্ঘ সময় ধরে চলছে (যেমন 30 মিনিট বা তার বেশি) তাদের প্রক্রিয়াটি ক্যাশ করা তালিকায় নামিয়ে দেওয়ার জন্য গুরুত্বের সাথে হ্রাস করা হতে পারে।

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

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

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

    যেহেতু ক্যাশড প্রসেসগুলি যেকোন সময় সিস্টেম দ্বারা মেরে ফেলা যেতে পারে, তাই ক্যাশে থাকা অবস্থায় অ্যাপগুলির সমস্ত কাজ বন্ধ করা উচিত৷ যদি ব্যবহারকারী-সমালোচনামূলক কাজটি অবশ্যই অ্যাপ দ্বারা সঞ্চালিত হয়, তবে এটি একটি সক্রিয় প্রক্রিয়া অবস্থা থেকে কাজ চালানোর জন্য উপরের APIগুলির একটি ব্যবহার করা উচিত।

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

    অ্যান্ড্রয়েড 13 থেকে শুরু করে, একটি অ্যাপ প্রক্রিয়া সীমিত বা কার্যকর করার সময় পেতে পারে না যতক্ষণ না এটি উপরের একটি সক্রিয় জীবনচক্র অবস্থায় প্রবেশ করে।

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

একটি প্রক্রিয়াকে কীভাবে শ্রেণীবদ্ধ করা যায় তা নির্ধারণ করার সময়, সিস্টেমটি তার সিদ্ধান্তকে ভিত্তি করে সবচেয়ে গুরুত্বপূর্ণ স্তরের উপর যেটি বর্তমানে সক্রিয় সমস্ত উপাদানগুলির মধ্যে পাওয়া যায়। এই উপাদানগুলির প্রতিটি কীভাবে একটি প্রক্রিয়া এবং অ্যাপ্লিকেশনের সামগ্রিক জীবনচক্রে অবদান রাখে সে সম্পর্কে আরও বিশদ বিবরণের জন্য Activity , Service এবং BroadcastReceiver ডকুমেন্টেশন দেখুন৷

একটি প্রক্রিয়ার অগ্রাধিকার অন্যান্য নির্ভরতাগুলির উপর ভিত্তি করেও বাড়ানো যেতে পারে যা একটি প্রক্রিয়াতে রয়েছে। উদাহরণস্বরূপ, যদি প্রসেস A Context.BIND_AUTO_CREATE পতাকা সহ একটি Service সাথে আবদ্ধ থাকে বা প্রক্রিয়া B-এ একটি ContentProvider ব্যবহার করে, তাহলে প্রক্রিয়া B-এর শ্রেণীবিভাগ সর্বদা প্রক্রিয়া A-এর মতোই গুরুত্বপূর্ণ।