অ্যাপ ডেভেলপমেন্টে Active Compilation Conditions: মূল ধারণা এবং প্রয়োগ

Active Compilation Conditions কী

Active Compilation Conditions হল কম্পাইলেশন ফ্ল্যাগ যা বিল্ড সময়ে সক্রিয় প্রিপ্রসেসর নির্দেশের সেট নির্ধারণ করে। রানটাইম ফ্ল্যাগ (if (isDebug) চেক) থেকে ভিন্ন, কম্পাইলেশন শর্তগুলি নিষ্ক্রিয় কোডকে বাইনারি ফাইল থেকে শারীরিকভাবে বাদ দেয়, যা কর্মক্ষমতা লাভ এবং অ্যাপ্লিকেশনের আকার হ্রাস করে।

পদ্ধতিটি প্রিপ্রসেসর বা প্রারম্ভিক কম্পাইলেশন পর্যায়ের স্তরে কাজ করে: কম্পাইলার সক্রিয় নামের একটি তালিকা পায়, এবং যখন এটি #if NAME নির্দেশের সম্মুখীন হয়, তখন পরীক্ষা করে যে NAME সেই তালিকায় আছে কিনা। যদি নামটি উপস্থিত না থাকে, তাহলে ব্লকের ভিতরের কোড উপেক্ষা করা হয় এবং কম্পাইল করা হয় না।

Swift.org Blog (2025) অনুসারে, রানটাইম ফ্ল্যাগের পরিবর্তে Active Compilation Conditions ব্যবহার করলে বিস্তৃত লগিং এবং ডিবাগিং টুলসহ প্রকল্পগুলির জন্য রিলিজ বাইনারির আকার গড়ে 12-18% হ্রাস পায়। এটি ইনস্টলেশন ফাইল আকারের সীমাবদ্ধতা সহ মোবাইল অ্যাপ্লিকেশনের জন্য বিশেষভাবে গুরুত্বপূর্ণ।

C/C++ প্রিপ্রসেসর স্তরে শর্তসাপেক্ষ কম্পাইলেশন থেকে প্রধান পার্থক্য হল যে Swift এবং Kotlin-এ Active Compilation Conditions কম্পাইলারের AST (Abstract Syntax Tree) স্তরে কাজ করে, টেক্সট প্রতিস্থাপন স্তরে নয়। এটি এগুলিকে আরও নিরাপদ এবং পূর্বানুমানযোগ্য করে তোলে: নিষ্ক্রিয় #if শাখায় কোনো সিনট্যাক্স ত্রুটি পার্সিং ধাপে ধরা পড়বে, রানটাইমে প্রকাশ পাবে না।

আরেকটি গুরুত্বপূর্ণ পার্থক্য হল যে Swift-এ, শর্ত #if os(iOS) || os(macOS) কম্পাইল সময়ে পরীক্ষা করা হয় এবং প্রিপ্রসেসর ম্যাক্রোর পরিবর্তে প্ল্যাটফর্মের নামের সাথে কাজ করে। এটি #define-এর মাধ্যমে ভুল টেক্সট সন্নিবেশ সম্পর্কিত বাগগুলির একটি সম্পূর্ণ শ্রেণী দূর করে, যা C/C++ প্রিপ্রসেসরে সম্ভব। Swift কম্পাইলার প্রতিস্থাপিত টেক্সটের পরিবর্তে AST দেখে, যা শর্তসাপেক্ষ কম্পাইলেশন ডিবাগিংকে উল্লেখযোগ্যভাবে সহজ করে তোলে।

Swift-এ Active Compilation Conditions

Swift #if নির্দেশের মাধ্যমে Active Compilation Conditions সমর্থন করে, যা লজিক্যাল অপারেটর &&, || এবং ! এর সাথে যুক্ত ফ্ল্যাগ নামের একটি তালিকা গ্রহণ করে। কম্পাইলার #if ... #endif-এর ভিতরের কোড শুধুমাত্র তখনই অন্তর্ভুক্ত করে যদি শর্ত সত্য হয়।

Swift-এ বিল্ট-ইন শর্ত

Swift বেশ কয়েকটি বিল্ট-ইন শর্ত প্রদান করে: DEBUG (ডিবাগ বিল্ডে স্বয়ংক্রিয়ভাবে সক্রিয়), swift(>=5.0) (কম্পাইলার সংস্করণ পরীক্ষা), canImport(UIKit) (মডিউল উপলব্ধতা পরীক্ষা) এবং targetEnvironment(simulator) (পরিবেশ পরীক্ষা)। এই শর্তগুলির জন্য কোনো অতিরিক্ত কনফিগারেশনের প্রয়োজন নেই।

