หน่วย
1. ข้อมูลเบื้องต้นเกี่ยวกับ AI ในการพัฒนาอุปกรณ์พกพา: บทบาท ขอบเขต การรับรองความถูกต้อง และความปลอดภัย 2. การสร้างโค้ดบนมือถือด้วยปัญญาประดิษฐ์: การพัฒนา Kotlin, Swift และข้ามแพลตฟอร์ม 3. การออกแบบส่วนต่อประสานและการสร้างโค้ด UI ด้วยปัญญาประดิษฐ์ 4. AI บนอุปกรณ์: Core ML, TensorFlow Lite และ ML Kit 5. การรวม Cloud AI และ LLM API: แชท โฟลว์ และความปลอดภัย 6. การสร้างการทดสอบด้วยปัญญาประดิษฐ์: การทดสอบหน่วย อินเทอร์เฟซ และระบบอัตโนมัติ 7. การดีบักและการวิเคราะห์ข้อขัดข้องด้วยปัญญาประดิษฐ์ 8. ประสิทธิภาพและการเพิ่มประสิทธิภาพแบตเตอรี่: แอปพลิเคชันที่รวดเร็วและมีประสิทธิภาพด้วยปัญญาประดิษฐ์ 9. ความเป็นส่วนตัว การอนุญาต และการใช้งานอย่างปลอดภัย 10. การเปิดตัวร้านค้า: App Store, Google Play และความเข้ากันได้ของ AI 11. โครงการแบบครบวงจร การใช้ปัญญาประดิษฐ์และแผนงานอย่างมีความรับผิดชอบในวิชาชีพ
หน่วย 2 / 11

การสร้างโค้ดบนมือถือด้วยปัญญาประดิษฐ์: การพัฒนา Kotlin, Swift และข้ามแพลตฟอร์ม

กำไร:

  • การได้รับโค้ดที่ง่ายต่อการบำรุงรักษาและทดสอบได้โดยการใช้สถาปัตยกรรม เช่น MVVM และการร้องขอแบบเลเยอร์ต่อเลเยอร์เป็นชิ้นเล็กๆ ก่อนที่จะให้ปัญญาประดิษฐ์สร้างโค้ด
  • ความสามารถในการจดจำกับดักเฉพาะภาษา เช่น ความปลอดภัยที่เป็นโมฆะและโครูทีนใน Kotlin, ตัวเลือกเสริมและลูปหน่วยความจำใน Swift และตรวจสอบโค้ดที่สร้างขึ้นกับกับดักเหล่านั้น
  • ความสามารถในการตรวจสอบสิทธิ์และการกำหนดค่าแยกกันสำหรับแต่ละแพลตฟอร์มในโครงการข้ามแพลตฟอร์ม (Flutter, React Native)

หัวใจของการพัฒนาอุปกรณ์เคลื่อนที่คือโค้ด และนั่นคือจุดที่ประโยชน์ที่เป็นรูปธรรมที่สุดจาก AI ปรากฏขึ้น แต่ประโยคที่ว่า "ให้ AI เขียนโค้ดให้ฉัน" ไม่ใช่กลยุทธ์ในตัวมันเอง การสร้างโค้ดที่ดี โดยต้องมีการผสมผสานภาษาที่ถูกต้อง สถาปัตยกรรมที่ถูกต้อง ขอบเขตที่ถูกต้อง และการตรวจสอบที่ถูกต้อง ในหน่วยนี้ เราจะได้เรียนรู้วิธีใช้ AI อย่างมีประสิทธิภาพและปลอดภัยสำหรับ Swift, ภาษาของ iOS, Kotlin, ภาษาของ Android และเครื่องมือข้ามแพลตฟอร์มที่ทำงานบนสองแพลตฟอร์มด้วยฐานโค้ดเดียว เป้าหมายคือการวางตำแหน่ง AI ไม่ใช่ "หุ่นยนต์โค้ด" แต่เป็นตัวเร่งความเร็วตามสถาปัตยกรรมที่คุณกำหนด

