সর্বাধিক সাধারণ অ্যান্ড্রয়েড অপ্টিমাইজেশান মিথ ডিবাঙ্ক করা হয়েছে৷

অ্যান্ড্রয়েড পারফরম্যান্স এবং সামগ্রিক অপ্টিমাইজেশান টিপস বাড়ানোর জন্য নিবেদিত প্রচুর নির্দেশনামূলক গাইড রয়েছে৷ তাদের মধ্যে কিছু বৈধ, এবং অন্যগুলি শুধুমাত্র তত্ত্বের উপর ভিত্তি করে, বা অ্যান্ড্রয়েড সিস্টেমে পুরানো অপারেশনাল পদ্ধতি, বা কেবল সাধারণ বাজে কথা। এর মধ্যে রয়েছে অদলবদল করার সুপারিশ, build.prop-এ যোগ করা মান এবং Linux কার্নেলে পরিবর্তনশীল পরিবর্তন।

এমনকি সেখানে এক টন "অপ্টিমাইজেশন স্ক্রিপ্ট" রয়েছে, সব-ই-এক ফ্ল্যাশযোগ্য .zips যা উল্লেখযোগ্যভাবে কার্যক্ষমতা, ব্যাটারি লাইফ এবং অন্যান্য জিনিসগুলিকে বৃদ্ধি করার প্রতিশ্রুতি দেয়৷ কিছু ​​ টুইকগুলি আসলে কাজ করতে পারে, তবে বেশিরভাগই কেবল একটি প্লাসিবো প্রভাব, বা আরও খারাপ, আসলে আপনার ডিভাইসে নেতিবাচক প্রভাব ফেলে৷

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

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

এই Appuals এক্সক্লুসিভ নিবন্ধে, আমরা “অপ্টিমাইজ করা” -এর জন্য সবচেয়ে সাধারণ কিছু সুপারিশ তুলে ধরব। অ্যান্ড্রয়েড পারফরম্যান্স, এবং সেগুলি কেবল একটি পৌরাণিক কাহিনী, বা ডিভাইসের কার্যক্ষমতার জন্য একটি বৈধ পরিবর্তন৷

অদলবদল

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

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

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

মোদ্দা কথা হল, উদাহরণস্বরূপ, 1GB র‍্যাম সহ একটি ডিভাইস কখনই একটি সোয়াপে প্রয়োজনীয় কর্মক্ষমতা ডেটা পৌঁছাতে পারে না, এবং তাই অ্যান্ড্রয়েডে অদলবদলের একেবারেই প্রয়োজন নেই৷ এটির বাস্তবায়ন কেবল ব্যবধানে পরিপূর্ণ এবং এটি একটি অবক্ষয় র দিকে নিয়ে যায় পারফরম্যান্সে, এটি অপ্টিমাইজ করার পরিবর্তে।

zRAM - পুরানো এবং আর কার্যকর নয়

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

zRAM-এর উদ্দেশ্য ছিল এন্ট্রি-লেভেল বাজেট-রেঞ্জ মাল্টি-কোর SoC, যেমন MTK চিপসেট এবং 512 MB RAM ব্যবহার করা ডিভাইসগুলির জন্য। খুব সস্তা চাইনিজ ফোন, মূলত. zRAM মূলত যা করে তা হল এনক্রিপশন স্ট্রিমের মাধ্যমে কার্নেলকে আলাদা করা।

