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

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

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

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

รูปแบบของอุปกรณ์ที่หลากหลาย

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

ข้อจำกัดของทรัพยากร

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

เงื่อนไขการเปิดตัวที่เปลี่ยนแปลงได้

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

หลักการสถาปัตยกรรมที่พบบ่อย

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

เมื่อแอป 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 ที่แสดงข้อมูลแอปพลิเคชันบนหน้าจอ
  • Data Layer ที่มีตรรกะทางธุรกิจของแอปและแสดงข้อมูลแอปพลิเคชัน

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

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

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

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

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

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

เลเยอร์ UI

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

เลเยอร์ UI ประกอบด้วย 2 สิ่งต่อไปนี้

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

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

ชั้นข้อมูล

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

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

ในสถาปัตยกรรมทั่วไป ที่เก็บของเลเยอร์ข้อมูลจะให้ข้อมูล แก่ส่วนอื่นๆ ของแอปและขึ้นอยู่กับแหล่งข้อมูล
รูปที่ 3 บทบาทของชั้นข้อมูลในสถาปัตยกรรมแอป

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

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

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

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

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

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

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

เมื่อรวมเลเยอร์โดเมนที่ไม่บังคับไว้ เลเยอร์นี้จะระบุการอ้างอิงไปยัง เลเยอร์ UI และขึ้นอยู่กับเลเยอร์ข้อมูล
รูปที่ 4 บทบาทของเลเยอร์โดเมนในสถาปัตยกรรมแอป

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

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

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

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

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

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

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

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

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

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

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

ลดการอ้างอิงคลาส Android

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

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

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

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

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

มุ่งเน้นที่แกนหลักที่เป็นเอกลักษณ์ของแอปเพื่อให้แอปโดดเด่นจากแอปอื่นๆ

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

ใช้เลย์เอาต์มาตรฐานและรูปแบบการออกแบบแอป

ไลบรารี Jetpack Compose มี API ที่มีประสิทธิภาพสำหรับการสร้างอินเทอร์เฟซผู้ใช้ที่ปรับเปลี่ยนตามอุปกรณ์ ใช้เลย์เอาต์มาตรฐานในแอปเพื่อ ปรับปรุงประสบการณ์ของผู้ใช้ในอุปกรณ์รูปแบบต่างๆ และขนาดการแสดงผลที่หลากหลาย ดูแกลเลอรีรูปแบบการออกแบบแอปเพื่อเลือกเลย์เอาต์ ที่เหมาะกับ Use Case ของคุณมากที่สุด

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

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

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

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

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

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

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

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

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

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

ตัวอย่าง

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