สถาปัตยกรรมของแอปเป็นรากฐานของแอปพลิเคชัน Android คุณภาพสูง สถาปัตยกรรมที่กำหนดไว้อย่างดีช่วยให้คุณสร้างแอปที่ปรับขนาดได้และบำรุงรักษาได้ ซึ่งปรับให้เข้ากับระบบนิเวศของอุปกรณ์ Android ที่ขยายตัวอย่างต่อเนื่องได้ ไม่ว่าจะเป็นโทรศัพท์, แท็บเล็ต, อุปกรณ์พับได้, อุปกรณ์ ChromeOS, จอแสดงผลในรถยนต์ และ XR
การจัดวางองค์ประกอบของแอป
โดยทั่วไปแล้ว แอป Android ประกอบด้วยคอมโพเนนต์ของแอปหลายรายการ เช่น บริการ ผู้ให้บริการเนื้อหา และตัวรับสัญญาณ การออกอากาศ คุณประกาศคอมโพเนนต์เหล่านี้ในไฟล์ Manifest ของแอป
อินเทอร์เฟซผู้ใช้ของแอปก็เป็นคอมโพเนนต์เช่นกัน ในอดีต UI สร้างขึ้นโดยใช้กิจกรรมหลายรายการ อย่างไรก็ตาม แอปสมัยใหม่ใช้
สถาปัตยกรรมแบบกิจกรรมเดียว Activity เดียวจะทำหน้าที่เป็นคอนเทนเนอร์สำหรับหน้าจอหรือปลายทาง Jetpack Compose
รูปแบบของอุปกรณ์ที่หลากหลาย
แอปสามารถทำงานได้ในอุปกรณ์หลายรูปแบบ ไม่ใช่แค่โทรศัพท์ แต่ยังรวมถึง แท็บเล็ต อุปกรณ์พับได้ อุปกรณ์ ChromeOS และอื่นๆ อย่าคิดไปเองว่าแอปจะอยู่ในแนวตั้งหรือแนวนอนเสมอ การเปลี่ยนแปลงการกำหนดค่า เช่น การหมุนอุปกรณ์ หรือการพับและกางอุปกรณ์แบบพับได้ จะบังคับให้แอป จัดองค์ประกอบ UI ใหม่ ซึ่งจะส่งผลต่อสถานะของแอป
ข้อจำกัดของทรัพยากร
อุปกรณ์เคลื่อนที่ (แม้จะเป็นอุปกรณ์ที่มีหน้าจอขนาดใหญ่) มีข้อจำกัดด้านทรัพยากร ดังนั้นระบบปฏิบัติการอาจหยุดกระบวนการของแอปได้ทุกเมื่อเพื่อจัดสรร ทรัพยากรให้กับกระบวนการอื่นๆ
เงื่อนไขการเปิดตัวที่เปลี่ยนแปลงได้
ในสภาพแวดล้อมที่มีข้อจำกัดด้านทรัพยากร คอมโพเนนต์ของแอปอาจ เปิดตัวแยกกันและไม่เป็นไปตามลำดับ นอกจากนี้ ระบบปฏิบัติการหรือ ผู้ใช้ยังทำลายคอมโพเนนต์ได้ทุกเมื่อ ดังนั้นจึงไม่ควรจัดเก็บข้อมูลหรือสถานะของแอปพลิเคชันไว้ในคอมโพเนนต์ของแอป ทำให้คอมโพเนนต์ของแอปมีข้อมูลครบถ้วนในตัวเอง โดยไม่ขึ้นต่อกัน
หลักการสถาปัตยกรรมที่พบบ่อย
หากใช้คอมโพเนนต์ของแอปเพื่อจัดเก็บข้อมูลและสถานะของแอปพลิเคชันไม่ได้ คุณควรออกแบบแอปอย่างไร
เมื่อแอป Android มีขนาดใหญ่ขึ้น การกำหนดสถาปัตยกรรมที่ ช่วยให้แอปปรับขนาดได้จึงเป็นสิ่งสำคัญ สถาปัตยกรรมแอปที่ออกแบบมาอย่างดีจะกำหนดขอบเขต ระหว่างส่วนต่างๆ ของแอปและหน้าที่รับผิดชอบของแต่ละส่วน
การแยกความกังวล
ออกแบบสถาปัตยกรรมของแอปให้เป็นไปตามหลักการที่เฉพาะเจาะจง 2-3 ข้อ
หลักการที่สำคัญที่สุดคือการแยกความกังวล การแยกแอปออกเป็นเมธอด คลาส ไฟล์ แพ็กเกจ โมดูล และเลเยอร์ ที่มีความรับผิดชอบและขอบเขตที่กำหนดไว้อย่างชัดเจน
ข้อผิดพลาดที่พบบ่อยคือการเขียนโค้ดทั้งหมดใน Activity
บทบาทหลักของ Activity คือการโฮสต์ UI ของแอป
ระบบปฏิบัติการ Android จะควบคุมวงจรของ Fragment โดยมักจะทำลายและสร้าง Fragment ใหม่
เพื่อตอบสนองต่อการกระทำของผู้ใช้ เช่น การหมุนหน้าจอ หรือเหตุการณ์ของระบบ เช่น หน่วยความจำเหลือน้อย
ลักษณะชั่วคราวนี้ทําให้ไม่เหมาะสําหรับการจัดเก็บข้อมูลหรือสถานะของแอปพลิเคชัน
หากคุณจัดเก็บข้อมูลใน Activity ข้อมูลนั้นจะหายไปเมื่อ
สร้างคอมโพเนนต์ขึ้นมาใหม่ อย่าฝากสถานะไว้กับคอมโพเนนต์ UI เหล่านี้เพื่อให้มั่นใจว่าข้อมูลจะยังคงอยู่และมอบประสบการณ์การใช้งานที่เสถียรให้แก่ผู้ใช้
เลย์เอาต์แบบปรับขนาดได้
สร้างแอปที่จัดการการเปลี่ยนแปลงการกำหนดค่าได้อย่างราบรื่น เช่น การเปลี่ยนแปลงการวางแนวของอุปกรณ์หรือการเปลี่ยนแปลงขนาดหน้าต่างแอป ใช้เลย์เอาต์มาตรฐานแบบปรับได้เพื่อมอบประสบการณ์การใช้งานที่ดีที่สุดในอุปกรณ์รูปแบบต่างๆ
ขับเคลื่อน UI จากโมเดลข้อมูล
หลักการสำคัญอีกอย่างคือการขับเคลื่อน UI จากโมเดลข้อมูล โดยควรใช้โมเดลที่คงอยู่ โมเดลข้อมูลแสดงถึงข้อมูลของแอป โดยจะ แยกจากองค์ประกอบ UI และคอมโพเนนต์อื่นๆ ในแอป ซึ่งหมายความว่า โมเดลข้อมูลจะไม่เชื่อมโยงกับวงจร UI และคอมโพเนนต์ของแอป แต่จะยังคง ถูกทำลายเมื่อระบบปฏิบัติการนำกระบวนการของแอปออกจากหน่วยความจำ
โมเดลแบบถาวรเหมาะสำหรับกรณีต่อไปนี้
ผู้ใช้จะไม่สูญเสียข้อมูลหากระบบปฏิบัติการ Android ทำลายแอปเพื่อเพิ่มพื้นที่ว่าง ให้กับทรัพยากร
แอปจะยังคงทำงานต่อไปในกรณีที่การเชื่อมต่อเครือข่าย ไม่สม่ำเสมอหรือใช้งานไม่ได้
สร้างสถาปัตยกรรมแอปตามคลาสโมเดลข้อมูลเพื่อให้แอปมีประสิทธิภาพและ ทดสอบได้
แหล่งข้อมูลที่เชื่อถือได้เพียงแหล่งเดียว
เมื่อกำหนดประเภทข้อมูลใหม่ในแอป ให้กำหนดแหล่งข้อมูลที่ถูกต้องแห่งเดียว (SSOT) ให้กับประเภทข้อมูลนั้น SSOT เป็นเจ้าของข้อมูลนั้น และมีเพียง SSOT เท่านั้นที่ แก้ไขหรือเปลี่ยนแปลงข้อมูลได้ SSOT จะแสดงข้อมูลโดยใช้ประเภทที่แก้ไขไม่ได้ เพื่อให้บรรลุเป้าหมายนี้ และเพื่อแก้ไขข้อมูล SSOT จะแสดงฟังก์ชันหรือรับเหตุการณ์ที่ประเภทอื่นๆ เรียกได้
รูปแบบนี้มีประโยชน์หลายประการ ดังนี้
- รวมการเปลี่ยนแปลงทั้งหมดของข้อมูลประเภทหนึ่งๆ ไว้ในที่เดียว
- ปกป้องข้อมูลเพื่อไม่ให้ข้อมูลประเภทอื่นแก้ไขได้
- ทำให้การเปลี่ยนแปลงข้อมูลติดตามได้ง่ายขึ้น จึงระบุข้อบกพร่องได้ง่ายขึ้น
ในแอปพลิเคชันที่ทำงานแบบออฟไลน์เป็นอันดับแรก แหล่งข้อมูลที่เชื่อถือได้สำหรับข้อมูลแอปพลิเคชันมักจะเป็นฐานข้อมูล ในกรณีอื่นๆ แหล่งข้อมูลที่เชื่อถือได้อาจเป็นViewModel
โฟลว์ข้อมูลแบบทิศทางเดียว
โดยมักจะใช้หลักการแหล่งข้อมูลที่ถูกต้องแห่งเดียว ร่วมกับรูปแบบการไหลของข้อมูลแบบทิศทางเดียว (UDF) ใน UDF state จะไหลไปในทิศทางเดียว โดยปกติจะไหลจากคอมโพเนนต์หลักไปยังคอมโพเนนต์ย่อย เหตุการณ์ ที่แก้ไขโฟลว์ข้อมูลในทิศทางตรงกันข้าม
ใน Android สถานะหรือข้อมูลมักจะไหลจากประเภทที่มีขอบเขตสูงกว่าใน ลำดับชั้นไปยังประเภทที่มีขอบเขตต่ำกว่า โดยปกติแล้ว ระบบจะทริกเกอร์เหตุการณ์จากประเภทที่มีขอบเขตต่ำกว่าจนกว่าจะถึง SSOT สำหรับประเภทข้อมูลที่เกี่ยวข้อง เช่น โดยปกติแล้วข้อมูลแอปพลิเคชันจะไหลจากแหล่งข้อมูลไปยัง UI เหตุการณ์ของผู้ใช้ เช่น การกดปุ่ม จะไหลจาก UI ไปยัง SSOT ซึ่งจะมีการแก้ไขข้อมูลแอปพลิเคชันและแสดงในประเภทที่ไม่เปลี่ยนแปลง
รูปแบบนี้ช่วยรักษาความสอดคล้องของข้อมูลได้ดีขึ้น มีแนวโน้มที่จะเกิดข้อผิดพลาดน้อยกว่า แก้ไขข้อบกพร่องได้ง่ายกว่า และให้ประโยชน์ทั้งหมดของรูปแบบ SSOT
ดูข้อมูลเพิ่มเติมเกี่ยวกับ UDF ได้ที่ โฟลว์ข้อมูลแบบทิศทางเดียวใน Jetpack Compose
สถาปัตยกรรมของแอปที่แนะนำ
เมื่อพิจารณาหลักการด้านสถาปัตยกรรมทั่วไป ให้ออกแบบแอปพลิเคชันแต่ละรายการโดยมีเลเยอร์อย่างน้อย 2 เลเยอร์ ดังนี้
- เลเยอร์ UI: แสดงข้อมูลแอปพลิเคชันบนหน้าจอ
- ชั้นข้อมูล: มีตรรกะทางธุรกิจของแอปและแสดงข้อมูลแอปพลิเคชัน
คุณสามารถเพิ่มเลเยอร์อีกชั้นหนึ่งที่เรียกว่าเลเยอร์โดเมนเพื่อลดความซับซ้อนและนำการโต้ตอบระหว่าง UI กับเลเยอร์ข้อมูลกลับมาใช้ใหม่
สถาปัตยกรรมแอปสมัยใหม่
สถาปัตยกรรมแอป Android สมัยใหม่ใช้เทคนิคต่อไปนี้ (รวมถึงเทคนิคอื่นๆ)
- สถาปัตยกรรมแบบปรับเปลี่ยนได้และแบบเลเยอร์
- การไหลของข้อมูลแบบทางเดียว (UDF) ในทุกเลเยอร์ของแอป
- เลเยอร์ UI ที่มีตัวยึดสถานะเพื่อจัดการความซับซ้อนของ UI
- โครูทีนและโฟลว์
- แนวทางปฏิบัติแนะนำสำหรับการแทรกทรัพยากร Dependency
ดูข้อมูลเพิ่มเติมได้ที่ คำแนะนำสำหรับสถาปัตยกรรม Android
เลเยอร์ UI
บทบาทของเลเยอร์ UI (หรือเลเยอร์การนำเสนอ) คือการแสดงข้อมูลแอปพลิเคชัน บนหน้าจอ เมื่อใดก็ตามที่ข้อมูลเปลี่ยนแปลง ไม่ว่าจะเป็นเนื่องจากการโต้ตอบของผู้ใช้ (เช่น การกดปุ่ม) หรืออินพุตภายนอก (เช่น การตอบกลับของเครือข่าย) UI จะอัปเดตเพื่อแสดงการเปลี่ยนแปลง
เลเยอร์ UI ประกอบด้วยโครงสร้าง 2 ประเภท ได้แก่
- องค์ประกอบ UI ที่แสดงข้อมูลบนหน้าจอ คุณสร้างองค์ประกอบเหล่านี้ โดยใช้ฟังก์ชัน Jetpack Compose เพื่อรองรับเลย์เอาต์แบบปรับอัตโนมัติ
- ตัวเก็บสถานะ (เช่น
ViewModel) ที่เก็บข้อมูล แสดงข้อมูลต่อ UI และจัดการตรรกะ ตัวเก็บสถานะควรมีอายุการใช้งานเท่ากับองค์ประกอบ UI ที่ตัวเก็บสถานะนั้นๆ ให้สถานะ ตัวอย่างเช่น ViewModel สำหรับ หน้าจอควรคงอยู่ในหน่วยความจำจนกว่าจะนำหน้าจอออกจาก Back Stack การนำทางย้อนกลับของแอป ดูข้อมูลเพิ่มเติมได้ที่อายุการใช้งานของสถานะ
สำหรับ UI แบบปรับเปลี่ยนได้ ตัวเก็บสถานะ เช่น ออบเจ็กต์ ViewModel จะแสดงสถานะ UI ที่ปรับให้เข้ากับคลาสขนาดหน้าต่างต่างๆ คุณใช้
currentWindowAdaptiveInfo() เพื่อสร้างสถานะ UI นี้ได้ จากนั้นคอมโพเนนต์ต่างๆ เช่น
NavigationSuiteScaffold จะใช้ข้อมูลนี้เพื่อสลับ
ระหว่างรูปแบบการนำทางต่างๆ (เช่น NavigationBar
NavigationRail หรือ NavigationDrawer) โดยอัตโนมัติตามพื้นที่หน้าจอที่มี
ดูข้อมูลเพิ่มเติมได้ที่เลเยอร์ UI และ สถาปัตยกรรม UI ของ Compose
ดูข้อมูลเพิ่มเติมเกี่ยวกับแอปและการนำทางแบบปรับอัตโนมัติได้ที่สร้างแอปแบบปรับอัตโนมัติและ สร้างการนำทางแบบปรับอัตโนมัติ
ชั้นข้อมูล
ชั้นข้อมูลของแอปมีตรรกะทางธุรกิจ ตรรกะทางธุรกิจคือสิ่งที่ สร้างคุณค่าให้กับแอปของคุณ ซึ่งประกอบด้วยกฎที่กำหนดวิธีที่แอป สร้าง จัดเก็บ และเปลี่ยนแปลงข้อมูล
เลเยอร์ข้อมูลประกอบด้วยที่เก็บ ซึ่งแต่ละที่เก็บอาจมีแหล่งข้อมูลตั้งแต่ 0 ถึงหลายแหล่ง สร้างคลาสที่เก็บสำหรับข้อมูลแต่ละประเภทที่คุณจัดการในแอป ตัวอย่างเช่น คุณอาจสร้างคลาส MoviesRepository สำหรับข้อมูลที่เกี่ยวข้องกับภาพยนตร์ หรือคลาส PaymentsRepository สำหรับข้อมูลที่เกี่ยวข้องกับการชำระเงิน
คลาสที่เก็บมีหน้าที่รับผิดชอบในเรื่องต่อไปนี้
- การเปิดเผยข้อมูลต่อส่วนอื่นๆ ของแอป
- รวมการเปลี่ยนแปลงข้อมูลไว้ในที่เดียว
- การแก้ไขความขัดแย้งระหว่างแหล่งข้อมูลหลายแหล่ง
- แยกแหล่งข้อมูลออกจากส่วนอื่นๆ ของแอป
- มีตรรกะทางธุรกิจ
คลาสแหล่งข้อมูลแต่ละคลาสมีหน้าที่รับผิดชอบในการทำงานกับแหล่งข้อมูลเพียงแหล่งเดียว ซึ่งอาจเป็นไฟล์ แหล่งข้อมูลเครือข่าย หรือฐานข้อมูลในเครื่อง คลาสแหล่งข้อมูลเป็นตัวเชื่อมระหว่างแอปพลิเคชันกับระบบสำหรับการดำเนินการข้อมูล
ดูข้อมูลเพิ่มเติมได้ที่หน้าชั้นข้อมูล
เลเยอร์โดเมน
เลเยอร์โดเมนเป็นเลเยอร์ที่ไม่บังคับระหว่างเลเยอร์ UI กับเลเยอร์ข้อมูล
เลเยอร์โดเมนมีหน้าที่ห่อหุ้มตรรกะทางธุรกิจที่ซับซ้อนหรือตรรกะทางธุรกิจที่ง่ายกว่าซึ่งโมเดลมุมมองหลายรายการนำกลับมาใช้ใหม่ เลเยอร์โดเมน ไม่บังคับ เนื่องจากแอปบางแอปไม่มีข้อกำหนดเหล่านี้ ใช้เฉพาะเมื่อจำเป็นเท่านั้น เช่น เพื่อจัดการความซับซ้อนหรือเพื่อความสามารถในการนำกลับมาใช้ใหม่
โดยทั่วไปแล้ว คลาสในเลเยอร์โดเมนเรียกว่า Use Case หรือ Interactor
แต่ละกรณีการใช้งานมีหน้าที่รับผิดชอบฟังก์ชันเดียว ตัวอย่างเช่น แอปของคุณอาจมีGetTimeZoneUseCaseคลาสหาก View Model หลายรายการต้องอาศัยเขตเวลาเพื่อแสดงข้อความที่เหมาะสมบนหน้าจอ
ดูข้อมูลเพิ่มเติมได้ที่หน้าเลเยอร์โดเมน
จัดการการขึ้นต่อกันระหว่างคอมโพเนนต์
คลาสในแอปของคุณต้องอาศัยคลาสอื่นๆ เพื่อให้ทำงานได้อย่างถูกต้อง คุณใช้รูปแบบการออกแบบต่อไปนี้เพื่อรวบรวมทรัพยากร Dependency ของคลาสหนึ่งๆ ได้
- การแทรกทรัพยากร Dependency (DI): การแทรกทรัพยากร Dependency ช่วยให้คลาสกำหนดทรัพยากร Dependency ได้โดยไม่ต้องสร้างทรัพยากร Dependency ในเวลาเรียกใช้ คลาสอื่นมีหน้าที่จัดเตรียมทรัพยากร Dependency เหล่านี้
- ตัวระบุตำแหน่งบริการ: รูปแบบตัวระบุตำแหน่งบริการมีรีจิสทรีที่คลาสสามารถรับทรัพยากร Dependency แทนการสร้างได้
รูปแบบเหล่านี้ช่วยให้คุณปรับขนาดโค้ดได้เนื่องจากมีรูปแบบที่ชัดเจน สำหรับการจัดการการอ้างอิงโดยไม่ต้องทำซ้ำโค้ดหรือเพิ่มความซับซ้อน รูปแบบยังช่วยให้คุณสลับไปมาระหว่างการติดตั้งใช้งานเวอร์ชันทดสอบและเวอร์ชันที่ใช้งานจริงได้อย่างรวดเร็ว
แนวทางปฏิบัติแนะนำโดยทั่วไป
การเขียนโปรแกรมเป็นสาขาที่ต้องใช้ความคิดสร้างสรรค์ และการสร้างแอป Android ก็เช่นกัน การแก้ปัญหามีหลายวิธี คุณอาจสื่อสารข้อมูลระหว่าง กิจกรรมหรือ Fragment หลายรายการ ดึงข้อมูลจากระยะไกลและจัดเก็บไว้ในเครื่อง สำหรับโหมดออฟไลน์ หรือจัดการสถานการณ์ทั่วไปอื่นๆ ที่แอปที่ซับซ้อน ต้องเจอ
แม้ว่าคำแนะนำต่อไปนี้จะไม่บังคับ แต่ในกรณีส่วนใหญ่ การทำตามคำแนะนำจะช่วยให้ฐานของโค้ดมีความแข็งแกร่ง ทดสอบได้ และบำรุงรักษาได้มากขึ้น
อย่าจัดเก็บข้อมูลในคอมโพเนนต์ของแอป
หลีกเลี่ยงการกำหนดจุดแรกเข้าของแอป เช่น กิจกรรม บริการ และ Broadcast Receiver เป็นแหล่งข้อมูล สร้างจุดแรกเข้า ให้สอดคล้องกับคอมโพเนนต์อื่นๆ เพื่อดึงข้อมูลชุดย่อยที่ เกี่ยวข้องกับจุดแรกเข้านั้นเท่านั้น คอมโพเนนต์ของแอปแต่ละรายการจะมีอายุสั้น ขึ้นอยู่กับการโต้ตอบของผู้ใช้กับอุปกรณ์และความจุของระบบ
ลดการขึ้นอยู่กับคลาส Android
ทำให้คอมโพเนนต์ของแอปเป็นคลาสเดียวที่ใช้ API ของ Android Framework SDK เช่น Context หรือ Toast การแยกคลาสอื่นๆ ในแอปออกจากคอมโพเนนต์ของแอปจะช่วยให้ทดสอบได้ง่ายขึ้นและลดการเชื่อมโยงภายในแอป
กำหนดขอบเขตความรับผิดชอบที่ชัดเจนระหว่างโมดูลในแอป
อย่ากระจายโค้ดที่โหลดข้อมูลจากเครือข่ายไปยังหลายๆ คลาส หรือแพ็กเกจในโค้ดเบส ในทำนองเดียวกัน อย่ากำหนดความรับผิดชอบหลายอย่างที่ไม่เกี่ยวข้อง เช่น การแคชข้อมูลและการเชื่อมโยงข้อมูล ในคลาสเดียวกัน ทำตามสถาปัตยกรรมแอปที่แนะนำ
เปิดเผยข้อมูลจากแต่ละโมดูลให้น้อยที่สุด
อย่าสร้างทางลัดที่เปิดเผยรายละเอียดการใช้งานภายใน คุณอาจประหยัดเวลาได้เล็กน้อยในระยะสั้น แต่มีแนวโน้มที่จะก่อให้เกิดหนี้ทางเทคนิคหลายครั้งเมื่อโค้ดเบสมีการพัฒนา
มุ่งเน้นที่แกนหลักที่เป็นเอกลักษณ์ของแอปเพื่อให้แอปโดดเด่นจากแอปอื่นๆ
อย่าเสียเวลาเขียนโค้ด Boilerplate เดิมซ้ำแล้วซ้ำเล่า แต่ให้ใช้เวลาและพลังงานไปกับสิ่งที่ทำให้แอปของคุณโดดเด่นแทน ให้ไลบรารี Jetpack และไลบรารีอื่นๆ ที่แนะนำจัดการบอยเลอร์เพลตที่ซ้ำซ้อน
ใช้เลย์เอาต์มาตรฐานและรูปแบบการออกแบบแอป
ไลบรารี Jetpack Compose มี API ที่มีประสิทธิภาพสำหรับการสร้างอินเทอร์เฟซผู้ใช้ที่ปรับเปลี่ยนได้ ใช้เลย์เอาต์มาตรฐานในแอปเพื่อ เพิ่มประสิทธิภาพประสบการณ์ของผู้ใช้ในอุปกรณ์หลากหลายรูปแบบและขนาดการแสดงผล ดูแกลเลอรีรูปแบบการออกแบบแอปเพื่อเลือกเลย์เอาต์ที่เหมาะกับกรณีการใช้งานของคุณมากที่สุด
คงสถานะ UI ไว้เมื่อมีการเปลี่ยนแปลงการกำหนดค่า
เมื่อออกแบบเลย์เอาต์ที่ปรับเปลี่ยนตามสถานการณ์ ให้รักษาสถานะ UI ไว้เมื่อมีการเปลี่ยนแปลงการกำหนดค่า เช่น การปรับขนาดจอแสดงผล การพับ และการเปลี่ยนการวางแนว สถาปัตยกรรมของคุณควรยืนยันว่าระบบจะรักษาสถานะปัจจุบันของผู้ใช้ไว้ เพื่อให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่ราบรื่น
ออกแบบคอมโพเนนต์ UI ที่นำกลับมาใช้ใหม่และประกอบกันได้
สร้างคอมโพเนนต์ UI ที่นำกลับมาใช้ใหม่และประกอบกันได้เพื่อรองรับการออกแบบที่ปรับเปลี่ยนได้ ซึ่งช่วยให้คุณรวมและจัดเรียงคอมโพเนนต์ใหม่ให้เหมาะกับขนาดหน้าจอและ ท่าทางต่างๆ ได้โดยไม่ต้องปรับโครงสร้างใหม่มากนัก
พิจารณาวิธีทำให้แต่ละส่วนของแอปทดสอบได้แยกกัน
API ที่กำหนดไว้อย่างดีสำหรับการดึงข้อมูลจากเครือข่ายจะช่วยให้การทดสอบโมดูลที่จัดเก็บข้อมูลนั้นไว้ในฐานข้อมูลในเครื่องเป็นไปได้ง่าย ในทางกลับกัน หากคุณรวมตรรกะจากฟังก์ชันทั้ง 2 นี้ไว้ในที่เดียว หรือกระจายโค้ดเครือข่ายไปทั่วทั้งโค้ดเบส การทดสอบจะยากขึ้นมาก หรืออาจเป็นไปไม่ได้เลย
ประเภทมีหน้าที่รับผิดชอบต่อนโยบายการทำงานพร้อมกัน
หากประเภทใดกำลังทำงานที่บล็อกเป็นเวลานาน ประเภทนั้นควร รับผิดชอบในการย้ายการคำนวณดังกล่าวไปยังเธรดที่เหมาะสม โดยประเภทจะทราบ ชนิดของการคำนวณที่กำลังทำอยู่และเทรดที่จะเรียกใช้การคำนวณ ประเภทควรเป็น main-safe ซึ่งหมายความว่าเรียกใช้จากเทรดหลักได้อย่างปลอดภัยโดยไม่บล็อก
เก็บข้อมูลที่เกี่ยวข้องและเป็นปัจจุบันให้ได้มากที่สุด
ด้วยวิธีนี้ ผู้ใช้จะเพลิดเพลินกับฟังก์ชันการทำงานของแอปได้แม้ว่าอุปกรณ์จะอยู่ในโหมดออฟไลน์ก็ตาม โปรดทราบว่าผู้ใช้บางรายอาจไม่ได้เชื่อมต่ออินเทอร์เน็ตความเร็วสูงตลอดเวลา และแม้ว่าจะเชื่อมต่อได้ แต่ก็อาจรับสัญญาณได้ไม่ดี ในสถานที่ที่มีผู้คนหนาแน่น
สิทธิประโยชน์ของสถาปัตยกรรม
การใช้สถาปัตยกรรมที่ดีในแอปจะช่วยให้ทีมวิศวกรรมและทีมโปรเจ็กต์ได้รับประโยชน์มากมาย ดังนี้
- ปรับปรุงความสามารถในการบำรุงรักษา คุณภาพ และความแข็งแกร่งของแอปโดยรวม
- ช่วยให้แอปปรับขนาดได้ ผู้คนและทีมจำนวนมากขึ้นสามารถมีส่วนร่วมในฐานของโค้ดเดียวกันโดยมีข้อขัดแย้งของโค้ดน้อยที่สุด
- ช่วยในการเริ่มต้นใช้งาน เนื่องจากสถาปัตยกรรมช่วยให้โปรเจ็กต์มีความสอดคล้องกัน สมาชิกใหม่ในทีมจึงสามารถเรียนรู้ได้อย่างรวดเร็วและทำงานได้อย่างมีประสิทธิภาพมากขึ้นใน เวลาที่น้อยลง
- ทดสอบได้ง่ายขึ้น สถาปัตยกรรมที่ดีจะสนับสนุนประเภทที่เรียบง่ายกว่า ซึ่งโดยทั่วไปแล้วจะทดสอบได้ง่ายกว่า
- ช่วยให้คุณตรวจสอบข้อบกพร่องอย่างเป็นระบบด้วยกระบวนการที่กำหนดไว้อย่างดี
แม้ว่าสถาปัตยกรรมที่ดีจะต้องใช้เวลาในการลงทุนตั้งแต่แรกเริ่ม แต่ก็ส่งผลโดยตรงต่อผู้ใช้ด้วย ผู้ใช้จะได้รับประโยชน์จากแอปพลิเคชันที่เสถียรมากขึ้นและฟีเจอร์ที่มากขึ้นเนื่องจากทีมวิศวกรทำงานได้อย่างมีประสิทธิภาพมากขึ้น
ตัวอย่าง
ตัวอย่างต่อไปนี้แสดงสถาปัตยกรรมแอปที่ดี