যখন একক কোর সহ পুরানো ডিভাইসগুলিতে zRAM ব্যবহার করা হয় , এমনকি যদি এই ধরনের ডিভাইসগুলিতে zRAM সুপারিশ করা হয়, বড় পরিমাণে ল্যাগগুলি ক্রপ আপ হতে থাকে। এটি KSM প্রযুক্তির সাথেও ঘটে (Kernel Same Page Merging) যা স্থান খালি করার জন্য অভিন্ন মেমরি পৃষ্ঠাগুলিকে একত্রিত করে। এটি আসলে Google দ্বারা সুপারিশ করা হয়েছে, কিন্তু এটি পুরানো ডিভাইসগুলিতে আরও বেশি ব্যবধানের দিকে নিয়ে যায়, কারণ ক্রমাগত সক্রিয় কোর থিডগুলি সদৃশ পৃষ্ঠাগুলি অনুসন্ধান করার জন্য মেমরি থেকে ক্রমাগত চলছে৷ মূলত, অপ্টিমাইজেশন টুইক চালানোর চেষ্টা করা ডিভাইসটিকে আরও ধীর করে দেয়, হাস্যকরভাবে।

সিডার - অ্যান্ড্রয়েড 3.0 থেকে পুরানো

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

হ্যাঁ, প্রচুর সংখ্যক প্রতিবেদন রয়েছে যা অনেক পুরানো Android ডিভাইসে ইনস্টলেশনের পরে আরও ভাল Android কার্যক্ষমতা ঘোষণা করে। . যাইহোক, লোকেরা যে কারণেই বিশ্বাস করুক না কেন এর মানে হল এটি আধুনিক অ্যান্ড্রয়েড ডিভাইসের জন্য একটি প্রযোজ্য অপ্টিমাইজেশন , যা একেবারেই অযৌক্তিক। সত্য যে Seeder এখনও রক্ষণাবেক্ষণ করা হয় এবং একটি “আধুনিক” হিসেবে দেওয়া হয় ল্যাগ রিডাকশন টুল হল ভুল তথ্যের একটি উদাহরণ – যদিও এটি সিডারের ডেভেলপারের দোষ নয়, এমনকি তাদের প্লে স্টোর পৃষ্ঠাও নোট করে যে Android 4.0+ এর পরে Seeder কম কার্যকর। তবুও যে কারণেই হোক না কেন, সিডার এখনও আধুনিক অ্যান্ড্রয়েড সিস্টেমের জন্য অপ্টিমাইজেশান আলোচনায় পপ আপ করে৷

সিডার মূলত অ্যান্ড্রয়েড 3.0 এর জন্য যা করে তা হল একটি বাগের সমাধান যেখানে অ্যান্ড্রয়েড রানটাইম সক্রিয়ভাবে এনট্রপি অর্জন করতে /dev/random/ ফাইল ব্যবহার করবে। /dev/random/ বাফারটি অস্থির হয়ে উঠবে, এবং সিস্টেমটি অবরুদ্ধ থাকবে যতক্ষণ না এটি প্রয়োজনীয় পরিমাণ ডেটা পূরণ করবে - Android ডিভাইসে বিভিন্ন সেন্সর এবং বোতামগুলির মতো ছোট জিনিসগুলি মনে করুন৷

সিডারের লেখক Linux- demon rngd নিয়েছিলেন , এবং Android এর inastroil-এর জন্য কম্পাইল করা হয়েছে যাতে এটি আরও দ্রুত এবং আরও বেশি অনুমানযোগ্য /dev/urandom পথ থেকে এলোমেলো ডেটা নেয় এবং /dev/random/কে নিঃশেষ হতে না দিয়ে প্রতি সেকেন্ডে dev/random/ এ মার্জ করে। এর ফলে একটি অ্যান্ড্রয়েড সিস্টেম তৈরি হয়েছে যা এনট্রপির অভাব অনুভব করেনি এবং অনেক মসৃণ কাজ করেছে৷

অ্যান্ড্রয়েড 3.0 এর পরে Google এই বাগটি ভেঙে দিয়েছে, তবুও কিছু কারণে, সিডার এখনও “প্রস্তাবিত টুইকস” এ পপ আপ করে অ্যান্ড্রয়েড কর্মক্ষমতা অপ্টিমাইজেশান জন্য তালিকা. অধিকন্তু, Seeder অ্যাপটিতে sEFix এর মতো কয়েকটি অ্যানালগ রয়েছে যার মধ্যে সীডারের কার্যকারিতা রয়েছে, একই rngd ব্যবহার করা হোক না কেন অথবা বিকল্প haveged , অথবা এমনকি /dev/urandom এবং /dev/random-এর মধ্যে একটি সিমলিঙ্ক। আধুনিক অ্যান্ড্রয়েড সিস্টেমের জন্য এটি একেবারেই অর্থহীন৷

