cell点中是否变灰色不是由UITableView控制的,是由Cell本身控制的
@property (nonatomic) UITableViewCellSelectionStyle selectionStyle; // default is UITableViewCellSelectionStyleBlue.
并且由该枚举控制
typedef NS_ENUM(NSInteger, UITableViewCellSelectionStyle) {
UITableViewCellSelectionStyleNone,
UITableViewCellSelectionStyleBlue,
UITableViewCellSelectionStyleGray,
UITableViewCellSelectionStyleDefault NS_ENUM_AVAILABLE_IOS(7_0)
};
可以通过代码进行拉伸
// create a resizable version of this image. the interior is tiled when drawn.
- (UIImage *)resizableImageWithCapInsets:(UIEdgeInsets)capInsets NS_AVAILABLE_IOS(5_0);
// the interior is resized according to the resizingMod
- (UIImage *)resizableImageWithCapInsets:(UIEdgeInsets)capInsets resizingMode:(UIImageResizingMode)resizingMode NS_AVAILABLE_IOS(6_0);
需要注意的是UIEdgeInsets，这是一结构体，包含 上／左／下／右四个参数。上左下右4参数定义了cap inset，就是离四条边的距离。拉伸时，cap到边的部分不会被拉伸，其余部分则会被拉伸.尤其需要注意的是，拉伸的时候左右和上下是独立进行的,并不是轮廓的直接放大
如上图所示,为什么第二行出现了两个箭头
按照1的规则，拉伸的时候，水平和垂直方向都分别拉伸。这样在水平拉伸的时候，箭头其实处于用于拉伸的部分。在拉伸的时候，先按照原有的尺寸添加进去，不足的地方再把中间不拉伸的部分填充进去，周而复始，直到填充完毕。因此，就有上面的现象了。
如果用Xcaasets管理图片,那么拉伸可以用GUI的方式进行,如下图拉伸方式可以选择横向/双向/纵向三种,淡色的部分是需要被填充的部分,而第一和第二条卡尺线之间的深色的部分,则是被重复填充的镜像.
参考:
TableView中可以添加TableCell,而其主要通过两个协议进行Table的管理 <UITableViewDataSource,UITableViewDelegate>,可以通过阅读头文件详细了解
该协议中的两个函数是Table管理Cell必须的,分别是Table有多少行和每行是什么Cell
@required
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section;
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath;
这个协议中是主要定义了cell的选中功能函数,也包括一些其它optional功能,如果仅仅是展示性质的cell,可以不用用到
// Selection
- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath;
TableView中cell的复用是十分十分重要的一个知识点,几乎所有面试都会问吧
就是我有100行cell,但是不可能一页(Screen的高度)显示完,那么我可以制造一种假象,仿佛我有100行,但是实际只有20行,每当用户进行滑动,我就把滑出屏幕的cell,重新拼接到屏幕下方,展示给用户
首先看不采用复用方法的Cell生成,遵循UITableViewDataSource生成cell
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath{
NSString *cellIdentifier = [NSString stringWithFormat:@"cell%tu",indexPath.row];
UITableViewCell *cell = [[UITableViewCell alloc]initWithStyle:UITableViewCellStyleDefault reuseIdentifier:cellIdentifier];
return cell;
}
由以上函数可知,这是传统思维,给予每个cell一个identifer然后通过后缀的行数返回给Table每个cell,这样如果我有100行,我就有100个cell在内存里,这样无疑是十分消耗内存的
复用就是,我使用一个cellIdentifer展示100个cell,那么就要用到**dequeueReusableCellWithIdentifier:**函数
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath{
static NSString *cellIdentifier = @"cellID";
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:cellIdentifier];
if (cell == nil) {
cell = [[UITableViewCell alloc]initWithStyle:UITableViewCellStyleDefault reuseIdentifier:cellIdentifier];
}
return cell;
}
以上的复用过程主要过程是
那么如果采用复用方法,100行的cell会发生什么
需要注意的是,通常为了保障动画的流畅,10行可能需要12-15个cell进行复用
由于Cell本身就是一个View,所以不一定非得加载在Table中,普通的View也可以直接用
UITableViewCell *cell = [[UITableViewCell alloc]init];
[self.view addSubview:cell];
但是由于其不在UITableViewDelegate的tableView:didSelectRowAtIndexPath:中实现选中功能,所以其本身不能交互,需要进行设置
[cell setUserInteractionEnabled:YES];
而且又由于其不是button,并不能touchUpInside,所以需要通过添加手势来交互
UITapGestureRecognizer *gestureOnCell = [[UITapGestureRecognizer alloc]initWithTarget:self action:@selector(tapGestureOnAlbumCell:)];
[cell addGestureRecognizer:gestureOnCell];
感觉并不好用呢╮<(=╯-╰=)>╭ 但是可以省去自定义view,可以利用系统的样式,减少开发工作
[cell setAccessoryType:UITableViewCellAccessoryDisclosureIndicator];
[cell.textLabel setText:@"cellTitle"];
[cell.imageView setImage:[UIImage imageNamed:@"account_headImg_picture"]];
通过StoryBoard建立的视图,会在info.plist里有一个键值Main storyboard file base name,可以改更第一次启动的StoryBoard的文件
如果通过xib或者纯代码建立的视图,需要在AppDelegate.m里的 application:willFinishLaunchingWithOptions: 实现以下代码
1 | - (BOOL)application:(UIApplication *)application willFinishLaunchingWithOptions:(NSDictionary *)launchOptions { |
以上是旧版代码，新版代码 Application 里面内置了一个window对象,可以用 self.window
1 | var window: UIWindow? |
代码完成了以下工作
AppDelegate就是你的程序的委托,实现了iOS本身和你的App的一些交互,你的程序安装到iOS里,就会有一个指针指向你的App(猜测),大厅是委托者,你的App是执行者(iOS.delegate = app),遵循AppDelegate的Protocol.
所以说启动程序,就是大厅执行了一个函数启动并进入了你的App,伪代码可以理解成[iOS launchApp:app],就进入了你的程序.你的程序的所有代码对于iOS这个系统来讲,都在一个出不去的函数里.
对于iOS本身和你App的交互,都在AppDelegate的协议里进行,比如进入后台等等.
任何可视化程序,包括操作系统,都是由以下视图结构构成: DrawContext(Screen)-Window-View-Context, DrawContext就是C++里的DC,承载像素点.像素点组成Window,Window(窗口)里可以管理不同的View(视图),View本身是由Context(上下文组成)
官方文档为Understanding Windows and Screens
Window主要包括三个功能点
在iOS上WindowLevel分为三个等级,通常所有的窗口都是Normal,窗口的等级都是根据排序来的,越靠前越高,Mac上不清楚分几个等级.
const UIWindowLevel UIWindowLevelNormal;
const UIWindowLevel UIWindowLevelAlert;
const UIWindowLevel UIWindowLevelStatusBar;
由Window等级可以知道一个Screen可以有多个Window,最典型的就是类似Mac桌面操作系统上,或者说iOS的Alert是一个Window,同时还存在app的主Window.但是我们的交互(键盘,触摸)指令是发送给哪个Window呢,所以就有了KeyWindow的概念,就是MFC里的焦点窗口.
由于iOS的程序只有一个Window,所有的界面都是在不同的View上展示的,所以默认的Window就应该是KeyWindow.而当Alert弹出的时候,KeyWindow会转移到Alert的Window上,你的交互才能被Alert窗口响应KeyWindow掌控着响应者链条,如果你不是init一个和UIScreen一样大小的Window,在没有被Window覆盖的Screen或者View无法响应用户操作
就是让你在App启动后,初始化的Window窗口变成该app的KeyWindow,用来响应操作,然后通过Visible顶置到所有Window的最前
通常iOS只有一个Window,但是并不说不可以有两个Window,在通过外接屏幕的时候,可以让外接的屏幕作为第二个Window来展示信息(duetdisplay这个App),可以参考官方文档Using Windows to Present Content on Multiple Displays所以要Visible到最前
Category可以看作对一个Class的方法扩展,让扩展的方法通过原有的类名就可以调用,建立方法是在Xcode中add file里选.m文件,然后可以选择添加Category
比如我要经常创建一个特殊的View,那我应该怎么实现,可以通过继承和类目这两种形式实现.
如果使用继承,那么会新建一个叫MyView的类继承于UIView,通过以下调用
[MyView createCustomView];
但是这样的代码拿去给别人看的时候,别人如果不知道MyView继承于UIView怎么办,比如不叫MyView叫MyPic之类的乱七八糟的名字.
创建类目文件
//MyView的类目
UIView+MyView.h
UIView+MyView.m
在使用的时候如下调用方法
#import "UIView+MyView.h"
[UIView createCustomView];
如此可以让其它开发者更明白你创建的是什么,而且更利于代码的通用性.
正如上文所说,Category主要是用来扩展方法,其自身通常不声明属性,例如UIView的扩展仅能访问UIView.h里的属性.在你扩展的不仅仅是方法,还有属性的时候,还是继承比较好.
Category技术上可以被私有化,也可以声明属性
通常我们的私有属性都是放在.m的Extension里,又叫做Class-Continue
@interface Class ()
@end
这个Class-Continue/Extension本身就是一个无分类名称的分类,因为”()”中无任何字节,而所有外部的Category内无法使用,即使写入到外部Category的.m中编译无误,也无法访问内部属性.但是如果不新建新的.h/.m文件,而是和Class本身共用一个,那就可以访问.(例如UIView等内部的Category都是利用该原理,很多分类和UIView Class共用.h/.m文件)
Caution:Class-Continue/Extension仅可被Class自身访问,无法被Class-Category访问,除非!!Category与Class本身共用一个.h/.m文件
因为Category并没有自己的实例化函数,Class在实例化(init)的时候内部的Property会被@synthesis成_property的名字.但并不会去Category的函数进行处理,所以Category内部无法通过_property调用自己的函数,需要通过**self.**调用
- (void)setProperty:(id)property {
self.property = property;
}
- (id)property {
if(self.property) {
return self.property;
}
id tempProperty = [[Class alloc]init];
returen tempProperty;
}
- (void)logProperty {
NSLog(@"%@",self.property);
}
如果不对Category的属性重写Get/Set方法,那么将会造成class.categoryProperty访问该属性的时候就会Crash.
不成,如果手动写了**@systhesis**编译器会报Error
@synthesize not allowed in a category's implementation
Category的实质是另外一个类,这个类继承了被扩展类的public成员和方法,并且可以声明和实现自己成员和方法,唯一与继承不同的是,扩展的所有成员都是被扩展类的public成员,并且与被扩展类共用一个类名.
整数判断无非是大于等于小于,但是如果在取某些整数的取不到,可以通过NSNotFound判断,如取字符串range
NSRange range = [textField.text rangeOfString:@"."];
if (range.location == NSNotFound) {
//do something
}
static const NSInteger NSNotFound = NSIntegerMax;
#define NSIntegerMax LONG_MAX
#define LONG_MAX __LONG_MAX__
NSNotFound本身就是NSIntegerMax,NSIntegerMax则是__LONG_MAX__,也就是long类型的最大值.如果你通过断点观察,无效的NSInteger就是一个特别长的数.
参照以往的定义
const的作用：
static的作用
针对不同变量
在当前的”{}”内部有且仅有一份,且不会随着函数结束而被释放(作用1),函数多次被调用,始终保持同一内存地址同一值(作用2).
在当前文件中只有一份(作用1),即使声明在.h中,多个.m加载同一个.h,变量名称一样,但是实际地址是独立的(作用3),每个独立的变量多次调用始终保持同一地址(作用2)
extern的作用
static常用于TableViewCell的Identifer
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath{
static NSString *cellIdentifier = @"cell";//使用静态避免多次初始化
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:cellIdentifier];
if (cell == nil) {
cell = [[UITableViewCell alloc]initWithStyle:UITableViewCellStyleDefault reuseIdentifier:cellIdentifier];
}
return cell;
}
const和extern常用于全局的常量字符串,比如全局的通知字符串,其中UIKIT_EXTERN等于extern,如果不加UIKIT_EXTERN,需要加载定义的头文件,如果加了,只需要加载UIKit库就可以使用,不需要特意加载头文件
//.h
UIKIT_EXTERN NSString *const CallBackNotification;
//.m
NSString *const CallBackNotification = @"CallBackNotification";
结论:Xcode7.2中对字符串的处理static已经不用特意标记了,已经被默认.只要是通过@””创建的字符串,只要内容一样,都指向同一个内存.
根据以上概念,static修饰于局部变量的时候,会延长局部变量的生命周期,到底是延长多久呢?于是用以下代码测试.
//viewController.m
- (void)viewDidAppear:(BOOL)animated {
[super viewDidAppear:animated];
for (int i = 0; i < 10; ++i) {
[self printValue];
}
NSLog(@"weakPoint = %p",_otherWeakClass.weakPoint);
}
- (void)printValue {
static NSString *tempStr = @"xxx";
if (!_otherWeakClass.point) {
_otherWeakClass.point = tempStr;
NSLog(@"weakPoint get value");
}
NSLog(@"%p ==== %@,weakPoint = %p",tempStr,tempStr,_otherWeakClass.weakPoint);
}
- (void)dealloc {
NSLog(@"ViewController did dealloc %p",self);
}
//otherWeakClass.m
- (void)touchUpInsidePrintBtn:(UIButton *)button {
NSLog(@"_waekPoint = %p,value = %@",_waekPoint,_waekPoint);
}
在以上测试中,用一个ViewController中声明的static的字符串,然后用另外一个类的weakPoint指针指向它.在不同的地方打印字符串本身或者weakPoint.
然后奇怪的事情发生了(￣ε(#￣) ,和教科书上讲的不一样
无论何时打印weakPoint,总能得到和tempStr一样的值和地址,也就是说内存始终没有被释放,检查weakPoint指向内存的retainCount,得到的是18446744073709551615,也就是(2^64-1）.这是什么鬼＞﹏＜
2016-01-11 14:43:16.835 Learn[24725:3132909] weakPoint get value
2016-01-11 14:43:20.541 Learn[24725:3132909] 0x10b36e620 ==== xxx,weakPoint = 0x10b36e620
2016-01-11 14:43:20.542 Learn[24725:3132909] 0x10b36e620 ==== xxx,weakPoint = 0x10b36e620
2016-01-11 14:43:20.542 Learn[24725:3132909] 0x10b36e620 ==== xxx,weakPoint = 0x10b36e620
.......
2016-01-11 14:43:20.543 Learn[24725:3132909] 0x10b36e620 ==== xxx,weakPoint = 0x10b36e620
2016-01-11 14:43:20.543 Learn[24725:3132909] weakPoint = 0x10b36e620,value = xxx
为了验证教科书是否正确,用以下代码,代替了Static那一行,按说应该10次输出10个不同的地址
NSString *tempStr = @"xxx";
结果呢…..让我思密达了,输出还是一模一样的….地址仍然没有变,那我再换一种呢
NSString *tempStr = [NSString stringWithFormat:@"%@",@"xxx"];
这样总是重新初始化了吧…结果(´･ω･`)还是没变…难道Xcode坏掉了
NSString *str1 = @"xxx";
NSString *str2 = @"xxx";
NSLog(@"str1 address = %p, str2 address = %p",str1,str2);
于是写下这样的基本代码来测试…发现str1和str2地址还是一样的….(°ー°〃=)>书本上写的都喂狗了么….为什么会这样
于是打上断点,在控制台里,分别用print和print object指令打印不同的字符串,看看有什么不同
static NSString *tempStr = @"xxx";//__NSCFConstantString
NSString *tempStr = @"xxx";//__NSCFConstantString
NSString *tempStr = [NSString stringWithFormat:@"%@",@"xxx"];//NSTaggedPointerString
发现凡是通过@””创建的都是__NSCFConstantString的字符串,static根本就没鸟用啊…但是通过stringWithFormat创建的就是NSTaggedPointerString.这两个有啥差别呢
字符串常量，是一种编译时常量，它的 retainCount 值很大，是 4294967295，在控制台打印出的数值则是 18446744073709551615==2^64-1，测试证明，即便对其进行 release 操作，retainCount 也不会产生任何变化。是创建之后便是放不掉的对象。相同内容的 __NSCFConstantString 对象的地址相同，也就是说常量字符串对象是一种单例。
这种对象一般通过字面值 @”…”、CFSTR(“…”) 或者 stringWithString: 方法（需要说明的是，这个方法在 iOS6 SDK 中已经被称为redundant，使用这个方法会产生一条编译器警告。这个方法等同于字面值创建的方法）产生。
这种对象存储在字符串常量区。
这个类型是标签指针字符串，这是苹果在 64 位环境下对 NSString,NSNumber 等对象做的一些优化。简单来讲可以理解为把指针指向的内容直接放在了指针变量的内存地址中，因为在 64 位环境下指针变量的大小达到了 8 位足以容纳一些长度较小的内容。于是使用了标签指针这种方式来优化数据的存储方式。从他的引用计数可以看出，这货也是一个释放不掉的单例常量对象。在运行时根据实际情况创建。
对于 NSString 对象来讲，当非字面值常量的数字，英文字母字符串的长度小于等于 9 的时候会自动成为 NSTaggedPointerString 类型.
如果有中文或其他特殊符号（可能是非 ASCII 字符）存在的话则会直接成为 ）__NSCFString 类型。
这种对象被直接存储在指针的内容中，可以当作一种伪对象。
这个才是教科书上教的传统的字符串,和 __NSCFConstantString 不同， __NSCFString 对象是在运行时创建的一种 NSString 子类，他并不是一种字符串常量。所以和其他的对象一样在被创建时获得了 1 的引用计数。
通过 NSString 的 stringWithFormat等方法创建的中文NSString对象一般都是这种类型。
这种对象被存储在堆上。
如果按照以上分析,把字符串改为中文,并且用初始化的方法进行生成,打印结果就是10个不同的地址了.
- (void)printValue {
NSString *tempStr = [NSString stringWithFormat:@"%@",@"哈哈"];
if (!_otherWeakClass.point) {
_otherWeakClass.point = tempStr;
NSLog(@"weakPoint get value");
}
NSLog(@"%p ==== %@,weakPoint = %p",tempStr,tempStr,_otherWeakClass.weakPoint);
}
如果这个时候我在初始化方法前加入Static行不行
static NSString *tempStr = [NSString stringWithFormat:@"%@",@"哈哈"];
这个时候编译器会提示错误:
Initializer element is not a compile-time constant
初始化方法不是一个编译时的常量,也就是说static必须针对一个可以编译时就确定的变量,而不是运行时动态生成的.这也是为什么很少见UIView前加入static的原因.
如果static变量声明时必须是complie-time(编译时)的,是不是就无法使用运行时的变量了?其实也是可以的,只要在编译时给予static变量一个固定值就可以了
{
static UIView *view = nil;//编译时给予空指针,确定指针的地址
view = [[UIView alloc]init];//运行时进行初始化,改变指针指向的内容
}
如此就延长了view的指针自身地址的生命周期,但是其指向的内容是可以改变的.即使多次进入代码片段view指向的Object也不会被释放.有人会有疑问,多次进入代码static那一行赋值不会再次赋值么?就如同编译器提示的一样,static是编译时语句,只有编译时被执行,运行时不会被执行,所以不会赋值nil多次
如果在同一个文件不同的函数中(局部变量),仅仅是针对该局部延长了生命周期,即使两个函数中的static变量都叫view,两个view并不在同一个地址,是两个独立的Object
- (void)functionOne {
static UIView *view = nil;
view = [[UIView alloc]init];
[view setBackgroundColor:[UIColor red]];
}
- (void)functionTwo {
static UIView *view = nil;//编译时给予空指针,确定指针的地址
view = [[UIView alloc]init];//运行时进行初始化,改变指针指向的内容
[view setBackgroundColor:[UIColor blue]];
}
在不同的.m文件中,由于.m之间是互相不可见的,所以static限定作用域的作用就基本无用了,和普通的全局变量一样.
static UIView *_view = nil;
@implementation Class
- (void)functionOne {
_view = [[UIView alloc]init];
}
@end
但是如果在.h文件中生命static的变量
//Class.h
static UIView *_view = nil;
@interface Class
- (void)functionOne;
@end
然后不同的点.m文件加载同一个.h
//Class1.m
#import "Class.h"
//Class2.m
#import "Class.h"
此时Class1.m中的全局变量_view和Class2.h中的全局变量_view不为同一个地址,两个的初始化是独立的.
同时在全局和局部声明static
static UIView *_view = nil;
@implementation Class
- (void)functionOne {
NSLog(@"%@",_view);//输出为nil
_view = [[UIView alloc]init];
NSLog(@"%@",_view);//输出为地址1
static UIView *_view = nil;//由于运行时不会执行,所以仍为全局的_view,地址1
NSLog(@"%@",_view);//输出仍为地址1
}
@end
全局声明static,局部声明同名临时变量.
static UIView *_view = nil;
@implementation Class
- (void)functionOne {
NSLog(@"%@",_view);//输出为nil
_view = [[UIView alloc]init];
NSLog(@"%@",_view);//输出为地址1
UIView *_view = nil;//由于运行时执行,所以从此行往下都是局部变量_view,往上的_view则为全局变量
NSLog(@"%@",_view);//输出为nil,打印的为局部变量
}
@end
如果我想自定义一个View,里面包含一个Label和一个Button,外界可以修改Label和Button的样式,如何定义
@property (nonatomic, strong) UIButton *button;
@property (nonatomic, strong) UILabel *label;
如果按照上文定义,因为存在Set函数,所以说可以用外界实例化的button和label进行Set,可能会影响到内部的处理,为了保护button和label不被更改,需要声明readonly
@property (nonatomic, strong, readonly) UIButton *button;
@property (nonatomic, strong, readonly) UILabel *label;
声明了readonly之后,虽然button和label无法通过Set更改,但是由于label本身的title这个属性不是readonly的,所以仍然可以更改
[view.label setTitle:@"change"];
但是这样就不行
[view setLabel:label];
Property的readonly并不会传递,声明为readonly的property如果还有下一级property不为readonly,下一级的property还是可以改变的
UIButton里的image和label,就是利用这个原理
缺失模块。
1、请确保node版本大于6.2
2、在博客根目录（注意不是yilia根目录）执行以下命令：
npm i hexo-generator-json-content --save
3、在根目录_config.yml里添加配置：
jsonContent:
meta: false
pages: false
posts:
title: true
date: true
path: true
text: false
raw: false
content: false
slug: false
updated: false
comments: false
link: false
permalink: false
excerpt: false
categories: false
tags: true