// Swift-এ বিল্ট-ইন শর্ত
#if DEBUG
    print("ডিবাগ বিল্ড — লগিং সক্রিয়")
#endif

#if canImport(UIKit)
    import UIKit
    let screen = UIScreen.main.bounds
#elseif canImport(AppKit)
    import AppKit
    let screen = NSScreen.main?.frame
#endif

Xcode-এ কাস্টম ফ্ল্যাগ

ডেভেলপাররা Xcode-এ Build Setting OTHER_SWIFT_FLAGS-এর মাধ্যমে নিজস্ব ফ্ল্যাগ যোগ করতে পারেন। ফ্ল্যাগটি -D উপসর্গ দিয়ে নির্দিষ্ট করা হয়, উদাহরণস্বরূপ -DBETA বা -DANALYTICS_ENABLED। বিভিন্ন কনফিগারেশনের (Debug, Release, Staging) জন্য ফ্ল্যাগের আলাদা সেট সেট করা যেতে পারে।

// কাস্টম BETA ফ্ল্যাগ হ্যান্ডলিং
#if BETA
    let apiEndpoint = "https://beta.api.com"
    let isLoggingEnabled = true
#else
    let apiEndpoint = "https://api.com"
    let isLoggingEnabled = false
#endif

func trackEvent(_ name: String) {
    #if ANALYTICS_ENABLED
        Analytics.log(name)
    #endif
}

প্ল্যাটফর্ম শর্ত #if os()

Swift প্ল্যাটফর্ম শর্ত সমর্থন করে: os(iOS), os(macOS), os(tvOS), os(watchOS), os(Linux), os(Windows)। এই শর্তগুলি লক্ষ্য বিল্ড প্ল্যাটফর্ম পরীক্ষা করে এবং প্ল্যাটফর্ম-নির্দিষ্ট ব্লক সহ একাধিক Apple প্ল্যাটফর্ম জুড়ে শেয়ার্ড কোড লেখার অনুমতি দেয়।

import Foundation

func getDeviceName() -> String {
    #if os(iOS)
        return UIDevice.current.name
    #elseif os(macOS)
        return Host.current.name ?? "Unknown"
    #else
        return "Other platform"
    #endif
}

Android এবং Kotlin-এ বিকল্প

Android ইকোসিস্টেমে, Active Compilation Conditions BuildConfig সিস্টেম, productFlavors এবং build.gradle.kts-এ ফ্ল্যাগের মাধ্যমে বাস্তবায়িত হয়। Kotlin-এ ভাষা স্তরে #if নির্দেশের সরাসরি সমতুল্য নেই, তবে বিকল্প পদ্ধতি প্রদান করে।

BuildConfig ফিল্ড ফ্ল্যাগ হিসেবে

সবচেয়ে সাধারণ পদ্ধতি হল প্রতিটি ফ্ল্যাগের জন্য একটি buildConfigField যোগ করা: buildConfigField("boolean", "BETA", "true")। এই ফিল্ডগুলি প্রতিটি Build Variant-এর জন্য আলাদাভাবে BuildConfig ক্লাসে জেনারেট হয়। DEBUG ফিল্ডটি ইতিমধ্যেই বিল্ট-ইন এবং ডিবাগ বিল্ডের জন্য স্বয়ংক্রিয়ভাবে সত্য।

// build.gradle.kts
android {
    buildTypes {
        debug {
            buildConfigField("boolean", "BETA", "true")
        }
        release {
            buildConfigField("boolean", "BETA", "false")
        }
    }
}

// Kotlin কোডে ব্যবহার
if (BuildConfig.BETA) {
    enableBetaFeatures()
}

Source Sets এবং productFlavors

Gradle প্রতিটি ফ্লেভারের জন্য আলাদা sourceSets ডিরেক্টরি তৈরি করার অনুমতি দেয়। উদাহরণস্বরূপ, src/demo/ এবং src/full/। বিভিন্ন sourceSets-এ একই নামের ক্লাস সংশ্লিষ্ট ফ্লেভার তৈরির সময় একে অপরকে প্রতিস্থাপন করে। এটি ফ্ল্যাগের চেয়ে বেশি শক্তিশালী একটি পদ্ধতি কারণ পুরো ক্লাস ওভাররাইড করা যেতে পারে।

// src/demo/java/com/example/Config.kt
object Config {
    const val API_URL = "http://demo.api.com"
    const val IS_BETA = true
}

// src/full/java/com/example/Config.kt
object Config {
    const val API_URL = "https://full.api.com"
    const val IS_BETA = false
}