এর অর্থহীন কারণ হল নতুন অ্যান্ড্রয়েড সংস্করণগুলি তিনটি প্রধান উপাদানে /dev/random/ ব্যবহার করে – libcrypto , এসএসএল সংযোগের এনক্রিপশন, এসএসএইচ কী তৈরি করা ইত্যাদির জন্য। WPA_supplication/hostapd যা WEP/WPA কী তৈরি করে এবং অবশেষে, EXT2/EXT3/EXT4 ফাইল সিস্টেম তৈরিতে আইডি তৈরি করার জন্য মুষ্টিমেয় লাইব্রেরি।

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

Odex

অ্যান্ড্রয়েড ডিভাইসে স্টক ফার্মওয়্যার প্রায় সবসময় ওডেক্স হয়। এর মানে হল যে APK ফরম্যাটে Android অ্যাপের স্ট্যান্ডার্ড প্যাকেজের পাশাপাশি, /system/app/ এবং /system/priv-app/-এ পাওয়া যায়, .odex এক্সটেনশনের সাথে একই ফাইলের নাম। ওডেক্স ফাইলগুলিতে অপ্টিমাইজ করা বাইটকোড অ্যাপ্লিকেশন রয়েছে যা ইতিমধ্যেই যাচাইকারী এবং অপ্টিমাইজার ভার্চুয়াল মেশিনের মধ্য দিয়ে চলে গেছে, তারপর dexopt এর মতো কিছু ব্যবহার করে একটি পৃথক ফাইলে রেকর্ড করা হয়েছে। টুল।

সুতরাং ওডেক্স ফাইলগুলি ভার্চুয়াল মেশিন অফলোড করার জন্য এবং ওডেক্সড অ্যাপ্লিকেশনের দ্রুত লঞ্চের প্রস্তাব দেওয়ার জন্য বোঝানো হয়েছে - নেতিবাচক দিক থেকে, ODEX ফাইলগুলি ফার্মওয়্যারে পরিবর্তনগুলিকে বাধা দেয় এবং আপডেটে সমস্যা তৈরি করে, তাই এই কারণে LineageOS-এর মতো অনেক কাস্টম রম বিতরণ করা হয় ODEX ছাড়া .

ওডেক্স ফাইল তৈরি করা বিভিন্ন উপায়ে করা হয়, যেমন ওডেক্সার টুল ব্যবহার করে - সমস্যাটি হল এটি সম্পূর্ণরূপে একটি প্লাসিবো প্রভাব। আধুনিক অ্যান্ড্রয়েড সিস্টেম যখন /system ডিরেক্টরিতে ওডেক্স ফাইল খুঁজে পায় না, তখন সিস্টেমটি আসলে সেগুলি তৈরি করবে এবং সেগুলিকে /system/dalvik-cache/ ডিরেক্টরিতে রাখবে। যখন আপনি একটি নতুন অ্যান্ড্রয়েড সংস্করণ ফ্ল্যাশ করেন এবং এটি কিছু সময়ের জন্য "ব্যস্ত, অ্যাপ্লিকেশন অপ্টিমাইজ করা" বার্তা দেয় তখন ঠিক এটিই ঘটে।

লোমেমোরিকিলার টুইকস

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

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

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

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

