iOS prefix.pch Melhores práticas
https://stackoverflow.com/questions/2845211
-
27-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPergunta
Eu já vi muitos desenvolvedores que adicionam várias macros de conveniência ao prefix.pch de seus projetos iOS.
O que (ou não) você recomenda adicionar ao arquivo prefix.pch iOS? Como é o seu prefix.pch?
Solução
Ewww… não coloque macros em um arquivo .pch! Um arquivo .pch é, por definição, um cabeçalho específico específico do projeto. Realmente não deve ser usado além do contexto do projeto e realmente não deveria conter nada, mas #includeareia #imports.
Se você tem algumas macros e de tal forma que deseja compartilhar entre os cabeçalhos, então os coloque em um arquivo de cabeçalho - Common.h ou o que quer que seja - e #include este No início do .pch.
Outras dicas
Para iOS e OS modernos, as pessoas deveriam estar usando Módulos. Isso é ativado por padrão para novos projetos, e a importação/inclusão é realizada usando @import.
Os módulos permitem que o compilador crie uma representação intermediária do conteúdo de um módulo (por exemplo, os cabeçalhos de uma estrutura). Assim como um PCH, essa representação intermediária pode ser compartilhada em várias traduções. Mas os módulos dão esse passo adiante porque um módulo não é necessariamente alvo específico, e suas declarações não precisam ser localizadas (para um *.pch). Essa representação pode economizar uma tonelada de trabalho redundante do compilador.
Usando módulos, você não precisa de um PCH, e provavelmente deve acabar com eles completamente @import local para a dependência. Nesse caso, um PCH está apenas salvando você de digitando inclusões locais para dependências (que IMO você deve fazer de qualquer maneira).
Agora, se olharmos para a pergunta original: você deve evitar preencher seu PCH com todos os tipos de coisas aleatórias; Macros, constantes, #defines, e todo tipo de pequenas bibliotecas. Geralmente, você deveria Omita o que realmente é desnecessário para a maioria dos seus arquivos de origem. Colocar todos os tipos de coisas no seu PCH está apenas adicionando um monte de peso e dependência. Vejo pessoas colocando tudo o que se vinculam e mais no PCH. Na realidade, as estruturas auxiliares normalmente precisam ser visíveis para algumas traduções na maioria dos casos. Por exemplo, "Aqui está o nosso StoreKit material - vamos importar o storeKit devo Seja visível. Especificamente, essas 3 traduções ". Isso mantém seus tempos de construção baixos e ajuda a acompanhar suas dependências, para que você possa reutilizar o código com mais facilidade. Portanto, em um projeto OBJC, você geralmente pararia na fundação. Se houver muito da interface do usuário, você pode considerar adicionar o UIKIT ou o AppKit ao seu PCH. Isso está supondo que você queira otimizar os tempos de construção. Um dos problemas com PCHs grandes que incluem (quase) tudo é que a remoção de dependências desnecessárias consome muito tempo. As dependências do seu projeto crescem e seus tempos de construção aumentam, você precisa revidar eliminando dependências desnecessárias para reduzir seus tempos de construção. Além disso, qualquer coisa que as mudanças geralmente deve ser mantida fora do seu PCH. Uma mudança requer uma reconstrução completa. Existem algumas opções para compartilhar PCHs. Se você usar PCHs, visam apoiar o compartilhamento.
Quanto ao que coloquei no meu PCH: parei de usá -los para a grande maioria dos alvos anos atrás. Geralmente, geralmente não é suficiente em comum para se qualificar. Lembre -se de que escrevo C ++, OBJC, OBJC ++ e C - O compilador emite um para cada lang em seu alvo. Portanto, possibilitá -los geralmente resultou em tempos de compilação mais lentos e E/S mais alta. Por fim, o aumento da dependência não é uma boa maneira de combater a dependência em projetos complexos. Trabalhando com vários idiomas/dialetos, há muita variação nas dependências necessárias para um determinado destino. Não, eu não aconselharia isso como ideal para cada projeto, mas isso dá alguma perspectiva ao gerenciamento de dependências em projetos maiores.
Referências
Notas
- Esta pergunta foi feita originalmente alguns anos antes da introdução dos módulos.
- Atualmente (Xcode 5.0), os módulos funcionam para C e OBJC, mas não C ++.
Eu concordo com o BBUM. Minha opinião sobre o arquivo PCH é que ele deve conter praticamente #include ou #import declarações. Então, se você tiver um monte de macros úteis e de alto nível, defina-as em algo como Common.h e #import Esse arquivo, como o BBUM sugeriu.
Eu costumo dar um passo adiante e uso o arquivo PCH para #import um arquivo chamado XXCategories.h (Onde XX é a convenção de prefixo de nomeação de classe que você usa) que contém #imports para todas as minhas categorias de classe de Uikit e fundação: NSString+XXAdditions.h, UIColor+XXAdditons.h, etc.
Crie um arquivo de cabeçalho "Macros.h"
Importe este cabeçalho para prefix.pch
Neste macros.h, colocou todas as estruturas e outras coisas importantes.
Se você está preocupado com o desempenho, não se preocupe, veja o que a Apple diz:
Cabeçalhos e desempenho
Se você está preocupado que incluir um arquivo de cabeçalho principal possa fazer com que seu programa incorpore, não se preocupe. Como as interfaces do OS X são implementadas usando estruturas, o código para essas interfaces reside em uma biblioteca compartilhada dinâmica e não no seu executável. Além disso, apenas o código usado pelo seu programa é carregado na memória em tempo de execução, para que sua presença na memória permaneça pequena. Quanto a incluir um grande número de arquivos de cabeçalho durante a compilação, mais uma vez, não se preocupe. O Xcode fornece uma instalação de cabeçalho pré -compilada para acelerar os tempos de compilação. Ao compilar todos os cabeçalhos da estrutura de uma só vez, não há necessidade de recomitar os cabeçalhos, a menos que você adicione uma nova estrutura. Enquanto isso, você pode usar qualquer interface das estruturas incluídas com pouca ou nenhuma penalidade de desempenho.
Também nas minhas macros.h coloquei muitas constantes como:
// delegate
#define UIAppDelegate (AppDelegate *)[[UIApplication sharedApplication] delegate]
#define APPDELEGATE ((AppDelegate *)[[UIApplication sharedApplication] delegate])
// system
#define IS_IPHONE_4INCH (UI_USER_INTERFACE_IDIOM()==UIUserInterfaceIdiomPhone && [UIScreen mainScreen].bounds.size.height==568)
#define IS_IPAD (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad)
// screen size
#define IS_IPAD (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad)
#define IS_IPHONE (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPhone)
#define IS_IPHONE_4 (IS_IPHONE && [[UIScreen mainScreen] bounds].size.height == 480.0)
#define IS_IPHONE_5 (IS_IPHONE && [[UIScreen mainScreen] bounds].size.height == 568.0)
#define IS_IPHONE_6 (IS_IPHONE && [[UIScreen mainScreen] bounds].size.height == 667.0)
#define IS_IPHONE_6PLUS (IS_IPHONE && [[UIScreen mainScreen] nativeScale] == 3.0f)
#define IS_IPHONE_6_PLUS (IS_IPHONE && [[UIScreen mainScreen] bounds].size.height == 736.0)
#define IS_RETINA ([[UIScreen mainScreen] scale] == 2.0)
#define IS_RETINA_DISPLAY ([[UIScreen mainScreen] respondsToSelector:@selector(displayLinkWithTarget:selector:)] && ([UIScreen mainScreen].scale == 2.0))
#define IS_PORTRAIT UIInterfaceOrientationIsPortrait([[UIApplication sharedApplication] statusBarOrientation])
#define IS_LANDSCAPE UIInterfaceOrientationIsLandscape([[UIApplication sharedApplication] statusBarOrientation])
//system version
#define SYSTEM_VERSION_LESS_THAN(v) ([[[UIDevice currentDevice] systemVersion] compare:v options:NSNumericSearch] == NSOrderedAscending)
#define SYSTEM_VERSION_GREATER_THAN(v) ([[[UIDevice currentDevice] systemVersion] compare:v options:NSNumericSearch] == NSOrderedDescending)
// math
#define DEGREES_TO_RADIANS(angle) ((angle) / 180.0 * M_PI)
#define RADIANS_TO_DEGREES(radians) ((radians) * (180.0 / M_PI))
// cores
#define RGB(r,g,b) [UIColor colorWithRed:(r)/255.0 green:(g)/255.0 blue:(b)/255.0 alpha:1]
#define RGBA(r,g,b,a) [UIColor colorWithRed:(r)/255.0 green:(g)/255.0 blue:(b)/255.0 alpha:a]
#define MAKECOLOR(R, G, B, A) [UIColor colorWithRed:((float)R/255.0f) green:((float)G/255.0f) blue:((float)B/255.0f) alpha:A]
#define MAKECOLORFROMHEX(hexValue) [UIColor colorWithRed: ((float)((hexValue & 0xFF0000) >> 16))/255.0 green:((float)((hexValue & 0xFF00) >> 8))/255.0 blue:((float)(hexValue & 0xFF))/255.0 alpha:1.0]
//customizations
#define SHOW_STATUS_BAR [[UIApplication sharedApplication] setStatusBarHidden:NO withAnimation:UIStatusBarAnimationNone];
#define HIDE_STATUS_BAR [[UIApplication sharedApplication] setStatusBarHidden:YES withAnimation:UIStatusBarAnimationNone];
#define SHOW_NAVIGATION_BAR [self.navigationController setNavigationBarHidden:FALSE];
#define HIDE_NAVIGATION_BAR [self.navigationController setNavigationBarHidden:TRUE];
#define VC_OBJ(x) [[x alloc] init]
#define VC_OBJ_WITH_NIB(x) [[x alloc] initWithNibName : (NSString *)CFSTR(#x) bundle : nil]
#define RESIGN_KEYBOARD [[[UIApplication sharedApplication] keyWindow] endEditing:YES];
#define CLEAR_NOTIFICATION_BADGE [UIApplication sharedApplication].applicationIconBadgeNumber = 0;
#define REGISTER_APPLICATION_FOR_NOTIFICATION_SERVICE [[UIApplication sharedApplication] registerForRemoteNotificationTypes:(UIRemoteNotificationTypeBadge | UIRemoteNotificationTypeSound | UIRemoteNotificationTypeAlert)]
#define HIDE_NETWORK_ACTIVITY_INDICATOR [[UIApplication sharedApplication] setNetworkActivityIndicatorVisible:NO];
#define SHOW_NETWORK_ACTIVITY_INDICATOR [[UIApplication sharedApplication] setNetworkActivityIndicatorVisible:YES];
