เขียนครั้งเดียว ปรับใช้ได้ทุกที่: เมื่อใดควรเป็นเนทีฟ

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

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

อย่างไรก็ตาม แม้แต่คำว่า "เนทีฟ" ก็เพิ่งถูกทำให้สับสนโดยเฟรมเวิร์กที่คอมไพล์เป็นโค้ดเนทีฟ (เช่น React Native, Xamarin เป็นต้น)

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

เขียนครั้งเดียวปรับใช้ได้ทุกที่

แนวคิดของ Write Once, Deploy Everywhere หมายถึงความสามารถของทีมพัฒนาในการเขียนแอปพลิเคชันเพียงครั้งเดียว โดยใช้สแต็กการพัฒนาเดียว บทคัดย่อของแพลตฟอร์มที่จะปรับใช้แอปพลิเคชัน และยังรักษาความสามารถในการปรับใช้ แอปพลิเคชันไปยังแพลตฟอร์มที่ต้องการทั้งหมด เช่น Android, iOS, Windows ฯลฯ ตามหลักการแล้ว วิธีนี้สามารถทำได้โดยไม่สูญเสียความสามารถในการบำรุงรักษา ประสิทธิภาพ หรือประสบการณ์ผู้ใช้ (UX)

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

โดยทั่วไป ปัจจัยที่ต้องพิจารณาเมื่อเลือกเส้นทางการพัฒนา ได้แก่

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

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

ในระดับสูง เส้นทางการพัฒนาอุปกรณ์พกพาที่แตกต่างกันสามารถแบ่งออกเป็นสองประเภท: เนทีฟหรือ WODE กล่าวคือ เนทีฟหรืออย่างอื่น พูดง่ายๆ ก็คือ คนๆ หนึ่งจะเขียนแอปพลิเคชันที่มาพร้อมเครื่องหรือไม่มีก็ได้ หมวดหมู่ WODE แบ่งออกเป็นสองกลุ่มเพิ่มเติม:

• เฟรมเวิร์ก ไฮบริด - เฟรมเวิ ร์กที่ใช้เทคโนโลยีเว็บเพื่อแสดงผลแอปพลิเคชันข้ามแพลตฟอร์มต่างๆ
• Non-hybrid frameworks - พวกที่ใช้ส่วนประกอบ UI ดั้งเดิม (เช่น ปุ่ม, ฟิลด์ข้อความ, และแม้แต่ตัวจัดการเลย์เอาต์) แทนที่จะแสดงมุมมองเว็บภายในแอปพลิเคชันเช่นเดียวกับเฟรมเวิร์กแบบไฮบริด

กรอบงาน WODE ส่วนใหญ่เป็น ลูกผสม อย่างไรก็ตาม เพื่อปรับปรุงทั้งประสิทธิภาพและข้อจำกัด UX ของเฟรมเวิร์กไฮบริดในขณะที่ยังคงให้ประโยชน์ของเฟรมเวิร์ก WODE อยู่ เทรนด์ปัจจุบันจึงมุ่งไปสู่ ​​non-hybrid จากแนวโน้มนี้ เฟรมเวิร์กเช่น React Native, Xamarin และ Appcelerator จึงได้รับความนิยม

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

โดยทั่วไป สุภาษิตที่ว่า " คุณได้ในสิ่งที่คุณจ่ายไป " จะถูกนำมาใช้ ดังนั้นหากต้นทุนสำคัญกว่าประสบการณ์ของลูกค้า เนทีฟอาจไม่ใช่ตัวเลือกที่เหมาะสม อย่างไรก็ตาม เมื่อ UX กลายเป็นสิ่งสำคัญ แอปพลิเคชันดั้งเดิมจะกลายเป็นตัวเลือกที่ชัดเจน เนื่องจากเพื่อปรับปรุง UX แอปพลิเคชันที่ใช้ WODE จะมีค่าใช้จ่ายจำนวนมากในรูปแบบของเวลาหรือความเชี่ยวชาญเฉพาะด้าน ซึ่งขัดต่อจุดประสงค์ในการเลือกผู้ที่ไม่ใช่เจ้าของภาษา เส้นทางการพัฒนาเป็นอันดับแรก

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