এই কারণে, টাস্ক-কিলাররা আগের মতো জনপ্রিয় নয়, যদিও Android নবাগতরা এখনও কিছু কারণে তাদের উপর নির্ভর করে (তথ্যের অভাব, দুঃখজনকভাবে) . দুর্ভাগ্যবশত, একটি নতুন প্রবণতা টাস্ক-কিলারকে প্রতিস্থাপন করেছে, lowmemorykiller এর প্রবণতা মেকানিজম টিউনিং। এটি উদাহরণস্বরূপ MinFreeManager হবে৷ অ্যাপ, এবং মূল ধারণা হল সিস্টেম ব্যাকগ্রাউন্ড অ্যাপগুলিকে মেরে ফেলা শুরু করার আগে RAM ওভারহেড বাড়ানো।

সুতরাং উদাহরণস্বরূপ, স্ট্যান্ডার্ড RAM সীমানায় কাজ করে - 4, 8, 12, 24, 32, এবং 40 Mb, এবং যখন 40 MB এর বিনামূল্যের সঞ্চয়স্থান পূর্ণ হয়, তখন ক্যাশ করা অ্যাপগুলির মধ্যে একটি যা মেমরিতে লোড হয় কিন্তু চলছে না বন্ধ করা হবে।

তাই মূলত, অ্যান্ড্রয়েডে সর্বদা কমপক্ষে 40 MB উপলব্ধ মেমরি থাকবে, যা lowmemorykiller এর আগে আরও একটি অ্যাপ্লিকেশন মিটমাট করার জন্য যথেষ্ট। এর পরিচ্ছন্নতার প্রক্রিয়া শুরু করে – যার অর্থ ব্যবহারকারীর অভিজ্ঞতায় হস্তক্ষেপ না করেই Android সর্বদা সর্বোচ্চ পরিমাণে উপলব্ধ RAM ব্যবহার করার জন্য যথাসাধ্য চেষ্টা করবে৷

দুঃখজনকভাবে, কিছু হোমব্রু উত্সাহী যা সুপারিশ করতে শুরু করেছেন তা হল মানটি বাড়ানো উচিত, উদাহরণস্বরূপ, LMK শুরু হওয়ার আগে 100 MB। এখন ব্যবহারকারী আসলে হারাবেন RAM (100 – 40 =60), তাই ব্যাক-এন্ড অ্যাপগুলি সঞ্চয় করার জন্য এই স্থানটি ব্যবহার করার পরিবর্তে, সিস্টেম এই পরিমাণ মেমরি মুক্ত রাখবে , এর জন্য একেবারেই কোন উদ্দেশ্য নেই।

LKM টিউনিং উপযোগী হতে পারে 512 র‍্যাম সহ অনেক পুরানো ডিভাইসের জন্য, কিন্তু সেগুলির মালিক কে? 2GB হল আধুনিক "বাজেট পরিসর", এমনকি 4GB RAM ডিভাইসগুলিকে আজকাল "মাঝারি-সীমা" হিসাবে দেখা হচ্ছে, তাই LMK টুইকগুলি সত্যিই পুরানো এবং অকেজো৷

I/O tweaks৷

অ্যান্ড্রয়েডের জন্য প্রচুর অপ্টিমাইজেশান স্ক্রিপ্টে আপনি প্রায়শই I/O সাবসিস্টেমকে সম্বোধন করে এমন টুইকগুলি খুঁজে পাবেন। উদাহরণস্বরূপ, থান্ডারবোল্টের দিকে নজর দেওয়া যাক! স্ক্রিপ্ট, যা এই লাইনগুলি ধারণ করে:

echo 0> $i/queue/rotational;echo 1024> $i/queue/nr_requests;

প্রথম লাইনটি একটি SSD-এর সাথে কাজ করার জন্য I/O শিডিউলারের নির্দেশনা দেবে, এবং দ্বিতীয়টি I/O সারির সর্বোচ্চ আকার 128 থেকে 1024 পর্যন্ত বাড়িয়ে দেয় - কারণ $i ভেরিয়েবলটিতে ব্লক ডিভাইসের গাছের একটি পথ রয়েছে /sys, এবং স্ক্রিপ্টটি লুপে চলে।

এর পরে, আপনি CFQ শিডিউলারের সাথে সম্পর্কিত একটি লাইন খুঁজে পাবেন:

