পরিষেবা বাইন্ডিং এবং প্রক্রিয়া অবস্থা

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

প্রক্রিয়ার অবস্থা এবং OOM স্কোর

অ্যান্ড্রয়েড ফ্রেমওয়ার্ক প্রতিটি চলমান প্রসেসের গুরুত্ব ট্র্যাক করতে প্রসেস স্টেট ব্যবহার করে। এরপর এই স্টেটগুলো OomAdjuster দ্বারা -1000 থেকে 1000 পর্যন্ত একটি OOM স্কোর অ্যাডজাস্টমেন্ট ( oom_score_adj ) মান নির্ধারণ করতে ব্যবহৃত হয়।

oom_score_adj মান কম হওয়ার অর্থ হলো প্রসেসটি অধিক গুরুত্বপূর্ণ এবং লো মেমোরি কিলার (LMK) দ্বারা কিল হওয়ার সম্ভাবনা কম।

সাধারণ প্রক্রিয়া অবস্থা

নিম্নলিখিত সারণীতে কয়েকটি সর্বাধিক প্রচলিত প্রসেস স্টেট এবং তাদের সাধারণ oom_score_adj মান দেখানো হয়েছে। একটি সম্পূর্ণ এবং হালনাগাদ তালিকার জন্য, অ্যান্ড্রয়েড সোর্স কোডে android.app.ActivityManager এবং com.android.server.am.psc.Constants দেখুন।

পরিষেবা বন্ধনের প্রভাব

যখন কোনো ক্লায়েন্ট প্রসেস (যেমন, TOP স্টেটে থাকা কোনো অ্যাপ) একটি সার্ভার প্রসেসের কোনো সার্ভিসের সাথে বাইন্ড হয়, তখন সার্ভার প্রসেসটি প্রায়শই একটি উচ্চতর প্রায়োরিটি লাভ করে । এটি নিশ্চিত করে যে ক্লায়েন্টের যতক্ষণ প্রয়োজন, ততক্ষণ সার্ভিসটি উপলব্ধ থাকে।

BIND ফ্ল্যাগ ব্যবহার করে উত্তরাধিকার নিয়ন্ত্রণ

Context.BIND_AUTO_CREATE ব্যবহার করার সময় ইনহেরিটেন্সই হলো ডিফল্ট আচরণ। তবে, ডেভেলপাররা bindService() বিভিন্ন ফ্ল্যাগ ব্যবহার করে নিয়ন্ত্রণ করতে পারেন যে বাইন্ডিংটি টার্গেট প্রসেসের গুরুত্বকে কীভাবে প্রভাবিত করবে।

OOM স্কোরের জন্য গুরুত্বপূর্ণ BIND ফ্ল্যাগসমূহ

সিস্টেম-ব্যাপী মেমরি চাপ ব্যবস্থাপনার ক্ষেত্রে নিম্নলিখিত ফ্ল্যাগগুলো সবচেয়ে প্রাসঙ্গিক:

• BIND_AUTO_CREATE : এটি সবচেয়ে প্রচলিত ফ্ল্যাগ। এটি নিশ্চিত করে যে বাইন্ডিং বিদ্যমান থাকা পর্যন্ত সার্ভিস প্রসেসটি চালু থাকবে। ডিফল্টরূপে, এটি সার্ভার প্রসেসের প্রায়োরিটিও ক্লায়েন্টের সাথে মিলিয়ে বাড়িয়ে দেয়।
• BIND_NOT_FOREGROUND : টার্গেট সার্ভিসের প্রসেসকে ফোরগ্রাউন্ড শিডিউলিং প্রায়োরিটিতে (সিপিইউ প্রায়োরিটি) উন্নীত হওয়া থেকে বিরত রাখে। তবে, এটি মেমরি প্রায়োরিটি ( oom_score_adj ) উন্নীত হওয়ার অনুমতি দেয় । এটি এমন ব্যাকগ্রাউন্ড কাজের জন্য উপযোগী, যা সিপিইউ সাইকেলের জন্য UI-এর সাথে প্রতিযোগিতা করবে না, কিন্তু কিল হওয়া থেকে সুরক্ষিত থাকা প্রয়োজন।
• BIND_WAIVE_PRIORITY : এটি একটি অত্যন্ত শক্তিশালী ফ্ল্যাগ যা সিস্টেমকে টার্গেট প্রসেসের শিডিউলিং বা মেমরি ম্যানেজমেন্ট প্রায়োরিটিতে প্রভাব না ফেলার নির্দেশ দেয়। সার্ভিস প্রসেসটিকে LRU লিস্টে থাকা একটি সাধারণ ব্যাকগ্রাউন্ড প্রসেসের মতোই পরিচালনা করা হবে, যার ফলে এটি বাউন্ড থাকা অবস্থাতেও OOM কিলিংয়ের জন্য যোগ্য বলে বিবেচিত হবে।
• BIND_ABOVE_CLIENT : এটি নির্দেশ করে যে সার্ভিসটি ক্লায়েন্ট অ্যাপের চেয়ে বেশি গুরুত্বপূর্ণ। যখন সিস্টেমের মেমরি পুনরুদ্ধার করার প্রয়োজন হয়, তখন এটি বাইন্ড করা সার্ভিসটি বন্ধ করার আগে ক্লায়েন্ট অ্যাপটি বন্ধ করতে পছন্দ করে। এটি BIND_AUTO_CREATE চেয়ে "শক্তিশালী", কারণ এটি ক্লায়েন্টের ক্ষতির বিনিময়ে সার্ভিসটির জন্য সুরক্ষার একটি অতিরিক্ত স্তর প্রদান করে।
• BIND_NOT_PERCEPTIBLE : টার্গেট সার্ভিসের গুরুত্ব PERCEPTIBLE লেভেলের নিচে নামিয়ে আনে, যার ফলে সিস্টেম আরও গুরুত্বপূর্ণ ও ব্যবহারকারী-বোধগম্য প্রসেসগুলোর জন্য জায়গা করে দিতে এর মেমরি পুনরুদ্ধার করতে পারে।

