คู่มือสถาปัตยกรรมแอป

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

คู่มือนี้ครอบคลุมแนวทางปฏิบัติแนะนำและสถาปัตยกรรมที่แนะนำสำหรับการสร้างแอปที่มีประสิทธิภาพและมีคุณภาพสูง

ประสบการณ์ของผู้ใช้แอปบนอุปกรณ์เคลื่อนที่

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

โปรดทราบว่าอุปกรณ์เคลื่อนที่ยังมีทรัพยากรจํากัดด้วย ดังนั้นระบบปฏิบัติการอาจหยุดกระบวนการของแอปบางรายการเพื่อเพิ่มพื้นที่ให้กับกระบวนการใหม่ได้ทุกเมื่อ

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

หลักการทั่วไปเกี่ยวกับสถาปัตยกรรม

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

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

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

การแยกข้อกังวล

หลักการที่สําคัญที่สุดที่ควรปฏิบัติตามคือการแยกข้อกังวล ข้อผิดพลาดที่พบบ่อยคือการเขียนโค้ดทั้งหมดใน Activity หรือ Fragment คลาสที่อิงตาม UI เหล่านี้ควรมีเฉพาะตรรกะที่จัดการการโต้ตอบระหว่าง UI กับระบบปฏิบัติการเท่านั้น การทำคลาสเหล่านี้ให้เรียบง่ายที่สุดเท่าที่จะทำได้จะช่วยหลีกเลี่ยงปัญหาต่างๆ เกี่ยวกับวงจรชีวิตของคอมโพเนนต์ และปรับปรุงความสามารถในการทดสอบของคลาสเหล่านี้

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

สร้าง UI ของไดรฟ์จากโมเดลข้อมูล

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

รูปแบบถาวรเหมาะสําหรับเหตุผลต่อไปนี้

• ผู้ใช้จะไม่สูญเสียข้อมูลหากระบบปฏิบัติการ Android ทำลายแอปของคุณเพื่อเพิ่มพื้นที่เก็บข้อมูล

• แอปจะยังคงทำงานต่อไปได้ในกรณีที่การเชื่อมต่อเครือข่ายไม่เสถียรหรือไม่พร้อมใช้งาน

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

แหล่งข้อมูลที่เชื่อถือได้เพียงแหล่งเดียว

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

รูปแบบนี้มีประโยชน์หลายประการ ดังนี้

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

ในแอปพลิเคชันแบบออฟไลน์ก่อน แหล่งข้อมูลสําหรับข้อมูลแอปพลิเคชันมักจะเป็นฐานข้อมูล ในบางกรณี แหล่งที่มาของข้อมูลที่เป็นความจริงอาจเป็น ViewModel หรือแม้แต่ UI

โฟลว์ข้อมูลแบบทิศทางเดียว

เรามักใช้หลักการแหล่งข้อมูลที่ถูกต้องแห่งเดียวในคู่มือที่มีรูปแบบการไหลของข้อมูลแบบทิศทางเดียว (UDF) ใน UDF state จะไหลไปในทิศทางเดียวเท่านั้น เหตุการณ์ที่แก้ไขการไหลของข้อมูลในทิศทางตรงกันข้าม

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

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

สถาปัตยกรรมแอปที่แนะนำ

ส่วนนี้จะสาธิตวิธีจัดโครงสร้างแอปตามแนวทางปฏิบัติแนะนำ

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

• เลเยอร์ UI ที่แสดงข้อมูลแอปพลิเคชันบนหน้าจอ
• เลเยอร์ข้อมูลที่มีตรรกะทางธุรกิจของแอปและแสดงข้อมูลแอปพลิเคชัน

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

สถาปัตยกรรมแอปสมัยใหม่

สถาปัตยกรรมแอปสมัยใหม่นี้สนับสนุนให้ใช้เทคนิคต่อไปนี้และอื่นๆ

• สถาปัตยกรรมแบบตอบสนองและแบบเป็นชั้น
• การรับส่งข้อมูลแบบทิศทางเดียว (UDF) ในเลเยอร์ทั้งหมดของแอป
• เลเยอร์ UI ที่มีตัวเก็บสถานะเพื่อจัดการความซับซ้อนของ UI
• Coroutine และ Flow
• แนวทางปฏิบัติแนะนำเกี่ยวกับการนําเข้าพึ่งพา

ดูข้อมูลเพิ่มเติมได้ที่ส่วนต่อไปนี้ หน้าสถาปัตยกรรมอื่นๆ ในสารบัญ และหน้าคำแนะนำที่มีสรุปแนวทางปฏิบัติแนะนำที่สําคัญที่สุด

เลเยอร์ UI

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

เลเยอร์ UI ประกอบด้วย 2 ส่วน ได้แก่

• องค์ประกอบ UI ที่แสดงผลข้อมูลบนหน้าจอ คุณสร้างองค์ประกอบเหล่านี้ได้โดยใช้ฟังก์ชัน View หรือ Jetpack Compose
• ตัวเก็บสถานะ (เช่น คลาส ViewModel) ที่เก็บข้อมูล แสดงข้อมูลต่อ UI และจัดการตรรกะ