สถาปัตยกรรมมาก่อน โค้ดเป็นอันดับสอง

ข้อผิดพลาดที่พบบ่อยที่สุดคือขอโค้ดจาก AI โดยตรงโดยไม่ต้องมีแผนทางสถาปัตยกรรม ก็เหมือนกับการก่อกำแพงโดยไม่วางรากฐาน สถาปัตยกรรมที่พบบ่อยที่สุดบนมือถือคือ MVVM (Model-View-ViewModel — รูปแบบการออกแบบที่แยกข้อมูล จอแสดงผล และตรรกะของจอแสดงผล) ซึ่งหมายความว่ามุมมองเป็นเพียงมุมมอง ตรรกะและสถานะอยู่ใน ViewModel และข้อมูลอยู่ในเลเยอร์โมเดล หากคุณไม่กำหนดการแยก AI นี้ตั้งแต่เริ่มต้น มันจะสร้างโครงสร้างที่ไม่สามารถทดสอบได้และบำรุงรักษายากซึ่งจะอัดตรรกะทั้งหมดลงในโค้ดหน้าจอ

ขั้นตอนการสร้างโค้ดที่ดีทีละขั้นตอน:

  1. ให้บริบท แพลตฟอร์ม ภาษา เวอร์ชัน สถาปัตยกรรม ไลบรารีที่ใช้
  2. ขอชั้น. อันดับแรกคือโมเดลข้อมูล จากนั้นจึงเป็นเครือข่าย/ชั้นข้อมูล จากนั้นจึง ViewModel จะอยู่บนหน้าจอ
  3. ขอชิ้นเล็กๆ. หนึ่งหน้าจอหรือหนึ่งฟังก์ชัน ไม่ใช่ไฟล์ขนาดยักษ์ 500 บรรทัด
  4. ตรวจสอบแต่ละชิ้น สร้าง ทดสอบ บูรณาการ จากนั้นไปยังแทร็กถัดไป
  5. ขอรีแฟคเตอร์ (ปรับปรุงโค้ด) "ทำให้สิ่งนี้อ่านง่ายขึ้นและทดสอบได้" ขั้นตอนหลังรหัสการทำงาน
คำแนะนำ: บอก AI ​​ว่า "แยกโค้ดตาม MVVM ส่วนไหนควรเป็น View ซึ่งควรเป็น ViewModel ซึ่งควรเป็น Model ให้แยกกัน" ประโยคเดียวนี้ช่วยปรับปรุงคุณภาพสถาปัตยกรรมของโค้ดที่สร้างขึ้นได้อย่างมาก

Kotlin และ Swift: ข้อควรพิจารณาเฉพาะภาษา

Kotlin (Android) และ Swift (iOS) เป็นภาษาที่ทันสมัยและปลอดภัย แต่ก็มีข้อผิดพลาดที่แตกต่างกัน ใน Kotlin ความปลอดภัยของโมฆะ (ตรวจสอบว่าตัวแปรสามารถเป็น "โมฆะ" ผ่านระบบประเภทได้หรือไม่) บางครั้ง AI ก็พิมพ์อย่างหลวมๆ ไม่จำเป็น !! โอเปอเรเตอร์ (เครื่องหมายที่บังคับให้เกิดความผิดพลาดหากเป็นโมฆะ) อาจทำให้แอปพลิเคชันเสียหาย ใน Swift การจัดการเสริมและวงจรการเก็บรักษาถือเป็นสิ่งสำคัญ AI อาจลืมเพิ่ม [ตัวตนที่อ่อนแอ] ในการปิด และสิ่งนี้จะทำให้หน่วยความจำรั่ว

ดังนั้นเมื่อคุณเลือกภาษา ให้เหลาข้อความตามนั้น: เช่น "Preserve null safety in Kotlin, don't use !!" หรือ "ป้องกันการวนซ้ำการอ้างอิงที่รัดกุมในการปิดใน Swift"

ข้อควรระวัง: โค้ดอะซิงโครนัสที่ผลิตโดย AI ต้องได้รับการดูแลเป็นพิเศษ การเลือกขอบเขตที่ไม่ถูกต้องใน Kotlin coroutines หรือการบล็อกเธรดหลักใน async/await ใน Swift จะทำให้แอปพลิเคชันหยุดทำงาน AI ทำผิดพลาดเหล่านี้บ่อยครั้ง อย่าเชื่อถือโดยไม่ได้ทดสอบ

การพัฒนาข้ามแพลตฟอร์ม: Flutter และ React Native

สำหรับผู้ที่ต้องการใช้ทั้ง iOS และ Android ด้วยรหัสฐานเดียว Flutter (ชุดเครื่องมือที่ใช้ภาษา Dart ของ Google) และ React Native (โซลูชันที่ใช้ JavaScript ของ Meta) มีความโดดเด่น AI มีประสิทธิภาพในสภาพแวดล้อมเหล่านี้เช่นกัน แต่บางครั้งก็ข้ามความแตกต่างของแพลตฟอร์ม (สิทธิ์ กฎของร้านค้า พฤติกรรมเฉพาะอุปกรณ์) ตัวอย่างเช่น ใน Flutter การอนุญาตกล้องถูกกำหนดไว้ในไฟล์ต่างๆ บน iOS และ Android AI สามารถเขียนได้เพียงอันเดียว ในโค้ดข้ามแพลตฟอร์ม จำเป็นต้องพูดว่า "ให้สิทธิ์และการกำหนดค่าที่จำเป็นสำหรับทั้งสองแพลตฟอร์มแยกกัน"

สรุปการเลือกตั้ง:

แนวทาง

เมื่อ

ความสนใจด้วย AI

เนทิฟ (Kotlin/Swift)

ประสิทธิภาพสูงสุด บูรณาการในเชิงลึกของอุปกรณ์

แต่ละแพลตฟอร์มมีรหัสแยกกัน ตรวจสอบสองครั้ง

กระพือปีก

ทีมเดียว UI ที่รวดเร็วและสม่ำเสมอ

ตรวจสอบสิทธิ์/การตั้งค่าเฉพาะแพลตฟอร์มด้วยตนเอง

ตอบสนองพื้นเมือง

มีทีมงานเว็บ/JS

ทดสอบส่วนบริดจ์ (เนทิฟบริดจ์) อย่างระมัดระวัง

มินิเคสสามอัน

กรณีที่ 1 — กับดักโครูทีน ทีม Android มีฟังก์ชันดึงรายการผลิตภัณฑ์จาก AI รหัสกำลังส่งคำขอเครือข่ายในเธรดหลัก ปัญหาไม่ปรากฏบนอุปกรณ์ทดสอบ แต่บนเครือข่ายที่อ่อนแอ แอปพลิเคชันค้างเป็นเวลา 4 วินาทีและให้คำเตือน ANR (แอปพลิเคชันไม่ตอบสนอง) ได้รับการแก้ไขแล้วเมื่อ AI ได้รับคำสั่งให้ "ทำงานเครือข่ายในโปรแกรมเลือกจ่ายงาน IO" บทเรียน: การเห็นพ้องต้องกันถูกควบคุมอยู่เสมอ

กรณีที่ 2 — หน่วยความจำรั่ว นักพัฒนา iOS พบว่าหลังจากเปิดและปิดหน้าจอที่สร้างโดย AI 20 ครั้ง หน่วยความจำของแอปก็เพิ่มขึ้นจาก 40 MB เป็น 180 MB เหตุผลก็คือไม่สามารถล้าง ViewController ออกจากหน่วยความจำได้เนื่องจาก [ตัวอ่อนแอ] หายไปในการปิด กราฟหน่วยความจำของ Xcode เผยให้เห็นกับดัก บทเรียน: จำเป็นต้องมีโปรไฟล์หน่วยความจำในการพัฒนาแบบเนทิฟ

