区块链技术博客
www.b2bchain.cn

iOS开发笔记(十四)求职学习资料

本文介绍了iOS开发笔记(十四)求职学习资料,有助于帮助完成毕业设计以及求职,是一篇很好的资料。

对技术面试,学习经验等有一些体会,在此分享。

前言

分享iOS开发中遇到的问题,和相关的一些思考。

正文

CocoaPod

最近有位同学在项目中添加了一个调试工具XXKitDebug,但是不想在线上开启,于是通过configurations进行区分,仅在’Debug’ 和 ‘DailyBuild’ 引入。(线上版本configurations是distribution)

pod_binary 'XXKitDebug','0.0.2', :configurations => ['Debug', 'DailyBuild']

然后在代码中通过宏定义来描述:

- (void)onShowDebugPage { #if __has_include(<XXKitDebug/XXKitDebug.h>)     [XXKitDebug showDebugPage]; #endif }

这段__has_include是否能够在Distribution情况下屏蔽下面的代码?

答案是:不可以,会出现链接失败。

官方文档有关于__has_include的说明,是通过检查指定的文件,是否能够正常引入来进行。
但是Podfile的解析和执行是在pod install的时候,此时并不知道将来的build的configuration,CocoaPod的解决办法是针对不同的configuration生成不同的xcconfig。比如说上面的XXKitDebug会在debug.xcconfig和distribution.xcconfig。

我们对比下debug.xcconfig和distribution.xcconfig的区别,发现两者在HEADER_SEARCH_PATHS选项中都添加了XXGeckoKitDebug,但是distribution.xcconfig在OTHER_LDFLAGS的时候并没有添加XXKitDebug
这样解释了为什么,__has_include可以找得到头文件,但是最终报符号缺失,因为链接时没有带上这个库的符号。

GCD

有一个业务场景是批量加载数据,实现用串行队列承载所有任务(下文self.queue),同时为了提高处理效率增加了并发,下文self.semaphore初始化为3,串行队列每次执行会获取self.semaphore,如果能够获取到则启动异步请求任务进行处理。

- (void)requestWithId:(NSString *)xxId {     // self.semaphore 初始化为3,self.queue是串行队列     dispatch_async(self.queue, ^{         dispatch_semaphore_wait(self.semaphore, DISPATCH_TIME_FOREVER);         // async request do some thing         {             ....             // done             dispatch_semaphore_signal(self.semaphore);         } }

后面版本迭代优化,发现self.queue处理速度比较慢,是否能直接把queue从串行队列改为并发队列?

如果直接改为并发队列,极端场景可能会出现以下的现象:

iOS开发笔记(十四)

当queue变成并发队列的时候,就出现经典的gcd并发队列阻塞操作问题,会导致线程爆炸。

思考🤔:如何避免类似这种问题的出现?
个人观点是不要有阻塞操作,所有任务存起来(比如说用数组存),并发若干个任务去执行,有任务完成就去数组里面取新任务。这样实现可以方便增加优先级,仅需要在取任务的逻辑增加优先级判断;还可以对超时任务进行处理,比如说每次添加任务都检查下是否有任务执行时间很长,判断是否跳过该任务。
阻塞操作容易导致线程卡死,又不好做后续的维护和扩展处理,因为在等待过程中整个线程无法进行逻辑处理。

Xcode

1.调试启动方式

在Xcode断点调试时,最常用的是按下command+R,然后等编译、链接、安装、运行。
但是这种方式无法调试通过Push启动、从其他App呼起等场景,此时可以修改下面的配置,在按下command+R的时候只会进行上述的前三步,待用户手动触发App启动。

iOS开发笔记(十四)

2.去除i386库的支持

i386是一个很老的架构,目前是32位的模拟器在使用。某一个依赖库的新版本不支持i386,build时在提示符号缺失。

Podfile增加如下部分
“`

前言

分享iOS开发中遇到的问题,和相关的一些思考。

正文

CocoaPod

最近有位同学在项目中添加了一个调试工具XXKitDebug,但是不想在线上开启,于是通过configurations进行区分,仅在’Debug’ 和 ‘DailyBuild’ 引入。(线上版本configurations是distribution)

pod_binary 'XXKitDebug','0.0.2', :configurations => ['Debug', 'DailyBuild']

然后在代码中通过宏定义来描述:

- (void)onShowDebugPage { #if __has_include(<XXKitDebug/XXKitDebug.h>)     [XXKitDebug showDebugPage]; #endif }

这段__has_include是否能够在Distribution情况下屏蔽下面的代码?

答案是:不可以,会出现链接失败。

官方文档有关于__has_include的说明,是通过检查指定的文件,是否能够正常引入来进行。
但是Podfile的解析和执行是在pod install的时候,此时并不知道将来的build的configuration,CocoaPod的解决办法是针对不同的configuration生成不同的xcconfig。比如说上面的XXKitDebug会在debug.xcconfig和distribution.xcconfig。

我们对比下debug.xcconfig和distribution.xcconfig的区别,发现两者在HEADER_SEARCH_PATHS选项中都添加了XXGeckoKitDebug,但是distribution.xcconfig在OTHER_LDFLAGS的时候并没有添加XXKitDebug
这样解释了为什么,__has_include可以找得到头文件,但是最终报符号缺失,因为链接时没有带上这个库的符号。

GCD

有一个业务场景是批量加载数据,实现用串行队列承载所有任务(下文self.queue),同时为了提高处理效率增加了并发,下文self.semaphore初始化为3,串行队列每次执行会获取self.semaphore,如果能够获取到则启动异步请求任务进行处理。

- (void)requestWithId:(NSString *)xxId {     // self.semaphore 初始化为3,self.queue是串行队列     dispatch_async(self.queue, ^{         dispatch_semaphore_wait(self.semaphore, DISPATCH_TIME_FOREVER);         // async request do some thing         {             ....             // done             dispatch_semaphore_signal(self.semaphore);         } }

后面版本迭代优化,发现self.queue处理速度比较慢,是否能直接把queue从串行队列改为并发队列?

如果直接改为并发队列,极端场景可能会出现以下的现象:

iOS开发笔记(十四)

当queue变成并发队列的时候,就出现经典的gcd并发队列阻塞操作问题,会导致线程爆炸。

思考🤔:如何避免类似这种问题的出现?
个人观点是不要有阻塞操作,所有任务存起来(比如说用数组存),并发若干个任务去执行,有任务完成就去数组里面取新任务。这样实现可以方便增加优先级,仅需要在取任务的逻辑增加优先级判断;还可以对超时任务进行处理,比如说每次添加任务都检查下是否有任务执行时间很长,判断是否跳过该任务。
阻塞操作容易导致线程卡死,又不好做后续的维护和扩展处理,因为在等待过程中整个线程无法进行逻辑处理。

Xcode

1.调试启动方式

在Xcode断点调试时,最常用的是按下command+R,然后等编译、链接、安装、运行。
但是这种方式无法调试通过Push启动、从其他App呼起等场景,此时可以修改下面的配置,在按下command+R的时候只会进行上述的前三步,待用户手动触发App启动。

iOS开发笔记(十四)

2.去除i386库的支持

i386是一个很老的架构,目前是32位的模拟器在使用。某一个依赖库的新版本不支持i386,build时在提示符号缺失。

Podfile增加如下部分
“`

前言

分享iOS开发中遇到的问题,和相关的一些思考。

正文

CocoaPod

最近有位同学在项目中添加了一个调试工具XXKitDebug,但是不想在线上开启,于是通过configurations进行区分,仅在’Debug’ 和 ‘DailyBuild’ 引入。(线上版本configurations是distribution)

pod_binary 'XXKitDebug','0.0.2', :configurations => ['Debug', 'DailyBuild']

然后在代码中通过宏定义来描述:

- (void)onShowDebugPage { #if __has_include(<XXKitDebug/XXKitDebug.h>)     [XXKitDebug showDebugPage]; #endif }

这段__has_include是否能够在Distribution情况下屏蔽下面的代码?

答案是:不可以,会出现链接失败。

官方文档有关于__has_include的说明,是通过检查指定的文件,是否能够正常引入来进行。
但是Podfile的解析和执行是在pod install的时候,此时并不知道将来的build的configuration,CocoaPod的解决办法是针对不同的configuration生成不同的xcconfig。比如说上面的XXKitDebug会在debug.xcconfig和distribution.xcconfig。

我们对比下debug.xcconfig和distribution.xcconfig的区别,发现两者在HEADER_SEARCH_PATHS选项中都添加了XXGeckoKitDebug,但是distribution.xcconfig在OTHER_LDFLAGS的时候并没有添加XXKitDebug
这样解释了为什么,__has_include可以找得到头文件,但是最终报符号缺失,因为链接时没有带上这个库的符号。

GCD

有一个业务场景是批量加载数据,实现用串行队列承载所有任务(下文self.queue),同时为了提高处理效率增加了并发,下文self.semaphore初始化为3,串行队列每次执行会获取self.semaphore,如果能够获取到则启动异步请求任务进行处理。

- (void)requestWithId:(NSString *)xxId {     // self.semaphore 初始化为3,self.queue是串行队列     dispatch_async(self.queue, ^{         dispatch_semaphore_wait(self.semaphore, DISPATCH_TIME_FOREVER);         // async request do some thing         {             ....             // done             dispatch_semaphore_signal(self.semaphore);         } }

后面版本迭代优化,发现self.queue处理速度比较慢,是否能直接把queue从串行队列改为并发队列?

如果直接改为并发队列,极端场景可能会出现以下的现象:

iOS开发笔记(十四)

当queue变成并发队列的时候,就出现经典的gcd并发队列阻塞操作问题,会导致线程爆炸。

思考🤔:如何避免类似这种问题的出现?
个人观点是不要有阻塞操作,所有任务存起来(比如说用数组存),并发若干个任务去执行,有任务完成就去数组里面取新任务。这样实现可以方便增加优先级,仅需要在取任务的逻辑增加优先级判断;还可以对超时任务进行处理,比如说每次添加任务都检查下是否有任务执行时间很长,判断是否跳过该任务。
阻塞操作容易导致线程卡死,又不好做后续的维护和扩展处理,因为在等待过程中整个线程无法进行逻辑处理。

Xcode

1.调试启动方式

在Xcode断点调试时,最常用的是按下command+R,然后等编译、链接、安装、运行。
但是这种方式无法调试通过Push启动、从其他App呼起等场景,此时可以修改下面的配置,在按下command+R的时候只会进行上述的前三步,待用户手动触发App启动。

iOS开发笔记(十四)

2.去除i386库的支持

i386是一个很老的架构,目前是32位的模拟器在使用。某一个依赖库的新版本不支持i386,build时在提示符号缺失。

Podfile增加如下部分
“`

部分转自互联网,侵权删除联系

赞(0) 打赏
部分文章转自网络,侵权联系删除b2bchain区块链学习技术社区 » iOS开发笔记(十四)求职学习资料
分享到: 更多 (0)

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

b2b链

联系我们联系我们