ผู้คนใช้เวลามากกว่า 4 ชั่วโมงต่อวันในการใช้แอพมือถือ ตลาดบางแห่งรายงานการใช้งานแอปสมาร์ทโฟนมากกว่า 5 ชั่วโมงต่อวัน

แอปพลิเคชันข้ามแพลตฟอร์มในลักษณะที่ผสมผสานข้อดีของเว็บและแอปเนทีฟเข้าด้วยกัน — รองรับหลายแพลตฟอร์ม ให้ประสิทธิภาพที่ค่อนข้างดีกว่า และกระบวนการพัฒนาที่รวดเร็วกว่าด้วยต้นทุนที่ลดลง

ข้อดีของการทำงานข้ามแพลตฟอร์ม: https://www.cisin.com/coffee-break/enterprise/what-are-the-advantages-of-cross-platform-mobile-development-in-enterprise-mobility.html

คำถามอยู่ที่ว่าแอปบนเว็บ ไฮบริด และเนทีฟจะทำงานอย่างไรเมื่อเรารันโมเดลแมชชีนเลิร์นนิงที่ใช้ CPU/GPU เราจำเป็นต้องทำการแปลงอินพุต/เอาท์พุตเพื่อรองรับโมเดล และสุดท้ายดึงเอาต์พุตจากโมเดลกลับไปที่ UI ของเรา

  • ไฮบริดหรือเว็บแอปของเราสามารถทำงานได้โดยไม่ค้างหรือล่าช้าหรือไม่?
  • เว็บและแอปไฮบริดสามารถให้ผลลัพธ์ที่ใกล้เคียงกันได้หรือไม่ หากท้ายที่สุดแล้วประสิทธิภาพไม่เท่ากันเมื่อเปรียบเทียบกับการใช้งานแบบเนทิฟเดียวกัน
  • คุณภาพของรูปภาพ/วิดีโอที่ถ่ายซึ่งจำเป็นต้องป้อนให้กับโมเดล ML คืออะไร
  • ไลบรารี่ที่ใช้ในเฟรมเวิร์กเหล่านี้ได้รับการสนับสนุน/จัดทำเป็นเอกสารได้ดีเพียงใด
  • กรอบการทำงานนี้สนับสนุนนวัตกรรมใหม่ๆ ในพื้นที่ AI-ML นี้ได้ดีเพียงใด พวกเขาทำการดัดแปลงเหล่านี้ได้ดีขนาดนั้นเลยเหรอ? ตัวอย่างเช่น AR/VR
  • ชุมชนช่วยเหลือนักพัฒนาเมื่อพวกเขาติดขัดได้ดีแค่ไหน?
  • การทำให้แอปเหล่านี้เป็นห้องสมุดเป็นเรื่องง่ายแค่ไหน?
  • ง่ายต่อการพัฒนาและบำรุงรักษา

จะพยายามตอบคำถามเหล่านี้ในบทความนี้

ผลงาน

ประสิทธิภาพมีความสำคัญเนื่องจากเราไม่เพียงแต่ต้องทำการคำนวณพื้นหลังเพื่อให้ได้ผลลัพธ์ที่เกี่ยวข้อง แต่ยังต้องแน่ใจว่าเราจะไม่มอบประสบการณ์ที่ช้าและล่าช้าแก่ผู้ใช้ของเรา

นี่คือจุดที่แอปพลิเคชันเนทิฟจะส่องสว่างที่สุด ประสิทธิภาพของ Flutter นั้นดีโดยสุจริต เพียงพอสำหรับความต้องการของเรา แต่เว็บทำงานได้แย่มากที่นี่ มันเริ่มต้นได้ดี แต่หลังจากการโต้ตอบบางอย่าง มันก็จะแล็กในขณะที่จับภาพ (และใช่ ฉันได้ล้างค่าขยะหลังจากการคำนวณทุกครั้ง)

Android และ flutter ชนะรอบนี้

คุณภาพของภาพ

ภาพที่ถ่ายจากกล้องออกมาได้ดีในระบบปฏิบัติการ Android และกระพือปีก แต่ในภาพบนเว็บ ฉันมองเห็นภาพที่มีเม็ดหยาบบ้าง อาจเป็น OEM ที่ทำขั้นตอนหลังการประมวลผลภาพ แต่ก็ยังดูดีกว่าเมื่อเปรียบเทียบกับภาพบนเว็บ

Android และ flutter ก็ชนะรอบนี้เช่นกัน

ห้องสมุด — การสนับสนุน — เอกสารประกอบ — ชุมชน — นวัตกรรมใหม่

Android มีข้อได้เปรียบอย่างยิ่งที่นี่ มีทีมงานใน Google ที่ทำงานเพื่อจัดการเรื่องนี้เท่านั้น เช่น: ทีม ARCore/ARKit เป็นผู้นำอย่างชัดเจนในแพลตฟอร์มดั้งเดิม มีเว็บไซต์และวิดีโอแนะนำมากมาย เอกสารที่อัปเดตเป็นประจำและแอปตัวอย่าง ฯลฯ

ไลบรารีได้รับการสนับสนุนสำหรับทุกแพลตฟอร์มที่มีการกล่าวถึงที่นี่