echo 1> $i/queue/iosched/back_seek_penalty;echo 1> $i/queue/iosched/low_latency;echo 1> $i/queue/iosched/slice_idle;

এর পরে আরও লাইন রয়েছে যা অন্যান্য পরিকল্পনাকারীদের অন্তর্গত, কিন্তু শেষ পর্যন্ত, প্রথম দুটি কমান্ড অর্থহীন কারণ:

একটি আধুনিক লিনাক্স কার্নেল বুঝতে সক্ষম যে এটি ডিফল্টরূপে কোন ধরনের স্টোরেজ মিডিয়ামের সাথে কাজ করছে৷

একটি দীর্ঘ ইনপুট-আউটপুট সারি (যেমন 1024) একটি আধুনিক অ্যান্ড্রয়েড ডিভাইসে অকেজো, আসলে এটি ডেস্কটপেও অর্থহীন - এটি সত্যিই শুধুমাত্র হেভি ডিউটি ​​সার্ভারে প্রস্তাবিত . আপনার ফোন একটি ভারী দায়িত্ব Linux সার্ভার নয়.

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

 আমি /sys/block/mmc* এ; doecho noop>
 $i/queue/schedulerecho 0> $i/queue/iostatsdone

এটি I/O পরিসংখ্যান সংগ্রহ থেকে সমস্ত ড্রাইভের জন্য নুপ শিডিউলারকে সক্ষম করবে, যার কার্যক্ষমতার উপর ইতিবাচক প্রভাব থাকা উচিত, যদিও একটি খুব ছোট এবং প্রায় সম্পূর্ণ নগণ্য৷

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

RAID-অ্যারেতে 1 - 8 MB এর মধ্যে উচ্চ পঠন-আগামী মানগুলি সুপারিশ করা হয়, তবে Android ডিভাইসগুলির জন্য, শুধুমাত্র 128 KB-এর ডিফল্ট মান ছেড়ে দেওয়া সর্বোত্তম৷

ভার্চুয়াল মেমরি ম্যানেজমেন্ট সিস্টেম টুইকস

আরেকটি সাধারণ "অপ্টিমাইজেশান" কৌশল হল ভার্চুয়াল মেমরি ম্যানেজমেন্ট সাবসিস্টেম টিউন করা। এটি সাধারণত শুধুমাত্র দুটি কার্নেল ভেরিয়েবলকে লক্ষ্য করে, vm.dirty_background_ratio এবং vm.dirty_ratio, যা "নোংরা" ডেটা সংরক্ষণের জন্য বাফারের আকার সামঞ্জস্য করার জন্য। নোংরা ডেটা সাধারণত এমন ডেটা যা ডিস্কে লেখা হয়েছে, তবে মেমরিতে আরও অনেক কিছু রয়েছে এবং ডিস্কে লেখার অপেক্ষায় রয়েছে৷

ভিএম ম্যানেজমেন্ট সাবসিস্টেমে লিনাক্স ডিস্ট্রোস এবং অ্যান্ড্রয়েস উভয় ক্ষেত্রেই সাধারণ পরিবর্তনের মানগুলি এরকম হবে:

vm.dirty_background_ratio =10vm.dirty_ratio =20

সুতরাং এটি যা করার চেষ্টা করে তা হল যখন নোংরা ডেটা বাফারটি RAM এর মোট পরিমাণের 10% হয়, তখন এটি pdflush জাগ্রত হয় প্রবাহ এবং ডিস্কে ডেটা লিখতে শুরু করে - যদি ডিস্কে ডেটা রেকর্ড করার অপারেশন খুব তীব্র হবে , বাফার বাড়তে থাকবে, এবং যখন এটি উপলব্ধ RAM এর 20% এ পৌঁছাবে, তখন সিস্টেমটি পরবর্তী লেখার ক্রিয়াকলাপ সিঙ্ক্রোনাস মোডে স্যুইচ করবে - প্রি-বাফার ছাড়াই। এর মানে ডিস্ক অ্যাপ্লিকেশনে লেখার কাজ ব্লক করা হবে, যতক্ষণ না ডাটা ডিস্কে লেখা হয় (একেএ 'ল্যাগ')।

