Um problema com o travamento da máquina real do pacote
1. Descrição do problema
1.1. Ambiente operacional
- Versão do simulador: iPhone6 && 8.4 || 9.3
- Versão da máquina real: iPhone6p && 8.4
- Certificado assinado: certificado emitido pela empresa, certificado de desenvolvimento pessoal
1.2. Antecedentes
Depois que a função do APP está basicamente concluída, porque a versão iOS será usada para demonstrar aos líderes, eu rapidamente empacotei as necessidades pela manhã.
1.3. Problema
Porque houve um problema que o pacote de compilação falhou ao instalar o telefone celular 5c dois dias atrás (a arquitetura não corresponde, / (ㄒ o ㄒ) / ~~), então honestamente empacotado com o arquivo de certificado corporativo, empacotado e carregado para o Site da Dandelion e, em seguida, usado Teste a instalação de digitalização 6p do telefone móvel.
Depois que a instalação foi bem-sucedida, cliquei em todas as funções, mas no final descobri de repente que uma função para abrir uma página da Web relatou um erro 404, e várias funções de abrir página da Web em outra página simplesmente travaram e travaram! Depois de um tempo na minha mente, rapidamente peguei o URL do navegador e o abri, o que é normal. Em seguida, use o simulador para executar o ponto de interrupção, e descobri que também é normal. É normal usar um certificado de desenvolvedor pessoal para depurar em uma máquina real! !
2. Solução
2.1. Idéias
Como é normal rodar no simulador e no modo de depuração da máquina real, comecei a suspeitar que o problema estava no certificado da empresa ou no pacote de arquivo.
Tentei outro pacote de arquivo de certificado corporativo e descobri que o mesmo problema ainda existe. O problema não existe com o uso de pacotes de construção de certificado corporativo. Portanto, sinto que o problema ainda está na embalagem do arquivo.
Eu verifiquei o log de travamento do telefone no Xcode e encontrei um aplicativo de encerramento devido à exceção não capturada 'NSInvalidArgumentException', motivo: ' * setObjectForKey: o objeto não pode ser nulo (chave: nsrsbh) mensagem de erro.
E essa informação nsrsbh só tem valor quando o APP está logado. No entanto, a função que apresenta o problema de travamento pode, na verdade, ser acessada diretamente, sem a necessidade de fazer login.
Portanto, o problema final está localizado no seguinte trecho de código:
GDWebURLParseType parseType;
if ([extraInfo[@"parserType"] isEqualToString:@"tgc"]) {
parseType = GDWebURLParseTypeTGC;
} else if ([extraInfo[@"parserType"] isEqualToString:@"cl"]) {
parseType = GDWebURLParseTypeCL;
} else if ([extraInfo[@"parserType"] isEqualToString:@"lt"]) {
parseType = GDWebURLParseTypeLT;
}
webUrl = [GDUtil parseWebURL:webUrl parseType:parseType];
A variável parseType é uma variável enumerada,
typedef NS_ENUM(NSUInteger, GDWebURLParseType) {
GDWebURLParseTypeLT,
GDWebURLParseTypeCL,
GDWebURLParseTypeTGC
};
O método + GDUtil parseWebURL: parseType: montará a url de acordo com os diferentes parseType. Quando o parseType for GDWebURLParseTypeLT, a atribuição do campo nsrsbh nas informações de falha acima será usada.
Deste ponto de vista, o problema está no valor padrão de parseType, que é um número aleatório no modo simulador / depuração, enquanto é 0 na máquina de arquivo real, então a lógica do código que precisa ser logado é inserida no estado não registrado., O que leva a um travamento.
2.2. Conclusão
Agora que o problema foi localizado, é fácil resolvê-lo, basta atribuir um valor inicial ao tipo de enumeração.
GDWebURLParseType parseType = NSIntegerMax;
Após a modificação, re-arquivar, empacotar, instalar e executar, tudo está OK.
3. Razão
A razão para esse problema não foi investigada em profundidade, mas pelas regras gramaticais normais, o valor inicial do tipo de enumeração definido globalmente é 0, que é GDWebURLParseTypeLT neste caso. Portanto, bons hábitos de codificação devem ser mantidos durante a codificação, e a inicialização de variável deve ser feita.