Üksus 2 / 11

Mobiilikoodide genereerimine tehisintellektiga: Kotlin, Swift ja platvormidevaheline arendus

Kasu:

  • Kergesti hooldatava ja testitava koodi hankimine, rakendades sellist arhitektuuri nagu MVVM ja taotledes kiht-kihilt väikeste tükkidena, enne kui tehisintellekti koodi genereerib.
  • Võimalus tuvastada keelespetsiifilisi lõkse, nagu nullohutus ja korutiini Kotlinis, valikulised ja mälusilmused Swiftis, ning kontrollida loodud koodi nende suhtes.
  • Võimalus kontrollida platvormideüleste (Flutter, React Native) projektides iga platvormi õigusi ja konfiguratsiooni eraldi

Mobiiliarenduse tuumaks on kood ja see on koht, kus tehisintellekti kõige käegakatsutavamad eelised ilmnevad. Kuid lause "Las tehisintellekt kirjutab mulle koodi" ei ole omaette strateegia. Hea koodi genereerimine; See nõuab õige keele, õige arhitektuuri, õigete piiride ja õige valideerimise ühendamist. Selles õppetükis õpime kasutama tehisintellekti tõhusalt ja ohutult iOS-i keele Swifti, Androidi keele Kotlini ja platvormideüleste tööriistade jaoks, mis töötavad kahel platvormil ühe koodibaasiga. Eesmärk on positsioneerida AI mitte "koodiautomaatina", vaid kiirendina, mille arhitektuuri määrate.

Esiteks arhitektuur, teiseks kood

Kõige tavalisem viga on AI-lt koodi küsimine otse ilma arhitektuurse plaanita. See on nagu seina ehitamine ilma vundamenti panemata. Mobiilseadmetes on kõige levinum arhitektuur MVVM (Model-View-ViewModel – kujundusmuster, mis eraldab andmed, kuvari ja ekraani loogika). See tähendab, et vaade on lihtsalt vaade, loogika ja olek elavad ViewModelis ning andmed on mudelikihis. Kui te seda eraldamist tehisintellektile algusest peale ei kehtesta, loob see testimatu ja raskesti hooldatava struktuuri, mis surub kogu loogika ekraanikoodi.

Terve koodi genereerimise voog samm-sammult:

  1. Andke kontekst. Platvorm, keel, versioon, arhitektuur, kasutatud raamatukogud.
  2. Küsi kihte. Kõigepealt andmemudel, seejärel võrk/andmekiht, seejärel ViewModel, viimasena ekraan.
  3. Küsi väikseid tükke. Üks ekraan või üks funktsioon; See ei ole hiiglaslik 500-realine fail.
  4. Kontrollige iga tükki. Ehitage, katsetage, integreerige; seejärel liikuge järgmisele rajale.
  5. Taotlege refaktorit (täiustage koodi). "tee see loetavamaks ja testitavamaks" samm pärast töötavat koodi.
Vihje: Öelge AI-le "lõigake kood vastavalt MVVM-ile: milline osa peaks olema View, milline peaks olema ViewModel, milline peaks olema mudel, andke need eraldi". See üksainus lause parandab märkimisväärselt loodud koodi arhitektuurilist kvaliteeti.

Kotlin ja Swift: keelespetsiifilised kaalutlused

Kotlin (Android) ja Swift (iOS) on kaasaegsed ja turvalised keeled, kuid neil on erinevad lõksud. Kotlinis on null-turvalisus (kontrollimine, kas muutuja saab tüübisüsteemi kaudu olla null) mõnikord AI poolt lõdvalt tipitud; mittevajalik!! operaator (märk, mis sunnib krahhi, kui see on null) võib rakenduse krahhi. Swiftis on valikulised haldus- ja säilitamistsüklid kriitilised; AI võib unustada sulgemistesse lisada [nõrk ise] ja see põhjustab mälulekke.

Nii et kui valite keelt, lihvige viipa vastavalt: "Säilitage Kotlinis null turvalisus, ärge kasutage !!" või "Vältida tugevat viitesilmust Swifti sulgurites".

