Langkah, jarak, kalori, kadar denyutan jantung, dan tidur perlu ditarik dari platform pengguna (Android Health Connect di Android, Apple HealthKit di iOS) oleh aplikasi kesihatan dan nutrisi — dan mempersembahkannya sebagai satu profil harian yang bersih, dinyahpenduaan. Terdapat sangat sedikit persamaan antara kedua-dua API: mekanik bacaan yang berasingan, skim kebenaran yang berbeza, dan struktur data yang berbeza. Kami membina lapisan penyegerakan mudah alih yang menjadikan mereka kelihatan seperti satu.
Cabaran
- Dua API natif yang tidak bersetuju tentang apa-apa. Apple HealthKit mengembalikan agregat harian melalui panggilan balik (callbacks); Health Connect mengembalikan sampel mentah, berpaginasi dengan metadata sumber yang kaya. Konsep yang sama, bentuk yang sama sekali berbeza — dan aplikasi perlu menormalkan kedua-duanya ke dalam satu skema.
- Pengiraan berganda adalah lalai. Telefon, jam tangan pintar, dan aplikasi pihak ketiga semuanya boleh melaporkan 8,000 langkah yang sama. Menjumlahkannya secara naif akan menggembungkan setiap metrik. Aplikasi perlu mengenali sumber yang bertindih dan mengira setiap aktiviti dunia nyata sekali sahaja.
- Ketepatan data tidak boleh membebankan bateri dan rangkaian. Data kesihatan berubah sepanjang hari, tetapi membaca sejarah penuh pada setiap penyegerakan akan menguras bateri dan memenuhkan sambungan selular. Kekerapan penyegerakan perlu kekal ringan sementara masih terasa langsung.
Kebenaran boleh mengelirukan. Puluhan jenis data, dua model kebenaran, sekatan bacaan latar belakang, dan pengguna yang memberikan beberapa skop tetapi tidak yang lain — semua ini perlu ditangani oleh aplikasi tanpa mengganggu aliran.
Penyelesaian Kami
Kami membina penyegerakan tiga lapisan: lapisan natif yang nipis membaca API setiap platform, lapisan normalisasi pada peranti menyahpenduaan dan menggulung data menjadi ringkasan harian, dan backend menyimpannya serta menyelaraskannya ke dalam satu lejar yang dipercayai. Klien tidak pernah menghantar sampel mentah — ia menghantar ringkasan harian yang bersih, betul zon masa.
Seni Bina
- iOS membaca Apple HealthKit melalui react-native-health; Android membaca Health Connect melalui react-native-health-connect.
- Normalisasi pada peranti mengubah output kedua-dua platform menjadi satu skema dan menyahpenduaan sebelum apa-apa meninggalkan telefon.
- Pencetus penyegerakan — Sejarah 30 hari pada pelancaran pertama, kemudian bacaan inkremental 1 hari yang ringan pada selang 10 minit dan pada setiap sambungan aplikasi.
- Pengangkutan — ringkasan harian yang dinormalkan dipostkan ke pelayan utama /user-health/system-activity, yang kemudian memajukannya (dengan ID pengguna + zon masa) ke mikroservis kesihatan.
- Penyimpanan Data — setiap sumber/hari disimpan secara idempotent sebagai HealthSystemAggregate; aliran perubahan MongoDB kemudian menyelaraskannya ke dalam HealthLedger setiap hari.
Aliran kerja terurus Expo / React Native dengan modul HealthKit dan Health Connect natif.
Ciri-ciri Utama
- Satu kontrak normalisasi untuk dua API. Pembaca khusus platform menyalurkan satu langkah formatHealthData yang mengeluarkan bentuk yang sama tanpa mengira sumber — jadi backend dan UI tidak pernah bercabang antara iOS vs Android.
2. Nyahpenduaan berasaskan maksima pada peranti. Dalam setiap sumber, bacaan sehari dijumlahkan; kemudian nilai harian adalah Math.max() merentasi sumber (kalori dikunci oleh source|deviceType), jadi beberapa bacaan dari satu peranti terkumpul manakala jam tangan dan telefon yang melaporkan hari yang sama tidak berganda:
// Sum readings within each source, then take the max ACROSS sources dateSourceMap[date][source] += entry.count; const totalSteps = Math.ceil(Math.max(...Object.values(dateSourceMap[date]))); |
3.Strategi bacaan yang betul untuk setiap platform. Bacaan Health Connect dipaginasi dengan gelung pageToken (1,000 rekod/halaman); agregat harian HealthKit diulang hari demi hari. Setiap keunikan terkandung dalam pembacanya sendiri, tidak kelihatan oleh aplikasi yang lain.
4. Kekerapan penyegerakan yang menghormati bateri. Pengisian semula 30 hari penuh hanya berjalan sekali (dilindungi oleh bendera panggilan pertama); selepas itu, setiap penyegerakan hanya menarik satu hari — pantas pada sambungan selular, murah pada kuasa.
5. Pengelompokan harian yang betul zon masa. Sampel dikelompokkan ke dalam kekunci YYYY-MM-DD dalam zon masa pengguna sendiri, jadi senaman pada pukul 11 malam akan jatuh pada hari yang betul tidak kira di mana pelayan berada.
6. Penulisan backend idempotent. Setiap ringkasan 'upsert' pada (userId, deviceId, source, date) — menghantar semula hari yang sama tidak melakukan apa-apa (no-op), menjadikan percubaan semula dan penyegerakan bertindih selamat.
7. Pengendalian kegagalan yang telus. Kebenaran yang hilang, bacaan kosong, dan ralat had kadar Health Connect ditangkap dan dipaparkan dengan bersih — hari kosong tidak pernah merosakkan penyegerakan, dan pengguna mendapat arahan yang jelas dan bukannya kegagalan senyap.
Hasil
- Satu profil kesihatan yang tunggal dan konsisten merentasi iOS dan Android — perbezaan platform tidak kelihatan oleh aplikasi yang lain.
- Sumber peranti/aplikasi yang bertindih dinyahpenduaan, jadi langkah dan kalori mencerminkan realiti dan bukannya jumlah yang digembungkan.
- Penyegerakan inkremental yang ringan memastikan data sentiasa terkini tanpa menguras bateri atau membazir data mudah alih.
Penulisan idempotent yang betul zon masa bermakna setiap metrik jatuh pada hari yang betul, dan percubaan semula tidak pernah merosakkan rekod.
Timbunan Teknologi
React Native (Expo) · react-native-health (HealthKit) · react-native-health-connect · NestJS · MongoDB · MongoDB Change Streams · moment-timezone