হাতে-কলমে: বাইন্ডিং প্রভাব পর্যবেক্ষণ

আমরা মেমোরিল্যাব অ্যাপ্লিকেশনটি ব্যবহার করে দেখাবো, কীভাবে একটি TOP অ্যাপের বাইন্ডিং একটি পৃথক প্রসেসের অবস্থাকে প্রভাবিত করে।

১. মেমোরিল্যাব চালু করুন

নিম্নলিখিত কমান্ডটি অ্যাপটি চালু করবে। এটি খোলার পর, নিশ্চিত করুন যেন অ্যাপটি ফোরগ্রাউন্ডে থাকে (এখনও হোম বাটন চাপবেন না বা অ্যাপ পরিবর্তন করবেন না)।

adb shell am start -n com.android.memorylab/.MainActivity

২. প্রক্রিয়াগুলি চিহ্নিত করুন

বাইন্ডিং করার আগে প্রসেসের অবস্থাগুলো যাচাই করে নিন। MemoryLab তার প্রধান UI একটি প্রসেসে চালায় এবং এর একটি RemoteService আছে যা একটি :remote প্রসেসে চলে।

adb shell dumpsys activity processes com.android.memorylab

নমুনা আউটপুট স্নিপেট:

  Process OOM control (154 total, non-act at 7, non-svc at 7):
    Proc #0: fg       T/A/TOP  LCMNFUATI  t: 0 13470:com.android.memorylab/u0a417 (top-activity)
        oom: max=1001 curRaw=0 setRaw=0 cur=0 set=0
        state: cur=TOP  set=TOP   lastRss=0.00 lastCachedRss=0.00

আপনি মূল প্রসেস com.android.memorylab TOP অবস্থায় দেখতে পাবেন। :remote প্রসেসটি এখনও চালু হয়নি।

৩. ট্রিগার বাইন্ডিং

সার্ভিস বাইন্ডিং চালু করতে অ্যাপে একটি ব্রডকাস্ট পাঠান:

adb shell am broadcast -a com.android.memorylab.LEAK_BINDER

৪. উন্নত অবস্থা পর্যবেক্ষণ করুন

প্রক্রিয়ার অবস্থাগুলো আবার যাচাই করুন:

adb shell dumpsys activity processes | grep -A 10 "com.android.memorylab"

নমুনা আউটপুট স্নিপেট:

  Proc #  1: vis      F/ /BTOP ---NFUATI  t: 0 13560:com.android.memorylab:remote/u0a417 (service)
    com.android.memorylab/.RemoteService<=Proc{13470:com.android.memorylab/u0a417}
    oom: max=1001 curRaw=100 setRaw=100 cur=100 set=100
    state: cur=BTOP set=BTOP  lastRss=0.00 lastCachedRss=0.00

:remote প্রসেসটি এখন চলছে এবং BTOP (Bound TOP) অবস্থায় আছে, যার oom_score_adj হলো ১০০। এটি একটি সাধারণ ব্যাকগ্রাউন্ড সার্ভিসের (যার প্রায়োরিটি 500 বা তার বেশি হয়ে থাকে) চেয়ে উল্লেখযোগ্যভাবে বেশি সুরক্ষিত। <=Proc{...} এই নোটেশনটি দেখায় কোন প্রসেসটি এই প্রায়োরিটি বৃদ্ধির জন্য দায়ী।

৫. পটভূমিতে পাঠান

