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

ทำไม API ที่คุยมากทำให้มือถือหมดแบต

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

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

ยังมีงาน CPU ด้วย ทุกคำขอหมายถึงการสร้างเฮดเดอร์ ทำงาน TLS แยกวิเคราะห์ JSON อัปเดตแคช และรันโค้ดแอพเพื่อรวมผล ถ้าการเชื่อมต่อหลุด งานเตรียมการจะทำซ้ำอีกครั้ง

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

แนวคิดปฏิบัติสำหรับ การออกแบบ API เพื่อลดการใช้แบตในมือถือ คือ: แสดง UI เดิมด้วยรอบทริปที่น้อยลง ไบต์ที่น้อยลง และงานเบื้องหลังที่น้อยลง

คุณสามารถติดตามความสำเร็จด้วยการเปลี่ยนแปลงที่จับต้องได้ไม่กี่อย่าง:

• คำขอต่อการโหลดหน้าจอน้อยลง
• ไบต์ที่ดาวน์โหลดต่อหน้าจอน้อยลง
• ค่าเฉลี่ยและกรณีแย่ของเวลาไปสู่การโต้ตอบสั้นลงบนเครือข่ายเซลลูลาร์
• การรีเฟรชเบื้องหลังและรีไทรน้อยลงเพื่อผลลัพธ์เดียวกัน

เมื่อค่านี้ดีขึ้น ความตอบสนองและอายุแบตเตอรี่มักจะดีพร้อมกัน

ควรวัดอะไรบ้างก่อนเปลี่ยนแปลง

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

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

แยกการจราจรด้านหน้า (foreground) ออกจากเบื้องหลัง หน้าจออาจดูเงียบ แต่โทรศัพท์อาจยุ่งกับการรีเฟรชเบื้องหลัง การซิงก์จาก push การอัปโหลด analytics หรือการ prefetch แบบ “กันไว้ก่อน” แยกสิ่งเหล่านี้เพื่อไม่ให้คุณไปปรับจูนผิดจุด

จุดร้อนมักรวมตัวกันรอบช่วงสำคัญ: การเปิดแอพ หน้าหลัก/ฟีด หน้ารายละเอียดที่แตกเป็นหลายคำขอ และการดึงเพื่อรีเฟรช เลือกหนึ่งหน้าและวัดแบบ end-to-end

ตั้งงบฐาน (baseline budget) เพื่อให้ทีมตกลงกันได้ว่า “ดี” คืออะไร เช่น: “การโหลดแบบเย็นของหน้าติดตามคำสั่งไม่ควรมีคำขอเกิน 6 ครั้งและดาวน์โหลดไม่เกิน 250 KB ก่อนแสดงสถานะ”

ถ้าต้องการ KPI คู่เรียบง่ายเริ่มด้วย (1) คำขอต่อการโหลดหน้าจอ และ (2) อัตรารีไทร การลดรีไทรบ่อยครั้งประหยัดแบตได้มากกว่าที่คาด เพราะการรีไทรซ้ำทำให้วิทยุตื่นนานขึ้น

ทีละขั้นตอน: ลดคำขอด้วยการรวมคำขอ (batching)

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

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

จากนั้นรวมคำขอที่เกิดขึ้นพร้อมกันอย่างสม่ำเสมอ โดยทั่วไปมีสองทางเลือก:

• สร้าง endpoint แบบเฉพาะหน้าจอนั้น (มักเสถียรที่สุด)
• เพิ่ม endpoint แบบ batch ที่รับรายการทรัพยากรเล็กๆ ที่คาดเดาได้

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

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

เฮดเดอร์แคชที่ช่วยประหยัดแบต (ไม่ใช่แค่แบนด์วิดท์)

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

ชัยชนะใหญ่คือการขอแบบมีเงื่อนไข แทนที่จะดาวน์โหลดข้อมูลซ้ำ ไคลเอนต์ถามว่า “อันนี้เปลี่ยนไหม?” ถ้าไม่ เซิร์ฟเวอร์ตอบด้วย 304 Not Modified ขนาดเล็ก

ใช้ ETag บนการตอบที่เป็นเวอร์ชันของทรัพยากร และให้ไคลเอนต์ส่ง If-None-Match ในการดึงครั้งถัดไป หากการสร้าง ETag ยาก Last-Modified กับ If-Modified-Since ก็ทำงานได้ดีสำหรับทรัพยากรแบบมี "อัพเดตที่" ง่ายๆ

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

ฝั่งแอพ ให้ปฏิบัติต่อ 304 เป็นเส้นทางด่วน อย่าแยกวิเคราะห์ JSON (เพราะไม่มี) อย่าสร้างโมเดลใหม่ และอย่าสะท้อน UI ให้กระพริบ เก็บสิ่งที่อยู่บนหน้าจอไว้แล้วอัปเดตแค่ตัวบ่งชี้

ตัวอย่าง: หน้าติดตามคำสั่งโพลสถานะทุก 15 วินาที ถ้าการตอบกลับมี ETag การตรวจสอบส่วนใหญ่จะได้ 304 แอพเก็บสถานะล่าสุดไว้และทำงานจริงเมื่อสถานะเปลี่ยน (เช่น จาก “Packed” เป็น “Shipped”)