กรณีที่ 3 — ความแตกต่างของแพลตฟอร์ม ทีม Flutter ได้รับรหัสการเข้าถึงแกลเลอรีจาก AI ซึ่งใช้งานได้บน Android แต่ขัดข้องบน iOS เหตุผลก็คือคำอธิบายสิทธิ์อนุญาตไลบรารีรูปภาพ (NSPhotoLibraryUsageDescription) ไม่ได้ถูกเพิ่มลงในไฟล์ Info.plist AI เขียนเฉพาะฝั่ง Android เท่านั้น ใช้เวลาแก้ไข 15 นาที แต่ร้านอาจถูกปฏิเสธหากตรวจไม่พบ

พรอมต์อ่อน / พรอมต์แข็งแกร่ง

ข้อความแจ้งที่อ่อนแอ: "เขียนโค้ด Kotlin ที่ดึงผลิตภัณฑ์จาก API"

พร้อมท์ที่มีประสิทธิภาพ: "สร้างโค้ดสำหรับ Android/Kotlin ที่ดึงรายการผลิตภัณฑ์จาก REST API - เลเยอร์เครือข่ายพร้อมชุดติดตั้งเพิ่ม, ฟังก์ชั่นระงับ - งานเครือข่ายใน Dispatchers.IO; การบล็อกเธรดหลัก - MVVM: พื้นที่เก็บข้อมูล -> ViewModel -> สถานะ UI ด้วย StateFlow- สถานะข้อผิดพลาด: ไม่มีเครือข่าย แยกสถานะคลาสที่ปิดผนึกสำหรับ 4xx, 5xx- ปกป้องความปลอดภัย null !! การใช้ !! ส่งออกเลเยอร์เป็นไฟล์แยกกัน 1 ประโยคในแต่ละคำอธิบาย"

การแจ้งเตือนที่รัดกุมช่วยป้องกันไม่ให้โค้ดที่สร้างขึ้นตกหลุมพรางของกรณีก่อนหน้า

เทมเพลตที่คัดลอกได้

เทมเพลตการผลิตแบบเลเยอร์: "พัฒนา [คุณสมบัติ] สำหรับ [แพลตฟอร์ม/ภาษา] ผลิตตามลำดับ:1) โมเดลข้อมูล (คลาสข้อมูล/โครงสร้าง)2) เลเยอร์เครือข่ายหรือแหล่งข้อมูล3) พื้นที่เก็บข้อมูล4) ViewModel (การจัดการสถานะ)5) หน้าจอ (UI)ส่งออกแต่ละเลเยอร์แยกกัน เพิ่มบันทึกการรวมระหว่างเลเยอร์เหล่านั้น"

เทมเพลตความปลอดภัยเฉพาะภาษา (Kotlin): "ตรวจสอบโค้ด Kotlin นี้: - การใช้งานที่ชัดเจนของ !! และประเภทแพลตฟอร์ม - ตรวจสอบขอบเขต Coroutine และการเลือกโปรแกรมเลือกจ่ายงาน - มีการเรียกที่บล็อกเธรดหลักหรือไม่ [รหัส]"

เทมเพลตความปลอดภัยเฉพาะภาษา (Swift): "ตรวจสอบรหัส Swift นี้: - ความเสี่ยงของการรักษาวงจรในการปิด (ตัวเองอ่อนแอ / ไม่มีเจ้าของ) - การใช้การบังคับแกะเสริม (!) - งานหนักที่ต้องย้ายออกจากเธรดหลัก [รหัส]"

เทมเพลตการควบคุมข้ามแพลตฟอร์ม: "แสดงรายการสิทธิ์ การกำหนดค่า และโค้ดเฉพาะแพลตฟอร์มทั้งหมดที่จำเป็นสำหรับฟีเจอร์ [Flutter/React Native] นี้บนทั้ง iOS และ Android จัดเตรียมรายการ Info.plist และ AndroidManifest.xml แยกต่างหาก"

ข้อผิดพลาดทั่วไป

  • การขอโค้ดโดยไม่ใช้สถาปัตยกรรม ผลลัพธ์ที่ได้คือ โครงสร้างที่ไม่อาจทดสอบได้ซึ่งอัดทุกอย่างลงบนหน้าจอ
  • เชื่อถือโดยไม่ต้องทดสอบโค้ดพร้อมกัน บล็อกเธรดหลักและขอบเขตที่ไม่ถูกต้องเป็นสาเหตุที่พบบ่อยที่สุดของการหยุดทำงาน
  • มองข้ามการจัดการหน่วยความจำ โดยเฉพาะการรั่วไหลในการปิด iOS จะไม่สามารถสังเกตได้หากไม่มีโปรไฟล์
  • ข้ามความแตกต่างของแพลตฟอร์ม ในเครื่องมือข้ามแพลตฟอร์ม การอนุญาตและการกำหนดค่าจะถูกเขียนแยกกันบนทั้งสองแพลตฟอร์ม
  • ไม่ตรวจสอบเวอร์ชันไลบรารี AI อาจแนะนำ Retrofit/Alamofire API ที่ล้าสมัย ตรวจสอบกับเอกสารราชการ
  • สร้างไฟล์ขนาดยักษ์เพียงไฟล์เดียว ไม่สามารถรักษาและตรวจสอบได้ ขอชั้น.

โดยสรุป

การสร้างโค้ดด้วย AI จะมีประสิทธิภาพเมื่อคุณระบุสถาปัตยกรรม ขั้นแรกกำหนดโครงสร้างเช่น MVVM จากนั้นขอทีละชั้นและเป็นชิ้นเล็ก ๆ รวบรวมและทดสอบแต่ละชิ้น ความปลอดภัยแบบ Null และ coroutine ใน Kotlin, ตัวเลือกเสริมและลูปหน่วยความจำใน Swift ต้องได้รับการดูแลเป็นพิเศษ ในเครื่องมือข้ามแพลตฟอร์ม การอนุญาตและการกำหนดค่าจะถูกเขียนแยกกันสำหรับแต่ละแพลตฟอร์ม ข้อความแจ้งที่รัดกุมจะบอกภาษา เวอร์ชัน สถาปัตยกรรม และกฎความปลอดภัยเฉพาะภาษาล่วงหน้า วิธีนี้จะช่วยป้องกันข้อผิดพลาดข้อขัดข้องและการรั่วไหลที่พบบ่อยที่สุดในการใช้งานจริง

งานสมัคร

สำหรับหน้าจอรายการ (เช่น “รายชื่อผู้ติดต่อ”) ขอรหัสจาก AI โดยใช้ “เทมเพลตการผลิตแบบเติมแต่ง” ในแพลตฟอร์มที่คุณเลือก (Kotlin หรือ Swift) เพิ่มโค้ดที่สร้างขึ้นลงในโปรเจ็กต์ คอมไพล์ และทำการตรวจสอบทั้งสองนี้: (1) กระบวนการเครือข่าย/แบบยาวทำงานบนเธรดหลักหรือไม่ (2) ความปลอดภัยที่เป็นโมฆะ/เป็นทางเลือกถูกต้องหรือไม่ ให้ AI แก้ไขปัญหาที่คุณพบด้วยเทมเพลตความปลอดภัยเฉพาะภาษา

รายการตรวจสอบ

  • [ ] ฉันระบุสถาปัตยกรรม (MVVM ฯลฯ) ก่อนที่จะขอรหัส
  • [ ] ฉันอยากได้มันทีละชั้น เป็นชิ้นเล็กๆ
  • [ ] ฉันทดสอบแล้วว่าโค้ดที่ใช้งานพร้อมกันไม่ได้บล็อกเธรดหลัก
  • [ ] ฉันตรวจสอบความปลอดภัยและการจัดการหน่วยความจำแบบ null/เป็นทางเลือกแล้ว
  • [ ] ฉันตรวจสอบสิทธิ์/การตั้งค่าของสองแพลตฟอร์มแยกกันในโครงการข้ามแพลตฟอร์ม
  • [ ] ฉันตรวจสอบเวอร์ชันไลบรารีและลายเซ็น API จากเอกสารอย่างเป็นทางการ