ViewController Lifecycle sa iOS: mga pangunahing konsepto, yugto at pamamaraan

Ano ang ViewController Lifecycle

ViewController Lifecycle — ay isang set ng mga metodo na natatanggap ng UIViewController mula sa UIKit sa buong pag-iral nito. Bawat screen sa isang iOS application ay sunod-sunod na dumadaan sa mga yugto ng paglikha, pag-load ng View, paglitaw sa screen, pagkawala, at pagpapalaya ng memorya. Awtomatikong tinatawag ng UIKit ang mga kaukulang metodo sa bawat yugto, at ang developer ay nag-o-override sa mga ito, nagdaragdag ng sarili nitong logic.

Ang arkitektura ng UIViewController ay pundasyon ng UIKit at nananatiling may kaugnayan kahit sa panahon ng SwiftUI — maraming proyekto ang gumagamit pa rin ng klasikong approach o hybrid na arkitektura. Ang pag-unawa sa Lifecycle ay nagbibigay-daan upang mahulaan kung kailan available ang mga subviews, kung kailan ligtas na baguhin ang layout, at kung anong mga operasyon ang gagawin sa paglitaw o pagtatago ng screen.

Bawat metodo ng lifecycle ay may tiyak na layunin: ang ilan ay tinatawag nang isang beses sa buong pag-iral ng controller, ang iba — sa bawat paglitaw o pagkawala. Ang paghahalo ng logic sa pagitan ng mga metodo ay humahantong sa mga bug na mahirap makita: pagtagas ng memorya, hindi tamang pag-update ng data, at mga hindi kinakailangang network request.

Buong siklo ng mga metodo ng UIViewController

Anim na metodo ang bumubuo sa buong lifecycle ng UIViewController. Ang pagkakasunod-sunod ng kanilang tawag ay nakapirmi at hindi nakadepende sa paraan ng navigation — push, present o unwind segue ay sumusunod sa parehong iskedyul.

loadView — paglikha ng root View

loadView — unang metodo ng siklo, tinatawag kapag ang View ng controller ay wala pa. Kung gumagamit ka ng Storyboard, awtomatikong nilo-load ng UIKit ang View mula sa xib file. Sa programmatic na paglikha ng interface, ina-override mo ang metodong ito, manu-manong itinatakda ang root View. Sa karamihan ng mga proyekto, ang loadView ay hindi ginagalaw — ang trabaho ay ginagawa sa viewDidLoad.

Ang pag-override ng loadView ay kinakailangan lamang sa mga tiyak na kaso: kapag ang buong interface ay nilikha gamit ang code nang walang Storyboard o kapag ang root View ay dapat mula sa isang hindi standard na klase. Inirerekomenda ng Apple na huwag tawagan ang super.loadView kapag nag-o-override — ganap mong pinapanagutan ang paglikha ng View.

override func loadView() {
    view = UIView()
    view.backgroundColor = .white
}

viewDidLoad — isang beses na inisyalisasyon

viewDidLoad — ang pinakamadalas gamitin na metodo ng siklo. Ito ay tinatawag nang isang beses pagkatapos ma-load ang View sa memorya, ngunit bago pa ito maipakita sa screen. Dito nako-configure ang mga subviews, pinupuno ang mga table ng data, nagrerehistro ng mga cell, at nag-subscribe sa mga notification na aktibo sa buong buhay ng controller.

Mahalagang tampok: ang viewDidLoad ay hindi muling tinatawag kapag muling nagpakita ang screen. Kung kailangan mong i-update ang data sa bawat paglitaw — gamitin ang viewWillAppear. Sa viewDidLoad, ilagay lamang ang isang beses na operasyon kung saan nakadepende ang pangunahing configuration.

viewWillAppear — paghahanda bago ipakita

viewWillAppear ay tinatawag sa bawat pagkakataon bago maging nakikita ang View sa user. Ang metodong ito ay tumatanggap ng parameter na animated, na nagpapahiwatig kung ang paglitaw ay may kasamang animation. Dito ina-update ang data, ni-reload ang mga table, nako-configure ang NavigationBar, at itinatago o ipinapakita ang mga elemento depende sa estado ng application.

Gamitin ang viewWillAppear para sa pag-sync ng estado sa pagitan ng mga screen: kung maaaring binago ng user ang data sa nakaraang screen, ang metodong ito ang tamang lugar para i-update ang interface. Bawat tawag ng viewWillAppear ay nauuna sa paglitaw ng screen, kahit sa pagbabalik mula sa isang child controller.

viewDidAppear — screen ganap na nakikita