แอปพลิเคชั่นพื้นเมือง

แอปพลิเคชันดั้งเดิมเขียนด้วยภาษาหลักของแพลตฟอร์มที่กำหนด ตัวอย่างเช่น แอปพลิเคชัน Android เขียนด้วย Java ในขณะที่แอปพลิเคชัน iOS เขียนด้วย Obj-C หรือ Swift พวกเขาต้องการวิศวกรพัฒนาที่จะเข้าใจภาษาและความแตกต่างเฉพาะของแพลตฟอร์ม ซึ่งรวมถึง ตัวอย่างเช่น การรวมแพ็คเกจของบุคคลที่สาม การจัดการเลย์เอาต์ การโต้ตอบของระบบปฏิบัติการ (OS) เป็นต้น

ข้อดี

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

หลักฐานง่ายๆ ของแนวคิดนี้สามารถพบได้โดยการเรียกดูชุมชนสนับสนุนสำหรับแพลตฟอร์มที่กำหนด เราจะพบตัวอย่างมากมายเกี่ยวกับวิธีการทำงานให้สำเร็จที่อาจ "ถูกจองจำ" แม้ว่าจะมีข้อจำกัดของกรอบงานพื้นฐาน

ตัวอย่าง iOS ที่เป็นรูปธรรมของงานที่ดูเหมือนง่าย อาจเป็นการแสดงภาพซ้อนทับแบบเต็มหน้าจอ เหนือองค์ประกอบ UI ภายนอกทั้งหมด เช่น แถบแท็บ แถบนำทาง ฯลฯ ดังที่แสดงใน รูปที่ 1 โดยปกติ สิ่งนี้อยู่นอกขอบเขตของ กำลังนำเสนอเลเยอร์ UI ปกติ ดังนั้น เพื่อให้มีการวางซ้อนแบบเต็มหน้าจอ จะต้องเพิ่มเลเยอร์ที่ซ่อนไว้เหนือแถบแท็บในสแต็กมุมมอง การปรับแต่งประเภทนี้โดยทั่วไปจะทำได้เฉพาะกับแอพพลิเคชั่นดั้งเดิมเท่านั้น

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

บำรุงรักษาได้มากที่สุด ระบบปฏิบัติการเปลี่ยนแปลงตลอดเวลา ระยะเวลา. เมื่อทำเช่นนั้น ขึ้นอยู่กับว่าทำการเปลี่ยนแปลงที่แตกหักหรือไม่ แอปพลิเคชันจะต้องได้รับการอัปเดตอย่างทันท่วงที เพื่อไม่ให้สูญเสียส่วนหนึ่งของฐานผู้ใช้ที่อัปเกรดเป็นระบบปฏิบัติการที่ใหม่กว่า เห็นได้ชัดว่ายิ่งเวลาผ่านไประหว่างเวลาที่มีการเปลี่ยนแปลงสำหรับผู้ใช้และแอปพลิเคชันที่ได้รับการอัปเดตน้อยลงเท่าไรก็ยิ่งดีเท่านั้น เวลานี้จะลดลงเมื่อไม่มีการขึ้นต่อกันที่จำเป็นต้องอัปเดตเพื่อรองรับ OS ใหม่นี้ ซึ่งเป็นกรณีเมื่อทำงานกับแอปพลิเคชันที่มาพร้อมเครื่อง

ข้อเสีย

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

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

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

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

แอพพลิเคชั่นไฮบริด

แอปพลิเคชันไฮบริดมักจะเขียนโดยใช้ HTML/CSS/LESS เพื่อออกแบบอินเทอร์เฟซผู้ใช้: "V" ในรูปแบบการออกแบบ MVC โดยทั่วไปแล้ว “C” หรือคอนโทรลเลอร์จะเขียนด้วย JavaScript - ควรใช้เฟรมเวิร์ก JavaScript MVC เช่น AngularJS การใช้เฟรมเวิร์กอย่าง AngularJS ช่วยให้สามารถแยกคลาสและความรับผิดชอบได้ดีกว่าปกติโดยใช้ jQuery เท่านั้น

