единица 2 / 11

Генериране на мобилен код с изкуствен интелект: Kotlin, Swift и кросплатформено развитие

Печалби:

  • Получаване на лесен за поддръжка и тестване код чрез налагане на архитектура като MVVM и изискване слой по слой на малки части, преди изкуственият интелект да генерира код.
  • Възможност за разпознаване на специфични за езика капани, като нулева безопасност и съпрограма в Kotlin, опционални и паметови цикли в Swift, и проверка на генерирания код спрямо тях.
  • Възможност за проверка на разрешенията и конфигурацията отделно за всяка платформа в междуплатформени (Flutter, React Native) проекти

Сърцето на мобилното развитие е кодът и там се появяват най-осезаемите ползи от AI. Но изречението „Оставете AI да напише код за мен“ не е стратегия сама по себе си. Добро генериране на код; Това изисква комбиниране на правилния език, правилната архитектура, правилните граници и правилното валидиране. В тази част ще се научим как да използваме AI ефективно и безопасно за Swift, езика на iOS, Kotlin, езика на Android, и инструменти за различни платформи, които работят на две платформи с една база код. Целта е да се позиционира AI не като „кодов автомат“, а като ускорител, чиято архитектура определяте вие.

Първо архитектурата, второ кодът

Най-често срещаната грешка е да поискате код директно от AI без архитектурен план. Това е като да изградите стена, без да поставите основа. Най-често срещаната архитектура на мобилни устройства е MVVM (Model-View-ViewModel — модел на проектиране, който разделя данните, дисплея и логиката на дисплея). Това означава, че изгледът е просто изглед, логиката и състоянието са живи в ViewModel, а данните са в слоя Model. Ако не наложите това разделяне на изкуствения интелект от самото начало, той създава нетестваща се и трудна за поддържане структура, която натъпква цялата логика в екранния код.

Здравословен процес на генериране на код стъпка по стъпка:

  1. Дайте контекста. Платформа, език, версия, архитектура, използвани библиотеки.
  2. Поискайте слоеве. Първо моделът на данните, след това слоят мрежа/данни, след това ViewModel, накрая екранът.
  3. Поискайте малки парчета. Един екран или една функция; Това не е огромен файл от 500 реда.
  4. Проверете всяко парче. Изградете, тествайте, интегрирайте; след това преминете към следващата песен.
  5. Поискайте рефакторинг (подобряване на кода). "направете това по-четливо и тестваемо" стъпка след работния код.
Подсказка: Кажете на AI ​​"разделете кода според MVVM: коя част трябва да бъде View, коя трябва да бъде ViewModel, която трябва да бъде Model, дайте ги отделно". Това единствено изречение драстично подобрява архитектурното качество на генерирания код.

Kotlin и Swift: специфични за езика съображения

Kotlin (Android) и Swift (iOS) са модерни, сигурни езици, но имат различни клопки. В Kotlin нулевата безопасност (проверка дали дадена променлива може да бъде "нулева" чрез системата от типове) понякога се въвежда свободно от AI; ненужно!! оператор (знакът, който принуждава срив, ако е нула) може да доведе до срив на приложението. В Swift незадължителните цикли на управление и задържане са критични; AI може да забрави да добави [weak self] в затваряния и това ще създаде изтичане на памет.

Така че, когато избирате език, усъвършенствайте съответно подканата: като „Запазване на нулева безопасност в Kotlin, не използвайте!“ или „Предотвратяване на силен референтен цикъл при затваряния в Swift“.

Внимание: Произведеният от AI асинхронен код изисква специално внимание. Избирането на грешен обхват в съпрограммите на Kotlin или блокиране на основната нишка в async/await в Swift ще замрази приложението. AI прави тези грешки често; Не му се доверявайте без да сте го тествали.

Разработка на различни платформи: Flutter и React Native

За тези, които искат да преминат както към iOS, така и към Android с единна кодова база, Flutter (базиран на език инструментариум Dart на Google) и React Native (базирано на JavaScript решение на Meta) се открояват. AI е мощен и в тези среди, но понякога заобикаля разликите в платформата (разрешения, правила за магазин, специфично за устройството поведение). Например във Flutter разрешението за камерата е дефинирано в различни файлове на iOS и Android; AI може да напише само едно. В междуплатформения код е важно да се каже „предоставете необходимите разрешения и конфигурация за двете платформи поотделно“.

Резюме на изборите:

подход

когато

внимание с AI

Роден (Kotlin/Swift)

Най-висока производителност, дълбока интеграция на устройството

Всяка платформа има отделен код; проверете два пъти

трептене

Един екип, бърз, последователен потребителски интерфейс

Проверете ръчно разрешението/настройките, специфични за платформата

React Native

Web/JS екип на разположение

Тествайте внимателно секциите на моста (родния мост).

три мини калъфа

Случай 1 — Корутинен капан. Екип на Android получи функция, която извлича списъка с продукти от AI. Кодът правеше мрежовата заявка в основната нишка; Проблемът не се появи на тестовото устройство, но на слабата мрежа, приложението замръзна за 4 секунди и даде предупреждение ANR (Application Not Responding). Беше коригирано, когато на AI беше казано да „върши мрежовата работа в IO диспечера“. Урок: паралелността винаги се контролира.

