主线程和主队列的关系

先说结论

主队列只在主线程中被执行的，而主线程运行的是一个 runloop，不仅仅只有主队列的中的任务，还会处理 UI 的布局和绘制任务。

几个例子

一、自定义串行队列，同步执行。

- (void)someMethod {
    dispatch_queue_t queue = dispatch_queue_create("com.kk", nil);
    dispatch_sync(queue, ^{
        NSLog(@"current thread = %@， curren queue = %@， main queue = %@", [NSThread currentThread], [NSString stringWithCString:dispatch_queue_get_label(DISPATCH_CURRENT_QUEUE_LABEL) encoding:NSUTF8StringEncoding], [NSString stringWithCString:dispatch_queue_get_label(dispatch_get_main_queue()) encoding:NSUTF8StringEncoding]);
    
    });
}

------------------
current thread = <NSThread: 0x600002c0cf00>{number = 1, name = main}， curren queue = com.kk， main queue = com.apple.main-thread
这里是主线程但不是主队列。

二、主线程判断的几个方法

//下面这几种切换到主线程执行的方法, 你更喜欢哪种?有什么优缺点?
//方法1
if ([NSThread isMainThread]) {
   //xxx
} else {
   dispatch_sync(dispatch_get_main_queue(), ^{
       //xxx
   });
}
// 如果是子线程执行这段代码，并且主队列里的任务是更新 UI，那么是会可能引起崩溃的。
    
//方法2
if ([NSThread isMainThread]) {
   //xxx
} else {
   dispatch_async(dispatch_get_main_queue(), ^{
       //xxx
   });
}
// 大部分都是这么用的，也没有什么问题
// 但是主线程不一定能过只跑主队列的任务。当主线程在同步执行自定义串行队列的任务时，那此方法的判断就不对了，因为此时是主线程且是非主队列
    
//方法3
dispatch_async(dispatch_get_main_queue(), ^{
   //xxx
});
// 始终异步放在下一个loop使用，会延迟执行时机

//方法4   
if (dispatch_queue_get_label(DISPATCH_CURRENT_QUEUE_LABEL) == dispatch_queue_get_label(dispatch_get_main_queue())) {
   //xxx
} else {
   dispatch_async(dispatch_get_main_queue(), ^{
       //xxx
   });
}
// 方法二已经解释了，这里可以通过判断队列label的形式，可以保证任务一定是放在主队列中的。虽然方法二，也不会造成什么问题，但是方法四会更加符合预期（任务一定要在主队列中）

综合来说，方法 4 是更好的判断是否是主线程的方式。

WKWebView 离线包方案比较

方案列表

• 沙盒方案：通过沙盒路径直接加载本地文件
• NSURLProtocol 方案：基于 NSURLProtocol 进行全局请求拦截
• LocalServer 方案：搭建本地服务器加载本地资源
• WKURLSchemeHandler 方案：基于 WKURLSchemeHandler 进行自定义Scheme 注册拦截

方案图表比较

一站式解决WKWebView各类问题

为什么要使用 WKWebView

• UIWebView 在 iOS 12 后被标记为过期了。

• H5 在 UIWebView 和 WKWebView 上的行为不一致，特别在滚动监听上了。另外像微信这样的分享渠道都是使用的 WKWebView，如果还在使用 UIWebView 的话，会导致 H5 的显示效果跟微信上的不一致。

• WKWebView 可以带来执行效率和渲染效率的提升。

为什么要重新造轮子

我们知道 WKWebView 有典型的两个问题：

1. 支持离线包时，ajax body 就会丢失

2. cookie 同步问题

关于 body 丢失的问题

我了解到的解决 body 丢失问题的方式如下：

• H5 在 进行 ajax 请求时，把 body 体放入请求头里，在拦截的时候，再从请求头里拿出 body，然后重新构建新的请求，通过 NSURLSession 发送。但是请求头不适合放入太多数据，而且也需要 H5 侧配合才行。

• H5 ajax 请求是通过 JSAPI 转发到 Native 来发送，这个确实可以解决 body 丢失的问题，但是会让 H5 侧有集成的成本。

