আপনার অ্যাপের মেমরি পরিচালনা করুন

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

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

উপলব্ধ মেমরি এবং মেমরি ব্যবহার মনিটর

আপনার অ্যাপের মেমরি ব্যবহারের সমস্যাগুলি সমাধান করার আগে আপনাকে অবশ্যই খুঁজে বের করতে হবে৷ অ্যান্ড্রয়েড স্টুডিওতে মেমরি প্রোফাইলার আপনাকে নিম্নলিখিত উপায়ে মেমরি সমস্যাগুলি খুঁজে পেতে এবং নির্ণয় করতে সহায়তা করে:

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

ইভেন্টের প্রতিক্রিয়া মেমরি রিলিজ

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

আপনি বিভিন্ন মেমরি-সম্পর্কিত ইভেন্টগুলিতে প্রতিক্রিয়া জানাতে onTrimMemory() কলব্যাক প্রয়োগ করতে পারেন, যেমনটি নিম্নলিখিত উদাহরণে দেখানো হয়েছে:

কোটলিন

import android.content.ComponentCallbacks2
// Other import statements.

class MainActivity : AppCompatActivity(), ComponentCallbacks2 {

    // Other activity code.

    /**
     * Release memory when the UI becomes hidden or when system resources become low.
     * @param level the memory-related event that is raised.
     */
    override fun onTrimMemory(level: Int) {

        if (level >= ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN) {
            // Release memory related to UI elements, such as bitmap caches.
        }

        if (level >= ComponentCallbacks2.TRIM_MEMORY_BACKGROUND) {
            // Release memory related to background processing, such as by
            // closing a database connection.
        }
    }
}

জাভা

import android.content.ComponentCallbacks2;
// Other import statements.

public class MainActivity extends AppCompatActivity
    implements ComponentCallbacks2 {

    // Other activity code.

    /**
     * Release memory when the UI becomes hidden or when system resources become low.
     * @param level the memory-related event that is raised.
     */
    public void onTrimMemory(int level) {

        if (level >= ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN) {
            // Release memory related to UI elements, such as bitmap caches.
        }

        if (level >= ComponentCallbacks2.TRIM_MEMORY_BACKGROUND) {
            // Release memory related to background processing, such as by
            // closing a database connection.
        }
    }
}

আপনার কত মেমরি প্রয়োজন তা পরীক্ষা করুন

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

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

নিম্নলিখিত উদাহরণ কোড স্নিপেট দেখায় কিভাবে আপনার অ্যাপে getMemoryInfo() পদ্ধতি ব্যবহার করতে হয়।

কোটলিন

fun doSomethingMemoryIntensive() {

    // Before doing something that requires a lot of memory,
    // check whether the device is in a low memory state.
    if (!getAvailableMemory().lowMemory) {
        // Do memory intensive work.
    }
}

// Get a MemoryInfo object for the device's current memory status.
private fun getAvailableMemory(): ActivityManager.MemoryInfo {
    val activityManager = getSystemService(Context.ACTIVITY_SERVICE) as ActivityManager
    return ActivityManager.MemoryInfo().also { memoryInfo ->
        activityManager.getMemoryInfo(memoryInfo)
    }
}

জাভা

public void doSomethingMemoryIntensive() {

    // Before doing something that requires a lot of memory,
    // check whether the device is in a low memory state.
    ActivityManager.MemoryInfo memoryInfo = getAvailableMemory();

    if (!memoryInfo.lowMemory) {
        // Do memory intensive work.
    }
}

// Get a MemoryInfo object for the device's current memory status.
private ActivityManager.MemoryInfo getAvailableMemory() {
    ActivityManager activityManager = (ActivityManager) this.getSystemService(ACTIVITY_SERVICE);
    ActivityManager.MemoryInfo memoryInfo = new ActivityManager.MemoryInfo();
    activityManager.getMemoryInfo(memoryInfo);
    return memoryInfo;
}

আরও মেমরি-দক্ষ কোড নির্মাণ ব্যবহার করুন

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

সংযতভাবে পরিষেবাগুলি ব্যবহার করুন

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

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

সাধারণত, ক্রমাগত পরিষেবাগুলি ব্যবহার করা এড়িয়ে চলুন কারণ তারা উপলব্ধ মেমরিতে রাখে। পরিবর্তে, আমরা আপনাকে একটি বিকল্প বাস্তবায়ন ব্যবহার করার পরামর্শ দিই, যেমন WorkManager । ব্যাকগ্রাউন্ড প্রসেস শিডিউল করতে WorkManager কিভাবে ব্যবহার করবেন সে সম্পর্কে আরও তথ্যের জন্য, Persistent work দেখুন।