Случай 2 — Изтичане на памет. Разработчик на iOS установи, че след отваряне и затваряне на екран, генериран от AI 20 пъти, паметта на приложението се увеличава от 40 MB на 180 MB. Причината беше, че ViewController не можеше да бъде изчистен от паметта поради липсващ [weak self] в затварянето. Графиката на паметта на Xcode разкри капана. Урок: профилът на паметта е задължителен при естественото развитие.

Случай 3 — Разлика в платформата. Екип на Flutter получи код за достъп до галерията от AI, той работеше на Android, но се срина на iOS. Причината беше, че описанието на разрешението за библиотека със снимки (NSPhotoLibraryUsageDescription) не беше добавено към файла Info.plist; AI написа само страната на Android. Това е 15-минутна корекция, но щеше да бъде отказ от магазина, ако не беше хванат.

Слаба подкана / Силна подкана

Слаба подкана: „Напишете код на Kotlin, който изтегля продукти от API.“

Мощна подкана: „Генериране на код за Android/Kotlin, който изтегля списъка с продукти от REST API.- Мрежов слой с модернизация, функция за спиране- Мрежова работа в Dispatchers.IO; блокиране на главната нишка- MVVM: Хранилище -> ViewModel -> Състояние на потребителския интерфейс с StateFlow- Състояния на грешка: няма мрежа, отделно състояние на запечатан клас за 4xx, 5xx- Защита на нулева защита, !! Използване на !! Експортиране слоеве като отделни файлове, обяснение на всяко изречение."

Силното подсказване предотвратява генерирания код от попадане в капаните на предишните случаи.

Копируеми шаблони

Многослоен производствен шаблон: „Разработване на [функция] за [платформа/език]. Произвеждане в ред: 1) Модел на данни (клас на данни/структура) 2) Мрежов слой или източник на данни 3) Хранилище 4) Модел на изглед (управление на състояние) 5) Екран (UI) Експортирайте всеки слой поотделно, добавете бележка за интеграция между тях.“

Специфичен за езика шаблон за защита (Kotlin): „Преглед на този код на Kotlin: - Ясно използване на !! и тип платформа - Проверете обхвата на Coroutine и избора на диспечер - Има ли извиквания, блокиращи основната нишка? [код]"

Специфичен за езика шаблон за защита (Swift): „Прегледайте този Swift код: - Риск от цикъл на запазване при затваряния (слаб/непритежаван себе си) - Използване на незадължително принудително разгъване (!) - Тежка работа, която трябва да бъде преместена извън основната нишка [код]“

Шаблон за контрол на различни платформи: „Избройте всички разрешения, конфигурации и специфичен за платформата код, необходими за тази функция [Flutter/React Native] както на iOS, така и на Android. Предоставете отделни записи Info.plist и AndroidManifest.xml.“

Често срещани грешки

  • Искане на код без налагане на архитектура. Резултатът: неподлежаща на тестване структура, която натъпква всичко на екрана.
  • Доверяване без тестване на паралелен код. Блокирането на основните нишки и неправилният обхват са най-честите причини за сривове.
  • Пренебрегване на управлението на паметта. Особено течове в iOS затваряния; Не се забелязва без заснемане на профил.
  • Заобикаляне на различията в платформата. В инструментите за различни платформи разрешенията и конфигурацията се записват отделно на двете платформи.
  • Не се проверява версията на библиотеката. AI може да предложи остарял Retrofit/Alamofire API; Проверете с официален документ.
  • Създаване на единичен гигантски файл. Невъзможност за поддръжка и проверка; поискайте слоеве.

В обобщение

Генерирането на код с AI е мощно, когато посочите архитектурата. Първо наложете структура като MVVM, след това поискайте слой по слой и на малки части, компилирайте и тествайте всяка част. Нулевата безопасност и съпрограмата в Kotlin, опционалните и паметовите цикли в Swift изискват специално внимание. В инструментите за различни платформи разрешенията и конфигурацията се записват отделно за всяка платформа. Силната подкана казва предварително езика, версията, архитектурата и специфичните за езика правила за сигурност; Това предотвратява най-често срещаните грешки при сривове и течове в производството.

Задача за приложение

За екран със списък (напр. „списък с контакти“), поискайте код от AI, като използвате „шаблон за производство на добавки“ в избраната от вас платформа (Kotlin или Swift). Добавете генерирания код към проект, компилирайте го и направете тези две проверки: (1) мрежовият/дълъг процес изпълнява ли се на основната нишка, (2) правилна ли е нулевата/незадължителна безопасност? Накарайте изкуствения интелект да поправи проблема, който откриете, с шаблон за защита, специфичен за езика.

контролен списък

  • [ ] Посочих архитектурата (MVVM и т.н.) преди да поискам код
  • [ ] Исках го слой по слой, на малки парчета
  • [ ] Тествах, че паралелният код не блокира основната нишка
  • [ ] Проверих нула/незадължително управление на безопасността и паметта
  • [ ] Проверих разрешенията/настройките на две платформи поотделно в междуплатформен проект
  • [ ] Проверих версиите на библиотеката и подписите на API от официалната документация