ডিভাইসের HOME বোতামটি চাপুন। অবস্থাগুলো আবার যাচাই করুন:

adb shell dumpsys activity processes | grep -A 10 "com.android.memorylab"

নমুনা আউটপুট স্নিপেট:

    Proc #  2: prev     b/ /LAST --------I  t: 0 13560:com.android.memorylab:remote/u0a417 (service)
        com.android.memorylab/.RemoteService<=Proc{13470:com.android.memorylab/u0a417}
        oom: max=1001 curRaw=700 setRaw=700 cur=700 set=700
        state: cur=LAST set=LAST  lastRss=0.00 lastCachedRss=0.00
    Proc #  1: prev     b/ /LAST --------I  t: 0 13470:com.android.memorylab/u0a417 (previous)
        oom: max=1001 curRaw=700 setRaw=700 cur=700 set=700
        state: cur=LAST set=LAST  lastRss=209MB lastCachedRss=0.00

এখন উভয় প্রসেসই একটি নিম্ন অগ্রাধিকার অবস্থায় ( PREV / oom_score_adj 700 ) স্থানান্তরিত হয়েছে, কারণ ক্লায়েন্ট প্রসেসটি আর TOP ) নেই। (দ্রষ্টব্য: স্টেট ডাম্পের LAST বলতে LAST_ACTIVITY অভ্যন্তরীণ অবস্থাকে বোঝায়, যা উচ্চ-স্তরের সারাংশে PREV সাথে ম্যাপ করা থাকে)।

প্রোকস্ট্যাটস দিয়ে বিশ্লেষণ

procstats টুলটি এই রাজ্যগুলোর একটি ঐতিহাসিক চিত্র প্রদান করে।

# View stats for MemoryLab over the last hour
adb shell dumpsys procstats --hours 1 com.android.memorylab

নমুনা আউটপুট স্নিপেট:

  *   com.android.memorylab / u0a417 / v37:
      *   Prc com.android.memorylab / u0a417 / v37:
             TOTAL: 0.89% (0.00-0.00-0.00/0.00-0.00-0.00/210MB-210MB-210MB over 1)
               Top: 0.89% (0.00-0.00-0.00/0.00-0.00-0.00/210MB-210MB-210MB over 1)
      *   Prc com.android.memorylab:remote / u0a417 / v37:
             TOTAL: 0.19%
           Bnd Top: 0.19%

এখানে, Bnd Top নির্দেশ করে যে, রিমোট প্রসেসটি TOP স্টেটে কোনো অ্যাপ্লিকেশনের দ্বারা আবদ্ধ থেকে কত শতাংশ সময় ব্যয় করেছে।

পারফেট্টো দিয়ে বাইন্ডিং ক্যাপচার এবং বিশ্লেষণ করা

dumpsys আপনাকে একটি স্ন্যাপশট দিলেও, Perfetto আপনাকে বাইন্ডিং ঘটার সঠিক মুহূর্তটি এবং রিয়েল-টাইমে OOM স্কোরের পরিবর্তন দেখতে দেয়।

১. একটি ট্রেস রেকর্ড করুন

এমন একটি কনফিগারেশন ব্যবহার করুন যাতে linux.process_stats এবং am atrace ক্যাটাগরি অন্তর্ভুক্ত থাকে:

adb shell perfetto -c - --txt -o /data/misc/perfetto-traces/service_bindings.perfetto-trace <<EOF
buffers: { size_kb: 65536 }
data_sources: {
    config {
        name: "linux.process_stats"
        process_stats_config { proc_stats_poll_ms: 100 }
    }
}
data_sources: {
    config {
        name: "linux.ftrace"
        ftrace_config { ftrace_events: "am/am_proc_bound" }
    }
}
duration_ms: 15000
EOF

২. OOM স্কোর পরিবর্তনগুলি জিজ্ঞাসা করুন

PerfettoSQL ব্যবহার করে, আপনি দেখতে পারেন যে UI প্রসেসের তুলনায় রিমোট প্রসেসের OOM স্কোর কীভাবে পরিবর্তিত হয়েছে:

SELECT ts, p.name, value AS oom_score_adj
FROM counter c
JOIN process_counter_track t ON c.track_id = t.id
JOIN process p USING (upid)
WHERE p.name LIKE 'com.android.memorylab%'
  AND t.name = 'oom_score_adj'
ORDER BY ts;

৩. বাইন্ডিং ইভেন্টগুলি সনাক্ত করুন

একটি বাইন্ডিং ডিপেন্ডেন্সি ঠিক কখন প্রতিষ্ঠিত হয়েছিল এবং কোন প্রসেস এটি শুরু করেছিল তা দেখতে, এই কোয়েরিটি ব্যবহার করুন:

SELECT
    s.ts,
    p.name AS process_name,
    t.name AS thread_name,
    s.name AS slice_name