Kotlin Multiplatform (KMP)-এর জন্য, expect/actual নির্দেশ উপলব্ধ, যা সাধারণ কোডে প্রত্যাশিত ঘোষণা ঘোষণা করতে এবং প্ল্যাটফর্ম-নির্দিষ্ট বাস্তবায়ন প্রদান করতে দেয়। এটি প্রভাবে Active Compilation Conditions-এর মতো একটি কম্পাইলার-স্তরের পদ্ধতি — অনুপযুক্ত প্ল্যাটফর্মের জন্য নিষ্ক্রিয় কোড কম্পাইল করা হয় না।

ব্যবহারের ক্ষেত্র এবং সর্বোত্তম অভ্যাস

Active Compilation Conditions চারটি প্রধান পরিস্থিতিতে ব্যবহৃত হয়: ডিবাগিং (লগ, ইন্সপেক্টর), A/B টেস্টিং (ফিচার ফ্ল্যাগ), প্ল্যাটফর্ম অভিযোজন (iOS/macOS শেয়ার্ড কোড) এবং লাইসেন্সিং (ফ্রি/পেড সংস্করণ)।

ডিবাগ লগিং

সবচেয়ে সাধারণ পরিস্থিতি হল শর্তসাপেক্ষ লগিং। ডিবাগ বিল্ডে, সমস্ত লগ কনসোলে লেখা হয়; রিলিজ বিল্ডে, কিছুই লগ করা হয় না। #if DEBUG বা BuildConfig.DEBUG ব্যবহার নিশ্চিত করে যে রিলিজ বাইনারিতে একটি লগার কলও নেই, এমনকি ইনলাইন করাগুলিও নয়।

func logRequest(_ url: URL, _ statusCode: Int) {
    #if DEBUG
        Logger.debug("Request to \(url.absoluteString) returned \(statusCode)")
    #endif
}

বিল্ড সময়ে ফিচার ফ্ল্যাগ

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

• নতুন ফিচার — কোড মুছে না দিয়ে পরবর্তী রিলিজ পর্যন্ত অসম্পূর্ণ কার্যকারিতা লুকান
• অ্যানালিটিক্স — শুধুমাত্র বিটা পরীক্ষকদের জন্য অতিরিক্ত মেট্রিক সংগ্রহ সক্রিয় করুন
• থার্ড-পার্টি SDK — অ্যাপ্লিকেশনের ফ্রি সংস্করণ থেকে ভারী লাইব্রেরি বাদ দিন
• UI কম্পোনেন্ট — শুধুমাত্র স্টেজিং বিল্ডে পরীক্ষামূলক স্ক্রিন দেখান

সর্বোত্তম অভ্যাস

Active Compilation Conditions সংযমের সাথে ব্যবহার করা উচিত। অত্যধিক সংখ্যক ফ্ল্যাগ কোড বোঝা কঠিন করে তোলে: ডেভেলপার নিশ্চিত হতে পারে না যে কোনো মুহূর্তে কোন শাখাগুলি কম্পাইল হবে। প্রতিটি ফ্ল্যাগ README বা একটি ডেডিকেটেড CONFIG.md ফাইলে ডকুমেন্ট করার সুপারিশ করা হয়।

বিতরণকৃত টিম সহ বড় প্রকল্পগুলিতে, CI-তে স্বয়ংক্রিয় ফ্ল্যাগ বৈধতা বাস্তবায়ন করা উপযোগী। প্রতিটি পুল রিকোয়েস্টকে Active Compilation Conditions-এর সব সম্ভাব্য কম্বিনেশন সহ বিল্ড পাস করা উচিত। এটি নিশ্চিত করে যে নিষ্ক্রিয় ফ্ল্যাগের অধীনে কোড রিফ্যাক্টরিংয়ের কারণে ভাঙেনি, এবং রিলিজ পর্যন্ত কোনো শর্তসাপেক্ষ কম্পাইলেশন শাখা অপরীক্ষিত থাকে না। xcresulttool (iOS-এর জন্য) এবং Gradle Build Scan (Android-এর জন্য) এর মতো টুল এই প্রক্রিয়া স্বয়ংক্রিয় করতে সাহায্য করে।

• ন্যূনতম ফ্ল্যাগ — প্রতি প্রকল্পে 5-7টির বেশি সক্রিয় শর্ত নয়। প্রতিটি ফ্ল্যাগ জটিলতার একটি বিন্দু।
• নামকরণ প্রথা — সমস্ত ফ্ল্যাগ UPPER_CASE-এ, প্রকল্প উপসর্গ সহ: MYAPP_BETA, MYAPP_ANALYTICS।
• কোড রিভিউ — #if বা buildConfigField-এর প্রতিটি যোগ আলাদা রিভিউয়ের মধ্য দিয়ে যেতে হবে।
• পরীক্ষা — CI-কে দিনে কমপক্ষে একবার ফ্ল্যাগের সব সম্ভাব্য কম্বিনেশন বিল্ড করা উচিত।