• 在请求之前把 url 上的 http/https scheme 替换成自定义的 customscheme，然后返回的 Html 中的子资源链接，使用 src=’//xxx.com/a.js’ 的形式去加载，这样也会让子资源带上 customscheme，通过这种方式 NSURLProtocol 只用注册和拦截 customscheme，针对 customscheme 丢失 body 信息没有任何影响，然后 H5 ajax 请求，还是可以走 http/https 来请求。这种也可以解决 body 丢失的问题，但是必须要求 H5 侧能够按照规范来，如果 H5 没有历史包袱，这种也是可行的，如果有历史包袱的话，也会有改动的成本。

• 注入 ajax hook js 代码，对所有 XMLHTTPRequest 对象进行 hook，在 open，send 等方法处进行拦截，通过 JSAPI 把 url，数据转发到 Native 去发送请求。这种可以解决 body 丢失的问题，而且对 H5 ajax 请求是无侵入式的，但是这种方式相关开源实践很少。

这里的话，只有 ajax hook 是无侵入式的，H5 侧没有任何改动成本，我自己的原则也是最小化改动 H5，让 H5 无感知的使用 WKWebView 的能力，所以 KKJSBridge 也是基于 ajax hook 来实现的。

关于 cookie 同步的问题

我们都知道 WKWebView 的 cookie 是单独保存在 WKWebView cookie 里的，而不是我们平时用的 NSHTTPCookieStorage，所以这就会导致 cookie 不同步的问题，一些文章也介绍了很多但是都没有说处理的很全面。这里我列下所有情况下 cookie 同步的问题：

• 首次同步请求的 cookie 同步（NSHTTPCookieStorage 同步到 WKWebView cookie）
• 异步 ajax 的 cookie 同步（NSHTTPCookieStorage 同步到 WKWebView cookie）
• 服务器端（302）重定向/浏览器重定向的 cookie 同步（NSHTTPCookieStorage 同步到 WKWebView cookie）
• 服务器端响应头里的 Set-Cookie 同步（WKWebView cookie 同步到 NSHTTPCookieStorage）
• H5 侧的 document.cookie 同步（WKWebView cookie 同步到 NSHTTPCookieStorage）
• 异步 ajax 响应头里的 Set-Cookie 同步（WKWebView cookie 同步到 NSHTTPCookieStorage）
• cookie HTTPOnly 同步 （NSHTTPCookieStorage 同步到 WKWebView cookie 和 WKWebView cookie 同步到 NSHTTPCookieStorage）

基本上开源的处理方式都只处理到了前四步，后面几个是没有涉及到的，针对剩下的 cookie 同步问题，我们也是需要处理。

所以 KKJSBridge 是为了完全解决上面两个问题而出的新轮子，同时 KKJSBridge 也会提供其他的特性。

KKJSBridge 支持的功能

• 基于 MessageHandler 搭建通信层

• 支持模块化的管理 JSAPI

• 支持模块共享上下文信息

• 支持模块消息转发

• 支持离线资源

• 支持 ajax hook 避免 body 丢失

• Native 和 H5 侧都可以控制 ajax hook 开关

• Cookie 统一管理

• WKWebView 复用

• 兼容 WebViewJavascriptBridge

Mac上使用Privoxy将socks5转换为http

shadowsocks 挺不错的，但是有些时候需要使用http代理来爬墙。这时候可以使用privoxy来将 socks5 代理转换为 http 代理。

配置

首先，确保 shadowsocks 已经正常起来的，默认的本地socks5端口号为 1080,可以使用 netstat 和 lsof 命令查看端口情况。

安装 privoxy, mac 使用 brew install privoxy 即可，安装完成后，修改 privoxy 配置文件。

如果安装过程报如下错误，先手动创建这个目录 sudo mkdir -p /usr/local/sbin, 再添加修改权限 chmod 777 /usr/local/sbin。

Error: The `brew link` step did not complete successfully
The formula built, but is not symlinked into /usr/local
Could not symlink sbin/privoxy
/usr/local/sbin is not writable.

