ตั้งแต่วันที่ 27 มีนาคม 2025 เป็นต้นไป เราขอแนะนำให้ใช้ android-latest-release
แทน aosp-main
เพื่อสร้างและมีส่วนร่วมใน AOSP โปรดดูข้อมูลเพิ่มเติมที่หัวข้อการเปลี่ยนแปลงใน AOSP
โหมดระงับ
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
สถานะพลังงานของ SoC
สถานะพลังงานของระบบวงจรรวมบนชิป (SoC) มีดังนี้ เปิด ไม่ได้ใช้งาน และหยุดทำงานชั่วคราว "เปิด" หมายถึง SoC ทำงานอยู่ "ไม่ได้ใช้งาน" คือโหมดพลังงานปานกลางที่ SoC เปิดอยู่แต่ไม่ทำงานใดๆ "หยุดชั่วคราว" คือโหมดพลังงานต่ำที่ SoC ไม่ได้เปิดเครื่อง โดยทั่วไปแล้ว การใช้พลังงานของอุปกรณ์ในโหมดนี้จะน้อยกว่าในโหมด "เปิด" 100 เท่า
เซ็นเซอร์ที่ไม่ปลุกระบบ
เซ็นเซอร์ที่ไม่ปลุกคือเซ็นเซอร์ที่ไม่ป้องกันไม่ให้ SoC เข้าสู่โหมดสลีปและไม่ปลุก SoC ให้รายงานข้อมูล โดยเฉพาะอย่างยิ่ง ไม่อนุญาตให้ไดรเวอร์ใช้การล็อกการปลุก แอปพลิเคชันมีหน้าที่รับผิดชอบในการใช้ Wake Lock บางส่วนหากต้องการรับเหตุการณ์จากเซ็นเซอร์ที่ไม่ปลุกขณะที่หน้าจอปิดอยู่ ขณะที่ SoC อยู่ในโหมดระงับ เซ็นเซอร์ต้องทำงานและสร้างเหตุการณ์ต่อไป ซึ่งจะใส่ไว้ใน FIFO ของฮาร์ดแวร์ (ดูรายละเอียดเพิ่มเติมได้ที่การรวม) ระบบจะส่งเหตุการณ์ใน FIFO ไปยังแอปพลิเคชันเมื่อ SoC ตื่นขึ้น หาก FIFO มีขนาดเล็กเกินกว่าที่จะจัดเก็บเหตุการณ์ทั้งหมดได้ ระบบจะลบเหตุการณ์เก่าๆ ออกเพื่อรองรับข้อมูลล่าสุด ในกรณีที่ร้ายแรงที่สุดซึ่งไม่มี FIFO เหตุการณ์ทั้งหมดที่สร้างขึ้นขณะที่ SoC อยู่ในโหมดระงับจะหายไป ข้อยกเว้นอย่างหนึ่งคือเหตุการณ์ล่าสุดจากเซ็นเซอร์การเปลี่ยนแปลงแต่ละตัว: เหตุการณ์ล่าสุดต้องได้รับการบันทึก นอก FIFO เพื่อไม่ให้สูญหาย
ทันทีที่ SoC ออกจากโหมดระงับ ระบบจะรายงานเหตุการณ์ทั้งหมดจาก FIFO และการดำเนินการจะกลับมาทำงานตามปกติ
แอปพลิเคชันที่ใช้เซ็นเซอร์ที่ไม่ปลุกระบบควรใช้การล็อกการปลุกเพื่อให้ระบบไม่เข้าสู่โหมดพัก ยกเลิกการลงทะเบียนจากเซ็นเซอร์เมื่อไม่ต้องการ หรือคาดว่าจะสูญเสียเหตุการณ์ขณะที่ SoC อยู่ในโหมดพัก
เซ็นเซอร์การปลุก
เซ็นเซอร์ปลุกจะส่งข้อมูลโดยไม่ขึ้นอยู่กับสถานะของ SoC ซึ่งต่างจากเซ็นเซอร์ที่ไม่ปลุก เมื่อ SoC ทำงานอยู่ เซ็นเซอร์ปลุกจะทํางานเหมือนเซ็นเซอร์ที่ไม่ปลุก เมื่อ SoC อยู่ในโหมดสลีป เซ็นเซอร์ปลุกจะต้องปลุก SoC เพื่อส่งเหตุการณ์ อุปกรณ์เหล่านี้ยังคงต้องปล่อยให้ SoC เข้าสู่โหมดสลีป แต่ต้องปลุก SoC ขึ้นเมื่อต้องรายงานเหตุการณ์ด้วย กล่าวคือ เซ็นเซอร์ต้องปลุก SoC และส่งเหตุการณ์ก่อนที่จะเกิดเวลาในการตอบสนองสูงสุดในการรายงานหรือ FIFO ของฮาร์ดแวร์เต็ม
ดูรายละเอียดเพิ่มเติมเกี่ยวกับการรวม
เพื่อให้แอปพลิเคชันมีเวลารับเหตุการณ์ก่อนที่ SoC จะเข้าสู่โหมดสลีปอีกครั้ง โปรแกรมควบคุมจะต้อง "ปลุกด้วยการกำหนดเวลาหมดอายุ" เป็นเวลา 200 มิลลิวินาทีทุกครั้งที่มีการรายงานเหตุการณ์ กล่าวคือ SoC ไม่ควรกลับไปอยู่ในโหมดสลีปภายใน 200 มิลลิวินาทีหลังจากการขัดจังหวะการปลุก ข้อกำหนดนี้จะหายไปใน Android เวอร์ชันในอนาคต และเราต้องใช้การล็อกการปลุกตามกำหนดเวลานี้จนกว่าจะถึงเวลานั้น
วิธีกำหนดเซ็นเซอร์ที่ปลุกและเซ็นเซอร์ที่ไม่ปลุก
จนถึง KitKat เซ็นเซอร์จะเป็นผู้กำหนดว่าเซ็นเซอร์เป็นเซ็นเซอร์ที่ปลุกหรือไม่ใช่เซ็นเซอร์ที่ปลุก โดยส่วนใหญ่จะเป็นเซ็นเซอร์ที่ไม่ใช่เซ็นเซอร์ที่ปลุก ยกเว้นเซ็นเซอร์พร็อกซิมิตีและเครื่องตรวจจับการเคลื่อนไหวที่สำคัญ
ตั้งแต่ L เป็นต้นไป เซ็นเซอร์หนึ่งๆ จะเป็นเซ็นเซอร์ปลุกหรือไม่นั้นจะมีการระบุด้วย Flag ในคำจำกัดความของเซ็นเซอร์ เซ็นเซอร์ส่วนใหญ่จะกำหนดได้ด้วยคู่ของตัวแปรที่ตื่นขึ้นและไม่ตื่นขึ้นของเซ็นเซอร์เดียวกัน ซึ่งในกรณีนี้ เซ็นเซอร์ต้องทํางานเหมือนเซ็นเซอร์ 2 ตัวที่แยกกันโดยไม่มีการโต้ตอบกัน ดูรายละเอียดเพิ่มเติมได้ที่การโต้ตอบ
เราขอแนะนำให้ติดตั้งเซ็นเซอร์ที่ปลุก 1 ตัวและเซ็นเซอร์ที่ไม่ปลุก 1 ตัวสำหรับเซ็นเซอร์แต่ละประเภทที่ระบุไว้ในประเภทเซ็นเซอร์ เว้นแต่จะระบุไว้เป็นอย่างอื่นในคำจำกัดความประเภทเซ็นเซอร์ ในคำจำกัดความของเซ็นเซอร์แต่ละประเภท ให้ดูว่าSensorManager.getDefaultSensor(sensorType)
จะแสดงเซ็นเซอร์ประเภทใด (เซ็นเซอร์ที่ปลุกหรือไม่ได้ปลุก) ซึ่งเป็นเซ็นเซอร์ที่แอปพลิเคชันส่วนใหญ่จะใช้
ตัวอย่างเนื้อหาและโค้ดในหน้าเว็บนี้ขึ้นอยู่กับใบอนุญาตที่อธิบายไว้ในใบอนุญาตการใช้เนื้อหา Java และ OpenJDK เป็นเครื่องหมายการค้าหรือเครื่องหมายการค้าจดทะเบียนของ Oracle และ/หรือบริษัทในเครือ
อัปเดตล่าสุด 2025-07-27 UTC
[[["เข้าใจง่าย","easyToUnderstand","thumb-up"],["แก้ปัญหาของฉันได้","solvedMyProblem","thumb-up"],["อื่นๆ","otherUp","thumb-up"]],[["ไม่มีข้อมูลที่ฉันต้องการ","missingTheInformationINeed","thumb-down"],["ซับซ้อนเกินไป/มีหลายขั้นตอนมากเกินไป","tooComplicatedTooManySteps","thumb-down"],["ล้าสมัย","outOfDate","thumb-down"],["ปัญหาเกี่ยวกับการแปล","translationIssue","thumb-down"],["ตัวอย่าง/ปัญหาเกี่ยวกับโค้ด","samplesCodeIssue","thumb-down"],["อื่นๆ","otherDown","thumb-down"]],["อัปเดตล่าสุด 2025-07-27 UTC"],[],[],null,["# Suspend mode\n\nSoC power states\n----------------\n\nThe power states of the system on a chip (SoC) are: on, idle, and suspend. \"On\" is when the\nSoC is running. \"Idle\" is a medium power mode where the SoC is powered but\ndoesn't perform any tasks. \"Suspend\" is a low-power mode where the SoC is not\npowered. The power consumption of the device in this mode is usually 100 times\nless than in the \"On\" mode.\n\nNon-wake-up sensors\n-------------------\n\nNon-wake-up sensors are sensors that do not prevent the SoC\nfrom going into suspend mode and do not wake the SoC up to report data. In\nparticular, the drivers are not allowed to hold wake-locks. It is the\nresponsibility of applications to keep a partial wake lock should they wish to\nreceive events from non-wake-up sensors while the screen is off. While the SoC\nis in suspend mode, the sensors must continue to function and generate events,\nwhich are put in a hardware FIFO. (See [Batching](/docs/core/interaction/sensors/batching) for more details.) The events in the\nFIFO are delivered to the applications when the SoC wakes up. If the FIFO is\ntoo small to store all events, the older events are lost; the oldest data is dropped to accommodate\nthe latest data. In the extreme case where the FIFO is nonexistent, all events\ngenerated while the SoC is in suspend mode are lost. One exception is the\nlatest event from each on-change sensor: the last event [must be saved](/docs/core/interaction/sensors/batching#precautions_to_take_when_batching_non-wake-up_on-change_sensors)outside of the FIFO so it cannot be lost.\n\nAs soon as the SoC gets out of suspend mode, all events from the FIFO are\nreported and operations resume as normal.\n\nApplications using non-wake-up sensors should either hold a wake lock to ensure\nthe system doesn't go to suspend, unregister from the sensors when they do\nnot need them, or expect to lose events while the SoC is in suspend mode.\n\nWake-up sensors\n---------------\n\nIn opposition to non-wake-up sensors, wake-up sensors ensure that their data is\ndelivered independently of the state of the SoC. While the SoC is awake, the\nwake-up sensors behave like non-wake-up-sensors. When the SoC is asleep,\nwake-up sensors must wake up the SoC to deliver events. They must still let the\nSoC go into suspend mode, but must also wake it up when an event needs to be\nreported. That is, the sensor must wake the SoC up and deliver the events\nbefore the maximum reporting latency has elapsed or the hardware FIFO gets full.\nSee [Batching](/docs/core/interaction/sensors/batching) for more details.\n\nTo ensure the applications have the time to receive the event before the SoC\ngoes back to sleep, the driver must hold a \"timeout wake lock\" for 200\nmilliseconds each time an event is being reported. *That is, the SoC should not\nbe allowed to go back to sleep in the 200 milliseconds following a wake-up\ninterrupt.* This requirement will disappear in a future Android release, and we\nneed this timeout wake lock until then.\n\nHow to define wake-up and non-wake-up sensors?\n----------------------------------------------\n\nUp to KitKat, whether a sensor was a wake-up or a non-wake-up sensor was\ndictated by the sensor type: most were non-wake-up sensors, with the exception\nof the [proximity](/docs/core/interaction/sensors/sensor-types#proximity) sensor and the [significant motion detector](/docs/core/interaction/sensors/sensor-types#significant_motion).\n\nStarting in L, whether a given sensor is a wake-up sensor or not is specified\nby a flag in the sensor definition. Most sensors can be defined by pairs of\nwake-up and non-wake-up variants of the same sensor, in which case they must\nbehave as two independent sensors, not interacting with one another. See\n[Interaction](/docs/core/interaction/sensors/interaction) for more details.\n\nUnless specified otherwise in the sensor type definition, it is recommended to\nimplement one wake-up sensor and one non-wake-up sensor for each sensor type\nlisted in [Sensor types](/docs/core/interaction/sensors/sensor-types). In each sensor type\ndefinition, see what sensor (wake-up or non-wake-up) will be returned by\n`SensorManager.getDefaultSensor(sensorType)`. It is the sensor\nthat most applications will use."]]