Android-ன் பில்ட் டூல்ஸ்கள் (build tools) இப்போது Kotlin Coroutines-களுக்கு ஒரு வேக அதிகரிப்பைப் (speed-boost) பெற்றுள்ளன. Android Gradle Plugin (AGP) 9.2.0 மற்றும் அதனுடன் வரும் R8 shrinker மூலம், coroutine நிலை கையாளுதலுக்கு (state handling) உதவும் bytecode மறுசீரமைக்கப்பட்டுள்ளது. இது பொதுவான coroutine செயல்பாடுகளில் கிட்டத்தட்ட இரண்டு மடங்கு வேகத்தை வழங்கும். Coroutines-ஐப் பயன்படுத்தும் Android செயலிகளை உருவாக்கும் டெவலப்பர்கள், ஒரு வரியைக் கூட மாற்றாமல் வேகமான cold-start நேரங்கள், நிலையான frame rates மற்றும் மேம்பட்ட பேட்டரி ஆயுளைப் பெற முடியும்.

Coroutine செயல்திறன் ஏன் முக்கியமானது

Kotlin Coroutines பல திரைகளில் (multiple threads) உள்ள உட்புற புலங்களை (internal fields) பாதுகாப்பாக மாற்ற AtomicFieldUpdater ஆப்ஜெக்ட்களைப் பயன்படுத்துகின்றன. இந்த அணுகுமுறை ஒவ்வொரு மாற்றத்திற்கும் ஒரு புதிய atomic ஆப்ஜெக்ட்டை உருவாக்குவதைத் தவிர்க்கிறது, ஆனால் Android-இல் இது மூன்று மறைமுகச் செலவுகளை (hidden costs) ஏற்படுத்துகிறது:

  • Class-loading தாமதம் – updater பிரதிபலிப்பு முறையில் (reflectively) உருவாக்கப்படுவதால், VM இயக்க நேரத்தில் (runtime) இலக்கு புலத்தைத் (target field) தேட வேண்டும்.
  • CPU வீணாதல் – ஒவ்வொரு முறையும் உண்மையான புலத்தை அணுகுவதற்கு முன், updater-ன் நிலையைச் சரிபார்க்க வேண்டியுள்ளது.
  • Inlining வரம்புகள் – கம்பைலரால் updater அழைப்புகளை inline செய்ய முடியாது, இதனால் உருவாக்கப்பட்ட bytecode பெரியதாகவும் மெதுவாகவும் இருக்கும்.

நடைமுறையில், channel send/receive, mutex lock/unlock, StateFlow updates மற்றும் coroutine dispatch போன்ற முக்கியமான செயல்பாட்டுப் பாதைகளில் (hot paths) இந்தச் செலவுகள் தெரியவருகின்றன. இதன் விளைவாக, செயலியின் சொந்த வேலைகளைச் செய்வதை விட, கணக்கு வழக்குகளுக்காகவே (bookkeeping) கணிசமான CPU நேரம் செலவிடப்படுகிறது.

AGP 9.2.0 மற்றும் R8-இல் என்ன மாறியுள்ளது

AGP 9.2.0-உடன் வரும் R8 என்ற code-shrinker, இப்போது கம்பைல் செய்யப்பட்ட bytecode-இல் உள்ள நிலையான AtomicFieldUpdater முறையை ஸ்கேன் செய்கிறது. அதைத் கண்டறியும்போது, அது நான்கு மாற்றங்களைச் செய்கிறது:

  1. புலத்தின் memory offset-ஐக் கண்டறிதல். R8 ஆப்ஜெக்ட் லேஅவுட்டிற்குள் இலக்கு புலத்தின் துல்லியமான இடத்தைக் கணக்கிடுகிறது.
  2. Updater ஆப்ஜெக்ட்டை நீக்குதல். Reflective wrapper நீக்கப்படுவதால், நினைவகம் (memory) சேமிக்கப்படுவதோடு class-loading வேலையும் தவிர்க்கப்படுகிறது.
  3. நேரடி sun.misc.Unsafe அழைப்பைச் சேர்த்தல். இந்த low-level API, ஒரு ஒற்றை atomic hardware instruction மூலம் புலத்தில் எழுதுகிறது.
  4. ஒவ்வொரு updater அழைப்பையும் மாற்றுதல். புதிய unsafe instruction மூலம் மாற்றுவதன் மூலம், JIT compiler அந்தச் செயல்பாட்டை inline செய்ய அனுமதிக்கிறது.

இதன் ஒட்டுமொத்த விளைவு என்னவென்றால், CPU இனி reflective lookup அல்லது runtime சோதனைகளைச் செய்ய வேண்டியதில்லை; அது நேரடியாக atomic instruction-ஐச் செயல்படுத்துகிறது. ஒரு டெவலப்பரின் பார்வையில் இந்த மாற்றம் கண்ணுக்குத் தெரியாது – coroutine API அதேபோலவே செயல்படும் – ஆனால் உள்ளுக்குள் (under the hood) குறியீடு "metal-level" வேகத்தில் இயங்குகிறது.

அளவிடக்கூடிய முன்னேற்றங்கள்

AGP 9.2.0, R8 மற்றும் minification ஆகியவற்றைச் செயல்படுத்தி பில்ட் செய்த பிறகு, ஒரு சாதாரண Android சாதனத்தில் மேற்கொள்ளப்பட்ட Benchmarks பின்வரும் வேக அதிகரிப்பைக் காட்டுகின்றன:

  • Channel send/receive: 2.01 × வேகமானது
  • Mutex lock/unlock: 1.90 × வேகமானது
  • StateFlow updates: 2.02 × வேகமானது
  • Coroutine dispatch: 1.68 × வேகமானது

