一般技术性平台的博客你都可以去尝试在上面写,iOS是属于技术性平台里面的分支,博客的内容都是垂直性地,所以没有存在专业与否的差别,只有对平台的选择的差别。而真正显现出博客主的专业程度的,是博客主里面的内容。故介绍几个活跃度,知名度都挺高的平台,你可以去尝试着发表,成与败看自身了。
创新互联建站拥有十年成都网站建设工作经验,为各大企业提供成都网站制作、成都网站设计、外贸营销网站建设服务,对于网页设计、PC网站建设(电脑版网站建设)、成都app软件开发公司、wap网站建设(手机版网站建设)、程序开发、网站优化(SEO优化)、微网站、域名申请等,凭借多年来在互联网的打拼,我们在互联网网站建设行业积累了很多网站制作、网站设计、网络营销经验,集策划、开发、设计、营销、管理等网站化运作于一体,具备承接各种规模类型的网站建设项目的能力。
CSND: 创立于1999年,中国最大的IT社区和服务平台,主要服务于软件开发者与IT从业者,有自成一套的周全体系。
博客园:创建于2004年1月,虽然诞生于一个小城市中,却仍旧获得了不错的发展。成长过程可谓励志。后来在上海创建了自己的团队,注册用户4w+,每日访问用户15w+,有博客,小组,博问,网摘,闪存,新闻频道,知识库和期刊多种区块。
开源中国:成立于2008年8月,主攻开源技术社区,200w+会员,有开源软件库、代码分享、资讯、协作翻译、码云、众包、招聘等几大模块内容。
blogspot:被收纳于Google,是国外的网站。首身是Pyra Labs公司创建的博客网站,提供网志书写和发布服务等功能,是全球最大、最为知名的博客服务提供商。
作为一个一个iOS底层开发小白,一直以来对于底层原理,都是一知半解的状态,希望从此时记录自己学习底层知识的过程,也希望对其他开发中可以有一个好的帮助,因为自己看其他人的博客时候,大多数作者都是基于自己认知的前提下,记录自己的知识,在我看来对于入门的人来说,非常晦涩难懂,所以希望自己的文章,可以更加帮助其他人循序渐进的了解更多关于 iOS 的知识。文章也会尽量一步步的探索更多业务开发之外的东西,对于任何方面的技能,都可以友善的帮助后来的开发者。文章中有任何错误,不恰当的地方,欢迎随时指正,多多交流才可以共同进步。想要学习 OpenGL 首先需要了解 OpenGL/OpenGL ES/Metal 三者之间的联系:
通俗来讲就是, Apple 作为大厂,肯定要发展自己的底层渲染技术,所以推出了 Metal ,在推出 Metal 之前,苹果的底层渲染也是基于 OpenGL/OpenGL ES 的,在 iOS 12.0以后,苹果摒弃了 OpenGL 的相关 API ,使用 Metal 作为自己的渲染技术,但是 OpenGL 相关的 API 依然可以使用,因为在 Metal 之前,苹果提供了非常丰富的关于使用 OpenGL 相关 API ,类似于苹果推出了 swift ,但是 OC 依然是自己主流语言一样。了解了相关的背景,我们接下来要知道图形 API 究竟是用来解决什么样的问题存在的。
OpenGL/OpenGL ES/Metal 在任何项目中解决问题的本质就是利用 GPU 芯片来高效的渲染图形图像。图形 API 是 iOS 开发者唯一接近 GPU 的方式。想要了解 OpenGL 就要先学习关于 OpenGL 的专业名词,了解了这些,才可以对以后的学习,有更加深刻的认识。
状态机在 OpenGL 可以这么理解, OpenGL 可以记录自己的状态(当前所使用的颜色、是否开启了混合功能等),可以接输入(当调用 OpenGL 函数的时候,实际上可以看成 OpenGL 在接受我们的输入),如我们调用 glColor3f ,则 OpenGL 接收到这个输入后会修改自己的“当前颜色”这个状态, OpenGL 可以进入停止状态,不再接收输入。在程序退出前, OpenGL 总会先停止工作;
这里有一个 iOS 中很经常听到的概念, 离屏渲染 ,很多人知道离屏渲染会对 APP 的性能造成较大的开销,但是却不知道原理是什么,相信大家了解了上面关于 OpenGL 关于交换缓冲区的概念后,有了一个更清晰的认识,即: Off-Screen Rendering 是需要开辟新的缓冲区的,不停地切换上下文的环境则是对性能的很大的消耗,所以在 iOS 开发中,我们应当尽量的避免离屏渲染。
在学习 OpenGL 的过程中,直接非常直观的掌握并理解这些概念并不是一件容易的事,但是至少需要在入门阶段,大致的了解这些概念的意思,然后通过后续的学习,慢慢的巩固前面学到的知识,温故而知新,一步步的打开关于 iOS 底层渲染知识的大门,学习的越来越深入,慢慢的回过头看以前的知识点的时候,就会豁然开朗了。
希望能一步步的记录自己学习的过程,慢慢进步,慢慢成长,文章中有任何错误的地方,欢迎指正。希望能多多交流,共同进步。
购买一个域名和虚拟主机。
博客程序选择wordpress或者zblog,很快就能搭建一个博客。
希望可以帮到你,有不清楚的可继续追问。
首先,需要明确你使用HTTP/HTTPS的用途,因为OSX和iOS平台提供了多种API,来支持不同的用途,官方文档《Making HTTP and HTTPS Requests》有详细的说明,而文档《HTTPS Server Trust Evaluation》则详细讲解了HTTPS验证相关知识,这里就不多说了。本文主要讲解我们最常用的NSURLConnection支持HTTPS的实现(NSURLSession的实现方法类似,只是要求授权证明的回调不一样而已),以及怎么样使用AFNetworking这个非常流行的第三方库来支持HTTPS。本文假设你对HTTP以及NSURLConnection的接口有了足够的了解。
验证证书的API
相关的Api在Security Framework中,验证流程如下:
1). 第一步,先获取需要验证的信任对象(Trust Object)。这个Trust Object在不同的应用场景下获取的方式都不一样,对于NSURLConnection来说,是从delegate方法-connection:willSendRequestForAuthenticationChallenge:回调回来的参数challenge中获取([challenge.protectionSpace serverTrust])。
2). 使用系统默认验证方式验证Trust Object。SecTrustEvaluate会根据Trust Object的验证策略,一级一级往上,验证证书链上每一级数字签名的有效性(上一部分有讲解),从而评估证书的有效性。
3). 如第二步验证通过了,一般的安全要求下,就可以直接验证通过,进入到下一步:使用Trust Object生成一份凭证([NSURLCredential credentialForTrust:serverTrust]),传入challenge的sender中([challenge.sender useCredential:cred forAuthenticationChallenge:challenge])处理,建立连接。
4). 假如有更强的安全要求,可以继续对Trust Object进行更严格的验证。常用的方式是在本地导入证书,验证Trust Object与导入的证书是否匹配。更多的方法可以查看Enforcing Stricter Server Trust Evaluation,这一部分在讲解AFNetworking源码中会讲解到。
5). 假如验证失败,取消此次Challenge-Response Authentication验证流程,拒绝连接请求。
ps: 假如是自建证书的,则会跳过第二步,使用第三部进行验证,因为自建证书的根CA的数字签名未在操作系统的信任列表中。
iOS授权验证的API和流程大概了解了,下面,我们看看在NSURLConnection中的代码实现:
使用NSURLConnection支持HTTPS的实现
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
// Now start the connection
NSURL * httpsURL = [NSURL URLWithString:@""];
self.connection = [NSURLConnection connectionWithRequest:[NSURLRequest requestWithURL:httpsURL] delegate:self];
//回调
- (void)connection:(NSURLConnection *)connection willSendRequestForAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge {
//1)获取trust object
SecTrustRef trust = challenge.protectionSpace.serverTrust;
SecTrustResultType result;
//2)SecTrustEvaluate对trust进行验证
OSStatus status = SecTrustEvaluate(trust, result);
if (status == errSecSuccess
(result == kSecTrustResultProceed ||
result == kSecTrustResultUnspecified)) {
//3)验证成功,生成NSURLCredential凭证cred,告知challenge的sender使用这个凭证来继续连接
NSURLCredential *cred = [NSURLCredential credentialForTrust:trust];
[challenge.sender useCredential:cred forAuthenticationChallenge:challenge];
} else {
//5)验证失败,取消这次验证流程
[challenge.sender cancelAuthenticationChallenge:challenge];
}
}
上面是代码是通过系统默认验证流程来验证证书的。假如我们是自建证书的呢?这样Trust Object里面服务器的证书因为不是可信任的CA签发的,所以直接使用SecTrustEvaluate进行验证是不会成功。又或者,即使服务器返回的证书是信任CA签发的,又如何确定这证书就是我们想要的特定证书?这就需要先在本地导入证书,设置成需要验证的Anchor Certificate(就是根证书),再调用SecTrustEvaluate来验证。代码如下
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
//先导入证书
NSString * cerPath = ...; //证书的路径
NSData * cerData = [NSData dataWithContentsOfFile:cerPath];
SecCertificateRef certificate = SecCertificateCreateWithData(NULL, (__bridge CFDataRef)(cerData));
self.trustedCertificates = @[CFBridgingRelease(certificate)];
//回调
- (void)connection:(NSURLConnection *)connection willSendRequestForAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge {
//1)获取trust object
SecTrustRef trust = challenge.protectionSpace.serverTrust;
SecTrustResultType result;
//注意:这里将之前导入的证书设置成下面验证的Trust Object的anchor certificate
SecTrustSetAnchorCertificates(trust, (__bridge CFArrayRef)self.trustedCertificates);
//2)SecTrustEvaluate会查找前面SecTrustSetAnchorCertificates设置的证书或者系统默认提供的证书,对trust进行验证
OSStatus status = SecTrustEvaluate(trust, result);
if (status == errSecSuccess
(result == kSecTrustResultProceed ||
result == kSecTrustResultUnspecified)) {
//3)验证成功,生成NSURLCredential凭证cred,告知challenge的sender使用这个凭证来继续连接
NSURLCredential *cred = [NSURLCredential credentialForTrust:trust];
[challenge.sender useCredential:cred forAuthenticationChallenge:challenge];
} else {
//5)验证失败,取消这次验证流程
[challenge.sender cancelAuthenticationChallenge:challenge];
}
}
建议采用本地导入证书的方式验证证书,来保证足够的安全性。更多的验证方法,请查看官方文档《HTTPS Server Trust Evaluation》
使用AFNetworking来支持HTTPS
AFNetworking是iOS/OSX开发最流行的第三方开源库之一,其作者是非常著名的iOS/OSX开发者Mattt Thompson,其博客NSHipster也是iOS/OSX开发者学习和开阔技术视野的好地方。AFNetworking已经将上面的逻辑代码封装好,甚至更完善,在AFSecurityPolicy文件中,有兴趣可以阅读这个模块的代码;
AFNetworking上配置对HTTPS的支持非常简单:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
NSURL * url = [NSURL URLWithString:@""];
AFHTTPRequestOperationManager * requestOperationManager = [[AFHTTPRequestOperationManager alloc] initWithBaseURL:url];
dispatch_queue_t requestQueue = dispatch_create_serial_queue_for_name("kRequestCompletionQueue");
requestOperationManager.completionQueue = requestQueue;
AFSecurityPolicy * securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeCertificate];
//allowInvalidCertificates 是否允许无效证书(也就是自建的证书),默认为NO
//如果是需要验证自建证书,需要设置为YES
securityPolicy.allowInvalidCertificates = YES;
//validatesDomainName 是否需要验证域名,默认为YES;
//假如证书的域名与你请求的域名不一致,需把该项设置为NO
//主要用于这种情况:客户端请求的是子域名,而证书上的是另外一个域名。因为SSL证书上的域名是独立的,假如证书上注册的域名是,那么mail.google.com是无法验证通过的;当然,有钱可以注册通配符的域名*.google.com,但这个还是比较贵的。
securityPolicy.validatesDomainName = NO;
//validatesCertificateChain 是否验证整个证书链,默认为YES
//设置为YES,会将服务器返回的Trust Object上的证书链与本地导入的证书进行对比,这就意味着,假如你的证书链是这样的:
//GeoTrust Global CA
// Google Internet Authority G2
// *.google.com
//那么,除了导入*.google.com之外,还需要导入证书链上所有的CA证书(GeoTrust Global CA, Google Internet Authority G2);
//如是自建证书的时候,可以设置为YES,增强安全性;假如是信任的CA所签发的证书,则建议关闭该验证;
securityPolicy.validatesCertificateChain = NO;
requestOperationManager.securityPolicy = securityPolicy;
这就是AFNetworking的支持HTTPS的主要配置说明,AFHTTPSessionManager与之基本一致,就不重复了。
3. 总结
虽然HTTPS相比于HTTP来说,会有一定的性能上的劣势,但对于网络飞速发展,移动设备的性能成倍增长的今天,安全才是我们更应该去考虑的。全网HTTPS并不是那么遥远。
唐巧建了个 iOS 开发的slack群组:iOS开发 Slack,里面有两个博客订阅的频道,中文一个,英文一个,都是已经挑选好的 Blog 订阅,不用自己重新甄选,省事有用!
另外唐巧也在维护一个 中文 iOS/Mac 开发博客列表:tangqiaoboy/iOSBlogCN · GitHub,外加 onevcat 喵神组织的 objc中国 翻译,基本涵盖了网络上优质的 iOS 中文文章了
国外:
Raywenderlich
NSHipster
Strings - objc.io issue #9
iOSDeveloperTips.com
Beginning iPhone App Development
Tuts+ Code Tutorials
Matt Gemmell
markj.net
mikeash.com: NSBlog
iOS App Dev Libraries, Controls, Tutorials, Examples and Tools
国内:
破船之家
代码手工艺人
唐巧的技术博客
iOS News
iWangKe.me
Lancy's Blog
不谈BUG、不谈信号,确实不能体现一部手机的实际作用,近年来苹果是踩了一些坑,因为专利问题而弃用了高通基带,导致iPhone信号严重变差,当然用户体验也变得比较的糟糕。
硬件问题显然是不能够利用iOS系统的更新去修复的,不然苹果也不会顶着“骂名”在经历几十个iOS版本的更新还是没有“修复”信号差这个通病,而高通因为和苹果的和解,最早只会2020年的6月份才开始在iPhone的新设备上进行装备。
本身的iOS系统也在iOS 13发布之后变成了BUG系统,机友现在只能够等待iOS 14新系统的到来才能弥补这许多的不足。
iOS从客观上来说是一个优秀的手机系统,就算不去仔细的分析其中的利弊,在如今各大手机厂商推出自己的系统UI之后还能保有一定的稳定市场,说明市场对iOS是认可的。从前有个笑言:“买苹果手机其实就是买iOS系统送手机”。
iPhone的可玩性很高,不单只是对其进行本身系统存在的功能上来说,从iPhone诞生后不久,BUG安全研究者、越狱工具开发者和苹果之间的相爱相杀持续了近十三年,越狱之后的iPhone能够借助插件为所欲为,实现原本没有的功能。虽然很多的插件让iPhone像安卓,但是他们会说:“像安卓的iPhone,你值得拥有”。
之前分享过iPhone安装Windows的消息,但是必须基于UTM虚拟机上安装,能够启用iPhone中70%的资源,对于大一点的系统就非常难受了,Windows 10的启动时间就超过了20分钟,这谁能忍。
不过,区别于正常使用手机,这就是叫做【玩机】,越狱也好、在iPhone上安装其他系统也好,都是属于研究作用的,稳定的工具可以让你把研究着去玩,但是也别忘记了,这是在非正常情况下使用手机,遇到众多的问题只能一步步的解决掉。
PostmarketOS手机操作系统是一款国外团队专门为旧手机准备的开源系统,现在已经支持超过139+款手机。开发出来的目的是为了应对厂商不对旧手机进行系统升级的情况。
这是基于Linux的操作系统,而安卓就是基于Linux内核创建的。
最近令人最振奋的消息就是国外的开发者将PostmarketOS移植到了iPhone 7上,而且最新的社区成果是做到了双分区!
什么意思?
就是能够在一部手机里同时存在两个系统,最终的效果是能够双启动手机系统。
这个本来是没有办法在iPhone手机安装的,由于checkm8硬件漏洞的发布,以及越狱工具checkra1n和Corellium的帮助下,真就被这群极客们在半年时间实现了。
安装方法开发者给的很全面,但是对于没有折腾心的机友来说确实是很难折腾成功,因为过程有点复杂。
千万不要用主力机做研究实验,可能会遇到不可撤销的错误。开发者博客上也说明了,虽然步骤已经过多次实验,证明可行,但是需要风险自担。
此处因为过程过于复杂和步骤太多,转述可能会有诸多错误,具体的方法和工具可以自行到开发者博客中查看,看不懂英语的可以使用浏览器的翻译功能进行查看。
开发者博客(复制全):
双启动实验: