Risoluzione dei problemi di iOS SDK
Importante
Visual Studio App Center è pianificato per il ritiro il 31 marzo 2025. Anche se è possibile continuare a usare Visual Studio App Center fino a quando non viene completamente ritirato, esistono diverse alternative consigliate a cui è possibile prendere in considerazione la migrazione.
Altre informazioni sulle sequenze temporali di supporto e sulle alternative.
Problemi durante l'installazione
- Nella console cercare un log Di asserzione con il messaggio "App Center SDK configurato correttamente". Il messaggio implica che l'SDK è configurato correttamente.
- Se si usa Cocoapods per integrare App Center nell'app iOS e si verifica un errore con il messaggio -
CocoaPods - Unable to find a specification for AppCenter
, eseguirepod repo update
per aggiornare il repository Cocoapods locale e quindi eseguirepod install
di nuovo. - Se si usa CocoaPods per integrare App Center nell'app iOS e durante la compilazione del progetto si verifica un errore con il messaggio ,
framework not found AppCenter.xcframework
è necessario aggiornare(reinstallare) Cocoapods alla versione tardiva eseguendo[sudo] gem install cocoapods
. - Se si integrano manualmente i file binari dell'SDK, assicurarsi di avere i moduli abilitati per il progetto.
I dati di Analisi non sono visualizzati nel portale
Assicurarsi di aver integrato correttamente i moduli SDK.
Assicurarsi che il segreto app corretto sia incluso insieme alla chiamata al
start:withServices:
metodo. È possibile copiare il codice esattostart:withServices:
aprendo l'app nel portale e passando a Introduzione pagina.Per visualizzare i log inviati al back-end, impostare il livello di log su Dettagliato nell'applicazione. L'SDK stamperà quindi i log nella console. Inserire la chiamata seguente prima dell'avvio dell'SDK:
[MSACAppCenter setLogLevel:MSACLogLevelVerbose]
AppCenter.logLevel = .verbose
Assicurarsi che "App Center SDK configurato correttamente" venga visualizzato nei log (a livello di log INFO ), quindi controllare se vengono visualizzati i log delle richieste HTTPS.
Assicurarsi che il dispositivo sia online.
In alcuni casi, la visualizzazione dei log nel portale potrebbe richiedere alcuni minuti. Attendere un po' di tempo, se questo è il caso.
Per verificare se il back-end di App Center ha ricevuto i dati, passare alla sezione Flusso di log nel servizio Analisi . Gli eventi dovrebbero essere visualizzati dopo l'invio.
Gli arresti anomali non vengono visualizzati nel portale
Assicurarsi di aver integrato correttamente i moduli SDK.
Assicurarsi che il segreto dell'app corretto sia incluso insieme alla chiamata al
start:withServices:
metodo. È possibile copiare il codice esattostart:withServices:
aprendo l'app nel portale e passando a Introduzione pagina.Gli arresti anomali di App Center inoltrano il log degli arresti anomali solo dopo il riavvio dell'app. Inoltre, l'SDK non inoltra i log di arresto anomalo se è collegato al debugger. Assicurarsi che il debugger non sia collegato quando si arresta l'arresto anomalo dell'app.
Per visualizzare i log inviati al back-end, impostare il livello di log su Dettagliato nell'applicazione. L'SDK stamperà quindi i log nella console. Inserire la chiamata seguente prima dell'avvio dell'SDK:
[MSACAppCenter setLogLevel:MSACLogLevelVerbose]
AppCenter.logLevel = .verbose
Assicurarsi che "App Center SDK configurato correttamente" venga visualizzato nei log (a livello di log INFO ), quindi controllare se vengono visualizzati i log delle richieste HTTPS.
Non usare altre librerie che forniscono funzionalità di creazione di report di arresto anomalo del sistema. È possibile avere un solo SDK per la segnalazione di arresti anomali integrato nell'app.
Assicurarsi che il dispositivo sia online.
In alcuni casi, la visualizzazione dei log nel portale potrebbe richiedere alcuni minuti. Attendere un po' di tempo, se questo è il caso.
Controllare se l'SDK ha rilevato l'arresto anomalo all'avvio dell'app successiva. È possibile chiamare l'API per verificare se l'app si è arrestata in modo anomalo nell'ultima sessione e visualizza un avviso. In alternativa, è possibile estendere il callback di arresto anomalo
didSucceedSendingErrorReport
per verificare se è stato inviato correttamente al server.Per verificare se il back-end di App Center ha ricevuto l'arresto anomalo, passare alla sezione Flusso di log nel servizio Analisi. I tuoi arresti anomali dovrebbero apparire lì, una volta che è stato inviato.
L'avviso che richiede agli utenti di un aggiornamento non contiene stringhe, ma solo le chiavi per loro
Ciò significa che l'oggetto AppCenterDistributeResources.bundle
non è stato aggiunto al progetto. Assicurarsi di aver eliminato il file nel progetto Xcode e che venga visualizzato nella fase di compilazione della destinazione dell'app Copy Bundle Resources
. Dovrebbe apparire lì se è stato aggiunto il file tramite trascinamento della selezione. Xcode lo esegue automaticamente. Se il file non è presente nella fase di compilazione, aggiungerlo in modo che venga compilato nel bundle dell'app.
Se si usano Cocoapods, le risorse vengono gestite automaticamente. Provare a reinstallare il pod.
Nella console vengono visualizzati messaggi che indicano che non è stato possibile aprire il database
A partire dalla versione 0.11.0 di iOS SDK, App Center usa SQLite per rendere persistenti i log prima di inviarli al back-end. Se si crea un bundle dell'applicazione con la propria libreria SQLite anziché quella fornita dal sistema operativo, potrebbero verificarsi errori come questo nella console [AppCenter] ERROR: -[MSACDBStorage executeSelectionQuery:]/147 Failed to open database
e non verranno visualizzate informazioni sull'analisi o sull'arresto anomalo del back-end. Aggiornare l'SDK alla versione 0.13.0 o successiva.
Gli aggiornamenti distribuiti e in-app bloccano i test automatizzati dell'interfaccia utente
Se gli aggiornamenti in-app sono abilitati, bloccano i test automatizzati dell'interfaccia utente. Il processo di aggiornamento tenterà di eseguire l'autenticazione nel back-end di App Center. È consigliabile non abilitare App Center Distribute per la destinazione di test dell'interfaccia utente.
Perché l'SDK viene distribuito come "libreria statica"
Gli obiettivi di progettazione principali per App Center SDK sono quello di avere un impatto minimo sull'app che usa App Center e di avere un SDK modulare. In questo modo l'SDK viene distribuito come diverse librerie condivise collegate dinamiche.
Storicamente, iOS non supportava librerie condivise collegate dinamiche, ma è stato aggiunto in iOS 8, come illustrato in questo post di blog di Landon Fuller.
Tuttavia, App Center viene distribuito come libreria condivisa collegata in modo statico che viene racchiusa in un framework falso "fat". Ciò significa che l'SDK è collegato in fase di compilazione e non al momento dell'avvio per ottenere prestazioni migliori. Il caricamento di più librerie condivise collegate dinamiche richiede tempo.
Apple consiglia di ottimizzare l'avvio dell'app per richiedere non più di 400 ms in una sessione WWDC. In particolare, è consigliabile usare librerie condivise statiche su quelle condivise dinamiche per raggiungere questo obiettivo. La distribuzione di App Center SDK per iOS come libreria condivisa collegata in modo statico segue la raccomandazione di Apple di offrire prestazioni ottimali e un impatto minimo sull'app che include l'SDK.
Per altre informazioni sulle librerie condivise collegate in modo statico e sulle librerie condivise collegate dinamiche, è consigliabile consultare la documentazione generale di Apple sull'argomento.
Perché i file binari dell'SDK sono così grandi? Sono preoccupato per le dimensioni dell'app
I file binari di AppCenter vengono distribuiti come framework "fat" che contengono sezioni per tutte le architetture iPhone e per il simulatore iPhone. Ecco perché, ad esempio , AppCenter.framework è di 10,5 MB da scaricare.
Le dimensioni compilate dei file binari dell'SDK saranno molto inferiori a quelle .framework
aggiunte all'app in Xcode. Tenere presente anche che anche le build di versione saranno inferiori rispetto alle compilazioni di debug.
Per illustrare questo problema, è stata creata un'applicazione Objective-C vuota con Xcode 9.2, sono stati aggiunti i file binari di App Center all'app e sono state distribuite le build di rilascio a un iPhone 7 che esegue iOS 11.3.
Sono stati eseguiti i test senza Bitcode abilitato e non è stato usato App Thinning. Puoi usare queste tecniche per ridurre ulteriormente le dimensioni binarie dell'app.
I numeri seguenti possono variare e dipendono dalle impostazioni di compilazione, quindi considerali una guida approssimativa. Ciò premesso, l'aggiunta di App Center SDK all'app ha un impatto minimo sulle dimensioni del file binario dell'applicazione.
Moduli di App Center usati | Dimensioni IPA esportate | Dimensioni dell'installazione |
---|---|---|
Nessuno (app vuota) | 24 KB | 132 KB |
Analytics in App Center | 120 KB | 377 KB |
Arresto anomalo di App Center | 239 KB | 705 KB |
Distribuzione di App Center | 163 KB | 528 KB |
Tutti i moduli di App Center | 314 KB | 930 KB |
Proteggere il valore segreto di App Center
L'identificatore app_secret
dell'app è necessario sapere a quale app si applica il traffico e non può essere usato per recuperare o modificare i dati esistenti. Se l'utente app_secret
è esposto, il rischio maggiore è l'invio di dati non validi all'app, ma non avrà effetto sulla sicurezza dei dati.
Per recuperare i dati sensibili, è necessario fornire un token app/utente, generato sul lato del client. Non è possibile rendere i dati sul lato client completamente sicuri.
È possibile migliorare la sicurezza dell'app usando una variabile di ambiente per inserire il segreto dell'app nel codice. In questo modo, il segreto non è visibile nel codice.