ตั้งแต่วันที่ 27 มีนาคม 2025 เป็นต้นไป เราขอแนะนำให้ใช้ android-latest-release แทน aosp-main เพื่อสร้างและมีส่วนร่วมใน AOSP โปรดดูข้อมูลเพิ่มเติมที่หัวข้อการเปลี่ยนแปลงใน AOSP
โหมดการรายงาน
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
เซ็นเซอร์สามารถสร้างเหตุการณ์ได้หลายวิธีที่เรียกว่าโหมดการรายงาน โดยเซ็นเซอร์แต่ละประเภทจะมีโหมดการรายงานที่เชื่อมโยงอยู่เพียงโหมดเดียว
โหมดการรายงานมี 4 โหมด
ต่อเนื่อง
ระบบจะสร้างเหตุการณ์ในอัตราคงที่ที่กําหนดโดยพารามิเตอร์ sampling_period_ns ที่ส่งไปยังฟังก์ชัน batch ตัวอย่างเซ็นเซอร์ที่ใช้โหมดการรายงานแบบต่อเนื่อง ได้แก่ ตัวตรวจวัดความเร่งและเครื่องวัดการหมุน
เมื่อเปลี่ยนแปลง
ระบบจะสร้างเหตุการณ์ก็ต่อเมื่อค่าที่วัดได้เปลี่ยนแปลงเท่านั้น
การเปิดใช้งานเซ็นเซอร์ที่ระดับ HAL (การเรียกใช้ activate(..., enable=1)) จะทริกเกอร์เหตุการณ์ด้วย ซึ่งหมายความว่า HAL ต้องแสดงผลเหตุการณ์ทันทีเมื่อมีการเปิดใช้งานเซ็นเซอร์แบบการเปลี่ยนแปลง ตัวอย่างเซ็นเซอร์ที่ใช้โหมดการรายงานเมื่อมีการเปลี่ยนแปลง ได้แก่ เซ็นเซอร์นับก้าว เซ็นเซอร์ตรวจหาบุคคลในบริเวณใกล้เคียง และเซ็นเซอร์วัดอัตราการเต้นของหัวใจ
พารามิเตอร์ sampling_period_ns ที่ส่งไปยังฟังก์ชัน batch ใช้เพื่อตั้งค่าเวลาขั้นต่ำระหว่างเหตุการณ์ที่ต่อเนื่องกัน ซึ่งหมายความว่าระบบจะไม่สร้างเหตุการณ์จนกว่าจะผ่านไป sampling_period_ns นาโนวินาทีนับจากเหตุการณ์ล่าสุด แม้ว่าค่าจะเปลี่ยนแปลงไปนับตั้งแต่นั้น หากค่ามีการเปลี่ยนแปลง ระบบจะต้องสร้างเหตุการณ์ทันทีที่ sampling_period_ns ผ่านไปนับจากเหตุการณ์ล่าสุด
ตัวอย่างเช่น
- เราเปิดใช้งานเครื่องนับก้าวด้วย
sampling_period_ns = 10 * 10^9
(10 วินาที)
- เราจะเดินเป็นเวลา 55 วินาที แล้วยืนนิ่งเป็นเวลา 1 นาที
- ระบบจะสร้างเหตุการณ์ทุกๆ 10 วินาทีในช่วง 1 นาทีแรก (รวมถึงเวลา
t=0 วินาทีเนื่องจากการเปิดใช้งานเซ็นเซอร์ และ t=60 วินาที) รวมเป็นเหตุการณ์ทั้งหมด 7 รายการ ไม่มีเหตุการณ์เกิดขึ้นในนาทีที่ 2 เนื่องจากค่าของจำนวนก้าวไม่มีการเปลี่ยนแปลงหลังจากผ่านไป t=60 วินาที
ถ่ายครั้งเดียว
เมื่อตรวจพบเหตุการณ์ เซ็นเซอร์จะปิดใช้งานตัวเอง แล้วส่งเหตุการณ์เดียวผ่าน HAL ลําดับมีความสำคัญเพื่อหลีกเลี่ยงเงื่อนไขการแข่งขัน
(ต้องปิดใช้งานเซ็นเซอร์ก่อนที่จะรายงานเหตุการณ์ผ่าน HAL) ระบบจะไม่ส่งเหตุการณ์อื่นๆ จนกว่าเซ็นเซอร์จะเปิดใช้งานอีกครั้ง
การเคลื่อนไหวที่เห็นได้ชัดเป็นตัวอย่างของเซ็นเซอร์ประเภทนี้
เซ็นเซอร์แบบยิงครั้งเดียวบางครั้งเรียกว่าเซ็นเซอร์ทริกเกอร์
ระบบจะไม่สนใจพารามิเตอร์ sampling_period_ns และ max_report_latency_ns ที่ส่งไปยังฟังก์ชัน batch ระบบจัดเก็บเหตุการณ์จากเหตุการณ์ที่เกิดขึ้นครั้งเดียวใน FIFO ของฮาร์ดแวร์ไม่ได้ และต้องรายงานเหตุการณ์ทันทีที่สร้างขึ้น
พิเศษ
ดูรายละเอียดเกี่ยวกับเวลาที่ระบบสร้างเหตุการณ์ได้ที่คำอธิบายประเภทเซ็นเซอร์แต่ละประเภท
ตัวอย่างเนื้อหาและโค้ดในหน้าเว็บนี้ขึ้นอยู่กับใบอนุญาตที่อธิบายไว้ในใบอนุญาตการใช้เนื้อหา 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,["# Reporting modes\n\nSensors can generate events in different ways called reporting modes;\neach sensor type has one and only one reporting mode associated with it.\nFour reporting modes exist.\n\nContinuous\n----------\n\nEvents are generated at a constant rate defined by the\n[sampling_period_ns](/docs/core/interaction/sensors/batching#sampling_period_ns)\nparameter passed to the `batch` function. Example sensors\nusing the continuous reporting mode are\n[accelerometers](/docs/core/interaction/sensors/sensor-types#accelerometer)\nand [gyroscopes](/docs/core/interaction/sensors/sensor-types#gyroscope).\n\nOn-change\n---------\n\nEvents are generated only if the measured values have changed.\nActivating the sensor at the HAL level (calling\n`activate(..., enable=1)` on it) also triggers an event,\nmeaning the HAL must return an event immediately when an on-change sensor\nis activated. Example sensors using the on-change reporting mode are the\nstep counter, proximity, and heart rate sensor types.\n\nThe\n[sampling_period_ns](/docs/core/interaction/sensors/batching#sampling_period_ns)\nparameter passed to the `batch` function is used to set the\nminimum time between consecutive events, meaning an event shouldn't be\ngenerated until `sampling_period_ns` nanoseconds elapsed since\nthe last event, even if the value changed since then. If the value changed,\nan event must be generated as soon as `sampling_period_ns` has\nelapsed since the last event.\n\nFor example, suppose:\n\n- We activate the step counter with `sampling_period_ns = 10 * 10^9` (10 seconds).\n- We walk for 55 seconds, then stand still for one minute.\n- The events are generated about every 10 seconds during the first minute (including at time `t=0` because of the activation of the sensor, and `t=60` seconds), for a total of seven events. No event is generated in the second minute because the value of the step count didn't change after `t=60` seconds.\n\nOne-shot\n--------\n\nUpon detection of an event, the sensor deactivates itself and then sends\na single event through the HAL. Order matters to avoid race conditions.\n(The sensor must be deactivated before the event is reported through the\nHAL). No other event is sent until the sensor is reactivated.\n[Significant\nmotion](/docs/core/interaction/sensors/sensor-types#significant_motion) is an example of this kind of sensor.\n\nOne-shot sensors are sometimes referred to as trigger sensors.\n\nThe `sampling_period_ns` and `max_report_latency_ns`\nparameters passed to the `batch` function are ignored. Events\nfrom one-shot events cannot be stored in hardware FIFOs; the events must\nbe reported as soon as they are generated.\n\nSpecial\n-------\n\nSee the individual [sensor type\ndescriptions](/docs/core/interaction/sensors/sensor-types) for details on when the events are generated."]]