ตัวอย่างของสแต็กเฟรมเวิร์กไฮบริดประเภทนี้คือเลเยอร์มุมมอง Ionic ที่ได้รับการสนับสนุนโดย AngularJS ซึ่งท้ายที่สุดแล้วจะถูกแปลงและแสดงผลในมุมมองเว็บบนแพลตฟอร์มที่ต้องการโดยใช้ PhoneGap และ Cordova เห็นได้ชัดว่ากรอบงาน WODE ประเภทนี้ต้องแลกมาด้วยความซับซ้อนที่เพิ่มขึ้น

นอกจากนี้ การใช้ JavaScript ยังนำมาซึ่งข้อจำกัดด้านการออกแบบและปัญหาด้านภาษาด้วย เป้าหมายของบทความนี้ไม่ใช่เพื่ออภิปรายข้อดีหรือข้อเสียของภาษาใดภาษาหนึ่ง อย่างไรก็ตาม ในฐานะผู้จัดการโครงการ การเลือกใช้ JavaScript ในสแต็กเทคนิคมือถือไม่ควรทำอย่างง่ายดาย ต่อไปนี้เป็นเพียงตัวอย่างเล็กๆ น้อยๆ ของบทความที่มีการเขียนอย่างดีเกี่ยวกับสาเหตุที่ควรหลีกเลี่ยง JavaScript หากเป็นไปได้:

• ปัญหาจาวาสคริปต์
  
• ทำไมฉันไม่ใช่ React Native Developer

ข้อดี

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

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

ข้อเสีย

UX ที่อาจไม่ดี ข้อเสียของการต้องเขียนเลเยอร์การดูเพียงเลเยอร์เดียวคือเลเยอร์หนึ่งเหลือไว้กับเลเยอร์การดูเดียว ซึ่งอาจส่งผลให้ UX ไม่ดี เนื่องจากการออกแบบ UI แบบเดียวเหมาะกับทุกรูปแบบ ล้มเหลวในการทำให้แอปพลิเคชันมีรูปลักษณ์และความรู้สึกที่สะดวกสบายและคุ้นเคยสำหรับผู้ใช้ในทุกแพลตฟอร์ม นอกจากนี้ เนื่องจากแอปพลิเคชันไฮบริดเป็นมุมมองเว็บที่ฝังอยู่ภายใน UI โดยพื้นฐานแล้ว จึงสามารถให้ผู้ใช้รู้สึกว่าพวกเขากำลังดูหน้าเว็บจริง ๆ แทนที่จะโต้ตอบกับแอปพลิเคชันที่มาพร้อมเครื่อง ประสบการณ์นี้มักจะส่งผลกระทบในทางลบต่อความพึงพอใจของผู้ใช้ และท้ายที่สุดก็คือการรักษาผู้ใช้ไว้

ค่าใช้จ่ายในการปรับแต่ง การปรับปรุง UX โดยการออกแบบ UI ที่ปรับแต่งเองสำหรับแต่ละแพลตฟอร์มส่งผลให้มีเฟรมเวิร์ก UI ที่ซับซ้อนและไม่ซ้ำใคร ซึ่งอาจมีค่าใช้จ่ายสูงในการสร้างและดูแลรักษายากเมื่อเวลาผ่านไป นอกจากนี้ เพื่อสร้างองค์ประกอบ UI ที่จะช่วยให้แอปพลิเคชันของตนโดดเด่น (เช่น แอนิเมชั่น มุมมองที่กำหนดเอง ฯลฯ) ต้องสร้างส่วนประกอบบริดจ์ที่กำหนดเองเพื่อแปลการออกแบบ UI ระดับสูงเป็นสิ่งที่เฟรมเวิร์กระดับล่าง เช่น คอร์โดวา จะเข้าใจ โดยทั่วไป ยิ่งมีการปรับแต่งและปรับปรุง UX ของแอปพลิเคชันไฮบริดมากเท่าใด ก็ยิ่งลดประโยชน์ของวงจรการออกแบบที่รวดเร็วและราคาไม่แพงลงเท่านั้น

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