Ettevaatust: AI-toodetud asünkroonne kood nõuab erilist tähelepanu. Kui valite Kotlini korutiinides vale ulatuse või blokeerite Swiftis asünkroonimis/ootamise põhilõime, külmutatakse rakendus. AI teeb neid vigu sageli; Ärge usaldage seda ilma seda testimata.

Platvormideülene arendus: Flutter ja React Native

Neile, kes soovivad kasutada nii iOS-i kui ka Androidi ühe koodibaasiga, paistavad silma Flutter (Google'i Dart keelepõhine tööriistakomplekt) ja React Native (Meta JavaScript-põhine lahendus). Tehisintellekt on ka nendes keskkondades võimas, kuid mõnikord läheb mööda platvormi erinevustest (load, poereeglid, seadmespetsiifiline käitumine). Näiteks rakenduses Flutter on kaamera õigused iOS-i ja Androidi erinevates failides määratletud; AI saab kirjutada ainult ühe. Platvormideüleses koodis on oluline öelda "anna vajalikud load ja konfiguratsioon mõlemale platvormile eraldi".

Valimiste kokkuvõte:

Lähenemine

millal

tähelepanu AI-ga

Emakeel (Kotlin/Swift)

Suurim jõudlus, seadmepõhine integratsioon

Igal platvormil on eraldi kood; kontrollige kaks korda

Laperdamine

Üks meeskond, kiire ja ühtlane kasutajaliides

Kontrollige käsitsi platvormipõhiseid lubasid/sätteid

Reageerige emakeelena

Veebi/JS-i meeskond on saadaval

Katsetage silla (natiivse silla) sektsioone hoolikalt

kolm minikarpi

Juhtum 1 – korutiinilõks. Androidi meeskond sai funktsiooni, mis tõmbab AI-st tooteloendi. Kood tegi põhilõimes võrgupäringu; Testseadmes probleem ei ilmnenud, kuid nõrgas võrgus rakendus hangus 4 sekundiks ja andis ANR (Application Not Responding) hoiatuse. See parandati, kui AI-l kästi "teha võrgutööd IO dispetšeris". Õppetund: samaaegsust kontrollitakse alati.

Juhtum 2 – mäluleke. iOS-i arendaja leidis, et pärast AI-ga loodud ekraani 20-kordset avamist ja sulgemist suurenes rakenduse mälu 40 MB-lt 180 MB-le. Põhjus oli selles, et ViewControllerit ei saanud mälust kustutada sulguris puuduva [nõrga mina] tõttu. Xcode'i mälugraafik paljastas lõksu. Õppetund: mäluprofiil on kohalikus arenduses kohustuslik.

3. juhtum – platvormide erinevus. Flutteri meeskond sai AI-lt galerii juurdepääsukoodi, see töötas Androidis, kuid jooksis iOS-is kokku. Põhjus oli selles, et faili Info.plist ei lisatud fototeegi loa kirjeldust (NSPhotoLibraryUsageDescription); AI kirjutas ainult Androidi poole. See on 15-minutiline parandus, kuid see oleks olnud poe tagasilükkamine, kui seda poleks tabatud.

Nõrk viip / Tugev viip

Nõrk viip: "Kirjutage Kotlini kood, mis tõmbab tooted API-st."

Võimas viip: "Genereerige Androidi/Kotlini jaoks kood, mis tõmbab tooteloendi REST API-st.- Võrgukiht koos moderniseerimisega, peata funktsioon - Võrgutöö Dispatchers.IO-s; peamise lõime blokeerimine - MVVM: hoidla -> ViewModel -> UI olek koos StateFlow-ga- Veaolekud: võrku pole, eraldi suletud klassi olek 4xx-ks, kaitsekiht 4xx-ks!! failid, iga üks lause selgitab."

Tugev viipamine hoiab ära genereeritud koodi sattumise eelmiste juhtumite lõksudesse.

Kopeeritavad mallid

Kihiline tootmismall: "Arendage [funktsioon] [platvormi/keele] jaoks. Tootke järjekorras:1) Andmemudel (andmeklass/struktuur)2) Võrgu- või andmeallika kiht3) Hoidla4) Vaatemudel (olekuhaldus)5) Ekraan (UI) Eksportige iga kiht eraldi, lisage nende vahele integreerimismärkus."

Keelespetsiifiline turbemall (Kotlin):"Vaadake see Kotlini kood üle: - !! ja platvormi tüübi selge kasutamine - Kontrollige korutiini ulatust ja dispetšeri valikut - Kas kõned blokeerivad põhilõimi?[kood]"

Keelespetsiifiline turbemall (Swift): "Vaadake see Swifti kood üle: - Sulgemiste puhul säilitustsükli oht (nõrk/tundmatu ise) - Valikulise sundlahtipakkimise kasutamine (!) - Raske töö, mis tuleb põhilõimest välja tõsta [kood]"

Platvormideülene juhtimismall: "Loetlege kõik selle funktsiooni [Flutter/React Native] jaoks vajalikud load, konfiguratsioonid ja platvormipõhine kood nii iOS-is kui ka Androidis. Esitage eraldi kirjed Info.plist ja AndroidManifest.xml."

Levinud vead

  • Koodi küsimine ilma arhitektuuri kehtestamata. Tulemus: testimatu struktuur, mis surub kõik ekraanile.
  • Usaldus ilma samaaegset koodi testimata. Peamised keermeplokid ja vale ulatus on krahhi kõige levinumad põhjused.
  • Vaade mäluhaldusele. Eriti lekked iOS-i sulgudes; Ilma profiili võtmiseta pole seda märgata.
  • Platvormi erinevustest möödahiilimine. Platvormiülestes tööriistades kirjutatakse load ja konfiguratsioon kahel platvormil eraldi.
  • Teegi versiooni ei kinnitata. AI võib soovitada vananenud Retrofit/Alamofire API-t; Kontrollige ametliku dokumendiga.
  • Ühe hiiglasliku faili loomine. Võimatu hooldada ja kontrollida; küsi kihte.

Kokkuvõttes

Koodi genereerimine AI-ga on arhitektuuri määramisel võimas. Esmalt kehtestage struktuur nagu MVVM, seejärel taotlege kihtide kaupa ja väikeste tükkidena, kompileerige ja testige iga tükki. Erilist tähelepanu nõuavad Kotlini nullohutus ja korutiini, Swifti valikulised ja mälusilmused. Platvormiülestes tööriistades kirjutatakse õigused ja konfiguratsioon iga platvormi jaoks eraldi. Tugev viip ütleb keele, versiooni, arhitektuuri ja keelepõhised turbereeglid ette; See hoiab ära tootmises levinumad krahhi- ja lekkevead.

Rakenduse ülesanne

Loendikuva (nt „kontaktide loend“) jaoks taotlege AI-lt koodi, kasutades teie valitud platvormil (Kotlin või Swift) olevat lisandite tootmismalli. Lisage loodud kood projekti, kompileerige see ja tehke järgmised kaks kontrolli: (1) kas võrk/pikk protsess töötab põhilõimel, (2) kas null/valikuline turvalisus on õige? Laske tehisintellektil leitud probleem keelepõhise turbemalli abil lahendada.

kontrollnimekiri

  • [ ] Enne koodi küsimist täpsustasin arhitektuuri (MVVM jne).
  • [ ] Tahtsin seda kiht kihi haaval, väikeste tükkidena
  • [ ] Testisin, et samaaegne kood ei blokeeri põhilõimi
  • [ ] Kontrollisin null/valikulist turva- ja mäluhaldust
  • [ ] Kontrollisin platvormideüleses projektis kahe platvormi õigusi/seadeid eraldi
  • [ ] Kontrollisin teegi versioone ja API allkirju ametlikust dokumentatsioonist