viewDidAppear ay nag-aabiso na ang View ay ganap nang lumitaw sa screen at lahat ng transition animation ay natapos na. Sa sandaling ito, ang screen ay handa na para sa interaksyon — nakikita ng user ang kumpletong interface at maaaring makipag-ugnayan dito. Ang metodong ito ay angkop para sa pagsisimula ng mga animation na dapat magsimula pagkatapos ng paglitaw, pagsisimula ng mga timer, at pagsubaybay ng analytics impressions.

Hindi tulad ng viewWillAppear, ginagarantiyahan ng viewDidAppear na ang screen ay hindi lamang nakikita kundi ganap na nai-render. Kung magsisimula ka ng animation sa viewWillAppear, ang ilang frames ay maaaring laktawan dahil hindi pa natatapos ng UIKit ang transition. Para sa maayos na animation, gamitin ang viewDidAppear.

viewWillDisappear — paghahanda para itago

viewWillDisappear ay tinatawag bago mawala ang View sa screen — sa paglipat sa ibang controller, pagsasara ng modal window, o pag-minimize ng application. Ito ang tamang lugar para mag-save ng estado, mag-unsubscribe sa mga notification, mag-stop ng mga aktibong proseso, at mag-release ng mga resource na hindi kailangan kapag hindi nakikita ang screen.

Mahalagang tandaan: ang viewWillDisappear ay hindi ginagarantiyahan na ang View ay tuluyang mawawala — maaaring kanselahin ang gesture. Kaya naman, i-save ang kritikal na data din sa viewDidDisappear, na tinatawag lamang pagkatapos ng aktwal na pagkawala.

viewDidDisappear — screen nakatago

viewDidDisappear ay nagtatapos sa siklo ng paglitaw at pagkawala. Ito ay tinatawag pagkatapos na ang View ay naitago na mula sa screen. Sa metodong ito, ang mga animation ay tuluyang itinitigil, tinatanggal ang mga pansamantalang bagay, at kinukumpirma ang pag-save ng data na sinimulan sa viewWillDisappear.

Ang metodong ito ay nauuna rin sa deinit ng controller — kung ang iyong UIViewController ay dini-destroy, ang viewDidDisappear ang magiging huling metodo ng Lifecycle bago ang tawag ng deinit. Gamitin ito para sa panghuling paglilinis na dapat mangyari bago ang pagkasira ng bagay.

Kailan tinatawag ang bawat metodo

Ang pagkakasunod-sunod ng tawag ay depende sa kung paano eksaktong lumilitaw ang screen: sa unang pagkakataon, sa pagbabalik, o sa modal na pagpapakita. Tingnan natin ang tatlong pangunahing senaryo mula sa perspektibo ng UIKit.

Pagkakasunod-sunod sa unang pagbukas

Sa unang paglitaw ng screen, dumadaan ang UIKit sa buong siklo ng paglikha: tinatawag ang loadView, pagkatapos ang viewDidLoad, pagkatapos nito ay magsisimula ang animation ng paglitaw. Sa panahon ng animation, tinatawag ang viewWillAppear, at pagkatapos matapos — ang viewDidAppear. Ito ang tanging senaryo kung saan lahat ng metodo mula loadView hanggang viewDidAppear ay tinatawag nang sunud-sunod.

override func viewDidLoad() {
    super.viewDidLoad()
    print("viewDidLoad — View na-load sa memorya")
}

override func viewWillAppear(_ animated: Bool) {
    super.viewWillAppear(animated)
    print("viewWillAppear — malapit nang lumitaw")
}

override func viewDidAppear(_ animated: Bool) {
    super.viewDidAppear(animated)
    print("viewDidAppear — screen ganap na nakikita")
}

Pagkakasunod-sunod sa pagbabalik

Kapag bumalik ang user sa nakaraang screen, hindi muling tinatawag ng UIKit ang viewDidLoad — ang View ay naka-load na sa memorya. Sa halip, sa bumabalik na screen, tanging viewWillAppear at viewDidAppear ang nagti-trigger, at sa kasalukuyang screen — viewWillDisappear at viewDidDisappear. loadView at viewDidLoad ay nilalaktawan dahil ang screen ay nasa navigation stack na.

Mga kakaiba sa present at dismiss

Modal na pagpapakita ay sumusunod sa parehong mga patakaran: sa bagong controller, ang buong siklo ay tinatawag sa unang paglitaw, at sa kasalukuyang — viewWillDisappear at viewDidDisappear. Sa dismiss, ang pagkakasunod-sunod ay baliktad: sa bumabalik na controller, muling nagti-trigger ang viewWillAppear at viewDidAppear, at sa nakatagong controller — ang mga pangwakas na metodo. Ang pag-uugaling ito ay uniform para sa lahat ng uri ng transition sa UIKit.