ให้ตั้งใจเรื่องข้อมูลอ่อนไหว การแคชไม่ใช่สิ่งที่ไม่ปลอดภัยเสมอไป แต่ต้องมีกฎชัดเจน หลีกเลี่ยงการแคชการตอบที่มีรายละเอียดส่วนบุคคลหรือโทเค็น เว้นแต่ความต้องการของผลิตภัณฑ์จะอนุญาต ใช้อายุสั้นสำหรับข้อมูลเฉพาะผู้ใช้ และป้องกันแคชที่แชร์จากการเก็บการตอบที่เป็นส่วนตัว (ใช้ Cache-Control: private เมื่อจำเป็น)

Payload ที่ชาญฉลาดขึ้น: ส่งน้อยกว่า แยกวิเคราะห์น้อยกว่า

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

เริ่มจากการตรวจ payload ต่อหน้าจอ เลือกหน้าจอหนึ่ง (เช่น ฟีดหน้าแรก) บันทึกขนาดการตอบกลับ และดูทีละฟิลด์: ไคลเอนต์เรนเดอร์อันนี้ไหม หรือใช้เพื่อการตัดสินใจแสดงไหม ถ้าไม่ ให้เอาออกจาก endpoint นั้น

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

การเปลี่ยนแปลงไม่กี่ข้อสามารถตัด payload ได้เร็ว:

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

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

ปฏิบัติต่อรูปแบบการตอบกลับเหมือนสัญญา เมื่อชื่อฟิลด์และชนิดคงที่ แอพต้องมี fallback น้อยลงและโค้ดป้องกันตัวน้อยลง ซึ่งช่วยให้ UI ลื่นและใช้แบตน้อยลง

ออกแบบให้เครือข่ายไม่ดีและรีไทรน้อยลง

แอพมือถือไม่ได้เผาผลาญแบตเฉพาะตอนส่งคำขอเท่านั้น แต่มันยังเผาเมื่อเกิดความล้มเหลว รีไทร ปลุกวิทยุอีกครั้ง และทำงานซ้ำ ถ้า API สมมติ Wi‑Fi ที่สมบูรณ์ ผู้ใช้จริงบน 4G ที่ไม่เสถียรจะจ่ายค่าดังกล่าว

ทำให้ง่ายต่อการขอข้อมูลให้น้อยลง ชอบตัวกรองฝั่งเซิร์ฟเวอร์และการแบ่งหน้า (pagination) แทนที่จะ “ดาวน์โหลดทุกอย่างแล้วกรองบนโทรศัพท์” ถ้าหน้าจอต้องการเหตุการณ์ล่าสุด 20 รายการสำหรับผู้ใช้หนึ่งคน ให้รองรับคิวรีนั้นโดยตรงเพื่อไม่ให้แอพดึงหลายร้อยแถวมาแล้วทิ้งส่วนใหญ่

รองรับ delta sync เพื่อให้ไคลเอนต์ถามว่า “อะไรเปลี่ยนตั้งแต่ครั้งสุดท้ายที่ฉันเช็ก” ซึ่งอาจง่ายเท่าการส่ง timestamp หรือหมายเลขเวอร์ชันที่เพิ่มขึ้น แล้วให้ไคลเอนต์ขออัปเดตและการลบเฉพาะตั้งแต่จุดนั้น

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

เมื่อเกิดรีไทร ให้หลีกเลี่ยง retry storms ใช้ exponential backoff พร้อม jitter เพื่อไม่ให้เครื่องนับพันชนกันเข้าเซิร์ฟเวอร์พร้อมกัน และเพื่อไม่ให้โทรศัพท์ตื่นทุกวินาที

ส่งรหัสข้อผิดพลาดที่ชัดเจนเพื่อช่วยให้แอพตัดสินใจได้ 401 ควรกระตุ้นการยืนยันตัวตนใหม่, 404 มักหยุดการรีไทร, 409 อาจต้องรีเฟรชสถานะ, และ 429 หรือ 503 ควรกระตุ้น backoff

พฤติกรรมไคลเอนต์ที่เพิ่มต้นทุน API ทวีคูณ

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

แคชข้อมูลที่เปลี่ยนไม่บ่อย รูปโปรไฟล์ ฟีเจอร์แฟลก และข้อมูลอ้างอิง (ประเทศ, สถานะ, หมวดหมู่) ไม่ควรถูกดึงทุกครั้งที่เข้าชม ให้มีอายุที่เหมาะ สม บันทึกลงดิสก์ และรีเฟรชเฉพาะเมื่อจำเป็น ถ้า API รองรับการตรวจสอบ (ETag หรือ Last-Modified) การเช็กอย่างรวดเร็วมักถูกกว่าการดาวน์โหลดใหม่ทั้งหมด

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

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

ถ้าคุณสร้าง backend ด้วย AppMaster จะง่ายขึ้นในการรองรับพฤติกรรมไคลเอนต์เหล่านี้โดยการออกแบบ endpoints ตามหน้าจอ รักษา schema การตอบกลับให้คงที่ และเพิ่มเฮดเดอร์การแคชอย่างมีการควบคุมเพื่อให้ไคลเอนต์นิ่งไว้ส่วนใหญ่ของเวลา