การออกแบบ API เพื่อแบตมือถือ: ลดการคุยมากเกินไป

ทำไม API ที่คุยมากทำให้มือถือหมดแบต\n\nAPI ที่ “คุยมาก” ทำให้แอพส่งคำขอเล็กๆ จำนวนมากเพื่อประกอบหน้าจอหนึ่งหน้า แม้แต่ละคำขอดูเหมือนจะไม่แพง แต่บนโทรศัพท์มันสะสมเร็ว\n\nผลกระทบหลักต่อแบตเตอรี่มักมาจากชิปวิทยุเครือข่าย ชิปเซลลูลาร์และ Wi‑Fi จะสลับไปยังสถานะกำลังไฟสูงเพื่อส่งและรับข้อมูล เมื่อแอพส่งคำขอหลายครั้งติดต่อกัน วิทยุจะถูกปลุกบ่อยขึ้นและอยู่ในสถานะใช้งานนานขึ้น ถึงแม้แต่ละการตอบกลับจะเล็ก การปลุกซ้ำๆ ก็ใช้พลังงานจริง\n\nยังมีงาน CPU ด้วย ทุกคำขอหมายถึงการสร้างเฮดเดอร์ ทำงาน TLS แยกวิเคราะห์ JSON อัปเดตแคช และรันโค้ดแอพเพื่อรวมผล ถ้าการเชื่อมต่อหลุด งานเตรียมการจะทำซ้ำอีกครั้ง\n\nการคุยมากยังทำให้ UI รู้สึกช้าลง แทนที่จะเป็นการโหลดที่คาดเดาได้ หน้าจอรอการเรียกหลายทอด คุณจะเห็นสปินเนอร์นานขึ้น การเรนเดอร์เป็นขั้นเป็นตอนที่กระโดดไปมา และเวลาไทม์เอาต์ยาวขึ้นเมื่อเครือข่ายอ่อน การรีเฟรชเบื้องหลังเลวร้ายลงในทางเดียวกัน: รีไทรมากขึ้น การปลุกมากขึ้น และแบตที่ลดลง\n\nแนวคิดปฏิบัติสำหรับ การออกแบบ API เพื่อลดการใช้แบตในมือถือ คือ: แสดง UI เดิมด้วยรอบทริปที่น้อยลง ไบต์ที่น้อยลง และงานเบื้องหลังที่น้อยลง\n\nคุณสามารถติดตามความสำเร็จด้วยการเปลี่ยนแปลงที่จับต้องได้ไม่กี่อย่าง:\n\n- คำขอต่อการโหลดหน้าจอน้อยลง\n- ไบต์ที่ดาวน์โหลดต่อหน้าจอน้อยลง\n- ค่าเฉลี่ยและกรณีแย่ของเวลาไปสู่การโต้ตอบสั้นลงบนเครือข่ายเซลลูลาร์\n- การรีเฟรชเบื้องหลังและรีไทรน้อยลงเพื่อผลลัพธ์เดียวกัน\n\nเมื่อค่านี้ดีขึ้น ความตอบสนองและอายุแบตเตอรี่มักจะดีพร้อมกัน\n\n## ควรวัดอะไรบ้างก่อนเปลี่ยนแปลง\n\nก่อนรวมคำขอหรือปรับเฮดเดอร์แคช ให้ได้ภาพชัดเจนว่าแอพทำอะไรวันนี้ ชัยชนะที่ได้เร็วที่สุดมักมาจากการแก้ offenders ซ้ำๆ ไม่กี่รายการ แต่คุณจะเจอมันได้ก็ต่อเมื่อวัดบนหน้าจอและฟลูว์จริง (ไม่ใช่แค่การทดสอบเส้นทางที่ปกติ)\n\nสำหรับหน้าจอที่มีทราฟฟิกสูงไม่กี่หน้า บันทึกพื้นฐาน: มีคำขอกี่ครั้งต่อการโหลด, เอนด์พอยต์ใดถูกเรียก, ไบต์ที่ส่งและรับ (เฮดเดอร์บวกบอดี), อัตรารีไทรและไทม์เอาต์, และใช้เวลานานเท่าไรจนหน้า UI รู้สึกใช้งานได้ ถ้าได้ ให้แยกอัตราข้อผิดพลาดตามประเภทเครือข่าย (Wi‑Fi เทียบกับเซลลูลาร์) การแยกแบบนี้มักเผยปัญหาที่คุณจะมองข้ามบนการเชื่อมต่อที่เสถียร\n\nแยกการจราจรด้านหน้า (foreground) ออกจากเบื้องหลัง หน้าจออาจดูเงียบ แต่โทรศัพท์อาจยุ่งกับการรีเฟรชเบื้องหลัง การซิงก์จาก push การอัปโหลด analytics หรือการ prefetch แบบ “กันไว้ก่อน” แยกสิ่งเหล่านี้เพื่อไม่ให้คุณไปปรับจูนผิดจุด\n\nจุดร้อนมักรวมตัวกันรอบช่วงสำคัญ: การเปิดแอพ หน้าหลัก/ฟีด หน้ารายละเอียดที่แตกเป็นหลายคำขอ และการดึงเพื่อรีเฟรช เลือกหนึ่งหน้าและวัดแบบ end-to-end\n\nตั้งงบฐาน (baseline budget) เพื่อให้ทีมตกลงกันได้ว่า “ดี” คืออะไร เช่น: “การโหลดแบบเย็นของหน้าติดตามคำสั่งไม่ควรมีคำขอเกิน 6 ครั้งและดาวน์โหลดไม่เกิน 250 KB ก่อนแสดงสถานะ”\n\nถ้าต้องการ KPI คู่เรียบง่ายเริ่มด้วย (1) คำขอต่อการโหลดหน้าจอ และ (2) อัตรารีไทร การลดรีไทรบ่อยครั้งประหยัดแบตได้มากกว่าที่คาด เพราะการรีไทรซ้ำทำให้วิทยุตื่นนานขึ้น\n\n## ทีละขั้นตอน: ลดคำขอด้วยการรวมคำขอ (batching)\n\nAPI ที่คุยมากเกิดขึ้นได้ง่ายโดยไม่ได้ตั้งใจ วิดเจ็ตแต่ละชิ้นโหลด “ข้อมูลของมัน” และหน้าจอหนึ่งกระตุ้นคำขอเล็กๆ หลายรายการ การแก้มักไม่ซับซ้อน: หาว่าสิ่งใดโหลดพร้อมกันเสมอและส่งกลับในคำขอที่น้อยลง\n\nเริ่มจากการทำแผนที่หน้าจอที่มีทราฟฟิกสูงหนึ่งหน้า (หน้าแรก, กล่องข้อความ, รายการคำสั่ง) เขียนสิ่งที่ปรากฏเหนือพับ แล้วไล่ตามแต่ละองค์ประกอบ UI ว่ามาจากคำขอใด คุณมักจะพบการเรียกซ้ำ (เช่น โปรไฟล์ผู้ใช้ที่ดึงสองครั้ง) และคำขอที่มักไปด้วยกัน (โปรไฟล์ + สิทธิ์ + จำนวนที่ยังไม่ได้อ่าน)\n\nจากนั้นรวมคำขอที่เกิดขึ้นพร้อมกันอย่างสม่ำเสมอ โดยทั่วไปมีสองทางเลือก:\n\n- สร้าง endpoint แบบเฉพาะหน้าจอนั้น (มักเสถียรที่สุด)\n- เพิ่ม endpoint แบบ batch ที่รับรายการทรัพยากรเล็กๆ ที่คาดเดาได้\n\nให้เก็บ batch ให้เป็นไปตามหน้าจอและมีขอบเขตชัดเจนเพื่อให้ง่ายต่อการแคช ตรวจสอบ และดีบัก\n\nกฎบางข้อช่วยไม่ให้การรวมคำขอกลายเป็นความยุ่งเหยิง คืนเฉพาะสิ่งที่หน้าจอต้องการตอนนี้ ไม่ใช่วัตถุเต็มรูปแบบ “เผื่อไว้” ถ้าบางชิ้นเป็นตัวเลือก ให้ทำให้ชัดเจนเพื่อที่ UI จะเรนเดอร์ส่วนสำคัญได้เร็ว นอกจากนี้ ออกแบบการตอบกลับให้ความล้มเหลวบางส่วนไม่บังคับให้รีไทรทั้งชุด ถูกกว่ามากที่จะรีไทรเฉพาะชิ้นที่ล้มเหลว มากกว่าการส่งทั้ง batch ใหม่ทั้งก้อน\n\n## เฮดเดอร์แคชที่ช่วยประหยัดแบต (ไม่ใช่แค่แบนด์วิดท์)\n\nการแคชคือฟีเจอร์ด้านแบต ทุกคำขอปลุกวิทยุ ทำให้ CPU ทำงาน และกระตุ้นการแยกวิเคราะห์และตรรกะในแอพ เฮดเดอร์แคชที่ดีจะเปลี่ยนการรีเฟรชหลายครั้งให้เป็นการตรวจสอบน้ำหนักเบา\n\nชัยชนะใหญ่คือการขอแบบมีเงื่อนไข แทนที่จะดาวน์โหลดข้อมูลซ้ำ ไคลเอนต์ถามว่า “อันนี้เปลี่ยนไหม?” ถ้าไม่ เซิร์ฟเวอร์ตอบด้วย 304 Not Modified ขนาดเล็ก\n\nใช้ ETag บนการตอบที่เป็นเวอร์ชันของทรัพยากร และให้ไคลเอนต์ส่ง If-None-Match ในการดึงครั้งถัดไป หากการสร้าง ETag ยาก Last-Modified กับ If-Modified-Since ก็ทำงานได้ดีสำหรับทรัพยากรแบบมี "อัพเดตที่" ง่ายๆ\n\nสำหรับข้อมูลที่เปลี่ยนไม่บ่อย ให้ตัดสินใจเรื่องแคชอย่างชัดเจน Cache-Control ควรสะท้อนความเป็นจริง max-age สั้นสำหรับโปรไฟล์ผู้ใช้อาจโอเค ในขณะที่ config ของแอพ รายการอ้างอิง และฟีเจอร์แฟลกมักจะยาวกว่าได้\n\nฝั่งแอพ ให้ปฏิบัติต่อ 304 เป็นเส้นทางด่วน อย่าแยกวิเคราะห์ JSON (เพราะไม่มี) อย่าสร้างโมเดลใหม่ และอย่าสะท้อน UI ให้กระพริบ เก็บสิ่งที่อยู่บนหน้าจอไว้แล้วอัปเดตแค่ตัวบ่งชี้\n\nตัวอย่าง: หน้าติดตามคำสั่งโพลสถานะทุก 15 วินาที ถ้าการตอบกลับมี ETag การตรวจสอบส่วนใหญ่จะได้ 304 แอพเก็บสถานะล่าสุดไว้และทำงานจริงเมื่อสถานะเปลี่ยน (เช่น จาก “Packed” เป็น “Shipped”)\n\nให้ตั้งใจเรื่องข้อมูลอ่อนไหว การแคชไม่ใช่สิ่งที่ไม่ปลอดภัยเสมอไป แต่ต้องมีกฎชัดเจน หลีกเลี่ยงการแคชการตอบที่มีรายละเอียดส่วนบุคคลหรือโทเค็น เว้นแต่ความต้องการของผลิตภัณฑ์จะอนุญาต ใช้อายุสั้นสำหรับข้อมูลเฉพาะผู้ใช้ และป้องกันแคชที่แชร์จากการเก็บการตอบที่เป็นส่วนตัว (ใช้ Cache-Control: private เมื่อจำเป็น)\n\n## Payload ที่ชาญฉลาดขึ้น: ส่งน้อยกว่า แยกวิเคราะห์น้อยกว่า\n\nทุกไบต์เพิ่มต้นทุนมากกว่าค่าแบนด์วิดท์บนมือถือ มันทำให้วิทยุตื่นนานขึ้นและทำให้แอพใช้ CPU ในการถอดรหัส JSON และอัปเดตโมเดล ถ้าคุณพยายาม ลดการคุยของ API ตัด payload มักเป็นชัยชนะที่เร็วที่สุด\n\nเริ่มจากการตรวจ payload ต่อหน้าจอ เลือกหน้าจอหนึ่ง (เช่น ฟีดหน้าแรก) บันทึกขนาดการตอบกลับ และดูทีละฟิลด์: ไคลเอนต์เรนเดอร์อันนี้ไหม หรือใช้เพื่อการตัดสินใจแสดงไหม ถ้าไม่ ให้เอาออกจาก endpoint นั้น\n\nสำหรับรายการ รูปร่าง “สรุป” เล็กๆ มักเพียงพอ แถวรายการมักต้องการ id, ชื่อ, สถานะ และ timestamp มันไม่ต้องการคำอธิบายเต็ม หรืออ็อบเจ็กต์ที่มีเนสติ้งลึก โหลดรายละเอียดเมื่อผู้ใช้เปิดไอเท็ม\n\nการเปลี่ยนแปลงไม่กี่ข้อสามารถตัด payload ได้เร็ว:\n\n- ใช้ id หรือโค้ด enum สั้นๆ แทนสตริงยาวที่ซ้ำกัน\n- อย่าส่งค่าเริ่มต้นที่ชัดเจนซึ่งไคลเอนต์สามารถสมมติได้\n- หลีกเลี่ยงการทำซ้ำอ็อบเจ็กต์เนสเต็ดในแต่ละรายการของลิสต์\n- รักษาชื่อฟิลด์และชนิดให้คงที่เพื่อที่ไคลเอนต์จะไม่ต้องเปลี่ยนทางและแยกวิเคราะห์ใหม่\n\nการบีบอัดช่วยได้ โดยเฉพาะบนเครือข่ายช้า แต่ทดสอบต้นทุน CPU บนอุปกรณ์จริง Gzip หรือ Brotli มักจะลดขนาดการส่งได้มาก แต่โทรศัพท์เก่าบางรุ่นอาจใช้เวลาถอดรหัสจนชัดเจน ชัยชนะที่ดีที่สุดยังคงเป็นการส่งข้อมูลให้น้อยตั้งแต่ต้น\n\nปฏิบัติต่อรูปแบบการตอบกลับเหมือนสัญญา เมื่อชื่อฟิลด์และชนิดคงที่ แอพต้องมี fallback น้อยลงและโค้ดป้องกันตัวน้อยลง ซึ่งช่วยให้ UI ลื่นและใช้แบตน้อยลง\n\n## ออกแบบให้เครือข่ายไม่ดีและรีไทรน้อยลง\n\nแอพมือถือไม่ได้เผาผลาญแบตเฉพาะตอนส่งคำขอเท่านั้น แต่มันยังเผาเมื่อเกิดความล้มเหลว รีไทร ปลุกวิทยุอีกครั้ง และทำงานซ้ำ ถ้า API สมมติ Wi‑Fi ที่สมบูรณ์ ผู้ใช้จริงบน 4G ที่ไม่เสถียรจะจ่ายค่าดังกล่าว\n\nทำให้ง่ายต่อการขอข้อมูลให้น้อยลง ชอบตัวกรองฝั่งเซิร์ฟเวอร์และการแบ่งหน้า (pagination) แทนที่จะ “ดาวน์โหลดทุกอย่างแล้วกรองบนโทรศัพท์” ถ้าหน้าจอต้องการเหตุการณ์ล่าสุด 20 รายการสำหรับผู้ใช้หนึ่งคน ให้รองรับคิวรีนั้นโดยตรงเพื่อไม่ให้แอพดึงหลายร้อยแถวมาแล้วทิ้งส่วนใหญ่\n\nรองรับ delta sync เพื่อให้ไคลเอนต์ถามว่า “อะไรเปลี่ยนตั้งแต่ครั้งสุดท้ายที่ฉันเช็ก” ซึ่งอาจง่ายเท่าการส่ง timestamp หรือหมายเลขเวอร์ชันที่เพิ่มขึ้น แล้วให้ไคลเอนต์ขออัปเดตและการลบเฉพาะตั้งแต่จุดนั้น\n\nการรีไทรเป็นสิ่งหลีกเลี่ยงไม่ได้ ดังนั้นทำให้การอัพเดตเป็น idempotent รีไทรไม่ควรเรียกเก็บซ้ำ ส่งซ้ำ หรือสร้างรายการซ้ำ คีย์ idempotency สำหรับการสร้างและการอัพเดตที่ตั้งค่ารัฐแทนการ "เพิ่มทีละหนึ่ง" ช่วยได้มาก\n\nเมื่อเกิดรีไทร ให้หลีกเลี่ยง retry storms ใช้ exponential backoff พร้อม jitter เพื่อไม่ให้เครื่องนับพันชนกันเข้าเซิร์ฟเวอร์พร้อมกัน และเพื่อไม่ให้โทรศัพท์ตื่นทุกวินาที\n\nส่งรหัสข้อผิดพลาดที่ชัดเจนเพื่อช่วยให้แอพตัดสินใจได้ 401 ควรกระตุ้นการยืนยันตัวตนใหม่, 404 มักหยุดการรีไทร, 409 อาจต้องรีเฟรชสถานะ, และ 429 หรือ 503 ควรกระตุ้น backoff\n\n## พฤติกรรมไคลเอนต์ที่เพิ่มต้นทุน API ทวีคูณ\n\nแม้จะมี API ที่ออกแบบดี ไคลเอนต์ก็อาจคูณงานเครือข่ายอย่างเงียบๆ บนมือถือ การปลุกซ้ำและระยะเวลาวิทยุเปิดบ่อยครั้งเหล่านี้มักจะใช้แบตกว่าไบต์เอง\n\nแคชข้อมูลที่เปลี่ยนไม่บ่อย รูปโปรไฟล์ ฟีเจอร์แฟลก และข้อมูลอ้างอิง (ประเทศ, สถานะ, หมวดหมู่) ไม่ควรถูกดึงทุกครั้งที่เข้าชม ให้มีอายุที่เหมาะ สม บันทึกลงดิสก์ และรีเฟรชเฉพาะเมื่อจำเป็น ถ้า API รองรับการตรวจสอบ (ETag หรือ Last-Modified) การเช็กอย่างรวดเร็วมักถูกกว่าการดาวน์โหลดใหม่ทั้งหมด\n\nปัญหาทั่วไปอีกอย่างคือคำขอซ้อนระหว่างการเดินทางในสถานะเดียวกัน สองส่วนของแอพขอทรัพยากรเดียวกันพร้อมกัน (เช่น เฮดเดอร์กับหน้าการตั้งค่าต่างขอกโปรไฟล์) หากไม่รวมการร้องขอ คุณจะส่งสองคำขอ แยกวิเคราะห์สองครั้ง และอัปเดตสถานะสองครั้ง ปฏิบัติต่อการเรียกเครือข่ายหนึ่งครั้งเป็นแหล่งความจริงเดียวและให้ผู้บริโภคหลายคนรอผลเดียวกัน\n\nการรีเฟรชเบื้องหลังควรตั้งใจทำเท่านั้น ถ้ามันไม่เปลี่ยนสิ่งที่ผู้ใช้จะเห็นเร็วๆ นี้ หรือจะไม่กระตุ้นการแจ้งเตือน ปกติแล้วมันรอได้ หลีกเลี่ยงการรันตรรกะรีเฟรชทุกครั้งเมื่อแอพกลับมาทำงาน เพิ่ม cooldown สั้นๆ และเช็กเมื่อข้อมูลอัปเดตครั้งสุดท้าย\n\nถ้าคุณสร้าง backend ด้วย AppMaster จะง่ายขึ้นในการรองรับพฤติกรรมไคลเอนต์เหล่านี้โดยการออกแบบ endpoints ตามหน้าจอ รักษา schema การตอบกลับให้คงที่ และเพิ่มเฮดเดอร์การแคชอย่างมีการควบคุมเพื่อให้ไคลเอนต์นิ่งไว้ส่วนใหญ่ของเวลา