Mga praktikal na senaryo ng paggamit

Tingnan natin ang apat na pangunahing senaryo kung saan ang pag-unawa sa Lifecycle ay direktang nakakaapekto sa kalidad ng code at karanasan ng user. Para sa bawat senaryo, nagbibigay kami ng halimbawa na may mga rekomendasyon.

Inisyalisasyon ng data sa viewDidLoad

viewDidLoad — lugar para sa paunang configuration na hindi nakadepende sa visibility ng screen. Dito nako-configure ang collectionView, nagrerehistro ng mga nib file para sa mga cell, gumagawa ng data source at layout. Kung naglo-load ka ng data mula sa network, sa viewDidLoad ay mas mabuting simulan lamang ang request, at i-update ang interface sa viewWillAppear kapag handa nang ipakita ang screen.

override func viewDidLoad() {
    super.viewDidLoad()
    tableView.register(
        MyCell.self,
        forCellReuseIdentifier: MyCell.identifier
    )
    viewModel.loadInitialData()
}

Pag-update ng nilalaman sa viewWillAppear

Gamitin ang viewWillAppear para mag-sync ng data sa bawat paglitaw ng screen. Halimbawa, kung maaaring binago ng user ang mga setting sa nakaraang screen, dito ina-update ang mga ipinapakitang halaga, ni-reload ang table, at itinatama ang estado ng NavigationBar. Tinitiyak nito na ang screen ay palaging nagpapakita ng napapanahong data sa anumang senaryo ng navigation.

override func viewWillAppear(_ animated: Bool) {
    super.viewWillAppear(animated)
    tableView.reloadData()
    navigationController?.setNavigationBarHidden(false, animated: animated)
}

Analytics at animation sa viewDidAppear

viewDidAppear ay perpekto para sa pagsisimula ng mga animation na dapat magsimula pagkatapos makita ng user ang screen. Dito rin ipinapadala ang mga analytics event: pagpapakita ng screen, pagsisimula ng onboarding, o pagsisimula ng pag-play ng video. Ang pagsisimula ng animation bago matapos ang transition ay humahantong sa maalog na interface — hindi nakakapaghanda ang UIKit ng sapat na frames.

Pag-save ng estado sa viewWillDisappear

Sa viewWillDisappear, sine-save ang mga draft, itinitigil ang mga timer, at nag-u-unsubscribe mula sa NotificationCenter. Ito ang huling sandali kung kailan ang screen ay nakikita pa at available para sa mga operasyon na nangangailangan ng konteksto ng user. Para sa kritikal na data, karagdagang ginagamit ang viewDidDisappear bilang seguro laban sa mga nakanselang gesture.

Mga karaniwang pagkakamali sa paggamit ng Lifecycle

Ang maling paggamit ng mga metodo ng lifecycle ay isa sa mga pinakakaraniwang pinagmumulan ng bug sa iOS applications. Tingnan natin ang mga pangunahing pagkakamali na ginagawa ng mga developer sa iba’t ibang yugto ng pagtatrabaho sa UIViewController.

Unang pagkakamali — paggawa ng mga subviews sa init o loadView kapag gumagamit ng Storyboard. Kung gumagamit ka ng Interface Builder, huwag i-override ang loadView nang hindi kinakailangan. Ang paggawa ng View sa loadView na may umiiral na storyboard ay humahantong sa pagbabalewala sa xib file at isang blangkong screen.

Ikalawang pagkakamali — pag-subscribe sa mga keyboard notification sa viewDidLoad nang hindi nag-a-unsubscribe. Kung nag-subscribe ka sa UIResponder.keyboardWillShowNotification ngunit hindi nag-unsubscribe kapag naitago ang screen, ang block ay tatawagin kahit pagkatapos ng deinit ng controller — ito ay isang pagtagas ng memorya na may potensyal na pag-crash ng application.

Ikatlong pagkakamali — mga timer at network request na sinimulan bago lumitaw ang screen. Pag-load ng mga imahe o pagsasagawa ng mga animation kapag ang View ay hindi pa nakikita — pag-aaksaya ng resources. Ilipat ang visual updates sa viewWillAppear o viewDidAppear.

Ikaapat na pagkakamali — pag-save ng data lamang sa viewWillDisappear. Sa interactive pop gesture, ang user ay maaaring magsimula ng swipe at kanselahin ito — ang metodo ay tinawag, ngunit ang screen ay hindi nawala. I-duplicate ang kritikal na pag-save sa viewDidDisappear o sa handler ng applicationDidEnterBackground.