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

คำถามแรกที่จะเกิดขึ้นในใจของคุณคือคุณควรใช้เทคโนโลยีการพัฒนาใดในการสร้างแอปพลิเคชัน

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

แนวทางพื้นเมือง

แอปพลิเคชันได้รับการพัฒนาในภาษา "ดั้งเดิม" สำหรับแต่ละแพลตฟอร์ม: Java สำหรับ Android และ Objective-C / C++ สำหรับ IOS

เริ่มแรกวิธีนี้ใช้ในการพัฒนาแอปพลิเคชันที่ "ติดตั้งอยู่ใน" อุปกรณ์ - นาฬิกาปลุก, เบราว์เซอร์, แกลเลอรี, เครื่องเล่นเพลง

แนวทางข้ามแพลตฟอร์ม

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

แอปพลิเคชันจะสามารถทำงานได้บนทุกแพลตฟอร์ม

ภาษาการเขียนโปรแกรมเป็นมาตรฐานเหมือนกับว่าคุณกำลังพัฒนาเว็บไซต์ - HTML และ CSS

วิธีการแบบผสมผสาน

แอปพลิเคชันแบบไฮบริดผสมผสานคุณลักษณะของการพัฒนาแบบเนทีฟและข้ามแพลตฟอร์ม

โดยพื้นฐานแล้ว นี่คือแอปพลิเคชันข้ามแพลตฟอร์มภายในเชลล์ "ดั้งเดิม"

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

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

การพัฒนาพื้นเมือง

1 ประสิทธิภาพและความเร็ว

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

ท่าทาง มัลติทัช และการติดตามตำแหน่งทางภูมิศาสตร์นั้นง่ายต่อการใช้งาน

2 ประสบการณ์ผู้ใช้

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

3 ไม่มีข้อจำกัด

แอปพลิเคชันสามารถเข้าถึงบริการและฟังก์ชันต่างๆ ของสมาร์ทโฟนได้อย่างสมบูรณ์ (ฐานข้อมูล ตำแหน่งทางภูมิศาสตร์ กล้อง)

4 ความง่ายในการทดสอบ

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

5 ความพร้อมใช้งาน

ผู้ใช้จะสามารถดาวน์โหลดแอปพลิเคชันได้จากร้านค้า "ดั้งเดิม": App Store, Google Play

6 ความสามารถในการปรับตัว

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

ข้อบกพร่อง

1 ความเร็วในการพัฒนา

หากคุณต้องการครอบคลุมทั้ง iOS และ Android ด้วยแอปของคุณ อาจใช้เวลานานกว่านั้น กระบวนการนี้เกี่ยวข้องกับการพัฒนาแอปพลิเคชันสองรายการที่แยกจากกัน

2 ต้นทุนการพัฒนา

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

3 การบริการและการสนับสนุน

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

1 ความเร็วในการพัฒนาและการลดต้นทุน

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

2 การบริการและการสนับสนุน

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

ข้อบกพร่อง

1 ความเร็วในการพัฒนาและการลดต้นทุน

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

2 ประสิทธิภาพต่ำ

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

3 ประสบการณ์ผู้ใช้

จำเป็นต้องพัฒนาอินเทอร์เฟซที่ใช้งานง่ายสำหรับผู้ใช้ทั้ง iOS และ Android

มิฉะนั้น แอปพลิเคชันที่สร้างขึ้นตาม iOS Human Interface Guide จะไม่สะดวกสำหรับผู้ใช้ Android และคุณจะใช้เวลามากขึ้นในการปรับปรุงประสบการณ์ผู้ใช้

4 อุทธรณ์ไปยัง "พื้นเมือง"

โซลูชันมาตรฐานสำหรับเนทีฟยังไม่ได้รับการแก้ไขในการพัฒนาข้ามแพลตฟอร์ม ดังนั้นนักพัฒนาพื้นเมืองจึงมักถูกดึงเข้ามาเพื่อแก้ไขฟังก์ชันการทำงาน

เมื่อข้ามแพลตฟอร์มชนะ:

• พื้นที่เล่นเกมบนมือถือ
• เมื่อคุณต้องการออกสู่ตลาดอย่างรวดเร็วเพื่อทำการทดสอบแนวคิดทางธุรกิจของคุณ หรือเมื่อคุณมีเว็บไซต์ที่ต้องการเปลี่ยนเป็นแอปด้วยต้นทุนที่ต่ำที่สุด

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

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

ในบทความนี้ เราจะเปรียบเทียบโซลูชันการพัฒนาข้ามแพลตฟอร์ม 6 โซลูชันที่ได้รับความนิยมในปี 2559 และพยายามค้นหาโซลูชันที่ดีที่สุด

เฟรมเวิร์กข้ามแพลตฟอร์ม PhoneGap, Xamarin, Unity, Qt และ Appcelerator Titanium, แพลตฟอร์ม Telerik ปัจจุบันครอง 80% ของตลาดการพัฒนาข้ามแพลตฟอร์มสำหรับอุปกรณ์มือถือ

