CDG Zig booking flow ကို Compose နဲ့ ပြန်ရေးခဲ့တုန်းက

CDG Zig ရဲ့ booking flow ဟာ XML layout တွေ၊ fragment အစုအဝေးတွေနဲ့ ရေးထားတာပါ။ နေရာရွေးတာ၊ ယာဉ်ရွေးတာ၊ ဈေးနှုန်းအတည်ပြုတာ၊ driver ကို map ပေါ်မှာ ကြည့်တာ — screen တိုင်းက သပ်သပ်စီ သီးခြားဖြစ်နေပါတယ်။ UI code ထပ်နေတာတွေ အများကြီးရှိပြီး screen တွေက လိုအပ်တာထက် ပိုကြာပြီး render ဖြစ်နေပါတယ်။

ဘာကြောင့် ရွှေ့ခဲ့တာလဲ

အကြောင်းရင်း နှစ်ခုရှိပါတယ်။ ပထမတစ်ခုက booking flow ဟာ app တစ်ခုလုံးမှာ အသုံးအများဆုံး screen ဖြစ်တာပါ။ ဒုတိယတစ်ခုက ကျွန်တော်တို့ ထပ်ထည့်ချင်တဲ့ screen အသစ်တွေ (multi-stop ride၊ fare estimate) တွေက layout အဟောင်းနဲ့ အဆင်မပြေဘဲ XML ကို ညှိနေရတာ ဖြစ်ပါတယ်။

Compose ကို ရွေးချယ်ရတာ XML ညံ့လို့ မဟုတ်ပါဘူး — booking state ကို UI အဖြစ် ဖတ်လို့ရတဲ့အခါ state-driven UI က booking object နဲ့ ပိုကိုက်ညီတာပါ။

ဘာတွေ ပြင်ခဲ့သလဲ

• Booking flow အတွက် Fragment ငါးခုကို NavHost တစ်ခုနဲ့ Composable screen တွေအစုအဝေးတစ်ခုနဲ့ အစားထိုးခဲ့ပါတယ်။
• မျှဝေသုံးတဲ့ အပိုင်းတွေ (date picker၊ payment row၊ address card) ကို app ရဲ့ ကျန်အပိုင်းတွေ သုံးနေတဲ့ library ထဲ ထည့်ခဲ့ပါတယ်။
• Map ကို MapView ကနေ Compose interop layer အသစ်ပြောင်းခဲ့ပြီး screen တိုင်းမှာ ရေးထားရတဲ့ lifecycle glue ကို ဖြုတ်ပစ်နိုင်ခဲ့ပါတယ်။

ဂဏန်းတွေ

Metric	အဟောင်း	အသစ်
Screen render (p95)	180 ms	125 ms
Crash rate (per 1k)	0.41	0.33
UI code လိုင်းရေ	3,200	1,840

Crash rate ကျတာက ကျွန်တော် အတော်ဂရုစိုက်တဲ့ အပိုင်းပါ။ Compose ကြောင့် crash တွေ သူ့အလိုလို ပျောက်သွားတာ မဟုတ်ပါဘူး — team က မရှိသေးတဲ့ unit နဲ့ UI test တွေ ရေးခဲ့ပြီး Crashlytics issue အထက်ဆုံးတွေကို စီစဉ်ဖြေရှင်းခဲ့ပါတယ်။ ရေရှည်မှာ ထိန်းထားနိုင်တာက habit ကြောင့် ဖြစ်ပါတယ် — release တိုင်းအပြီး crash နဲ့ ANR report တွေ ပြန်စစ်တဲ့ အကျင့်က regression ကို ရက်အနည်းငယ်အတွင်း မြင်နိုင်စေပါတယ်။

ထပ်လုပ်ရင် ဘာပြင်မလဲ

Screen တွေကို မစခင် design system ကနေ စချင်ပါတယ်။ Migration ရဲ့ ပထမ သုံးပတ်က app ရဲ့ အခြားနေရာနှစ်ခုမှာ ရှိပြီးသား button နဲ့ row တွေကို ပြန်ရေးနေရတာ ဖြစ်ပါတယ်။ မျှဝေသုံးတဲ့ အပိုင်းတွေကို အရင် ခွဲထုတ်ခဲ့ရင် migration အချိန် ထက်ဝက်လောက် သက်သာမှာပါ။