অ্যান্ড্রয়েড ৮.০ রিলিজে অ্যান্ড্রয়েড রানটাইম (ART) উল্লেখযোগ্যভাবে উন্নত করা হয়েছে। নীচের তালিকায় ডিভাইস নির্মাতারা ART-তে যে উন্নতিগুলি আশা করতে পারেন তার সংক্ষিপ্তসার রয়েছে।
সমসাময়িক কম্প্যাক্টিং আবর্জনা সংগ্রাহক
গুগল আই/ও-তে ঘোষিত হিসাবে, অ্যান্ড্রয়েড ৮.০-তে ART-তে একটি নতুন কনকমার্টেন্ট কম্প্যাক্টিং গার্বেজ কালেক্টর (GC) রয়েছে। এই কালেক্টরটি প্রতিবার GC চালানোর সময় এবং অ্যাপটি চলাকালীন হিপকে কম্প্যাক্ট করে, থ্রেড রুট প্রক্রিয়াকরণের জন্য শুধুমাত্র একটি সংক্ষিপ্ত বিরতি দিয়ে। এর সুবিধাগুলি এখানে দেওয়া হল:
- GC সর্বদা হিপকে সংকুচিত করে: Android 7.0 এর তুলনায় গড়ে 32% ছোট হিপ আকার।
- কম্প্যাকশন থ্রেড লোকাল বাম্প পয়েন্টার অবজেক্ট অ্যালোকেশন সক্ষম করে: অ্যালোকেশন অ্যান্ড্রয়েড ৭.০ এর তুলনায় ৭০% দ্রুত।
- অ্যান্ড্রয়েড ৭.০ জিসির তুলনায় এইচ২ বেঞ্চমার্কের জন্য ৮৫% কম বিরতির সময় অফার করে।
- হিপের আকারের উপর নির্ভর করে আর বিরতির সময় নির্ধারণ করা হয় না; অ্যাপগুলি জ্যাঙ্ক সম্পর্কে চিন্তা না করেই বড় হিপ ব্যবহার করতে সক্ষম হবে।
- জিসি বাস্তবায়নের বিস্তারিত - বাধাগুলি পড়ুন:
- পঠন বাধা হল প্রতিটি বস্তু ক্ষেত্রের পঠনের জন্য করা অল্প পরিমাণ কাজ।
- এগুলি কম্পাইলারে অপ্টিমাইজ করা হয়েছে, তবে কিছু ব্যবহারের ক্ষেত্রে ধীরগতি আনতে পারে।
লুপ অপ্টিমাইজেশন
অ্যান্ড্রয়েড ৮.০ রিলিজে ART বিভিন্ন ধরণের লুপ অপ্টিমাইজেশন ব্যবহার করে:
- বাউন্ড চেক এলিমিনেশন
- স্ট্যাটিক: কম্পাইল-টাইমে রেঞ্জগুলি সীমার মধ্যে রয়েছে বলে প্রমাণিত হয়
- গতিশীল: রান-টাইম পরীক্ষা নিশ্চিত করে যে লুপগুলি সীমানার মধ্যে থাকে (অন্যথায় বাদ দিন)
- আবেশন পরিবর্তনশীল নির্মূল
- ডেড ইন্ডাকশন সরান
- লুপের পরে ব্যবহৃত আবেশনকে বদ্ধ-রূপের রাশি দিয়ে প্রতিস্থাপন করুন।
- লুপ-বডির ভিতরে ডেড কোড এলিমিনেশন, ডেড হয়ে যাওয়া সম্পূর্ণ লুপ অপসারণ
- শক্তি হ্রাস
- লুপ রূপান্তর: বিপরীতকরণ, আন্তঃপরিবর্তন, বিভাজন, আনরোলিং, ইউনিমডুলার ইত্যাদি।
- সিমডাইজেশন (যাকে ভেক্টরাইজেশনও বলা হয়)
লুপ অপ্টিমাইজারটি ART কম্পাইলারের নিজস্ব অপ্টিমাইজেশন পাসে থাকে। বেশিরভাগ লুপ অপ্টিমাইজেশন অন্যত্র অপ্টিমাইজেশন এবং সরলীকরণের অনুরূপ। কিছু অপ্টিমাইজেশনের সাথে চ্যালেঞ্জ দেখা দেয় যা CFG কে স্বাভাবিকের চেয়ে আরও বিস্তৃত উপায়ে পুনর্লিখন করে, কারণ বেশিরভাগ CFG ইউটিলিটি (nodes.h দেখুন) একটি CFG তৈরির উপর ফোকাস করে, পুনর্লিখনের উপর নয়।
শ্রেণী শ্রেণিবিন্যাস বিশ্লেষণ
অ্যান্ড্রয়েড ৮.০-এ ART ক্লাস হায়ারার্কি অ্যানালাইসিস (CHA) ব্যবহার করে, যা একটি কম্পাইলার অপ্টিমাইজেশন যা ক্লাস হায়ারার্কি বিশ্লেষণ করে তৈরি তথ্যের উপর ভিত্তি করে ভার্চুয়াল কলগুলিকে সরাসরি কলে রূপান্তরিত করে। ভার্চুয়াল কলগুলি ব্যয়বহুল কারণ এগুলি একটি vtable লুকআপের চারপাশে বাস্তবায়িত হয় এবং এগুলি কয়েকটি নির্ভরশীল লোড নেয়। এছাড়াও ভার্চুয়াল কলগুলিকে ইনলাইন করা যায় না।
এখানে সম্পর্কিত বর্ধিতকরণের একটি সারসংক্ষেপ দেওয়া হল:
- গতিশীল একক-বাস্তবায়ন পদ্ধতির স্থিতি আপডেট - ক্লাস লিঙ্কিং সময়ের শেষে, যখন vtable পূরণ করা হয়, ART সুপার ক্লাসের vtable এর সাথে একটি এন্ট্রি-বাই-এন্ট্রি তুলনা পরিচালনা করে।
- কম্পাইলার অপ্টিমাইজেশন - কম্পাইলার একটি পদ্ধতির একক-বাস্তবায়ন তথ্যের সুবিধা গ্রহণ করবে। যদি একটি পদ্ধতি A.foo-তে একক-বাস্তবায়ন ফ্ল্যাগ সেট থাকে, তাহলে কম্পাইলার ভার্চুয়াল কলটিকে একটি সরাসরি কলে ভার্চুয়ালাইজ করবে এবং ফলস্বরূপ সরাসরি কলটিকে ইনলাইন করার চেষ্টা করবে।
- কম্পাইল করা কোড অবৈধকরণ - ক্লাস লিঙ্কিং সময় শেষে যখন একক-বাস্তবায়ন তথ্য আপডেট করা হয়, যদি A.foo পদ্ধতিতে পূর্বে একক-বাস্তবায়ন ছিল কিন্তু সেই অবস্থা এখন অবৈধ করা হয়, তাহলে সমস্ত কম্পাইল করা কোড যা এই ধারণার উপর নির্ভর করে যে পদ্ধতি A.foo-তে একক-বাস্তবায়ন রয়েছে তাদের কম্পাইল করা কোড অবৈধ করা প্রয়োজন।
- ডিঅপ্টিমাইজেশন - স্ট্যাকে থাকা লাইভ কম্পাইল করা কোডের জন্য, সঠিকতা নিশ্চিত করার জন্য অবৈধ কম্পাইল করা কোডটিকে ইন্টারপ্রেটার মোডে জোর করে ডিঅপ্টিমাইজেশন শুরু করা হবে। সিঙ্ক্রোনাস এবং অ্যাসিনক্রোনাস ডিঅপ্টিমাইজেশনের একটি সংকর ডিঅপ্টিমাইজেশনের একটি নতুন প্রক্রিয়া ব্যবহার করা হবে।
.oat ফাইলগুলিতে ইনলাইন ক্যাশে
ART এখন ইনলাইন ক্যাশে ব্যবহার করে এবং যেসব কল সাইটের জন্য পর্যাপ্ত ডেটা বিদ্যমান, সেগুলিকে অপ্টিমাইজ করে। ইনলাইন ক্যাশে বৈশিষ্ট্যটি প্রোফাইলে অতিরিক্ত রানটাইম তথ্য রেকর্ড করে এবং এটি ব্যবহার করে অগ্রিম সংকলনে গতিশীল অপ্টিমাইজেশন যোগ করে।
ডেক্সলেআউট
ডেক্সলেআউট হল অ্যান্ড্রয়েড ৮.০-তে চালু করা একটি লাইব্রেরি যা ডেক্স ফাইল বিশ্লেষণ করে প্রোফাইল অনুসারে পুনরায় সাজায়। ডেক্সলেআউটের লক্ষ্য হল ডিভাইসে নিষ্ক্রিয় রক্ষণাবেক্ষণ সংকলনের সময় ডেক্স ফাইলের অংশগুলিকে পুনরায় সাজানোর জন্য রানটাইম প্রোফাইলিং তথ্য ব্যবহার করা। ডেক্স ফাইলের যে অংশগুলি প্রায়শই একসাথে অ্যাক্সেস করা হয় সেগুলিকে একত্রিত করে, প্রোগ্রামগুলি উন্নত লোকালয় থেকে আরও ভাল মেমরি অ্যাক্সেস প্যাটার্ন পেতে পারে, RAM সাশ্রয় করতে পারে এবং শুরু করার সময় কমাতে পারে।
যেহেতু বর্তমানে প্রোফাইল তথ্য শুধুমাত্র অ্যাপগুলি চালানোর পরেই পাওয়া যায়, তাই নিষ্ক্রিয় রক্ষণাবেক্ষণের সময় dexlayout dex2oat-এর অন-ডিভাইস সংকলনে একীভূত হয়।
ডেক্স ক্যাশে অপসারণ
অ্যান্ড্রয়েড ৭.০ পর্যন্ত, DexCache অবজেক্টে চারটি বৃহৎ অ্যারে ছিল, যা DexFile-এর নির্দিষ্ট উপাদানের সংখ্যার সমানুপাতিক, যথা:
- স্ট্রিং (প্রতি DexFile::StringId-এর জন্য একটি রেফারেন্স),
- প্রকার (প্রতি DexFile::TypeId-এর জন্য একটি রেফারেন্স),
- পদ্ধতি (প্রতি DexFile::MethodId-এর জন্য একটি নেটিভ পয়েন্টার),
- ক্ষেত্র (প্রতি DexFile::FieldId-এর জন্য একটি নেটিভ পয়েন্টার)।
এই অ্যারেগুলি আমরা পূর্বে সমাধান করা বস্তুগুলির দ্রুত পুনরুদ্ধারের জন্য ব্যবহার করা হয়েছিল। অ্যান্ড্রয়েড 8.0-এ, পদ্ধতি অ্যারে ছাড়া সমস্ত অ্যারে সরানো হয়েছে।
দোভাষীর কর্মক্ষমতা
অ্যান্ড্রয়েড ৭.০ রিলিজে "mterp" - অ্যাসেম্বলি ভাষায় লেখা একটি কোর ফেচ/ডিকোড/ইন্টারপ্রেট মেকানিজম সমন্বিত একটি ইন্টারপ্রেটার - প্রবর্তনের মাধ্যমে ইন্টারপ্রেটারের কর্মক্ষমতা উল্লেখযোগ্যভাবে উন্নত হয়েছে। Mterp দ্রুত ডালভিক ইন্টারপ্রেটারের আদলে তৈরি, এবং arm, arm64, x86, x86_64, mips এবং mips64 সমর্থন করে। কম্পিউটেশনাল কোডের জন্য, Art-এর mterp মোটামুটি ডালভিকের দ্রুত ইন্টারপ্রেটারের সাথে তুলনীয়। তবে, কিছু পরিস্থিতিতে এটি উল্লেখযোগ্যভাবে - এমনকি নাটকীয়ভাবে - ধীর হতে পারে:
- কর্মক্ষমতা আহ্বান করুন।
- স্ট্রিং ম্যানিপুলেশন, এবং ডালভিকে অভ্যন্তরীণ হিসাবে স্বীকৃত অন্যান্য পদ্ধতির ভারী ব্যবহারকারী।
- স্ট্যাক মেমোরির ব্যবহার বেশি।
অ্যান্ড্রয়েড ৮.০ এই সমস্যাগুলির সমাধান করে।
আরও ইনলাইনিং
অ্যান্ড্রয়েড ৬.০ থেকে, ART একই ডেক্স ফাইলের মধ্যে যেকোনো কল ইনলাইন করতে পারে, কিন্তু বিভিন্ন ডেক্স ফাইল থেকে কেবল লিফ পদ্ধতি ইনলাইন করতে পারে। এই সীমাবদ্ধতার দুটি কারণ ছিল:
- অন্য একটি ডেক্স ফাইল থেকে ইনলাইন করার জন্য সেই অন্য একটি ডেক্স ফাইলের ডেক্স ক্যাশে ব্যবহার করতে হয়, একই ডেক্স ফাইল ইনলাইনিংয়ের বিপরীতে, যা কেবল কলারের ডেক্স ক্যাশে পুনরায় ব্যবহার করতে পারে। স্ট্যাটিক কল, স্ট্রিং লোড বা ক্লাস লোডের মতো কয়েকটি নির্দেশাবলীর জন্য কম্পাইল করা কোডে ডেক্স ক্যাশে প্রয়োজন।
- স্ট্যাক ম্যাপগুলি কেবল বর্তমান ডেক্স ফাইলের মধ্যে একটি পদ্ধতি সূচক এনকোড করছে।
এই সীমাবদ্ধতাগুলি মোকাবেলা করার জন্য, Android 8.0:
- কম্পাইল করা কোড থেকে ডেক্স ক্যাশে অ্যাক্সেস সরিয়ে দেয় ("ডেক্স ক্যাশে অপসারণ" বিভাগটিও দেখুন)
- স্ট্যাক ম্যাপ এনকোডিং প্রসারিত করে।
সিঙ্ক্রোনাইজেশনের উন্নতি
ART টিম MonitorEnter/MonitorExit কোড পাথগুলিকে টিউন করেছে, এবং ARMv8-এ ঐতিহ্যবাহী মেমরি বাধার উপর আমাদের নির্ভরতা কমিয়েছে, যেখানে সম্ভব নতুন (অর্জন/মুক্তি) নির্দেশাবলী দিয়ে সেগুলি প্রতিস্থাপন করেছে।
দ্রুততর দেশীয় পদ্ধতি
@FastNative এবং @CriticalNative অ্যানোটেশন ব্যবহার করে জাভা নেটিভ ইন্টারফেস (JNI) তে দ্রুত নেটিভ কল পাওয়া যায়। এই অন্তর্নির্মিত ART রানটাইম অপ্টিমাইজেশনগুলি JNI ট্রানজিশনগুলিকে দ্রুততর করে এবং বর্তমানে অবচিত !bang JNI নোটেশন প্রতিস্থাপন করে। অ্যানোটেশনগুলি নন-নেটিভ পদ্ধতির উপর কোনও প্রভাব ফেলে না এবং শুধুমাত্র bootclasspath প্ল্যাটফর্ম জাভা ল্যাঙ্গুয়েজ কোডের জন্য উপলব্ধ (কোনও প্লে স্টোর আপডেট নেই)।
@FastNative অ্যানোটেশনটি নন-স্ট্যাটিক পদ্ধতিগুলিকে সমর্থন করে। যদি কোনও পদ্ধতি কোনও jobject প্যারামিটার বা রিটার্ন মান হিসাবে অ্যাক্সেস করে তবে এটি ব্যবহার করুন।
@CriticalNative অ্যানোটেশনটি নিম্নলিখিত বিধিনিষেধ সহ নেটিভ পদ্ধতিগুলি চালানোর আরও দ্রুত উপায় প্রদান করে:
- পদ্ধতিগুলি অবশ্যই স্ট্যাটিক হতে হবে—প্যারামিটার, রিটার্ন মান, অথবা অন্তর্নিহিত
thisজন্য কোনও অবজেক্ট থাকবে না। - শুধুমাত্র আদিম প্রকারগুলি স্থানীয় পদ্ধতিতে স্থানান্তরিত হয়।
- নেটিভ পদ্ধতিটি তার ফাংশন সংজ্ঞায়
JNIEnvএবংjclassপ্যারামিটার ব্যবহার করে না। - গতিশীল JNI লিঙ্কিংয়ের উপর নির্ভর না করে পদ্ধতিটি
RegisterNativesএ নিবন্ধিত হতে হবে।
@FastNative নেটিভ পদ্ধতির কর্মক্ষমতা 3x পর্যন্ত উন্নত করতে পারে, এবং @CriticalNative 5x পর্যন্ত উন্নত করতে পারে। উদাহরণস্বরূপ, একটি Nexus 6P ডিভাইসে পরিমাপ করা একটি JNI ট্রানজিশন:
| জাভা নেটিভ ইন্টারফেস (JNI) আমন্ত্রণ | কার্যকর করার সময় (ন্যানোসেকেন্ডে) |
|---|---|
| নিয়মিত জেএনআই | ১১৫ |
| !ব্যাং জেএনআই | ৬০ |
@FastNative | ৩৫ |
@CriticalNative | ২৫ |