আপনার যা বোঝা উচিত তা হল বাফার আকার 10% না পৌঁছালেও , সিস্টেমটি 30 সেকেন্ড পরে স্বয়ংক্রিয়ভাবে পিডিফ্লাশে কিক করবে। 10/20 এর সংমিশ্রণটি বেশ যুক্তিসঙ্গত, উদাহরণস্বরূপ 1GB র‍্যাম সহ একটি ডিভাইসে এটি 100/200MB র‍্যামের সমান হবে, যা বিস্ফোরিত রেকর্ডের পরিপ্রেক্ষিতে যথেষ্ট বেশি যেখানে গতি প্রায়শই সিস্টেমে স্পীড রেকর্ডের নিচে থাকে -মেমরি, বা SD-কার্ড, যেমন অ্যাপ ইনস্টল করার সময় বা কম্পিউটার থেকে ফাইল কপি করার সময়।

কিছু কারণে, স্ক্রিপ্ট লেখকরা এই মানটিকে আরও বেশি, অযৌক্তিক হারে ঠেলে দেওয়ার চেষ্টা করেন। উদাহরণস্বরূপ আমরা Xplix-এ খুঁজে পেতে পারি অপ্টিমাইজেশন স্ক্রিপ্ট 50/90 হিসাবে উচ্চ হার।

sysctl -w vm.dirty_background_ratio=50sysctl -w vm.dirty_ratio=90

1 GB মেমরি সহ একটি ডিভাইসে, এটি একটি নোংরা বাফারের সীমা 500/900 MB এ সেট করে, যা একটি Android ডিভাইসের জন্য সম্পূর্ণ অকেজো, কারণ এটি শুধুমাত্র ডিস্কে ধ্রুবক রেকর্ডিং এর অধীনে কাজ করবে – এমন কিছু যা শুধুমাত্র একটি ভারী লিনাক্স সার্ভারে ঘটে।

থান্ডারবোল্ট ! স্ক্রিপ্ট একটি আরো যুক্তিসঙ্গত মান ব্যবহার করে, কিন্তু সামগ্রিকভাবে, এটি এখনও মোটামুটি অর্থহীন:

 if [ "$mem" -lt 524288 ];thensysctl -w vm.dirty_background_ratio=15;sysctl -w vm.dirty_ratio=30;elif [ "$mem" -lt 1049776 ];thensysctl -w vm.dirty_background_ratio=30 10;sysctl -w vm.dirty_ratio=20;elsesysctl -w vm.dirty_background_ratio=5;sysctl -w vm.dirty_ratio=10;fi;

প্রথম দুটি কমান্ড 512 MB র‍্যাম সহ স্মার্টফোনে, দ্বিতীয়টি - 1 GB সহ, এবং অন্যগুলি - 1 GB-এর বেশি। কিন্তু প্রকৃতপক্ষে ডিফল্ট সেটিংস পরিবর্তন করার একমাত্র কারণ রয়েছে - একটি খুব ধীর অভ্যন্তরীণ মেমরি বা মেমরি কার্ড সহ একটি ডিভাইস। এই ক্ষেত্রে ভেরিয়েবলের মানগুলি ছড়িয়ে দেওয়া যুক্তিসঙ্গত, অর্থাৎ, এরকম কিছু তৈরি করা:

sysctl -w vm.dirty_background_ratio=10sysctl -w vm.dirty_ratio=60

তারপর, যখন একটি সার্জ সিস্টেম অপারেশনগুলি লিখে, ডিস্কে ডেটা রেকর্ড না করে, শেষ পর্যন্ত সিঙ্ক্রোনাস মোডে স্যুইচ করবে না, যা অ্যাপ্লিকেশনগুলিকে রেকর্ড করার সময় ল্যাগ কমাতে অনুমতি দেবে৷

