現(xiàn)在在做的這個(gè)產(chǎn)品，由于需求不斷的添加，工程越來(lái)越大，編譯速度是越來(lái)越慢。之前就看過(guò)帖子:
使用宏定義過(guò)多的話，隨著工程越來(lái)越大，編譯速度會(huì)越來(lái)越慢。
當(dāng)時(shí)也想過(guò)替換成常量，但是當(dāng)時(shí)的替換方法有問(wèn)題，導(dǎo)致編譯的時(shí)候有很多重復(fù)的變量，替換失敗了，就不了了之，直到最近，每次編譯的時(shí)間實(shí)在是超出了我的容忍極限，于是下定決心，一定要替換掉。又從網(wǎng)上查看帖子，從簡(jiǎn)書上看到了這篇文章【如何正確使用const,static,extern】|那些人追的干貨，仔細(xì)閱讀，研究，詢問(wèn)博主之后，終于塵埃落定,替換了之前使用宏定義的常量。
現(xiàn)在獻(xiàn)上一段代碼：
static CGFloat const kLogoImageWidth = 100; //logo寬度
static CGFloat const kLogoImageHeight = 100; //logo寬度
static CGFloat const kLogoImageY = 110;
static CGFloat const kBtnHeight = 40;
static CGFloat const kPadding = 30;
static CGFloat const kWeixinTopPadding = 15;
static CGFloat const kWeiboLoginBottom = 230;
#define kScaleSpace(designSpace) ((designSpace)*(SCREEN_HEIGHT/667.0)) //根據(jù)iphone6 的設(shè)計(jì)稿計(jì)算縮放高度
替換的時(shí)候一定要注意數(shù)據(jù)類型。對(duì)于 CGFloat 和 NSString類型替換的時(shí)候也是一樣的。代碼如下：
static CGFloat const kBottomHeight = 50.0; //底部視圖高度
static NSString *const CELL_TITLE_KEY = @"CELL_TITLE_KEY";
static NSString *const CELL_CONTENT_KEY = @"CELL_CONTENT_KEY";
替換完成之后代碼的編譯速度確實(shí)上去了，現(xiàn)在編譯快了。希望對(duì)正在為編譯速度慢感到困惑的您有所幫助！
補(bǔ)充說(shuō)明：以上的類型常量替換宏的情況，只是適用于單個(gè)文件的情況。如果是多個(gè)文件共享的常量，蘋果推薦的這樣的方式
- UserInfoModelConstants.h
extern NSString *const BKUSER_AGE_KEY ;
extern NSString *const BKUSER_TELPHONE_KEY ;
extern NSString *const BKUSER_ADDRESS_KEY ;
extern NSString *const BKUSER_BRIEF_KEY ;
- UserInfoModelConstants.m
NSString *const BKUSER_AGE_KEY = @"XXXXX.userAge";
NSString *const BKUSER_TELPHONE_KEY = @"XXXXX.telphoneNO";
NSString *const BKUSER_ADDRESS_KEY = @"XXXXX.address";
NSString *const BKUSER_BRIEF_KEY = @"XXXXX.brief";
在需要使用共享常量的文件中引入UserInfoModelConstants.h即可。如果還有什么不足的地方希望大家指出。
以上只是我在閱讀別的帖子之后的一點(diǎn)體驗(yàn)和總結(jié)，如果有疑問(wèn)歡迎微博@藍(lán)光95_176探討！