เนื่องจากปริมาณการใช้และการปรับตัวของ ML-AI นั้นค่อนข้างน้อยกว่าบนเว็บและแอพข้ามแพลตฟอร์ม การสนับสนุน — เอกสาร — ชุมชนทั้ง 3 จึงมีน้อยกว่าอย่างมากในทั้งสอง

Android ชนะรอบนี้

ไลบรารี / SDK / โมดูล

ทำให้แอปกลายเป็นไลบรารี่ที่สามารถรวมไว้ได้ทุกที่

Android และ flutter ต่างก็มีปัญหาเดียวกันที่นี่ สีน้ำตาลแดงของการรอคอยการเปิดตัวไคลเอนต์ ปัญหาการรวม การพึ่งพาของเราที่จะเพิ่มลงในแอปไคลเอนต์ เวอร์ชันไม่ตรงกัน ฯลฯ

Flutter ค่อนข้างใหม่และเราไม่ทราบขอบเขตของปัญหาทั้งหมดที่นี่ ลูกค้าต้องเปิดใช้งาน flutter ในแอปของตนเพื่อรันโมดูลของเราหรือไม่ ขนาดแอปจะป่องขึ้น 2x บางครั้งอาจถึง 3x ด้วยการกระพือปีก มันยากแค่ไหนที่จะเพิ่มการกระพือปีกเพื่อตอบสนองต่อแอปไคลเอ็นต์เนทิฟหรือ xamarin หรือไอออนิก ทุกอย่างยังคงเป็นคำถามอยู่

นี่คือจุดที่เว็บจะเป็นราชา เพียงปรับใช้กับเซิร์ฟเวอร์ของเราแล้วปล่อยให้ลูกค้าใช้ URL ภายในแอปของพวกเขา นั่นคือทั้งหมดที่

เห็นได้ชัดว่าเว็บเป็นผู้ชนะที่นี่ แอนดรอยด์ก็ดี Flutter ดูเหมือนจะมีความเสี่ยง

การพัฒนาและการบำรุงรักษา

เว็บลดการพัฒนาลงครึ่งหนึ่งเนื่องจากเราจะใช้เว็บแอปเดียวกันทั้งใน iOS และ Android แต่ Android ดำเนินการตรวจสอบบน Chromium และ iOS ใช้ Safari อาจต้องมีการแก้ไขเล็กน้อยที่นี่

นอกจากนี้ Flutter ยังช่วยลดเวลาในการพัฒนาลงอย่างมาก เนื่องจากความสามารถข้ามแพลตฟอร์ม หวังว่าไลบรารีที่เราจำเป็นต้องใช้ในการรันแอป เช่น tflite หรือ pytorch จะสามารถทำงานบนทั้งสองแพลตฟอร์มและให้ผลลัพธ์ที่ดีจนถึงปัจจุบัน

Native จะต้องมีทรัพยากร 2 อย่างเพื่อการพัฒนา และสำหรับการเปลี่ยนแปลงหรือการบำรุงรักษาใดๆ เราจะต้องพยายามเกือบสองเท่าเพื่อให้มีการอัปเดต

เว็บและพลิ้วไหวชนะรอบนี้

คำตัดสิน

กระพือ

สำหรับแอปประเภทนี้ที่เราต้องการการประมวลผลจำนวนมาก และการเข้าถึงฮาร์ดแวร์ ไฮบริดไม่ได้ให้ผลลัพธ์ที่ยอดเยี่ยมแก่เรา มันจะมีประโยชน์เพียงเพราะมันจะลดความพยายามในการพัฒนาของเรา แต่ในท้ายที่สุด อาจมีเวลาที่เราต้องกลับมาที่แอปแบบเนทีฟเพื่อเข้าถึงส่วนประกอบหลักได้มากขึ้น และเนื่องจากข้อจำกัดด้านขนาดจากไคลเอนต์

พื้นเมือง

ยกเว้นความพยายามในการพัฒนาและปัญหาการเปิดตัวอย่างรวดเร็ว Native ดูเหมือนจะเป็นหนทางข้างหน้า ชุมชนที่น่าทึ่ง ไลบรารีหลักที่ดีกว่าโดยผู้สร้าง และการสนับสนุนและคำอธิบายโดยละเอียดในเรื่องเดียวกัน

เว็บ

วิธีนี้จะช่วยแก้ปัญหาทั้งความพยายามในการพัฒนาและการเปิดตัวอย่างรวดเร็วของปัญหาคอขวดแบบเนทิฟแต่ประสิทธิภาพ การไม่มีการโต้ตอบกับคอมโพเนนต์ดั้งเดิม และการสนับสนุนไลบรารีที่น้อยลงทำให้เกิดปัญหาที่นี่

คำแนะนำ

ลองใช้ความสามารถดั้งเดิมเพื่อให้ได้ผลลัพธ์ที่ดีที่สุดเท่าที่จะเป็นไปได้และรวมเข้ากับผลิตภัณฑ์ที่มีค่าที่สุดของเรา
นอกจากนี้เรายังมีเว็บแอปไว้สำรองได้อีกด้วย เราสามารถจัดส่งเว็บแอปนี้เป็นทางเลือกสำรองหรือเมื่อเราโอเคกับการประนีประนอมด้านคุณภาพเพื่อการเปิดตัวที่รวดเร็วยิ่งขึ้น