ดูข้อมูลเพิ่มเติมเกี่ยวกับเลเยอร์นี้ได้ที่หน้าเลเยอร์ UI

ชั้นข้อมูล

ชั้นข้อมูลของแอปมีตรรกะทางธุรกิจ ตรรกะทางธุรกิจคือสิ่งที่ให้คุณค่าแก่แอปของคุณ ซึ่งประกอบด้วยกฎที่กําหนดวิธีที่แอปสร้าง จัดเก็บ และเปลี่ยนแปลงข้อมูล

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

คลาสที่เก็บมีหน้าที่รับผิดชอบงานต่อไปนี้

• การเปิดเผยข้อมูลแก่ส่วนที่เหลือของแอป
• เปลี่ยนข้อมูลไว้ในที่เดียว
• การแก้ไขความขัดแย้งระหว่างแหล่งข้อมูลหลายแห่ง
• การแยกแหล่งที่มาของข้อมูลจากส่วนอื่นๆ ของแอป
• มีตรรกะทางธุรกิจ

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

ดูข้อมูลเพิ่มเติมเกี่ยวกับเลเยอร์นี้ได้ที่หน้าชั้นข้อมูล

เลเยอร์โดเมน

ชั้นโดเมนเป็นเลเยอร์ที่ไม่บังคับซึ่งอยู่ตรงกลางระหว่าง UI กับชั้นข้อมูล

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

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

ดูข้อมูลเพิ่มเติมเกี่ยวกับเลเยอร์นี้ได้ที่หน้าเลเยอร์โดเมน

จัดการการพึ่งพาระหว่างคอมโพเนนต์

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

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

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

เราขอแนะนำให้ทำตามรูปแบบการฉีด Dependency และการใช้คลัง Hilt ในแอป Android Hilt จะสร้างออบเจ็กต์โดยอัตโนมัติด้วยการเรียกใช้ผ่านลําดับชั้นของ Dependency ให้การรับประกันเกี่ยวกับ Dependency ในเวลาคอมไพล์ และสร้างคอนเทนเนอร์ Dependency สําหรับคลาสเฟรมเวิร์ก Android

แนวทางปฏิบัติแนะนำโดยทั่วไป

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

แม้ว่าคำแนะนำต่อไปนี้จะไม่บังคับ แต่ในกรณีส่วนใหญ่ การทำตามคำแนะนำเหล่านี้จะทำให้ฐานโค้ดมีความเสถียร ทดสอบได้ และดูแลรักษาได้ในระยะยาว

อย่าจัดเก็บข้อมูลไว้ในคอมโพเนนต์แอป

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

ลดการพึ่งพาคลาส Android

คอมโพเนนต์ของแอปควรเป็นคลาสเดียวที่ใช้ API ของเฟรมเวิร์ก Android SDK เช่น Context หรือ Toast การแยกคลาสอื่นๆ ในแอปออกจากคลาสเหล่านี้จะช่วยในการทดสอบและลดการเชื่อมโยงภายในแอป

กำหนดขอบเขตความรับผิดชอบที่ชัดเจนระหว่างโมดูลต่างๆ ในแอป

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

เปิดเผยข้อมูลจากแต่ละโมดูลให้น้อยที่สุด

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

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

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

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

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

ประเภทมีหน้าที่รับผิดชอบต่อนโยบายการทำงานพร้อมกัน

หากประเภทหนึ่งทํางานแบบบล็อกที่ใช้เวลานาน ก็ควรรับผิดชอบในการย้ายการประมวลผลนั้นไปยังเธรดที่เหมาะสม ประเภทนั้นๆ จะทราบประเภทการคํานวณที่ทําอยู่และควรเรียกใช้เธรดใด ประเภทควรเป็นแบบปลอดภัยสำหรับหลัก ซึ่งหมายความว่าสามารถเรียกใช้จากเธรดหลักได้โดยไม่บล็อก

เก็บข้อมูลที่เกี่ยวข้องและเป็นปัจจุบันไว้มากที่สุด

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

ประโยชน์ของสถาปัตยกรรม

การใช้สถาปัตยกรรมที่ดีในแอปจะมีประโยชน์มากมายต่อทีมโครงการและทีมวิศวกร ดังนี้

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

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

ตัวอย่าง

ตัวอย่างต่อไปนี้จาก Google แสดงสถาปัตยกรรมแอปที่ดี โปรดดูตัวอย่างการใช้งานคำแนะนำนี้

แนะนำสำหรับคุณ

ชั้นข้อมูล

Discover the latest app development tools, platform updates, training, and documentation for developers across every Android device.

อัปเดตแล้ว Aug 23, 2024

เลเยอร์ UI

Discover the latest app development tools, platform updates, training, and documentation for developers across every Android device.

อัปเดตแล้ว Aug 23, 2024

เหตุการณ์ UI

Discover the latest app development tools, platform updates, training, and documentation for developers across every Android device.

อัปเดตแล้ว Aug 23, 2024