编辑 config 文件：

vim /usr/local/etc/privoxy/config

修改内容如下：

forward-socks5 / 127.0.0.1:1080 .listen-address 127.0.0.1:8118

listen-address 默认是监听本地8118端口，如果端口没有被占用，可以不用修改

启动 privoxy

/usr/local/sbin/privoxy /usr/local/etc/privoxy/config

可以使用 ps aux|grep privoxy和 lsof -i:8118来检查是否成功启动

YYWebImage,SDWebImage和PINRemoteImage比较

共同的特性

1. 以类别 api 下载远程图片。
2. 图片缓存
3. 图片提前解码
4. 其他

图片框架比较

图片后处理

根据下面的比较，可以看出图片后处理方面，PINRemoteImage > YYWebImage > SDWebImage

• YYWebImage:

  • 支持不带标记的后处理。

    /** Set the view's `image` with a specified URL. @param imageURL The image url (remote or local file path). @param placeholder he image to be set initially, until the image request finishes. @param options The options to use when request the image. @param manager The manager to create image request operation. @param progress The block invoked (on main thread) during image request. @param transform The block invoked (on background thread) to do additional image process. @param completion The block invoked (on main thread) when image request completed. */ - (void)yy_setImageWithURL:(nullable NSURL *)imageURL placeholder:(nullable UIImage *)placeholder options:(YYWebImageOptions)options manager:(nullable YYWebImageManager *)manager progress:(nullable YYWebImageProgressBlock)progress transform:(nullable YYWebImageTransformBlock)transform completion:(nullable YYWebImageCompletionBlock)completion;

• SDWebImage: 不支持图片后处理。

• PINRemoteImage:

  • 支持带标记的图片后处理。对于同一张图片，当需要不同的后处理方式时（a 界面需要正圆角，b 界面需要小幅度的圆角），尤为有用。

    /** Set placeholder on view and retrieve the image from the given URL, process it using the passed in processor block and set result on view. Call completion after image has been fetched, processed and set on view. @param url NSURL to fetch from. @param placeholderImage PINImage to set on the view while the image at URL is being retrieved. @param processorKey NSString key to uniquely identify processor. Used in caching. @param processor PINRemoteImageManagerImageProcessor processor block which should return the processed image. @param completion Called when url has been retrieved and set on view. */ - (void)pin_setImageFromURL:(nullable NSURL *)url placeholderImage:(nullable PINImage *)placeholderImage processorKey:(nullable NSString *)processorKey processor:(nullable PINRemoteImageManagerImageProcessor)processor completion:(nullable PINRemoteImageManagerImageCompletion)completion;

仿微信图片压缩方式

现状

目前公司 app 压缩图片，是压缩成一个固定大小的，比如把所有图片压缩成一个 120k 的图片，或者压缩成一个 300k的图片，这两种方式都不好，压缩成 120 会让原始图片质量太低，而显示模糊。

图片上传限定到 300k，也不是很对，这样会造成所有的图片都会以 300k 上传，这样会造成两个问题：

1. 上传速度会很慢，也比较耗流量。9 张图一起上传会更慢。
2. 300k 图片质量其实和 150k 左右的图片看起来差不多，过多的图片空间占用意义不大。

参考微信

因为发现微信的图片压缩后质量还不错，于是选择了 12 张不同大小不同尺寸的图片进行测试。

发现微信客户端上的图片压缩后，基本是 90k~200k 这个范围。

代码实现

本来一开始想试下鲁班算法，但是发现鲁班算法压缩后的图片大小跟微信的还是有些区别了，所以就放弃了。

于是参考微信，简单实现 iOS 压缩方式如下：

iOS界面开发需要用Point乘以屏幕比例系数吗

现状

由于公司给 app 设计的效果图是基于 iPhone 6 的，效果图的宽度是 375 point。为了适应大小屏幕，我们专门封装了一个函数来获取一个适配的点。

inline CGFloat Point(void)
{
    static CGFloat point;
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        point = ([UIScreen mainScreen].bounds.size.width / 375.0f);//以iPhone6为标准的比例值
    });
    
    return point;
}