অপ্টিমাইজ করা ডেটা কন্টেইনার ব্যবহার করুন

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

অ্যান্ড্রয়েড ফ্রেমওয়ার্কে SparseArray , SparseBooleanArray , এবং LongSparseArray সহ বেশ কয়েকটি অপ্টিমাইজ করা ডেটা কন্টেনার রয়েছে৷ উদাহরণস্বরূপ, SparseArray ক্লাসগুলি আরও দক্ষ কারণ তারা কী এবং কখনও কখনও মানটিকে অটোবক্স করার সিস্টেমের প্রয়োজনীয়তা এড়ায়, যা প্রতি এন্ট্রিতে আরও একটি বা দুটি বস্তু তৈরি করে।

প্রয়োজনে, আপনি সর্বদা একটি চর্বিহীন ডেটা কাঠামোর জন্য কাঁচা অ্যারেতে স্যুইচ করতে পারেন।

কোড বিমূর্ততা সঙ্গে সতর্ক থাকুন

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

সিরিয়ালাইজড ডেটার জন্য লাইট প্রোটোবাফ ব্যবহার করুন

প্রোটোকল বাফার (প্রোটোবাফ) হল একটি ভাষা-নিরপেক্ষ, প্ল্যাটফর্ম-নিরপেক্ষ, এক্সটেনসিবল মেকানিজম যা Google দ্বারা স্ট্রাকচার্ড ডেটা সিরিয়ালাইজ করার জন্য ডিজাইন করা হয়েছে—এক্সএমএল-এর মতো, কিন্তু ছোট, দ্রুত এবং সহজ। আপনি যদি আপনার ডেটার জন্য প্রোটোবাফগুলি ব্যবহার করেন তবে সর্বদা আপনার ক্লায়েন্ট-সাইড কোডে লাইট প্রোটোবাফগুলি ব্যবহার করুন৷ নিয়মিত প্রোটোবাফগুলি অত্যন্ত ভার্বোস কোড তৈরি করে, যা আপনার অ্যাপে অনেক সমস্যা সৃষ্টি করতে পারে, যেমন র‍্যাম ব্যবহার বৃদ্ধি, APK আকারের উল্লেখযোগ্য বৃদ্ধি এবং ধীরগতি সম্পাদন।

আরও তথ্যের জন্য, protobuf readme দেখুন।

স্মৃতি মন্থন এড়িয়ে চলুন

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

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

উদাহরণস্বরূপ, আপনি লুপের for একাধিক অস্থায়ী বস্তু বরাদ্দ করতে পারেন। অথবা, আপনি একটি ভিউ এর onDraw() ফাংশনের ভিতরে নতুন Paint বা Bitmap অবজেক্ট তৈরি করতে পারেন। উভয় ক্ষেত্রেই, অ্যাপটি উচ্চ ভলিউমে দ্রুত প্রচুর বস্তু তৈরি করে। এগুলি তরুণ প্রজন্মের সমস্ত উপলব্ধ স্মৃতি দ্রুত গ্রাস করতে পারে, একটি আবর্জনা সংগ্রহের ঘটনা ঘটতে বাধ্য করে৷

মেমরি প্রোফাইলার ব্যবহার করে আপনার কোডের সেই জায়গাগুলি খুঁজে বের করুন যেখানে মেমরি মন্থন বেশি হয় সেগুলি ঠিক করার আগে।

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

আপনি অবজেক্ট পুল ব্যবহারের ক্ষেত্রে উপকারী কিনা তাও মূল্যায়ন করতে পারেন। একটি অবজেক্ট পুলের সাথে, মেঝেতে একটি অবজেক্ট ইনস্ট্যান্স ড্রপ করার পরিবর্তে, আপনি এটিকে একটি পুলে ছেড়ে দেন যখন এটির আর প্রয়োজন নেই৷ পরের বার যখন এই ধরনের একটি বস্তুর উদাহরণ প্রয়োজন, আপনি এটি বরাদ্দ না করে পুল থেকে এটি অর্জন করতে পারেন।

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

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

মেমরি-নিবিড় সম্পদ এবং লাইব্রেরি সরান

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

সামগ্রিক APK আকার হ্রাস করুন

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

আপনার সামগ্রিক অ্যাপের আকার হ্রাস করার বিষয়ে আরও তথ্যের জন্য, আপনার অ্যাপের আকার হ্রাস করুন দেখুন।

নির্ভরতা ইনজেকশনের জন্য হিল্ট বা ড্যাগার 2 ব্যবহার করুন

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

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

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

বহিরাগত লাইব্রেরি ব্যবহার সম্পর্কে সতর্কতা অবলম্বন করুন

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

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

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

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