অতিরিক্ত অকেজো টুইক এবং পারফরম্যান্স টিউনিংস

সেখানে আরও অনেক "অপ্টিমাইজেশান" আছে যা সত্যিই কিছু করে না। তাদের বেশিরভাগেরই কোনো প্রভাব নেই, অন্যরা উন্নতি করতে পারে কিছু ​​ পারফরম্যান্সের দিক, অন্য উপায়ে ডিভাইসটিকে অবনমিত করার সময় (সাধারণত এটি পারফরম্যান্স বনাম ব্যাটারি ড্রেন পর্যন্ত ফুটে ওঠে) .

এখানে কিছু অতিরিক্ত জনপ্রিয় অপ্টিমাইজেশান রয়েছে যা Android সিস্টেম এবং ডিভাইসের উপর নির্ভর করে কার্যকর হতে পারে বা নাও হতে পারে৷

• ত্বরণ - কর্মক্ষমতা উন্নত করার জন্য ছোট ত্বরণ এবং আন্ডারভোল্টিং - সামান্য ব্যাটারি বাঁচায়।
• ডাটাবেস অপ্টিমাইজেশান – তাত্ত্বিকভাবে এটি উচিত ডিভাইস কর্মক্ষমতা একটি উন্নতি, কিন্তু এটা সন্দেহজনক.
• Zipalign – পরিহাসের বিষয় হল, স্টোরের APK-ফাইলের মধ্যে অন্তর্নির্মিত Android SDK বৈশিষ্ট্য বিষয়বস্তু সারিবদ্ধ হওয়া সত্ত্বেও আপনি দেখতে পাচ্ছেন যে অনেক সফ্টওয়্যার zipalign এর মাধ্যমে প্রেরণ করা হয় না।
• অপ্রয়োজনীয় সিস্টেম পরিষেবাগুলি নিষ্ক্রিয় করুন, অব্যবহৃত সিস্টেম এবং কদাচিৎ-ব্যবহৃত তৃতীয় পক্ষের অ্যাপ্লিকেশনগুলিকে সরিয়ে দিন। মূলত, ব্লোটওয়্যার আনইনস্টল করা।
• একটি নির্দিষ্ট ডিভাইসের জন্য অপ্টিমাইজেশন সহ কাস্টম কার্নেল (আবারও, সমস্ত নিউক্লিয়াস সমানভাবে ভাল নয়)।
• ইতিমধ্যে বর্ণনা করা হয়েছে I/O শিডিউলার নূপ৷
৷
• স্যাচুরেশন অ্যালগরিদম টিসিপি ওয়েস্টউড – ওয়্যারলেস নেটওয়ার্কের জন্য ডিফল্ট অ্যান্ড্রয়েড কিউবিকে আরও দক্ষতার সাথে ব্যবহার করা হয়, কাস্টম কার্নেলে উপলব্ধ৷

অকেজো সেটিংস build.prop

XDA ডেভেলপারস ফোরাম থেকে LaraCraft304 একটি সমীক্ষা চালিয়েছে এবং দেখেছে যে একটি চিত্তাকর্ষক সংখ্যক /system/build.prop সেটিংস যা "বিশেষজ্ঞদের" ব্যবহারের জন্য সুপারিশ করা হয় উৎস AOSP এবং CyanogenMod-এ বিদ্যমান নেই৷ এখানে তালিকা আছে:

ro.ril.disable.power.collapsero.mot.eri.losalert.delayro.config.hw_fast_dormancyro.config.hw_power_savingwindowsmgr.max_events_per_secpersist.cust.tel.eonsro.max.fling_velocityro.ockdalvick.min. .verify-bytecodedebug.performance.tuningvideo.accelerate.hwro.media.dec.jpeg.memcapro.config.nocheckinprofiler.force_disable_ulogprofiler.force_disable_err_rptersist.sys.shutdown.modero.HOME_APP_ADJ