FROM slice s
JOIN thread_track tt ON s.track_id = tt.id
JOIN thread t USING (utid)
JOIN process p USING (upid)
WHERE s.name LIKE 'bindService:{com.android.memorylab%';

সিস্টেম-টু-অ্যাপ বাইন্ডিং

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

এখানে কিছু বাস্তব উদাহরণ দেওয়া হলো যা একটি সাধারণ ডিভাইসে দেখা যায়:

VoiceInteractor

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

যখন কোনো অ্যাসিস্ট্যান্ট ট্রিগার ঘটে (যেমন গুগল পিক্সেল ফোনে "ওকে গুগল" হটওয়ার্ড), তখন ডিজিটাল অ্যাসিস্ট্যান্টকে তাৎক্ষণিকভাবে সাড়া দিতে হয়। এটি নিশ্চিত করার জন্য, system_server ব্যবহারকারীর দ্বারা নির্বাচিত ভয়েস ইন্টারঅ্যাকশন সার্ভিসের সাথে একটি স্থায়ী বাইন্ডিং বজায় রাখে।

আপনি যদি প্রসেসের অবস্থাগুলো পরীক্ষা করেন (যেমন, dumpsys activity processes ব্যবহার করে), তাহলে আপনি com.google.android.googlequicksearchbox:interactor মতো একটি প্রসেসকে BFGS (Bound Foreground Service) অবস্থায় দেখতে পারেন, যা system_server (UID 1000)-এর একটি বাইন্ডিং দ্বারা সচল রাখা হয়েছে।

NotificationListenerService

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

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

লঞ্চারের "-1 স্ক্রিন" (নিউজ ফিড)

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

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

অন্যান্য সাধারণ উদাহরণ

• লঞ্চার (HOME_APP_ADJ) : লঞ্চার অ্যাপ (হোম)-এর প্রায়োরিটি লিস্টে নিজস্ব একটি বিশেষ স্লট রয়েছে। যদিও এটি সবসময় কোনো সার্ভিসের সাথে যুক্ত থাকে না, এটিকে HOME_APP_ADJ (সাধারণত 600 ) অ্যাসাইন করা হয়। সিস্টেম লঞ্চারটিকে চালু রাখতে পছন্দ করে, কারণ ব্যবহারকারী প্রায়শই এতে ফিরে আসেন। প্রকৃতপক্ষে, সিস্টেম লঞ্চারটিকে কিল করার চেয়ে পূর্বে ব্যবহৃত অ্যাপটিকে ( PREV_APP_ADJ = 700 ) কিল করতে বেশি পছন্দ করবে, কারণ লঞ্চার কিল করলে যেকোনো অ্যাপ থেকে বের হওয়ার সময় ব্যবহারকারীর অভিজ্ঞতা ধীরগতির হবে, যেহেতু লঞ্চারটি কোল্ড স্টার্ট হওয়ার জন্য অপেক্ষা করতে হবে।
• ইনপুট মেথড এডিটর (IME) : আপনি যখন টাইপ করেন, তখন সিস্টেম আপনার নির্বাচিত কীবোর্ড অ্যাপের (যেমন, Gboard) সাথে সংযুক্ত হয়। এর ফলে, কীবোর্ড সাময়িকভাবে লুকানো থাকলেও কীবোর্ড প্রসেসটি সক্রিয় থাকে। এটি নিশ্চিত করে যে আপনি অন্য কোনো টেক্সট ফিল্ডে ট্যাপ করলে কীবোর্ডটি সঙ্গে সঙ্গে পুনরায় প্রদর্শিত হতে পারে।
• এনএফসি পেমেন্ট : আপনি যখন অর্থ প্রদানের জন্য আপনার ফোন ট্যাপ করেন, তখন সিস্টেমটি এনএফসি পেমেন্ট পরিষেবার (যেমন, গুগল ওয়ালেট) সাথে সংযুক্ত হয়। এই লেনদেনগুলির জন্য প্রায়শই মার্চেন্ট টার্মিনালের পক্ষ থেকে কঠোর রিয়েল-টাইম প্রয়োজনীয়তা থাকে। যদি পেমেন্ট অ্যাপটিকে হঠাৎ করে চালু করতে হয়, তাহলে লেনদেনটি টাইম আউট হয়ে ব্যর্থ হতে পারে।

আপস এবং কর্মক্ষমতার সংকট

পারফরম্যান্স ও নির্ভুলতার জন্য বাইন্ডিং অপরিহার্য হলেও, এর ফলে সিস্টেমের মেমোরির স্বাস্থ্যের ওপর নেতিবাচক প্রভাব পড়ে।

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

← এলাকা | ↑ উপরে | সিস্টেম-ব্যাপী →