Sorunun Tarihçesi
Jeofencing teknolojisi, modern iş gücü yönetim çözümlerinin kritik bir bileşeni olarak ortaya çıkmış olup, basit GPS yarıçap kontrollerinden, Wi-Fi konumlandırma, hücresel üçgenleme ve Bluetooth işaretlerini kullanan sofistike çoklu sensör füzyon sistemlerine evrilmiştir. Android ve iOS pil optimizasyon çerçevelerinin —özellikle Doze modu, Uygulama Bekleme ve Düşük Güç Modu— yaygınlaşması, arka planda konum hizmetlerini korumak için işletim sistemlerinin agresif bir şekilde kısıtlama getirmesi nedeniyle önemli bir karmaşıklık yaratmıştır. Bu durum, gerçek zamanlı jeofens izleme için iş ihtiyaçları ile kaynak tüketimini sınırlamak amacıyla tasarlanan platform kısıtlamaları arasında bir gerilim yaratmıştır.
Sorun
Temel doğrulama zorluğu, tüketici sınıfı GNSS (Küresel Navigasyon Uydu Sistemi) alıcılarının doğasında bulunan hassasiyetsizlikten kaynaklanmaktadır. Bu alıcılar, açık havada 5-20 metre konum kaymalarına ve çok yolların etkisi nedeniyle kentsel kanyonlarda daha yüksek varyanslara sahip olmaktadır. Çokgen jeofens geometrileri ve 100 metre yarıçap toleransları ile birleştirildiğinde, bu kaymalar yanlış pozitif giriş/çıkış olayları üretmektedir, özellikle kullanıcılar yüksek hızla sınır yakınlarından geçerken. Ayrıca, SQLite kuyrukları kullanan çevrimdışı yapı mimarileri, cihaz saatlerinin manuel olarak değiştirilmesi durumunda veri bütünlüğü riskleri oluşturmakta, bu durum jeofens geçişlerinin zamansal sırasını bozmakta veya bulut REST uç noktaları ile senkronizasyon çatışmalarına neden olmaktadır.
Çözüm
Kapsamlı bir manuel test metodolojisi, üç katmanlı bir yaklaşım benimsemelidir: statik laboratuvar testi, sınır hesaplamalarını doğrulamak için Android Debug Bridge (ADB) geo fix komutları ve iOS GPX dosyası simülasyonu ile; kontrollü saha testi ile, sinyal bozulmasını ve RF parazitini simüle etmek için Faraday kafesleri kullanarak; ve manuel saat ayarlama ile zaman dilimi geçişlerini içeren zamansal manipülasyon testi. Testçilerin, uygulamanın Android üzerinde Batarya Optimizasyonlarını Yoksay izinlerini ve iOS üzerinde Arka Plan Uygulama Yenileme durumunu doğru bir şekilde talep ettiğini doğrulamakla birlikte, yanlış geçişleri bastıran debouncing algoritmalarını (genellikle 10-15 saniye ve 50 metre hareket eşiklerde) doğrulaması gerekmektedir.
Orta ölçekli bir lojistik şirket, dağıtım merkezlerinin etrafında çokgen jeofensler kullanarak depo varış ve ayrılışlarını izlemek için bir sürücü izleme uygulaması kurdu. Sürücüler, depo kapıları yakınında, 80 metre içinde trafik ışıklarında durduklarında yanlış “erken varış” bonuslarının tetiklendiğini bildirdilerken, sistem hızlı bir şekilde otoyola çıkan sürümlerin ayrılma olaylarını sık sık kaçırıyordu. Bu hatalar, maaş anlaşmazlıklarına neden oldu ve doğru bekleme süresi hesaplamalarına dayanan rotayı optimize etme algoritmalarını geçersiz kıldı.
Bir potansiyel çözüm, ham GPS koordinatlarının bir AWS Lambda fonksiyonuna aktarılarak tamamen sunucu tarafında jeofen hesaplaması yapılmasını içermekteydi. Bu yaklaşım, merkezi bir mantıksal yapı ve kolay güncellemeler sağlarken istemci tarafı kod değişikliklerine gerek kalmamıştır. Ancak, sürekli ağ bağlantısı ve yüksek pil tüketimi gerektirdiği için sık sık iletim aralıklarıyla, dört saat içinde %40 pil tüketimine ve hücresel sinyalin olmadığı yer altı yükleme alanlarında tamamen başarısızlığa neden olmuştur.
Bir başka çözüm, basit mesafe hesaplamaları kullanarak yanıt süresini maximize etmek için agresif istemci tarafı filtrelemesi önerdi. Bu, yalnızca jeofens geçişleri sırasında iletimleri gruplandırarak pil kullanımını azalttı, ancak kentsel testler, köprüleri geçen sürücülerin su ve binalardan yansıyan uydu sinyallerinin birçok hızlı giriş/çıkış döngüsü tetiklemesine neden olan felaket “zıplama” etkilerini ortaya çıkardı. Bu, veri tabanında çoğaltılmış kayıtların ve yanlış iş süresi hesaplamalarının ortaya çıkmasına neden oldu, bu da maaş sistemini karıştırdı ve uyumluluk ihlalleri yarattı.
Seçilen çözüm, SQLite kuyruklama ve arka plan konum izni sertleştirmesi ile birlikte bir hibrit istemci tarafı debouncing tamponu uyguladı. Durum geçişlerini tetiklemek için 15 saniyelik bekleme gereksinimi ve 75 metre minimum hareket eşiği yapılandırdık, ayrıca Doze modunun sonlandığını önlemek için açık Android ön plan hizmeti bildirimleri kullandık. Çevrimdışı senaryolar için, senkronizasyon sırasında saat sahtekarlığını tespit etmek için NTP (Ağ Zaman Protokolü) doğrulama kontrolleri uyguladık. Bu, yanlış pozitifleri %94 oranında azaltırken, kabul edilebilir pil seviyelerini korudu (8 saatlik bir vardiya sırasında %12 pil tüketimi), ancak bu, saha doğrulaması için karmaşık TestFlight ve Firebase Uygulama Dağıtımı yapımlarını gerektirdi.
Dağıtım, maaş anlaşmazlıklarını başarıyla ortadan kaldırdı ve transit süre hesaplamalarında %99.2 doğruluk sağladı. Ancak, Xiaomi ve Huawei gibi yaklaşık %3 oranındaki Android cihazlarının, standart Android izinlerini geçersiz kılan üreticiye özel pil tasarrufu modları kullandığını keşfettik. Bu, Çin iç pazarına özel bir sıcak yamanın yayımlanmasını gerektirdi ve küresel dağıtımı iki hafta erteledi.
Uygulamanın, erken varış veya geç çıkışları sahte göstermek için cihaz saati manipülasyonunu doğru bir şekilde ele almasını nasıl doğrularsınız?
Adaylar genellikle yalnızca sunucu zaman damgalarını kontrol etmeyi önerir, oysa meşru çevrimdışı işlemlerin geçici olarak istemci saatine güvenmesi gerekmektedir. Doğru yaklaşım, uygulamanın her jeofens olayı için hem cihaz zaman damgasını hem de monotonic saat referansını (örneğin, SystemClock.elapsedRealtime() Android üzerinde veya mach_absolute_time iOS üzerinde) kaydettiğini doğrulamaktadır. Senkronize ederken, sistemin, cihaz zamanının NTP zamanından önemli ölçüde farklı olduğu veya imkansız sıralar sergilediği durumları işaret etmesi gerekmektedir (örneğin, bir çıkış zaman damgasının bir girişin önünde olması gibi).
Kullanıcı, transit sırasında konum izinlerini devre dışı bırakınca veya iOS Ayarlar üzerinden kalıcı olarak geri alırsa, jeofens davranışını nasıl test edersiniz?
Birçok testçi, yalnızca ilk izin verme akışına odaklanarak, aktif oturumda izin geri alımı için gerekli karmaşık durum makinesini ihmal etmektedir. Doğru metodoloji, bir jeofens geçişini tetiklemek, ardından Ayarlar > Gizlilik > Konum Servisleri'ne giderek izinleri “Her Zaman”dan “Kullanırken” veya “Asla”ya değiştirmek için aktif takip sırasında işlem yapmaktır. Testçiler, uygulamanın iOS üzerinde CLLocationManager yetkilendirme başarısızlığını veya Android üzerinde SecurityException'ı düzgün bir şekilde ele alarak arka plan izlemeyi durdurmasını, çökmeden, “izin kayboldu” meta verisi ile biriken olayları saklamasını ve bağlamsal yeniden yetkilendirme istemlerini göstermesini doğrulamak zorundadır.
Karmaşık geometriler gibi düzensiz depo sınırları veya paylaşılan otoparklar yakınında çokgen jeofenslerin doğruluğunu nasıl doğrularsınız?
Genç testçiler genellikle dairesel jeofenslerin yeteceğini varsaydıklarından, komşu tesislerde yanlış pozitiflere neden olurlar. Detaylı cevap, uydu görüntüsü sınırlarıyla tam olarak hizalanmış köşelere sahip GeoJSON çokgenleri oluşturmayı gerektirir, ardından test yollarını yürüyerek doğrulamak amacıyla “yakın kaçırma” senaryolarını test etmek gerekir. Testçiler, test yollarını görselleştirmek için Google Earth KML örtülerini kullanmalı ve GPS hata ayıklama uygulamaları (GPS Durumu Android üzerinde, Spyglass iOS üzerinde) ile koordinat hassasiyetini doğrulamalıdır ve Ray Casting algoritmasının konveks olmayan çokgenlerin (L şeklindeki depolar gibi) içindeki noktaları doğru bir şekilde tanımladığını doğrulamalıdır.