ตารางด้านล่างแสดงคุณลักษณะหลักของแต่ละเฟรมเวิร์ก:

	PhoneGap	ซามาริน	ความสามัคคี	จำนวน	Appcelerator ไทเทเนียม	Telerik AppBuilder
ภาษา	JavaScript, HTML5, CSS3 และภาษาพื้นเมือง (Java, Objective-C, C#)	C#, Xaml	C#, UnityScript, บู	C++ คิวเอ็มแอล	จาวาสคริปต์, หลาม, รูบี้, PHP	.Net, JavaScript, HTML5, Java, PHP
แพลตฟอร์มที่รองรับ	Android, iOS, Windows Phone, Blackberry, WebOS, Symbian, Bada, Ubuntu, ระบบปฏิบัติการ Firefox	iOS, Android, Windows Phone และ Windows 8/RT, Tizen	Android, iOS, Windows Phone, Tizen, PS 4, Xbox One	Android, iOS, WinRT, Windows, Symbian, Linux, QNX	iOS, Android, BlackBerry, Windows, Tizen, บริษัท เด็นโซ่	iOS, แอนดรอยด์, แบล็คเบอร์รี่, วินโดวส์, วินโดวส์โฟน
ราคา	ราคา PhoneGap เวอร์ชันที่ต้องชำระเงิน: จาก $9.99 เวอร์ชันฟรี: พร้อมใช้งาน การเป็นสมาชิก Adobe Creative Cloud: พร้อมใช้งาน	ราคา ซามาริน ชุมชน Xamarin Studio: ฟรี ชุมชน Visual Studio: ฟรี Visual Studio มืออาชีพ: พร้อมใช้งาน องค์กร Visual Studio: พร้อมใช้งาน	ราคา ความสามัคคี ฉบับส่วนตัว: ฟรี Professional Edition: จาก $75 ต่อเดือน	ราคา จำนวน มีเวอร์ชันฟรี เวอร์ชันที่ต้องชำระเงินเริ่มต้นที่ $79	ราคา แอพเซเลเตอร์ อินดี้: $39 ต่อเดือน มีช่วงทดลองใช้งานฟรี ราคาเริ่มต้นที่ $39 ต่อเดือน
โอเพ่นซอร์ส	+	-	-	+	+	-
UI	เว็บ	พื้นเมือง	UI แคนวาส	พื้นเมือง	พื้นเมือง	เว็บ

PhoneGap

PhoneGap ช่วยให้คุณสร้างแอปพลิเคชั่นมือถือโดยใช้เทคโนโลยีเว็บมาตรฐาน (HTML5, JavaScript และ CSS3) เป็นผลให้สิ่งนี้ทำให้ความนิยมของเฟรมเวิร์กเพิ่มขึ้นอย่างรวดเร็ว ด้วยความช่วยเหลือนี้ คุณสามารถทำได้โดยไม่ต้องพัฒนาในภาษาการเขียนโปรแกรมเช่น Java สำหรับ Android, Objective-C สำหรับ iOS และ C#

PhoneGap Build ช่วยให้คุณสร้างบิลด์สำหรับ iOS, Android และ Windows Phone ได้พร้อมกันโดยไม่จำเป็นต้องติดตั้งเครื่องมือ SDK ใด ๆ (แน่นอนว่ามีเล่ห์เหลี่ยมในเรื่องนี้ - เมื่อพัฒนาก็ยังดีกว่าถ้าสร้างในเครื่อง อย่างน้อยบน Android ก่อนส่งไปทดสอบ) แต่ที่สำคัญกว่านั้น บริการนี้ช่วยให้คุณสร้าง iOS ในระบบคลาวด์ได้โดยไม่ต้องมี Mac

การติดตั้ง PhoneGap ต้องใช้ความพยายามอย่างมาก ดังนั้นฉันขอแนะนำให้คุณฟรีครึ่งวัน... ล้อเล่นนะ การติดตั้ง XCode ใช้เวลาประมาณ 3 นาที ประกอบด้วยการดาวน์โหลดไฟล์เก็บถาวร การแตกไฟล์ และการติดตั้ง นั่นคือทั้งหมดที่

PhoneGap ให้โอกาสในการใช้ฟังก์ชันดั้งเดิมของอุปกรณ์มือถือเพื่อทำงานกับ:

• มาตรความเร่ง,
• กล้อง,
• เข็มทิศ,
• ผู้ติดต่อ
• การจัดเก็บไฟล์,
• ตำแหน่งทางภูมิศาสตร์,
• ฐานข้อมูล
• กิจกรรม, การแจ้งเตือน,
• สื่อ ฯลฯ

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

ข้อดี:

• PhoneGap มี API ง่ายๆ ที่ทำให้ง่ายต่อการเริ่มพัฒนาสำหรับผู้ที่เคยใช้ HTML, CSS และ JavaScript
• ความสามารถในการใช้ไลบรารี JavaScript ที่มีอยู่ (JQuery, Prototype, Sencha Touch)
• รองรับแพลตฟอร์มมือถือทั้งหมด

ข้อบกพร่อง:

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

ซามาริน

Xamarin เป็นเฟรมเวิร์กข้ามแพลตฟอร์มตัวที่สองในรายการของเรา Xamarin ช่วยให้คุณสร้างตรรกะแอปพลิเคชันเดียวโดยใช้ C# และ .NET

ในทางปฏิบัติแล้ว แพลตฟอร์ม Xamarin แสดงถึงแพลตฟอร์มย่อยจำนวนหนึ่ง แพลตฟอร์มย่อยเหล่านี้มีบทบาทสำคัญ โดยแอปพลิเคชันสามารถกำหนดเส้นทางคำขอไปยังอินเทอร์เฟซแอปพลิเคชันบนอุปกรณ์ได้ อินเทอร์เฟซแบบภาพถูกกำหนดไว้ ตรรกะเชื่อมโยงกับ C# และทั้งหมดนี้ใช้งานได้บน Android, iOS และ Windows Phone วิดีโอเกี่ยวกับการพัฒนาแอปพลิเคชันบน Xamarin

ข้อดี:

• ชุมชนขนาดใหญ่และกำลังเติบโต
• นักพัฒนาสามารถใช้ TestCloud เพื่อทดสอบแอปพลิเคชันโดยอัตโนมัติ
• หากคุณคุ้นเคยกับ C# และ .NET อยู่แล้ว คุณไม่จำเป็นต้องใช้เวลามากมายในการเรียนรู้เฟรมเวิร์กใหม่ๆ มากมาย
• คุณสามารถใช้โค้ดที่เขียนแล้วซ้ำได้
• แอพพลิเคชั่นภายใต้ระบบต่าง ๆ จะมีลักษณะคล้ายกันมาก
• เค้าโครงแบบไดนามิกสำหรับ iOS นั้นง่ายกว่าการใช้ข้อจำกัดด้วยตนเองอย่างไม่มีสิ้นสุด
• ต้องขอบคุณ CustomRenderers ที่ทำให้การควบคุมมาตรฐานได้รับการเสริมด้วยคุณสมบัติที่กำหนดเองได้อย่างง่ายดาย (เช่น การไล่ระดับสีสำหรับปุ่มต่างๆ จะใช้เวลาสองสามนาที แม้ว่าจะไม่ได้ผลก็ตาม)

ข้อบกพร่อง:

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

Telerik AppBuilder

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

ความสามารถในการสร้างแอปพลิเคชัน iOS ที่ทำงานบน Windows หรือ Linux ก็เป็นข้อดีอีกประการหนึ่ง

ข้อดี:

• Telerik มีปลั๊กอิน Visual Studio และ Sublime Text สำหรับ AppBuilder
• AppBuilder นำเสนอวิธีที่รวดเร็วในการนำเข้าปลั๊กอิน Cordova
• IDE ออนไลน์ที่ครบครัน
• ใช้งานง่ายและเรียนรู้

ข้อบกพร่อง:

• ชุมชนเล็กๆ

ความสามัคคี

เครื่องมือหลายแพลตฟอร์มสำหรับการพัฒนาแอปพลิเคชันและเกม 2D และ 3D Unity ยังเป็นหนึ่งในเครื่องมือที่ดีที่สุดสำหรับการสาธิตเนื้อหา 3D แอปพลิเคชันที่สร้างขึ้นโดยใช้ Unity ทำงานภายใต้ระบบปฏิบัติการ Windows, OS X, Linux, Android, Apple iOS, Windows Phone, BlackBerry รวมถึงบนคอนโซลเกม Wii, PlayStation 3 และ Xbox 360 วิดีโอพร้อมการพัฒนาเกมมือถือบน Unity .

ข้อดี:

• ตัวเลือกที่ยอดเยี่ยมสำหรับการสร้างเกมมือถือสำหรับอุปกรณ์หลากหลายประเภท
• เอ็นจิ้น 3D ให้ผลลัพธ์คุณภาพสูงโดยไม่ต้องมีการกำหนดค่าที่ซับซ้อน
• มีปลั๊กอินฟรีดีๆ มากมาย
• Unity ช่วยให้นักพัฒนาสร้างเชเดอร์ของตัวเองและเปลี่ยนวิธีที่ Unity เรนเดอร์เกมได้

ข้อบกพร่อง:

• UI และความยากในการใช้งานสำหรับผู้เริ่มต้น
• ซอร์สโค้ดไม่พร้อมใช้งาน
• คอมไพเลอร์ Unity ไม่ได้รับการปรับให้เหมาะสมสำหรับโปรเซสเซอร์ ARM บนอุปกรณ์มือถือบางรุ่น

ไลบรารี Qt สำหรับการสร้างแอปพลิเคชันแบบหน้าต่างข้ามแพลตฟอร์มใน C ++ Qt ไม่ควรได้รับการพิจารณาว่าเป็นชุดของคลาสสำหรับการสร้าง GUI แต่เป็นชุดเครื่องมือที่ครบครันของคลาสสำหรับทุกโอกาส เป็นไปได้ที่จะพัฒนาโปรแกรมไม่เพียงแต่ในภาษา C++ แต่ยังเป็นภาษา QML ซึ่งคล้ายกับ JavaScript มาก นี่เป็นสาขาพิเศษของการพัฒนา Qt ที่มุ่งสร้างต้นแบบและพัฒนาแอปพลิเคชันมือถืออย่างรวดเร็ว วิดีโอที่มีการพัฒนา Tiled Map Editor บน Qt.


ข้อดี:

• Qt มีเครื่องมือดีๆ มากมายที่ช่วยในการพัฒนา เช่น IDE QT Creator, Qt Designer และการสร้างโปรไฟล์โค้ด
• มีไลบรารีที่มี API ที่ใช้งานง่ายสำหรับองค์ประกอบต่างๆ เช่น เครือข่าย ภาพเคลื่อนไหว และอื่นๆ

ข้อบกพร่อง:

• Qt เป็นเรื่องยากสำหรับผู้เริ่มต้น

Appcelerator ไทเทเนียม

Titanium เป็นแพลตฟอร์มแบบเปิดโดยสมบูรณ์สำหรับการพัฒนา การปรับใช้ การกระจาย และการรันเว็บแอปพลิเคชันในท้ายที่สุด Appcelerator Titanium ช่วยให้คุณสร้างแอปพลิเคชั่นมือถือใน JavaScript, HTML และ CSS

คุณสามารถสร้างแอพพลิเคชั่นเนทิฟที่ทันสมัยและที่สำคัญที่สุดได้โดยใช้ระบบปฏิบัติการยอดนิยมในปัจจุบัน: Windows, GNU/Linux หรือ MacOS X

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

ข้อดี:

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

ข้อบกพร่อง:

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

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

React Native คืออะไร? นี่คือเฟรมเวิร์ก JS ที่ใช้ JS และ React - ไลบรารี JS สำหรับการสร้าง UI (ระดับมุมมอง)

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

ข้อดี:

• ขั้นตอนการทำงานและเครื่องมือที่เป็นหนึ่งเดียว: ไม่ว่าคุณจะทำงานบนเวอร์ชัน Android หรือ iOS คุณก็ยังคงใช้เครื่องมือเดิม
• ด้วยเหตุนี้ - ความเร็วและความสะดวกในการพัฒนา
• การเชื่อมโยงแอปรุ่นเก่ากับ JS API และแอปไฮบริด: สมมติว่าคุณมีแอป iOS สำเร็จรูปอยู่แล้วและต้องการเปลี่ยนไปใช้ React Native จากนั้นคุณสามารถรวมส่วนประกอบดั้งเดิมเพื่อให้มีอยู่ใน React Native ดังนั้นคุณจึงสามารถค่อยๆ ย้ายไปที่ React ได้ และผลลัพธ์ที่ได้ก็คือแอปพลิเคชันไฮบริด - ครึ่งหนึ่งของแอปพลิเคชันเนทิฟ และครึ่งหนึ่งใน React และส่วนประกอบดั้งเดิมบางส่วนใน JS API

ไม่มีวิธีแก้ปัญหาที่สมบูรณ์แบบ แต่ละเฟรมเวิร์กมีข้อดีและข้อเสียต่างกันไป สำหรับการใช้งานที่เรียบง่ายมาก ฉันขอแนะนำให้ใช้ PhoneGap จนกว่าการตอบสนองจะกลายเป็นเกณฑ์สำคัญ สำหรับการพัฒนาที่จริงจังยิ่งขึ้น ควรใช้ Xamarin ดีกว่า แต่ถึงแม้จะมี Xamarin ก็ยังดีกว่าถ้ารวมการพัฒนาแบบเนทีฟสำหรับองค์ประกอบ UI ส่วนใหญ่

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

แอปพลิเคชันแบบเนทีฟได้รับการออกแบบมาสำหรับพารามิเตอร์และคุณสมบัติของแพลตฟอร์มเฉพาะ(ระบบปฏิบัติการมือถือ ระบบนิเวศที่เกี่ยวข้อง และคุณลักษณะทางเทคนิคของอุปกรณ์มือถือ) และใช้ความสามารถทั้งหมดของแพลตฟอร์มฮาร์ดแวร์ที่จำเป็นในการทำงานร่วมกับแอปพลิเคชัน ตั้งแต่กล้องและโมดูล GPS ไปจนถึงมาตรความเร่ง การควบคุมด้วยท่าทาง และฮาร์ดแวร์อื่นๆ - คุณสมบัติที่รองรับของสมาร์ทโฟนหรือแท็บเล็ตโดยเฉพาะ นอกจากนี้ แอปพลิเคชันเนทิฟที่พัฒนาในสตูดิโอสามารถรับเป็นผลิตภัณฑ์สำเร็จรูปและวางไว้ในร้านแอปพลิเคชันมือถือ (เช่น Google Play หรือ Apple App Store)

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

นักออกแบบออนไลน์ส่วนใหญ่สร้างอะไร?

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

นักออกแบบออนไลน์ไม่ได้สร้างแอปพลิเคชันแบบเนทีฟ แต่เป็นเว็บแอปพลิเคชันซึ่งไม่ใช่ผลิตภัณฑ์ซอฟต์แวร์ในความหมายคลาสสิก โดยพื้นฐานแล้วเป็นเว็บไซต์พิเศษที่ดูและทำหน้าที่เหมือนกับแอปพลิเคชันเนทีฟ แต่จริงๆ แล้วไม่ใช่เว็บไซต์ใดเลย ตามกฎแล้วเพื่อให้ใช้งานได้คุณต้องมีเบราว์เซอร์ที่ติดตั้งและกำหนดค่าบนอุปกรณ์มือถือที่มีอินเทอร์เน็ต เว็บแอปพลิเคชันนั้นสร้างขึ้นโดยใช้ HTML5 ส่วนหนึ่งอธิบายความนิยมที่เพิ่มขึ้นของเว็บแอป (และข้อเท็จจริงที่ว่าระบบปฏิบัติการมือถือ Tizen ใหม่ของ Samsung และ Android บางรุ่นใช้เว็บแอปด้วยเทคโนโลยีนี้)

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

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

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

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

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

คุณควรเลือกอะไร?

แอปพลิเคชันแต่ละประเภทมีข้อดีและข้อเสียของตัวเอง นี่เป็นเพียงแอปพลิเคชันที่สำคัญที่สุดเท่านั้น:

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

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

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

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

กระบวนการติดตั้ง:แม้ว่าจะต้องติดตั้งแอปแบบเนทีฟและแบบไฮบริดบนอุปกรณ์ของคุณ และต้องได้รับสิทธิ์ในการเข้าถึงส่วนประกอบบางอย่างของแพลตฟอร์มซอฟต์แวร์และฮาร์ดแวร์ แต่เว็บแอปนั้นจะถูก "ติดตั้ง" โดยพื้นฐานแล้วเพียงแค่เพิ่มบุ๊กมาร์กลงในเบราว์เซอร์มือถือของคุณ

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

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

การทำงานกับเนื้อหาขั้นตอนการเพิ่มไปยังร้านค้าแอปพลิเคชันและการชำระเงินเพิ่มเติม:แอพเนทีฟและไฮบริดต้องผ่านกระบวนการอนุมัติพิเศษหลังจากเพิ่มเข้าไปใน App Store นอกจากนี้ อาจอยู่ภายใต้ข้อจำกัดบางประการเนื่องจากกฎและนโยบายภายในของ App Store และ Google Play (โดยเฉพาะอย่างยิ่งหากเรากำลังพูดถึงเนื้อหา "สำหรับผู้ใหญ่" การพนัน เครื่องดื่มแอลกอฮอล์ หรือหัวข้อที่คล้ายกัน)

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

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

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

คุณต้องการสั่งซื้อแอปพลิเคชันเนทิฟหรือไม่? ส่งใบสมัครของคุณโดยมีหัวเรื่อง “Application Development” อยู่ในอีเมลของเรา - และเราจะติดต่อคุณภายใน 24 ชั่วโมงและชี้แจงรายละเอียดทั้งหมดเพื่อหารือเพิ่มเติม

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

ของคุณที่รัก...

ก่อนอื่น เรามาพูดถึงการพัฒนาของชนพื้นเมืองกันก่อน ทุกอย่างเป็นเรื่องง่ายที่นี่: สำหรับแต่ละแพลตฟอร์มก็มี ภาษาพื้นเมือง: สำหรับ Android นี่คือ Java สำหรับ iOS - Objective-C หรือ Swift สำหรับ Windows Phone - C# เป็นต้น ภาษาแม่แต่ละภาษามีชุดเทคโนโลยีและกรอบงานของตนเอง

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

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

การพัฒนาข้ามแพลตฟอร์ม

มีสองวิธีหลักในการพัฒนาแอปพลิเคชันข้ามแพลตฟอร์ม: ทำ "ด้วยตนเอง" โดยการเขียน รหัส C++ และ Wrappers สำหรับแพลตฟอร์มต่างๆหรือใช้อย่างใดอย่างหนึ่ง เทคโนโลยีที่พัฒนาขึ้นเป็นพิเศษ.

การพัฒนา “ด้วยมือ”

สาระสำคัญของแนวทางแรกก็คือ รหัสซี++สามารถเปิดตัวได้ทุกที่ Android ใช้ NDK สำหรับสิ่งนี้ Windows Phone ใช้ Managed C แพลตฟอร์มอื่นๆ ก็มีวิธีการประมวลผลและเรียกใช้โค้ดเป็นของตัวเอง อีกประการหนึ่งคือโค้ดดังกล่าวจะถูกจำกัดความสามารถ ตัวอย่างเช่นใน Android จะไม่สามารถเข้าถึงหน้าจอหรือสตาร์ทเองได้ เพื่อหลีกเลี่ยงข้อจำกัดเหล่านี้ ขั้นแรกไลบรารีที่มีตรรกะหลักจะเขียนด้วยภาษา C++ จากนั้นจึงเขียน Wrapper ในภาษาท้องถิ่นที่รันไลบรารีและตรวจสอบให้แน่ใจว่ามีการโต้ตอบกับอุปกรณ์ อย่างไรก็ตาม เป็นที่น่าสังเกตว่าแนวทางนี้เหมาะสำหรับแอปพลิเคชันในช่วงที่จำกัดเท่านั้น โดยที่ไคลเอ็นต์ต้องใช้ตรรกะมากมาย ซึ่งเหมาะสมที่จะวางไว้ในไลบรารีที่แยกต่างหาก

เทคโนโลยี

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

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

อีกทางเลือกหนึ่งในการเขียนแอปพลิเคชันข้ามแพลตฟอร์มคือการใช้งาน HTML5 + จาวาสคริปต์- อย่างไรก็ตาม นี่คือวิธีการเขียนโปรแกรมแก้ไขข้อความ Atom, Visual Studio Code และ Slack (ใช่แล้ว แม้แต่เวอร์ชันเดสก์ท็อปก็ยังเป็นเบราว์เซอร์ที่ออกแบบมาให้ดูเหมือนแอปพลิเคชันทั่วไป)

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

ความคิดนี้ดูไร้สาระ แต่ถ้าคุณลองคิดดู ก็สามารถพิสูจน์ได้ ด้วยการพัฒนาแนวคิดเรื่องอินเทอร์เน็ตของสรรพสิ่งและการเพิ่มขึ้นของจำนวนอุปกรณ์ IoT ต่างๆ ในอนาคต เราคาดว่าความต้องการโปรแกรมเมอร์จะเพิ่มขึ้นอย่างรวดเร็วซึ่งสามารถรับประกันการมีปฏิสัมพันธ์กับโลกภายนอกได้ และอุปสรรคในการเข้าสู่ JavaScript นั้นต่ำกว่าใน C หรือ Assembler มาก คุณไม่สามารถโต้แย้งได้!

มันไม่ง่ายอย่างนั้น

ข้อดีของการพัฒนาข้ามแพลตฟอร์มคือคุณสามารถเขียนแอปพลิเคชันหรือส่วนประกอบใดๆ ของแอปพลิเคชันได้เพียงครั้งเดียว โดยใช้ C++ เช่น และรันบนแพลตฟอร์มและอุปกรณ์ต่างๆ เป็นเหตุผลที่จะต้องใช้ต้นทุนน้อยลง ดูเหมือน - เขียนและชื่นชมยินดี! อย่างไรก็ตาม วิธีการนี้ก็มีข้อเสียหลายประการเช่นกัน

และพวกเขาทั้งหมดมีเหตุผลเดียว:ทุกแพลตฟอร์มมีความแตกต่างกัน.

ลองพิจารณาความไม่สะดวกหลักๆ ที่คุณจะต้องเผชิญเมื่อเข้าสู่เส้นทางการพัฒนาข้ามแพลตฟอร์ม

ประสบการณ์ผู้ใช้เชิงลบ

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

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

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

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

ข้อจำกัดในการพัฒนาฟังก์ชันการทำงาน

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

การกระทำที่คุ้นเคยอย่างการลากและวางนั้นแตกต่างกันโดยพื้นฐานสำหรับ Mac และแพลตฟอร์มอื่นๆ ขณะที่บน Windows หรือ Linux การกระทำนี้จะได้รับการจัดการโดยแอปพลิเคชันเอง แต่บน Mac ระบบปฏิบัติการจะเริ่มทำงาน ซึ่งหมายความว่านักพัฒนาจะต้องสร้างเหตุการณ์ “เปิดไฟล์” แยกต่างหากเพื่อให้การดำเนินการนี้ทำงานได้อย่างถูกต้องบน Mac ซึ่งหมายความว่าคุณจะต้องยอมรับกับการเพิ่มขึ้นของต้นทุนแรงงานในการพัฒนาหรือความจริงที่ว่าการลากและวางที่ผู้ใช้คุ้นเคยบนแพลตฟอร์มนี้จะไม่ทำงาน

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

แอปพลิเคชันข้ามแพลตฟอร์มช้าลง: ตำนานหรือความจริง?

ในเกือบทุกการถกเถียงเกี่ยวกับข้อดีและข้อเสียของการพัฒนาข้ามแพลตฟอร์ม คุณจะเห็นข้อโต้แย้งว่าแอปพลิเคชันข้ามแพลตฟอร์มนั้นช้ากว่าแอปพลิเคชันดั้งเดิมอย่างมาก นี่เป็นทั้งจริงและเท็จ ตัวอย่างเช่น โค้ดที่เขียนด้วยภาษา C++ และทำงานบน Android โดยใช้ NDK จะทำงานเร็วกว่าแอปพลิเคชันแบบเนทีฟเสียอีก ในทางกลับกัน หากคุณใช้ PhoneGap เช่น แอปพลิเคชันจะเริ่มทำงานเหมือนกับ “บ้านที่แจ็คสร้าง” PhoneGap เรียก JS ซึ่งเรียก Java ซึ่งทำงานบนเครื่อง Java ซึ่งกำลังทำงานอยู่บนเครื่องจริงอยู่แล้ว โทรศัพท์. แน่นอนว่าเราไม่ได้พูดถึงความเร็วอีกต่อไป

แล้วคุณควรเลือกอะไร?

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

ตัวอย่างเช่นเกมไขปริศนายอดนิยมปี 2048 ได้รับการพัฒนาให้ดีขึ้นในฐานะแอพพลิเคชั่นข้ามแพลตฟอร์ม พัฒนาบนเทคโนโลยีเว็บ โดยจะทำงานได้ทุกที่: คุณสามารถใช้ PhoneGap เดียวกันเพื่อรันบนแพลตฟอร์มมือถือ, Electron - สำหรับ Windows, Linux และ Mac และสำหรับเว็บไซต์, แอปพลิเคชั่น VKontakte และ Facebook คุณไม่จำเป็นต้องลงแรงแม้แต่น้อย : แอปพลิเคชันจะเปิดขึ้นโดยตรง สิ่งที่คุณต้องทำคือรวบรวมโปรแกรมโดยใช้แพ็คเกจที่แตกต่างกัน และสร้างไอคอนสำหรับแต่ละแพลตฟอร์ม เสร็จแล้วแอปพลิเคชั่นนี้แยกไม่ออกจากแอปพลิเคชั่นดั้งเดิม!

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

“Sketch ใช้งานได้กับ Windows หรือ Linux หรือไม่?

เนื่องจากเทคโนโลยีและเฟรมเวิร์กที่เป็นเอกสิทธิ์ของ OS X ที่ Sketch สร้างขึ้น น่าเสียดายที่เราจะไม่พิจารณาที่จะสนับสนุน Sketch บนแพลตฟอร์มใดแพลตฟอร์มหนึ่งเหล่านี้”

(มีเวอร์ชันสำหรับ Windows หรือ Linux หรือไม่?

เนื่องจากข้อเท็จจริงที่ว่า Sketch ได้รับการพัฒนาบนเทคโนโลยีและเฟรมเวิร์กเฉพาะสำหรับ OS X ขออภัย เราไม่ได้พิจารณาที่จะย้ายไปยังแพลตฟอร์มใดๆ เหล่านี้)

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

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

มาสรุปกัน

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

มีกรอบการทำงานและเทคโนโลยีมากมายสำหรับการพัฒนาข้ามแพลตฟอร์ม ตัวอย่างที่ได้รับความนิยมมากที่สุด ได้แก่ Ionic, Unity 3D, Xamarin, React Native และการใช้ HTML + JavaScript

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

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

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

หากคุณพบข้อผิดพลาด โปรดเน้นข้อความและคลิก Ctrl+ป้อน.

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

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

ก่อนอื่นเรามาดูคำศัพท์อีกครั้ง

ญาติ

หากนักพัฒนาในกระบวนการเขียนแอปพลิเคชันใช้ภาษาการเขียนโปรแกรมที่นำมาใช้สำหรับแพลตฟอร์มเฉพาะไม่ว่าจะเป็น Objective-C และ Swift สำหรับ iOS หรือแอปพลิเคชันดังกล่าวจะเรียกว่าเนทิฟ (จากภาษาอังกฤษเป็นภาษาพื้นเมือง - เป็นธรรมชาติ)

ข้อดีของแอปพลิเคชันเนทิฟ:

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

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

และไม่ใช่ญาติ

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

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

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

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

ข้อดี:

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

ข้อบกพร่อง:

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

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

แพลตฟอร์มและเครื่องมือการพัฒนาข้ามแพลตฟอร์มยอดนิยม

ดังที่เราเขียนไว้ข้างต้น มีสองวิธี - การเปลี่ยนโค้ดเป็นภาษาพื้นเมืองในขั้นตอนการประกอบ หรือเพิ่ม wrapper บางอย่างที่แปลการโทรเข้าและออกจากระบบ

Cordova และ PWA เป็นเครื่องมือสองอย่างที่ทำงานได้อย่างแม่นยำในอุดมการณ์ของกระดาษห่อ

คอร์โดวาและ HTML5

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

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

มีการสร้างเฟรมเวิร์กจำนวนมากสำหรับแนวทางนี้ แต่โดยพื้นฐานแล้วเฟรมเวิร์กทั้งหมดก็ทำสิ่งเดียวกัน ความแตกต่างระหว่างพวกเขาคือ Cordova (PhoneGap) ไม่ได้ตั้งค่าข้อจำกัดและเทมเพลตบนตรรกะและ UI สำหรับโปรเจ็กต์ HTML5 ของคุณ และเฟรมเวิร์กทำงานกับองค์ประกอบ UI สำเร็จรูปของตัวเองที่เลียนแบบแพลตฟอร์มมือถือและตรรกะการพัฒนาของตัวเอง ตัวอย่างของแนวทางนี้คือ: Ionic Framework - wrapper; Framework7, Mobile Angular UI, Sencha Touch, Kendo UI - เฟรมเวิร์กอินเทอร์เฟซ

กปภ

เทคโนโลยีที่ทันสมัยจาก Google เป็นเว็บแอปพลิเคชันเดียวกัน แต่ผ่านการใช้เทคโนโลยีบางอย่าง (โดยหลักเรียกว่า Service Worker - สคริปต์ที่ทำงานอยู่เบื้องหลังและ Web App Manifest - คำอธิบายของเว็บแอปพลิเคชันในรูปแบบที่เข้าใจได้สำหรับมือถือ system ) พวกเขาสามารถทำงานแบบเนทิฟได้โดยไม่ต้องมี PhoneGap wrapper สามารถติดตั้งบนหน้าจอหลัก ข้าม App Store ทำงานแบบออฟไลน์ ทำงานด้วยการแจ้งเตือนแบบพุช และด้วยฟังก์ชันดั้งเดิม

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

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

ซามาริน

แพลตฟอร์มไมโครซอฟต์ ภาษาโปรแกรมมาตรฐานสำหรับการพัฒนาองค์กรคือ C# และสภาพแวดล้อมการพัฒนาข้ามแพลตฟอร์มคือ Visual Studio ผลลัพธ์คือแอปพลิเคชันดั้งเดิมสำหรับ iOS, Android และ Windows จริงขนาดค่อนข้างใหญ่

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

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

เนื่องจากเป็นแพลตฟอร์มที่ค่อนข้างใหม่ React Native ยังคงประสบปัญหาอย่างเห็นได้ชัด (แม้ว่าจะไม่ใช่หายนะ) เนื่องจากขาดเครื่องมือและเอกสารในการพัฒนา

กระพือปีก

โดยธรรมชาติแล้วยักษ์ใหญ่อย่าง Google ไม่สามารถเพิกเฉยต่อหัวข้อการพัฒนาแอปพลิเคชัน Android และ iOS ข้ามแพลตฟอร์มได้ Flutter แม้ว่าปัจจุบันจะอยู่ในช่วงเบต้าเท่านั้น แต่ใช้แนวทางที่แตกต่างจาก React Native และ Xamarin มันไม่ได้เปลี่ยนซอร์สโค้ดให้เป็นเนทีฟโค้ดซึ่งดำเนินการโดยแพลตฟอร์ม แต่ในความเป็นจริงจะดึงหน้าต่างบนหน้าจอสมาร์ทโฟนและเรนเดอร์องค์ประกอบทั้งหมดด้วยตัวมันเอง ภาษาที่ใช้คือ Dart “กรรมสิทธิ์” ซึ่ง Google สร้างขึ้นเป็น JavaScript เวอร์ชันปรับปรุง

สิ่งนี้มีทั้งข้อดี (เช่น อินเทอร์เฟซที่เหมือนกันภายนอก) และข้อเสีย (เช่น การวาดอินเทอร์เฟซใหม่ต้องใช้หน่วยความจำและเวลา CPU ที่แน่นอน)

แพลตฟอร์มดังกล่าวกำลังพัฒนาอย่างรวดเร็วและ Google ก็ลงทุนความพยายามและเงินจำนวนมากไปกับมัน แต่เมื่อเทียบกับ Flutter แล้ว แม้แต่ React Native ก็ดูเหมือนเป็นระบบนิเวศที่มั่นคงและน่าประทับใจมาก

จะเลือกอะไรดี

หัวของคุณอาจจะหมุนอยู่แล้ว แต่คุณก็ยังไม่รู้ว่าจะเลือกอะไร เรามาแสดงรายการคำถามง่ายๆ เพื่อช่วยคุณ:

• มันควรจะทำงานบนอุปกรณ์ใด ๆ ได้หรือไม่? เลือก HTMLเป็นพื้นฐาน;
• คุณมีเงินทุนเพียงพอ ไม่รีบร้อน และต้องการแอปพลิเคชันคุณภาพสูงสุดหรือไม่? คุณมีเส้นทางตรงไปที่ การพัฒนาพื้นเมือง;
• คุณมีนักพัฒนาเว็บแบบ "ในตัว" หรือคุณเพียงต้องการลองใช้แอปพลิเคชันบนมือถืออย่างรวดเร็วและง่ายดายหรือไม่? ที่นี่เราสามารถแนะนำได้ Cordova/HTML หรือ PWA;
• คุณมีระบบ CRM ของคุณเองและมีนักพัฒนา C# คอยสนับสนุนหรือไม่ เอามัน ซามาริน;
• คุณ "อยากลอง" แต่คุณต้องทำให้ทุกอย่างสวยงามและทันสมัยใช่ไหม? มองออกไป ตอบสนองพื้นเมืองหรือกระพือ.

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

• แอพนามบัตรธรรมดาเหรอ? เอา ตอบสนอง Native หรือ HTML5และคุณจะได้รับสองแพลตฟอร์มในราคาที่ต่ำที่สุด
• คุณมีเว็บไซต์ที่มีการเข้าชมสูงและต้องทดสอบสถานะของคุณในพื้นที่มือถือหรือไม่? HTML5;
• แอพพลิเคชั่นที่ซับซ้อนพร้อมการเข้าถึงฟังก์ชั่นอุปกรณ์ที่ต้องการ? การพัฒนาแบบเนทีฟ, Xamarin, React Native.

การพัฒนาข้ามแพลตฟอร์มไม่ใช่ยาครอบจักรวาล

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

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