การจัดการปลั๊กอินที่ไม่สำคัญ จำคุณลักษณะที่กำหนดเองเหล่านั้นที่ทีมออกแบบใช้เวลาหลายสัปดาห์ในการขัดเกลา ตามด้วยอีกสองสามสัปดาห์ในขณะที่ทีมพัฒนาสร้างส่วนประกอบสะพานที่จำเป็นเพื่อให้ Cordova สามารถทำงานร่วมกับพวกเขาได้หรือไม่ พวกเขาจะไม่ทำงานเว้นแต่จะมีปลั๊กอิน Cordova ที่สนับสนุนสำหรับสิ่งที่ทีมพยายามบรรลุ ซึ่งหมายความว่าหนึ่งในสองสิ่ง: ไม่ว่าทีมจะสร้างขึ้นเองหรือต้องหาปลั๊กอินของบุคคลที่สามที่เหมาะสมซึ่งทำงานได้ดี น่าเสียดายที่ไม่มีตัวเลือกที่สองบ่อยกว่านั้น ด้วยเหตุนี้ จึงต้องใช้เวลาในการพัฒนาเพิ่มเติมเพื่อสร้างปลั๊กอินที่กำหนดเอง ตามด้วยความพยายามในการสนับสนุน เมื่อเวลาผ่านไป เพื่อจัดการไลบรารีที่เพิ่มขึ้นของปลั๊กอิน Cordova ที่แอปพลิเคชันต้องการ แน่นอนว่าเมื่อเกิดการอัปเดต Cordova มีความเป็นไปได้สูงที่ปลั๊กอินเหล่านี้จะต้องได้รับการอัปเดตเช่นกัน

ระบบปฏิบัติการรองรับความล่าช้า ปัญหาส่วนประกอบสะพานเรียงซ้อน/ปลั๊กอิน Cordova ที่กล่าวถึงก่อนหน้านี้จะรุนแรงขึ้นอีกเมื่อระบบปฏิบัติการเปลี่ยนฟังก์ชันการทำงานหลัก เมื่อ Cordova, PhoneGap และ Ionic ได้รับการอัปเดตเพื่อรองรับการเปลี่ยนแปลงแล้ว อาจจำเป็นต้องอัปเดตปลั๊กอินที่กำหนดเองและส่วนประกอบบริดจ์ด้วย โดยไม่คำนึงถึงลำดับความสำคัญของงานนี้ ส่งผลให้มีเวลาเพิ่มขึ้นในระหว่างที่แอปพลิเคชันไม่สนับสนุนผู้ใช้ปลายทางที่อัปเดตเป็นระบบปฏิบัติการใหม่ แน่นอนว่านี่เป็นสถานการณ์ที่เลวร้ายที่สุดที่ Apple หรือ Google ทำการเปลี่ยนแปลงแบบทำลายล้างและเข้ากันได้แบบย้อนกลับไม่ได้ ซึ่งไม่เคยเกิดขึ้น… ใช่ไหม โดยทั่วไป เฟรมเวิร์กระดับกลางใดๆ ก็ตามที่อยู่นอกเหนือการควบคุมของผู้พัฒนาและต้องได้รับการอัปเดตก่อน จะทำให้กระบวนการล่าช้าเท่านั้น สุดท้าย การใช้เฟรมเวิร์กระดับกลางอาจทำให้ผู้จัดการโครงการต้องปวดหัวในการวางแผน เนื่องจากยังไม่ทราบระยะเวลาของเฟรมเวิร์กเหล่านี้

แอปพลิเคชันที่ไม่ใช่แบบไฮบริด

แอปพลิเคชันที่ไม่ใช่แบบไฮบริดเริ่มต้นชีวิตเช่นเดียวกับคู่หูไฮบริดของพวกเขา - เลเยอร์ UI ที่ออกแบบในภาษาแพลตฟอร์มที่ไม่ใช่เจ้าของภาษา: React Native ใช้ HTML/CSS ที่ได้รับการสนับสนุนโดย JavaScript หรือ Xamarin ซึ่งใช้ C # เนื่องจากราก. NET

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

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

