今天遇到了个挺离奇的问题，丫的，设的圆角总是缺了个角。
上图
眼看，因为一直感觉总是左边圆缺的那一块，就是右边圆多的那一块，所以一直查代码，觉得原因出在前后两个空间重叠了。
到了把两个圆拉到很远了，丫的，还是不圆，我就奔溃了··
耗了很久，才发现与画圆角算法无关，是像素点惹的祸！
像素对不齐！
一开始以为是高度是奇数出问题
因为是做全圆角的，所以角度是取1/height,当时height = 21,在retina屏，21*2 = 42,偶数。 其实关系不大。
影响效果最大是宽度的值太精确了
之前之所以一直没遇到过这个问题，莫过于，正常情况下，我们都把宽高写死了，都是用那些很正常的整数吧，自己不会故意把值设成30.78这么奇葩吧···，
小数取整，在C语言有几种选择：
书读了一遍，还在我桌面，希望有空能常翻翻回味回味，有新参透也在这里补充。
发现一个bug,或者代码不工整的地方，立马fix好。若留着不修，破窗子会越来越多，这样整个项目会慢慢恶化腐烂下去。
重复分为强加性重复，无意性重复，无耐性重复以及开发人员之间的重复。觉得最容易重复的是无耐性重复，因为相同的动作、需求，去拷贝一个大致相同的函数，修改一些参数去实现类似的功能，看似合理又省事，但的确会留下隐患（将来有改动就得处处改了）。应更多考虑用设计模式来优化代码结构。如项目中WebService 中内聚处理了接口返回码resCode,内聚处理网络错误提示，而不是每次请求都重复去判断resCode == 1；开发人员之间的重复，就涉及代码架构同分工了，最明显的就是重复造轮子，事倍功半。
该术语表示某种不相依赖性或者解耦性。如果两个或更多食物中的一个发生变化，不会影响其他事物，这些事物就是正交的。在设计良好的系统中，数据库代码与用户界面是正交的：你可以改动界面，而不影响数据库；更换数据库，而不用改动接界面。
Eliminate Effects Between Unrelated Things (消除无关事物之间的影响)
设计自足（self-contained）的组件:独立，具有单一，良好定义的目的（内聚性）。如果组件是相互隔离的，你就知道你能够改变其中之一，而不用担心其余组件。只要你不改变组件的外部接口，就不会造成波及整个系统的问题。
there are no final decisions,不存在最终决策。
设计灵活的结构去保证需求的变动不至于致命。这样的结构最大的特点是具有正交性，即常说的内部低耦合，层层分离。
刚好碰到一个切身相关的例子：这段时间需要将项目的sdk换成欢聚云的sdk,才发现项目之初，就已经把原来用的sdk封装了一层model，再去用。这样巧妙的设计让现在换sdk的时候只需到封装的那层model改就可以了。不然，要是以前一开始就各自为政，随意到处调用sdk的话，就得跑去UI层去处处改就GG了T.T
主要实现了组件间（模块间）端到端的连接，用以检查你离目标有多远，并在必要的情况下进行调整。
拽光代码并非用过就扔的代码：你编写它，就是为了保留它。它含有任何一段产品代码都拥有的完整个的错误检查、结构、文档以及自查。只是功能不全而已。
虽然简约但是完整，并且构成了最终系统骨架的一部分。
用过就扔的代码，或者就是用笔画出来的草图
可以为下列情况制作原型：
checkList:
语言的界限就是一个人世界的界限
简称DBC,软件系统中的每一个函数和方法都会做某件事情。在开始做某事之前，例程对世界的状态可能有某种期望，并且也可能有能力陈述系统结束时的状态。
Design with Contracts.
在“正交性”中，我们建议编写“羞怯”的代码。这里，强调的重点是在“懒惰”的代码上：对在开始之前接受的东西要严格，而允诺返回的东西哟啊尽可能少。记住，如果你的合约表明你将接受任何东西，并允诺返回整个世界，那你就有大量代码要写了。
在设计时简单地列举输入域的范围是什么、边界条件是什么、例程允诺交付什么，—或者不允诺交付什么。不对这些事项作出陈述，你就回到了靠巧合编程，那是许多项目开始、结束、失败的地方。
谁负责检查前条件，是调用者，还是被调用的例程？如果作为语言的一部分实现，答案是两者都不是：前条件是在调用者调用例程之后，但在进入例程自身之前，在幕后测试的。因而如果要对参数进行任何显示的检查，就必须由调用者来完成。
无论何时你发现自己在思考“但那当然不可能发生”，增加代码检查他。最容易的方法是使用断言
if it can’t happen, Use Assertions to ensure that it won’t.
不仅仅在测试环境打开断言，书中更倾向于生产环境也把断言开着，只把那些特别影响性能的断言关掉。
异常很少应作为程序的正常流程的一部分使用；异常应保留给意外事件。假定某个未被抓住的异常会终止你的程序了，问问你自己：“如果移走所有的异常处理器，这些代码是否仍然能运行？”如果答案是“否”，那么异常也许就正在被用在非异常的情形中。
e.g. 你的代码试图打开一个文件进行读取，而该文件并不存在，是否应该引发异常，这里分2种情况讨论：
Use Exceptions for Exceptional Problems.
异常表示即时的、非局部的控制转移。
如果把异常当成正常流程处理的话，代码的可读性和可维护性将受到打击。
错误处理器是检测到错误调用的例程。
e.g-》p105 遵循谁打开，谁关闭，谁分配，谁释放原则。与iOS早期的MRC思想一样。
保持灵活的一种方法是少写代码。改动代码会使你引入新bug的可能性增大。
个人觉得减少重复，减少硬编码的意思。
把你的代码组织成最小组织单位（模块），并限制他们的交互。
Minimize Coupling Between Modules
百科了一下
很多面向对象程序设计语言用”.”表示对象的域的解析算符，因此得墨忒耳定律可以简单地陈述为“只使用一个.算符”。因此，a.b.Method()违反了此定律，而a.Method()不违反此定律。一个简单例子是，人可以命令一条狗行走（walk），但是不应该直接指挥狗的腿行走，应该由狗去指挥控制它的腿如何行走。
public void show Balance (BankAccount acct)
{
Money amt = acct.getBalance();
printToScreen(amt.printFormat());
}
acct 为传入参数对象，可以调用acc.getBalance(),但amt.printFormat()就相当于acc.getBalance().printFormat(), 即a.b.Method(),违反了得墨忒耳定律，因此，可略去中间Money对象，直接在BankAccount中新增个printBalance()方法即可。
public void show Balance (BankAccount acct)
{
acct.pintBalance();
}
实践中，其实就意味着编写大量的包装方法，让一个包工头类将请求转发给下面的分工。
一句话就是模块之间仅仅暴露有限 关键信息，作最少交互。
使系统变得高度可配置，用元数据描述应用的配置选项。（这里说得有点像OSX 的系统偏好设置吧？）
put Abstractions in Code, Details in Metadata
Always Design for Concurrency
本书对并发非常看重，还给了个将流程工作向并发操作的小tips:
Analyze Workflow to Improve Concurrency
将需求流程转化为UML图，其中没有指入箭头的项目可以考虑并发操作。
要清楚，我们身处雷区，如果依靠巧合编程，就如同在雷区碰运气排雷一样，随时爆炸身亡了。
这个雷我上个月就踩过。
当时意识不够，没意识到线上环境是如此大凶险的，擅自用uid为key存储数据了。在开发这个版本的时候，一直没出问题，想当然地认为产品上线也会顺顺利利的，殊不知，在n个版本之前，已经有同事用过uid来存储另一种类型的数据了，尽管这个数据早在版本迭代中废弃没用了，但一直存在与用户机器中。而OC 恰恰又是动态语言，不管你代码写他是什么，数据类型要到运行时才能确定···。
种种巧合在这个时间点堆砌起来，bang的一声，就这样炸开了。
好了，言归正传，巧合编程主要包括实现的偶然性，语境的偶然性和隐含的假定。
当初我犯了实现的偶然性和隐含的假定。假定了在我之前没人用过uid作key存过数据，况且既然版本测试没问题了，就真的没问题了。
把需要重构的代码当做是一种“肿瘤”，你现在可以手术，趁它还小把它取出来，你也可以等他增大并扩散—但那时再切除它就会更昂贵、更危险。等再久一些，“病人”就有可能会丧命。
在隔离状态下，对每个模块进行测试，目的是检验其行为。
软件的单元测试，是指对模块进行演练的代码。
编写测试代码，确保给定的单元遵守其合约。通过广泛的测试用例与边界条件，测试模块是否实现了它允诺的功能。
测试模块之间相互依赖的情况：
依赖于LinkedList 和 Sort 的模块 A
之前听过很多大牛的分享，都很强烈使用单元测试。我们项目是否也考虑下引入？
需求很少存在于表面上。通常，他们深深埋藏在层层假定、误解和政治手段的下面
Don’t gather requirements - Dig for them
Work with a User to think like a User
当遇到一些合适的、描述应用需要做什么的情景，把它们写下来，并发布，每个人都可以以此为据用作讨论的基础文档—开发者、最终用户、以及项目出资人。
可以用UML活动图捕捉工作流，而且有时要为手边的事务建模。概念图很有用，但真正的用例是具有层次结构和交叉链接的文字描述，用例间可以互相嵌套。
制作需求文档的一大危险是太过具体，好的需求文档会保持抽象，在涉及需求的地方，最简单的、能准确地反应商业需求的陈述是最好的。这并非意味着可以含糊不清—你必须把底层的语意不变项当做需求进行捕捉，并把及的或当前的工作实践当做政策记入文档。
需求不是架构，需求不是设计，也不是用户界面
一旦开始讨论需求，用户和领域专家就会使用对他们有特定含义的属于。e.g.“客户”和“顾客”。
要创建并维护项目词汇表（project glossary）—定义项目中使用专业术语的地方。项目的所有参与者，从最终用户到设计人员，都应该使用这个词汇表，以确保一致性。
秘诀是确定真正的（而不是想象的）约束，并在其中找出解决方法。有些约束是绝对的；有些则只是先入之见。
Don’t think Outside the Box — find the box.
构建原型，选择一个你觉得会有困难的地方，开始进行某种“概念验证”。在典型情况下，可能会发生两种情况：
编写程序规范就是把需求规约到程序员能够接管的程度的过程。这是个交流活动，旨在解释并澄清系统的需求。
没有给编码者留下任何解释余地的设计会剥夺了他们发挥技巧和艺术才能的权利。
Don’t be a slave to Formal Methods
Expensive TOOls do not Produce Better Designs
注重实效的程序员批判的看待方法学，并从各种方法学中提取精华，融合成一套工作习惯。
你应该不断努力提炼和改善你的开发过程。绝不要把方法学的代办限制当做你的世界的边界。
一旦参与项目的人员超过一个，你就需要建立一些基本原则，并相应地分派任务。
确保每个人主动监视环境的变化—监视好任何不在最初约定中的东西。
按照功能划分团队。让各团队按照个人的能力，在内部自行进行组织。每个团队都按照他们约定的承诺，对项目中的其他团队富有责任。
我们是在需求内聚的、在很大程序上自足的团队—和使代码模块化是使用的标准完全一样
开发过程中就要找到自己的bug,以免以后经受由他人找到我们的不过所带来的羞耻。
test early, test often, test automatically.
好的项目拥有的测试代码可能比产品代码还要多。
coding ain’t done till all the tests run
对某个模块进行演练的代码
检测多个模块所组成的系统的集成问题
是否用户所需？是否满足系统的功能需求？
代码可能遇到的一些限制包括：
use Saboteurs to test your Testing
故意引入bug,并证实测试能抓住他们
test state Coverage, Not code Cerage
测试尝试去覆盖所有代码的状态。
任何产品代码一旦存在，就需要进行测试
大多数测试都应该自动完成。
一旦测试人员找到了某个bug,应该对自动化测试进行修改，从此每次都自动化的检查那个特定的bug
为项目制作的文档基本上有两种：内部文档和外部文档。
注释应该讨论为何做某事、它的目的和目标（因为代码已经说明他是怎么完成的）。
我们喜欢看到见得模块级头注释、关于重要数据与类型的注释、以及给每个类和没个方法所加的简要头注释，用以描述函数的用法和任何不明了的事情。
注重实效的程序员不会逃避责任。相反，我们乐于接受挑战，乐于是我们的专业知识广为人知。
不应该怀着猜忌心组织要查看你的代码的人；出于同样的原因，你应该带着尊重对待他人的代码。
支付宝首页tableView的大概有如下几个特点：
而单纯的tableHeaderView,sectionHeader啊，是无法实现这两个功能的。
以下是我的实现思路：
1 创建一个View，作为“headerView”
- (void)initHeaderView
{
_headerView = [[MyHeaderView alloc] initWithFrame:CGRectMake(0, 64, DRScreenWidth, HeaderViewHeight)];
_headerView.backgroundColor = [UIColor yellowColor];
[self.view addSubview:_headerView];
}
2 创建tableView,将其contentInset设在headerView下沿
- (void)initTableView
{
_tableView = [[UITableView alloc] initWithFrame:CGRectMake(0, 0, DRScreenWidth, DRScreenHeight) style:UITableViewStylePlain];
_tableView.dataSource = self;
_tableView.delegate = self;
_tableView.backgroundColor = [UIColor purpleColor];
_tableView.contentInset = UIEdgeInsetsMake(HeaderViewHeight, 0, 0, 0);
[_tableView addObserver:self forKeyPath:@"contentOffset" options:NSKeyValueObservingOptionNew context:nil];
[self.view addSubview:_tableView];
}
看到这里，可能有的读者会有疑问，
_tableView.contentInset = UIEdgeInsetsMake(HeaderViewHeight, 0, 0, 0);
这句有何意义呢？干嘛不直接把tableView的frame放在headerView下面就好了？
其实这句大有玄机。我们继续看HeaderView里面究竟实现了什么。
- (instancetype)initWithFrame:(CGRect)frame
{
self = [super initWithFrame:frame];
if (self) {
[self initBtn];
[self addObserver];
}
return self;
}
- (void)addObserver
{
[self addObserver:self forKeyPath:@"frame" options:NSKeyValueObservingOptionNew context:nil];
}
#pragma mark - KVO
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary<NSKeyValueChangeKey,id> *)change context:(void *)context
{
CGRect rect = [change[NSKeyValueChangeNewKey] CGRectValue];
NSLog(@"head view height = %f",rect.size.height);
CGFloat height = rect.size.height;
if (height < visibleOffset) {
_btn.hidden = YES;
_aView.hidden = YES;
} else {
_btn.hidden = NO;
_aView.hidden = NO;
}
}
这里的kvo主要是为了通过监听frame的变化来控制subView的显影。
而下面这句才能解释上面那个问题：
#pragma mark - touch
- (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event
{
UIView *view = [super hitTest:point withEvent:event];
if ([view isKindOfClass:[self class]]) {
return nil;
}
return view;
}
重写了hittest,反正让用户怎么也摸不到自身！就是为了解决当触摸点在headerView上面的时候，hitTest返回对象是跌在他下面的tableView,来让tableView响应滑动。
好了，回到正题。
我们好像还没实现初衷的3个特性。
第1，2点也是通过KVO来改变headerView的height或origin.y实现的。
首先看看改变height：
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary<NSKeyValueChangeKey,id> *)change context:(void *)context
{
if ([keyPath isEqualToString:@"contentOffset"]) {
CGPoint offset = [change[NSKeyValueChangeNewKey] CGPointValue];
NSLog(@"KVO:%f",offset.y);
if (offset.y > -(HeaderViewHeight +navigationBarHeightPlusStatusBarHeight) && offset.y < -navigationBarHeightPlusStatusBarHeight) {
CGRect frame = _headerView.frame;
frame.size.height = - navigationBarHeightPlusStatusBarHeight - offset.y;
_headerView.frame = frame;
} else if (offset.y <= -(HeaderViewHeight +navigationBarHeightPlusStatusBarHeight)) {
//tableView下滑，headerView保持不变
_headerView.frame = CGRectMake(0, navigationBarHeightPlusStatusBarHeight, DRScreenWidth, HeaderViewHeight);
} else if (offset.y >= -navigationBarHeightPlusStatusBarHeight) {
//tableView上滑，直到两者上沿重叠，headerView高度设0
_headerView.frame = CGRectMake(0, navigationBarHeightPlusStatusBarHeight, DRScreenWidth, 0);
}
}
}
上面的逻辑很清楚了，主要是通过改变headerView的高度，来造成headerView随tableView滑动的错觉。
当然，也可以改变HeaderView的y来实现。
看代码：
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary<NSKeyValueChangeKey,id> *)change context:(void *)context
{
if ([keyPath isEqualToString:@"contentOffset"]) {
CGPoint offset = [change[NSKeyValueChangeNewKey] CGPointValue];
NSLog(@"KVO:%f",offset.y);
if (offset.y > -(HeaderViewHeight +navigationBarHeightPlusStatusBarHeight) && offset.y < -navigationBarHeightPlusStatusBarHeight) {
CGRect frame = _headerView.frame;
frame.origin.y = fabs(offset.y) - HeaderViewHeight;
_headerView.frame = frame;
} else if (offset.y <= -(HeaderViewHeight +navigationBarHeightPlusStatusBarHeight)) {
_headerView.frame = CGRectMake(0, navigationBarHeightPlusStatusBarHeight, DRScreenWidth, HeaderViewHeight);
} else if (offset.y >= -navigationBarHeightPlusStatusBarHeight) {
_headerView.frame = CGRectMake(0, -HeaderViewHeight+navigationBarHeightPlusStatusBarHeight, DRScreenWidth, HeaderViewHeight);
}
}
}
最后，就是第3个特性了：
#pragma mark - scrollview delegate
- (void)scrollViewWillEndDragging:(UIScrollView *)scrollView withVelocity:(CGPoint)velocity targetContentOffset:(inout CGPoint *)targetContentOffset
{
// NSLog(@"willENdDragging:%f",scrollView.contentOffset.y);
if (targetContentOffset->y > -132 && targetContentOffset->y < -navigationBarHeightPlusStatusBarHeight) {
*targetContentOffset = CGPointMake(0, -navigationBarHeightPlusStatusBarHeight);
} else if (targetContentOffset->y <= -132 && targetContentOffset->y > -(navigationBarHeightPlusStatusBarHeight + HeaderViewHeight)) {
*targetContentOffset = CGPointMake(0, -(navigationBarHeightPlusStatusBarHeight + HeaderViewHeight));
}
}
实现这个代理就👌。关于这个代理详细可看我上一篇文章UITableView串烧
- (void)scrollViewWillEndDragging:(UIScrollView *)scrollView withVelocity:(CGPoint)velocity targetContentOffset:(inout CGPoint *)targetContentOffset
{
//这里将注意力放在targetContentOffset 存取就好了，设置这个滑动去指定Offset
if (targetContentOffset -> y < aValue) {
*targetContentOffset = CGPointMake(expectX, expectY);
}
}
velocity.y > 0 有向下划的趋势
velocity.y > 0 有向上滑的趋势
项目中的具体情况没有这么简单，tmd外面一个大tableView，cell里面又装着好几个tableView ,这就需要用delegate 或者 notification由下至上，将这个回调传递给最外层的controller了。
//_tableView : 大tableView,
//scrollView：cell里面装的tableView,小tableView
//maxOffsetY: 大tableView能滑动的最大位置，可用大tableViewContentSizeY - 小tableView.frame.height
//originOffsetY:大tableView的originOffsetY
- (void)innerTableViewDidScroll:(UIScrollView *)scrollView
{
CGPoint scrollViewPoint = scrollView.contentOffset;
CGPoint detailTableviewContentOffset = _tableView.contentOffset;
//需要设置maxOffset 和 originalOffsetY即可
CGFloat maxOffsetY = headerViewHeight - 64;
if (scrollViewPoint.y > 0 && detailTableviewContentOffset.y < maxOffsetY) {
CGFloat detailTableViewContentOffsetY = originalOffsetY;
if (scrollViewPoint.y + detailTableviewContentOffset.y < maxOffsetY) {
detailTableViewContentOffsetY = scrollViewPoint.y + detailTableviewContentOffset.y;
} else {
detailTableViewContentOffsetY = maxOffsetY;
}
[_tableView setContentOffset:CGPointMake(detailTableviewContentOffset.x, detailTableViewContentOffsetY)];
CGRect scrollViewBounds = scrollView.bounds;
scrollViewBounds.origin = CGPointZero;
scrollView.bounds = scrollViewBounds;
}
if (scrollViewPoint.y < 0 && detailTableviewContentOffset.y > 0) {
CGFloat detailTableViewContentOffsetY = originalOffsetY;
if (scrollViewPoint.y + detailTableviewContentOffset.y > 0) {
detailTableViewContentOffsetY = scrollViewPoint.y + detailTableviewContentOffset.y;
} else {
detailTableViewContentOffsetY = originalOffsetY;
}
[_tableView setContentOffset:CGPointMake(detailTableviewContentOffset.x, detailTableViewContentOffsetY)];
CGRect scrollViewBounds = scrollView.bounds;
scrollViewBounds.origin = CGPointZero;
scrollView.bounds = scrollViewBounds;
}
NSLog(@"container tableview contentOffset:%f", scrollViewPoint.y);
}
使用时需要设置maxOffset 和 originalOffsetY即可
还有这3行值得注意的：
CGRect scrollViewBounds = scrollView.bounds;
scrollViewBounds.origin = CGPointZero;
scrollView.bounds = scrollViewBounds;
每次移动后记得将origin 归零。
- (void)scrollViewDidScroll:(UIScrollView *)scrollView
{
CGFloat scrollOffsetY = scrollView.contentOffset.y;
[self setNavigationBarAlphaWithContentOffset:scrollOffsetY];
}
- (void)setNavigationBarAlphaWithContentOffset:(CGFloat)y
{
_navigationBar.alpha = y / (headerViewHeight - 64);
}
当navigationBar 下沿到达 headerViewHeight 的下沿时，navigationBar.alpha = 1;
需要注意的，分母记得减去statusbarheight(20) + navigationBarHeight(44)
简要言之，就是CF(core foundation) 和 Foundation 之间的某些对象可以无缝强制转换。
e.g. NSLocale 和 CFLocaleRef ,强转就可以直接用了！
NSLocale *gbNSLocale = [[NSLocale alloc] initWithLocaleIdentifier:@"en_GB"];
CFLocaleRef gbCFLocale = (__bridge CFLocaleRef)gbNSLocale;//不转移所有权，还是归arc管理计数
CFStringRef cfIdentifier = CFLocaleGetIdentifier(gbCFLocale);
NSLog(@"cfIdentifier: %@", (__bridge NSString *)cfIdentifier);
// Logs: "cfIdentifier: en_GB"
CFLocaleRef myCFLocale = CFLocaleCopyCurrent();//有copy,create等字眼，就拥有了cf对象了，需要手动管理计数
NSLocale *myNSLocale = (NSLocale *)CFBridgingRelease(myCFLocale);//所用权移交arc
NSString *nsIdentifier = [myNSLocale localeIdentifier];
CFShow((CFStringRef)[@"nsIdentifier: " stringByAppendingString:nsIdentifier]);
普通的bridge oc->cf，是不用手动管理计数的。
根据wwdc2012,有create，copy或__bridge_retained等字眼，才需要手动CFBridgingRelease()。
参考：
https://stackoverflow.com/questions/14064336/arc-and-cfrelease
@protocol TimingFuntionImp<NSObject>
-(CGFloat)update:(CGFloat)t;
@end
@interface TimingFuntionLinear : NSObject<TimingFuntionImp>
@end
@interface TimingFuntionEaseIn : NSObject<TimingFuntionImp>
@end
@interface TimingFuntionEaseOut : NSObject<TimingFuntionImp>
@end
@interface TimingFuntionEaseInOut : NSObject<TimingFuntionImp>
@end
@implementation TimingFuntionLinear
-(CGFloat)update:(CGFloat)t
{
return t;
}
@end
@implementation TimingFuntionEaseIn
-(CGFloat)update:(CGFloat)t
{
return powf(t, rateConstant);
}
@end
@implementation TimingFuntionEaseOut
-(CGFloat)update:(CGFloat)t{
return 1.0-powf((1.0-t), rateConstant);
}
@end
@implementation TimingFuntionEaseInOut
-(CGFloat) update: (CGFloat) t
{
t *= 2;
if (t < 1)
return 0.5f * powf (t, rateConstant);
else
return 0.5f * (2.0f - powf(2.0 - t, rateConstant));
}
@end
原理挺简单，无非就是用一次函数，幂函数的图像来理解，重拾一下高中数学知识。。
（1）加载内存当中之后，会一直停留在内存当中，不会随着对象的销毁而销毁。
（2）加载进去图片之后，占用的内存归系统管理，我们无法管理。
（3）相同的图片，图片不会重复加载。
（4）加载到内存中后，占据内存空间较大。
（1）加载到内存当中后，占据内存空间较小。
（2）相同的图片会被重复加载内存当中。
（3）对象销毁的时候，加载到内存中图片会随着一起销毁。
imageName：由于一直停留在ram,所以更适合于经常用到的,且不太大的图片。
而imageWithContentsofFile：更适合用于图片数据较大的情况,且比较少用到的情况。
+ (UIImage *)imageNamed:(NSString *)imageName withBundleName:(NSString *)bundleName
{
NSBundle *bundle = [self bundleNamed:bundleName];
if (SystemLessThan(8.0)) {
NSString *path = [[bundle resourcePath] stringByAppendingPathComponent:imageName];
UIImage *image = [UIImage imageWithContentsOfFile:path];
return image;
}
else {
return [UIImage imageNamed:imageName inBundle:bundle compatibleWithTraitCollection:nil];
}
}
+ (NSBundle *)bundleNamed:(NSString *)bundleName
{
NSString *bundlePath = [[NSBundle mainBundle] pathForResource:bundleName ofType:@"bundle"];
return [NSBundle bundleWithPath:bundlePath];
}