所以在使用的时候，就会是效果图上里面的点乘以适配点。比如一张 140 x 140 图片距离屏幕左边 20 点。

UIImageView *imageView = [UIImageView new];
imageView.frame = CGRectMake(20 * Point(), 0, 140 * Point(), 140 * Point());

这样的话，在大屏幕里面，间距和图片大小都会比效果图更大，

在小屏幕里面，间距和图片大小都会比效果图更小，这样就可以适配小屏幕了。

虽然这样很好的适配小屏幕，但是会让大屏幕的间距看起来很大，总体看起来没有很好的利用空间。比如距离左边 20 点，在 7p 上就是 22.08，会多出 2.08 的点，这样就会距离左边更大了。

20 * Point() = 20 * 1.104 = 22.08

目录

1. 问题
2. 尝试 xcodebuild
3. 查看 WCDB 是怎么编译
4. 尝试自动静态库
5. 尝试手动静态库
6. 总结

1. 问题

由于项目需求，需要使用一款数据库，直接使用 sqlite 会手动写很多 sql 代码，也容易出错。使用苹果官方的 core data，core data 不是线程安全的，需要严格区分在不同的线程使用不同的 manage context，使用上也增加了代码复杂度，也会更容易出现 bug。于是考虑下基于 sqlite 的开源方案。

FMDB: 其实就是 sqlite 的语法糖，多线程访问需要使用专门的 queue，不支持 ORM。
Realm: 是为速度而生的数据库，很多配套设施并不齐全。
WCDB: 性能高，支持线程安全，支持 ORM。缺点：1. 基于objective c++，所以只要使用到了 WCDB 的地方，都需要以 mm 为文件后缀。2. 增大包体积。

想找到一款易使用有安全的数据库，最后还是考虑使用了 WCDB， 虽然它也有自己的不足，但是还是可以接受的。

于是通过 pod 在项目中使用了 WCDB，并写了小 demo 熟悉下了使用方式。

pod 'WCDB'

在熟悉了使用方式之后，就可以在项目里使用了，在开发阶段都是通过模拟器或者真机测试，以为都很好。但是在搭建 Bamboo 的 CICD 就会报以下错。

fts5_storage.c:305:9: error: 'sqlite3_api_routines' has no member named '__builtin___snprintf_chk'

The following build commands failed:
	CompileC /Users/karosli/Library/Developer/Xcode/DerivedData/xxx-dleyffpkgrddqzfvrhnoakpqgdvz/Build/Intermediates.noindex/ArchiveIntermediates/LefitCoach/IntermediateBuildFilesPath/Pods.build/Debug-iphoneos/WCDB.build/Objects-normal/armv7/fts5.o WCDB/sqlcipher/fts5.c normal armv7 c com.apple.compilers.llvm.clang.1_0.compiler
(1 failure)

iOS 循环滚动视图，包含文字滚动，banner 滚动

效果图：

demo 地址：
https://github.com/karosLi/KLRecycleScrollView

功能：

• 支持上下滚动和左右滚动
• 支持自定义子视图
• 支持分页和不分页
• 支持自动滚动

jenkins-fastlane 持续集成和自动化打包

目录

• 背景
• 自动化打包脚本
• 配置 Jenkins

背景

先看下目前都有哪些打包方式：

方式一

debug 包：直接 build 出一个 app，放到 itunes 里，然后上传 fir 或者 蒲公英。
release 包：archive 出一个 ipa，通过 application loader 上传到 itunes。

方式二

自动化脚本，一键打出 debug 包和 release 包，以前都会使用 shenzhen 去做自动化脚本，现在 shenzhen 已经被 fastlane 替代。

方式三

Jenkins + Fastlane + GitLab + fir (或者蒲公英)

很明显方式二更快捷，也节约了时间成本，但是还是会不够自动化，是手动触发去打包的，所以综上所诉方式三是最能满足需求的，不仅可以基于触发器自动打包，还可以在 Jenkins 上引入需要的插件来扩展功能。