ข้อดี

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

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

วงจรการพัฒนาที่เร็วขึ้น นอกจากทีมที่มีขนาดเล็กกว่าแล้ว เฟรมเวิร์กที่ไม่ใช่แบบไฮบริดยังช่วยให้วงจรการพัฒนาเร็วขึ้นเมื่อปรับใช้กับหลายแพลตฟอร์ม เนื่องจากจำเป็นต้องออกแบบเลเยอร์การดูเพียงชั้นเดียว

ทำซ้ำได้เร็วขึ้น (React) กรอบงาน React มอบคุณสมบัติอันทรงพลังที่ช่วยให้การเปลี่ยนแปลงในแอปพลิเคชันสามารถแสดงผลได้แบบเรียลไทม์: ไม่จำเป็นต้องคอมไพล์ใหม่ สร้างใหม่ ฯลฯ ดังนั้น React emulator เป็นเครื่องมือการพัฒนาที่ทรงพลังอย่างไม่น่าเชื่อซึ่งช่วยลดระยะเวลาในการใช้งานแต่ละครั้งได้อย่างมาก วงจร

ข้อเสีย

ค่าใช้จ่ายในการปรับแต่ง เมื่อแอปพลิเคชันที่ไม่ใช่แบบไฮบริดต้องการให้ UX ได้รับการปรับปรุงโดยการออกแบบ UI ที่ปรับแต่งเองสำหรับแต่ละแพลตฟอร์ม จะส่งผลให้ส่วนประกอบ UI ที่ซับซ้อนและไม่เหมือนใครซึ่งสามารถสร้างต้นทุนสูงและดูแลรักษาได้ยากเมื่อเวลาผ่านไป นอกจากนี้ยังหมายถึงการเขียนส่วนประกอบบริดจ์ที่กำหนดเองเพื่อเสริมช่องว่างในการสนับสนุนองค์ประกอบดั้งเดิมของเฟรมเวิร์ก เช่นเดียวกับไฮบริด ค่าใช้จ่ายนี้ลดประโยชน์ของวงจรการออกแบบที่รวดเร็วและราคาไม่แพง แต่ต่างจากแอปพลิเคชันไฮบริดตรงที่ส่วนประกอบบริดจ์ถูกเขียนขึ้นสำหรับแต่ละแพลตฟอร์มที่ต้องการ ในภาษาแม่ของพวกเขา ซึ่งหมายความว่าแทนที่จะใช้แอปพลิเคชันที่ไม่ใช่แบบไฮบริดจะเป็นทางเลือกที่ยืดหยุ่นสำหรับทีมที่ประกอบด้วยนักพัฒนาเว็บเป็นหลัก ทีมที่เลือกเส้นทางที่ไม่ใช่แบบไฮบริดจะต้องเรียนรู้ไม่เพียงแต่ภาษาเฉพาะของกรอบงาน (เช่น JSX หรือ C#) แต่ ภาษาแม่ของแต่ละแพลตฟอร์ม (Java, Obj-C หรือ Swift)

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

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

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

การสนับสนุนระยะยาว (React Native) ปัญหานี้เกิดขึ้นเฉพาะกับ React Native และเกี่ยวข้องกับข้อเท็จจริงแปลก ๆ ที่ปัจจุบัน Facebook ไม่ได้ให้คำมั่นสัญญาในแผนการสนับสนุนระยะยาวสำหรับกรอบงานของตน อาจกล่าวได้ว่ามีความเสี่ยงต่ำเนื่องจากบริษัทใช้เฟรมเวิร์กของตนเองสำหรับแอปบนอุปกรณ์เคลื่อนที่ แต่ควรหยุดชั่วคราวสำหรับผู้จัดการโครงการเพื่อพิจารณาว่าเหตุใด Facebook ปฏิเสธที่จะแสดงความคิดเห็นในเรื่องนี้

การเลือกแนวทางที่เหมาะสม

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

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

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

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

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