இந்த எண்கள் பயனாளர் அனுபவத்தில் (user-experience) குறிப்பிடத்தக்க முன்னேற்றத்தைத் தருகின்றன. Coroutine synchronization-க்காக ஒரு வினாடியின் ஒரு பகுதியைச் செலவிட்ட cold launch இப்போது விரைவாக முடிவடைகிறது, இது முதல் frame-ஐத் திரையில் காட்ட UI thread-க்கு அதிக இடவசதியை (headroom) வழங்குகிறது. CPU பயன்பாடு குறைவது, பிராசஸர் விரைவாக sleep நிலைக்குச் செல்ல உதவுகிறது, இது பேட்டரி ஆயுளை மேம்படுத்தும்.

இந்த நன்மைகளைப் பெறுவது எப்படி

குறியீட்டில் எந்த மாற்றமும் தேவையில்லை. இந்த மறுசீரமைப்பைச் செயல்படுத்த உங்களுக்குத் தேவை:

  • AGP 9.2.0 அல்லது அதற்குப் புதியது – புதுப்பிக்கப்பட்ட R8 உள்ள பதிப்பு.
  • R8 – மேலே உள்ள AGP-யைப் பயன்படுத்தி பில்ட் செய்யும்போது தானாகவே பயன்படுத்தப்படும்.
  • Kotlin Coroutines 1.8.0+ – optimizer எதிர்பார்க்கும் AtomicFieldUpdater முறையைக் கொண்ட லைப்ரரி பதிப்பு.
  • உங்கள் release build type-இல் isMinifyEnabled = true – minification ஆன் செய்யப்பட்டிருக்கும் போது மட்டுமே R8 இயங்கும்.

ஒரே ஒரு கூடுதல் படிநிலை உங்கள் ProGuard (அல்லது R8) விதிகளை (rules) ஆய்வு செய்வதுதான். volatile புலங்கள் அல்லது updater வகுப்புகளை அப்படியே வைத்திருக்கும் விரிவான -keep வழிகாட்டுதல்கள் இந்த மறுசீரமைப்பைத் தடுக்கும். அந்தப் புலங்களை மாற்ற R8-க்கு அனுமதிக்கும் வகையில் விதிகள் இருப்பதை உறுதி செய்யவும்; இல்லையெனில் optimizer பழைய reflective முறையையே பயன்படுத்தும்.

Android Studio-வின் APK Analyzer மூலம் இந்த மாற்றத்தை நீங்கள் சரிபார்க்கலாம். கம்பைல் செய்யப்பட்ட APK-வைத் திறந்து, JobSupport போன்ற ஒரு coroutine support class-ஐக் கண்டறிந்து, decompiled bytecode-ஐப் பார்க்கவும். மறுசீரமைப்பு வெற்றியடைந்தால், static updater புலங்கள் இருக்காது மற்றும் அதற்குப் பதிலாக Unsafe-க்கான நேரடி அழைப்புகளைக் காண்பீர்கள்.

எச்சரிக்கைகள் மற்றும் முரண்பாடுகள்

இந்த மேம்படுத்தல் (optimization) இரண்டு நிபந்தனைகளைச் சார்ந்துள்ளது, அவை எல்லாத் திட்டங்களுக்கும் (projects) பொருந்தாது:

  1. Minification கண்டிப்பாகச் செயல்படுத்தப்பட வேண்டும். Debug builds, அல்லது பிழைத்திருத்த வசதிக்காக minification-ஐ முடக்கி வைத்துள்ள release builds, இந்த நன்மையைப் பெறாது.
  2. ProGuard விதிகள் தளர்வாக (permissive) இருக்க வேண்டும். Coroutine internals-க்காக தீவிரமான -keep முறைகளைப் பயன்படுத்தும் திட்டங்களில், அந்த விதிகளைத் தளர்த்த வேண்டியிருக்கலாம்; கவனமாகச் சோதனை செய்யாவிட்டால், இது shrinking தொடர்பான பிழைகளால் உட்புற வகுப்புகளை (internal classes) பாதிக்கக்கூடும்.

நீங்கள் இலக்கு வைத்துள்ள பல்வேறு சாதனங்களில் சோதனை செய்வது ஒரு சிறந்த நடைமுறையாகும்.

அடுத்து கவனிக்க வேண்டியவை

இந்த மறுசீரமைப்பு (rewrite), மொழியின் சுருக்கங்களுக்குப் (language abstractions) பின்னால் மறைந்துள்ள செயல்திறனை, build-time bytecode மாற்றங்கள் எவ்வாறு வெளிக்கொண்டு வர முடியும் என்பதைக் காட்டுகிறது. உங்கள் குறிப்பிட்ட பணிச்சுமையின் (workload) அடிப்படையில் கிடைக்கும் முன்னேற்றங்களை உறுதிப்படுத்த, coroutine-அதிகமாகப் பயன்படுத்தும் உங்கள் சொந்தக் குறியீட்டை (code) profile செய்து பார்க்கவும்.

முக்கியக் குறிப்பு: AGP 9.2.0-க்கு மேம்படுத்துவதும் மற்றும் R8-இன் minification-ஐச் செயல்படுத்துவதும், Kotlin coroutine-அதிகமாகப் பயன்படுத்தும் செயலிகளுக்கு, மூலக் குறியீட்டை (source code) மாற்றாமலேயே முக்கியமான synchronization வேகத்தை கிட்டத்தட்ட இருமடங்காக உயர்த்துகிறது—இதற்கு build configuration, optimizer தனது வேலையைச் செய்ய அனுமதிக்க வேண்டும்.