一、线程安全场景

多个线程中同时访问同一块资源，也就是资源共享。多牵扯到对同一块数据的读写操作，可能引发数据错乱问题。

比较经典的线程安全问题有购票和存钱取钱问题，为了说明读写操作引发的数据混乱问题，以存钱取钱问题来做个说明。

1. 购票案例

用代码示例如下：

@IBAction func ticketSale() {



        tickets = 30



        let queue = DispatchQueue.global()



        queue.async {



            for _ in 0..<10 {



                self.sellTicket()



            }



        }



        queue.async {



            for _ in 0..<10 {



                self.sellTicket()



            }



        }



        queue.async {



            for _ in 0..<10 {



                self.sellTicket()



            }



        }



    }



    //卖票



    func sellTicket() {



        var oldTicket = tickets



        sleep(UInt32(0.2))



         oldTicket -= 1



         tickets = oldTicket



        print("还剩\(tickets)张票 ---- \(Thread.current)")



    }

同时有三条线程进行卖票，对余票进行减操作，三条线程每条卖10次，原定票数30，应该剩余票数为0，下面看下打印结果：

可以看到打印票数不为0

2. 存钱取钱案例

先用个图说明

上图可以看出，存钱和取钱之后的余额理论上应该是500，但由于存钱取钱同时访问并修改了余额，导致数据错乱，最终余额可能变成了400，下面用代码做一下验证说明：

//存钱取钱



    @IBAction func remainTest() {



        remain = 500



        let queue = DispatchQueue.global()



        queue.async {



            for _ in 0..<5 {



                self.saveMoney()



            }



        }



        queue.async {



            for _ in 0..<5 {



                self.drawMoney()



            }



        }



    }



    //存钱



    func saveMoney() {



       var oldRemain = remain



        sleep(2)



        oldRemain += 100



        remain = oldRemain



        print("存款100元，账户余额还剩\(remain)元 ----\(Thread.current)")



    }



    



    //取钱



    func drawMoney() {



        var oldRemain = remain



         sleep(2)



         oldRemain -= 50



         remain = oldRemain



        print("取款50元，账户余额还剩\(remain)元 ---- \(Thread.current)")



    }

上述代码存款5次100，取款5次50，最终的余额应该是 500 + 5 * 100 - 5 * 50 = 750

如图所示，可以看到在存款取款之间已经出现错乱了

上述两个案例之所以出现数据错乱问题，就是因为有多个线程同时操作了同一资源，导致数据不安全而出现的。

那么遇到这个问题该怎么解决呢？自然而然的，我们想到了对资源进行加锁处理，以此来保证线程安全，在同一时间，只允许一条线程访问资源。

加锁的方式大概有以下几种：

• OSSpinLock
• os_unfair_lock
• pthread_mutex
• dispatch_semaphore
• dispatch_queue(DISPATCH_QUEUE_SERIAL)
• NSLock
• NSRecursiveLock
• NSCondition
• NSConditionLock

1. OSSpinLock 自旋锁

OSSpinLock 是自旋锁，在系统框架 libkern/OSAtomic 下

如图，系统提供了以下几个API

• 定义lock let osspinlock = OSSpinLock()
• OSSpinLockTry

官方给定的解释如下

Locks a spinlock if it would not block

return false, if the lock was already held by another thread,

return true, if it took the lock successfully.

尝试加锁，加锁成功则继续，加锁失败则直接返回，不会阻塞线程

• OSSpinLockLock

Although the lock operation spins, it employs various strategies to back



off if the lock is held. 

加锁成功则继续，加锁失败，则会阻塞线程，处于忙等状态

• OSSpinLockUnlock: 解锁

使用

@IBAction func ticketSale() {



        osspinlock = OSSpinLock()



        tickets = 30



        let queue = DispatchQueue.global()



        queue.async {



            for _ in 0..<10 {



                self.sellTicket()



            }



        }



        queue.async {



            for _ in 0..<10 {



                self.sellTicket()



            }



        }



        queue.async {



            for _ in 0..<10 {



                self.sellTicket()



            }



        }



    }



    //卖票



    func sellTicket() {



        OSSpinLockLock(&osspinlock)



        var oldTicket = tickets



        sleep(UInt32(0.2))



         oldTicket -= 1



         tickets = oldTicket



        print("还剩\(tickets)张票 ---- \(Thread.current)")



        OSSpinLockUnlock(&osspinlock)



    }

可以看到，最终的余票数量已经是正确的了，这里要注意的是osspinlock需要做成全局变量或者属性，多个线程要用这同一把锁去加锁和解锁，如果每个线程各自生成锁，则达不到要加锁的目的了

那么自旋锁是怎么样做到加锁保证线程安全的呢？
先来介绍下让线程阻塞的两种方法：

• 忙等:也就是自旋锁的原理，它本质上就是个while循环，不停地去判断加锁条件，自旋锁没有让线程真正的阻塞，只是将线程处在while循环中，系统CPU还是会不停地分配资源来处理while循环指令。
• 真正阻塞线程: 这是让线程休眠，类似于Runloop里的match_msg() 实现的效果，它借助系统内核指令，让线程真正停下来处于休眠状态，系统的CPU不再分配资源给线程，也不会再执行任何指令。系统内核用的是symcall指令来让线程进入休眠

它的原理就是，自旋锁在加锁失败时，让线程处于忙等状态，让线程停留在临界区之外，一旦加锁成功，就可以进入临界区对资源进行操作。

通过这个可以看到，苹果在iOS10之后就弃用了OSSpinLock,官方建议用 os_unfair_lock来代替，那么为什么要弃用呢？因为在iOS10之后线程可以设置优先级，在优先级配置下，可以产生优先级反转，使自旋锁卡住，自旋锁本身已经不再安全。

2. os_unfair_lock

os_unfair_lock 是苹果官方推荐的，自iOS10之后用来替代 OSSpinLock 的一种锁

• os_unfair_lock_trylock: 尝试加锁，加锁成功返回true，继续执行。加锁失败，则返回false，不会阻塞线程。
• os_unfair_lock_lock: 加锁，加锁失败，阻塞线程继续等待。加锁成功，继续执行。
• os_unfair_lock_unlock : 解锁

使用：

//卖票



    func sellTicket() {



        os_unfair_lock_lock(&unfairlock)



        var oldTicket = tickets



        sleep(UInt32(0.2))



         oldTicket -= 1



         tickets = oldTicket



        print("还剩\(tickets)张票 ---- \(Thread.current)")



        os_unfair_lock_unlock(&unfairlock)



    }

打印结果和OSSpinLock一样，os_unfair_lock摒弃了OSSpinLock的while循环实现的忙等状态，而是采用了真正让线程休眠，从而避免了优先级反转问题。

3. pthread_mutex

pthread_mutex是pthread跨平台的一种解决方案，mutex 为互斥锁，等待锁的线程会处于休眠状态。
互斥锁的初始化比较麻烦，主要为以下方式：

1. var ticketMutexLock = pthread_mutex_t()
2. 初始化属性:

var attr = pthread_mutexattr_t()

pthread_mutexattr_init(&attr)

pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_NORMAL)

3. 初始化锁：pthread_mutex_init(&ticketMutexLock, &attr)

关于互斥锁的使用，主要提供了以下方法：

1. 尝试加锁：pthread_mutex_trylock(&ticketMutexLock)
2. 加锁：pthread_mutex_lock(&ticketMutexLock)
3. 解锁：pthread_mutex_unlock(&ticketMutexLock)
4. 销毁相关资源：pthread_mutexattr_destory(&attr), pthread_mutex_destory(&ticketMutexLock)

使用方式如下：

要注意，在析构函数中要将锁进行销毁释放掉
在初始化属性中，第二个参数有以下几种方式：

PTHREAD_MUTEX_DEFAULT = PTHREAD_MUTEX_NORMAL，代表普通的互斥锁
PTHREAD_MUTEX_ERRORCHECK 代表检查错误锁
PTHREAD_MUTEX_RECURSIVE 代表递归互斥锁

互斥锁的底层原理实现也是通过阻塞线程，等待锁的线程处于休眠状态，CPU不再给等待的线程分配资源，和上面讲到的os_unfair_lock原理类似，都是通过内核调用symcall方法来休眠线程，通过这个对比也能推测出，os_unfair_lock实际上也可以归属于互斥锁

3.1 递归互斥锁

如图所示，如果是上述场景，方法1里面嵌套方法2，正常调用时，输出应该为：

若要对上述场景保证线程安全，先用普通互斥锁添加锁试下

结果打印如下：

和预想中的不一样，如果懂得锁机制便会明白，图中所示的rsmText2中加锁失败，需要等待rsmText1中的锁释放后才可加锁，所以rsmText2方法开始等待并阻塞线程，程序无法再执行下去，那么rsmText1中锁释放的逻辑就无法执行，就这样造成了死锁，所以只能打印rsmText1中的输出内容。
解决这个问题，只需要给两个方法用两个不同的锁对象进行加锁就可以了，但是如果是针对于同一个方法递归调用，那么就无法通过不同的对象去加锁，这时候应该怎么办呢？递归互斥锁就该用上了。

如上，已经可以正常调用并加锁
那么递归锁是如何避免死锁的呢？简而言之就是允许对同一个对象进行重复加锁，重复解锁，加锁和解锁的次数相等，调用结束时所有的锁都会被解开

3.2 互斥锁条件 pthread_cond_t

互斥锁条件所用到的常见方法如下：

1. 定义一个锁： var condMutexLock = pthread_mutex_t()
2. 初始化锁对象：pthread_mutex_init(&condMutexLock)
3. 定义条件对象：var condMutex = pthread_cond_t()
4. 初始化条件对象：pthread_cond_init(&condMutex, nil)
5. 等待条件：pthread_cond_wait(&condMutex, &condMutexLock) 等待过程中会阻塞线程，知道有激活条件的信号发出，才会继续执行
6. 激活一个等待该条件的线程：pthread_cond_signal(&condMutex)
7. 激活所有等待该条件的线程pthread_cond_broadcast(&condMutex)
8. 解锁：pthread_mutex_unlock(&condMutexLock)
9. 销毁锁对象和销毁条件对象：pthread_mutex_destroy(&condMutexLock) pthread_cond_destroy(&condMutex)

下面设计一个场景：

• 在一个线程里对dataArr做remove操作，另一个线程里做add操作
• dataArr为0时，不能进行删除操作

@IBAction func mutexCondTest(_ sender: Any) {



        initMutextCond()



    }



    func initMutextCond() {



        //初始化属性



        var attr = pthread_mutexattr_t()



        pthread_mutexattr_init(&attr)



        pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_NORMAL)



        //初始化锁



        pthread_mutex_init(&condMutexLock, &attr)



        //释放属性



        pthread_mutexattr_destroy(&attr)



        //初始化cond



        pthread_cond_init(&condMutex, nil)



        _testDataArr()



        



    }



    func _testDataArr() {



        let threadRemove = Thread(target: self, selector: #selector(_remove), object: nil)



        threadRemove.name = "remove 线程"



        threadRemove.start()



        



        sleep(UInt32(1))



        let threadAdd = Thread(target: self, selector: #selector(_add), object: nil)



        threadAdd.name = "add 线程"



        threadAdd.start()



        



    }



    @objc func _add() {



        //加锁



        pthread_mutex_lock(&condMutexLock)



        print("add 加锁成功---->\(Thread.current.name!)开始")



        sleep(UInt32(2))



        dataArr.append("test")



        print("add成功，发送条件信号 ------ 数组元素个数为\(dataArr.count)")



        pthread_cond_signal(&condMutex)



        //解锁



        pthread_mutex_unlock(&condMutexLock)



        print("解锁成功，\(Thread.current.name!)线程结束")



    }



    @objc func _remove() {



        //加锁



        pthread_mutex_lock(&condMutexLock)



        print("remove 加锁成功，\(Thread.current.name!)线程开启")



        if(dataArr.count == 0) {



            print("数组内没有元素，开始等待，数组元素为\(dataArr.count)")



            pthread_cond_wait(&condMutex, &condMutexLock)



            print("接收到条件更新信号，dataArr元素个数为\(dataArr.count),继续向下执行")



        }



        dataArr.removeLast()



        print("remove成功，dataArr数组元素个数为\(dataArr.count)")



        



        //解锁



        pthread_mutex_unlock(&condMutexLock)



        print("remove解锁成功，\(Thread.current.name!)线程结束")



    }



    



    deinit {



//        pthread_mutex_destroy(&ticketMutexLock)



        pthread_mutex_destroy(&condMutexLock)



        pthread_cond_destroy(&condMutex)



    }

输出结果为：

从打印结果来看，如果不满足条件时进行条件等待 pthread_cond_wati,remove 线程是解锁，此时线程是休眠状态，然后等待的add 线程进行加锁成功，处理add的逻辑。

当add 操作完毕时，通过 pthread_cond_signal发出信号，remove线程收到信号后被唤醒，然后remove线程会等待add线程解锁后，再进行加锁处理后续的逻辑.

整个过程中一共用到了三次加锁，三次解锁，这种锁可以处理线程依赖的场景.

4. NSLock, NSRecursiveLock, NSCondition

上文中提到了mutex普通互斥锁 mutex递归互斥锁 与 mutext条件互斥锁，这几种锁都是基于C语言的API，苹果在此基础上做了面向对象的封装，分别对应如下：

• NSLock 封装了 pthread_mutex_t的 attr类型为 PTHREAD_MUTEX_DEFAULT 或者 PTHREAD_MUTEX_NORMAL 普通锁
• NSRecursiveLock 封装了 pthread_mutex 的 attr类型为PTHREAD_MUTEX_RECURSIVE递归锁
• NSCondition 封装了 pthread_mutex_t 和 pthread_cond_t

底层实现和 pthread_mutex_t一样，这里只看下使用方式即可：

4.1 NSLock

//普通锁 

let lock = NSLock() 

lock.lock()

lock.unlock()

4.2 NSRecursiveLock

let lock = NSRecursiveLock()

lock.lock()

lock.unlock()

4.3 NSCondition

let condition = NSCondition()

condition.lock()

condition.wait()

condition.signal()//condition.broadcast()

condition.unlock()

4.4 NSConditionLock

这个是NSCondition 的进一步封装，该锁允许我们在锁中设定条件具体条件值，有了这个功能，我们可以更加方便的多条线程的依赖关系和前后执行顺序

下面用一个场景来模拟下顺序控制的功能，有三条线程执行A,B,C三个方法，要求按A,C,B的顺序执行

@IBAction func conditionLockTest(_ sender: Any) {



       let threadA = Thread(target: self, selector: #selector(A), object: nil)



        threadA.name = "ThreadA"



        threadA.start()



       let threadB = Thread(target: self, selector: #selector(B), object: nil)



        threadB.name = "ThreadB"



        threadB.start()



       let threadC = Thread(target: self, selector: #selector(C), object: nil)



        threadC.name = "ThreadC"



        threadC.start()



    }



    @objc func A() {



        conditionLock.lock()



        print("A")



        sleep(UInt32(1))



        conditionLock.unlock(withCondition: 3)



    }



    @objc func B() {



        conditionLock.lock(whenCondition: 2)



        print("B")



        sleep(UInt32(1))



        conditionLock.unlock()



    }



    @objc func C() {



        conditionLock.lock(whenCondition: 3)



        print("C")



        conditionLock.unlock(withCondition: 2)



    }

输出结果为：

A



C



B

5. dispatch_semaphore

信号量 的初始值可以用来控制线程并发访问的最大数量，初始值为1，表示同时允许一条线程访问资源，这样可以达到线程同步的目的

• 创建信号量：dispatch_semaphore_create(value)

• 等待：dispatch_semaphore_wait(semaphore, 等待时间) 信号量的值 <= 0，线程就休眠等待，直到信号量 > 0，如果信号量的值 > 0，则就将信号量的值递减1，继续执行下面的程序

• 信号量值+1: dispatch_semaphore_signal(semaphore)

调试是程序是开发过程中必不可少的环节，每当我们完成一段代码或者发现一些问题都需要对程序进行调试。高效的调试能帮我们节省大量的开发时间。这篇文章我将分享一些提高调试效率的工具和它们的使用方法。

在开发iOS APP的时候我们最频繁进行调试的莫过于UI了。

一、UI的调试

开发中我们经常需要多次修改UI元素的样式进行微调，查看效果并确定正确的数值。

Xcode

如下图所示，Xcode 提供了完备的UI调试工具。

在左边，我们可以看到完整对视图树，中间有各个视图对3D拆分展示，右边，可以看到当前选中的视图的一些信息。

Xcode在进行UI调试的时候，会暂停APP，视图的信息也只能查看不能方便的修改。在UI调试的时候需要修改代码然后重新编译运行才能看到最终的效果。

在频繁调试UI样式的时候是很耗费时间的（如果电脑性能非常好可能会耗费的时间可能会短一些）所以这不是最佳的选择。

LookIn

在这里向大家介绍一款视图调试工具Lookin，它是由腾讯的QMUI团队开发并开源的一款免费的UI调试工具。

有了它，我们就能进行高效的UI调试。

使用方法也非常简单，具体可以查看官方的集成指导。

接下来我将分几点简单的介绍一下这个工具的强大功能。

查看与修改UI

Lookin 可以查看与修改 iOS App 里的 UI 对象，类似于 Xcode 自带的 UI Inspector 工具，不需要重新编译运行。而且借助于“控制台”和“方法监听”功能，Lookin 还可以进行 UI 之外的调试。

独立运行
此外，虽然 Lookin 主体是一款 macOS 程序，它亦可嵌入你的 iOS App 而单独运行在 iPhone 或 iPad 上。

显示变量名
Lookin 会显示变量名，以及 indexPath 等各种提示。

显示手势
添加了手势的 UIView，或添加了 Target-Action 的 UIControl，左侧都会被加上一个小蓝条，点击即可查看信息或调试手势

测距
按住 Option 键，即可测量任意两个 view 之间的距离

导出文件

通过手机或电脑将当前 iOS App 的 UI 结构导出为 Lookin 文件以备之后查看，或直接转发给别人。
当测试发现BUG时可以完美对固定现场，并可以将文件发送给开发者查看当时的视图结构。

二、热重载

💉Injection III

Lookin已经帮我们解决了很多问题，但当我们修改了代码的业务逻辑，或者修改了UI的加载逻辑，或者对代码进行了比较大的改动，此时还是需要重新编译运行才能使新的代码生效。同样会耗费许多时间编译、重新运行、点击屏幕到达刚才修改的页面的时间。

这个时候就是我们的第二款高效开发的得力助手登场的时候了。

它就是 💉 Injection III，一款开源免费的热重载工具。

Injection III 是一款能在iOS开发时实现类似Web前端那样热重载的工具。他会监听代码文件的变化，当代码发生改变，他会将改变的部分自动编译成一个动态链接库，然后动态的加载到程序中，达到不重启APP直接热重载的目的。

下面我简单介绍一下如何使用它。

我们可以在 Mac App Store 上下载InjectionIII。打开后会在状态栏有一个蓝色的注射器图标，选择Open Project 打开工程所在目录开始监听我们的文件更改。

接下来在工程中进行一些配置，

在 Xcode 的 build setting 的 Other Linker Flags 中添加-Xlinker -interposable

在AppDelegate的applicationDidFinishLaunching方法中加入如下代码：

#if DEBUG

	//for iOS:

	Bundle(path: "/Applications/InjectionIII.app/Contents/Resources/iOSInjection.bundle")?.load()

	//for tvOS:

	Bundle(path: "/Applications/InjectionIII.app/Contents/Resources/tvOSInjection.bundle")?.load()

	//Or for macOS:

	Bundle(path: "/Applications/InjectionIII.app/Contents/Resources/macOSInjection.bundle")?.load()

#endif

接下来，编译运行你的APP，此时控制台会打印Injection的相关信息

同时状态栏的图标也会变为红色。此时说明Injection启动成功。

接下来你就可以修改一下代码，并保存，Injection会自动编译并自动将其注入到模拟器中运行的APP。控制台也会打印相关的信息。

同时，它会为被注入的类提供一个回调@objc func injected() ，当某个类被注入时，会调用该方法。

我们可以在这里刷新UI，就能做到实时更新UI了。

注意事项

虽然Injection很强大，但它也有很多限制：

• 你可以修改class、enum、struct 的成员方法的实现，但如果是inline函数则不行，如果有这种情况需要重新编译运行。

• 它只支持模拟器，不支持真机。

• 你不能修改class、enum、struct的布局（即成员变量和方法的顺序），如果有这种情况需要重新编译运行。

• 你不能增加或删除存储类型的属性和方法，如果有这种情况需要重新编译运行。

更多详情可以参见官方的说明：InjectionIII/README.md at main · johnno1962/InjectionIII (github.com)

虽然 Injection III 有很多限制，但它依然能为我们带来非常大的效率提升。

另一个热重载神器： krzysztofzablocki/Inject

krzysztofzablocki/Inject: Hot Reloading for Swift applications! (github.com)

它配合 Injection III 可以更方便的实现热重载和界面自动刷新，实现类似Swift UI的自动刷新效果，但是，它只支持Swift，并且通过Swift Package Manager进行安装。

三、写在最后

实用的工具很多，找到一款既强大又好用的工具，并且把它用好能够很大的提升我们开发的效率。

希望大家能喜欢我分享的这两款工具，希望它们能为大家带来效率的提升。

一. 问题背景

项目中遇到一个问题，就是当App不在首页的时候，切换到其他App比如微信，然后返回App当前页面，然后从当前页面返回首页，会在首页viewWillAppear这里去拉取是否有未完成订单的接口，刷新UITableView，这时会出现广告位闪烁问题。

二. 问题排查

1.原因分析

这个问题经过断点调试和排除法，发现只要当App进入后台后，回来刷新首页的UITableView都有可能出现闪烁现象。

因此首先我们对图片的加载做延迟操作，并在Cell生成方法调用里面添加相关打印:

可以看到如下打印日志:

从打印日志我们可以看出来，调用reloadData方法后，原来UITableView的cell位置会调整。

但是如果我们App没有进入后台，而是直接调用UITableView的reloadData方法，并不会出现闪烁现象。

因此可以这里可以推测应该是进入后台做了什么操作导致，回到App刷新才会导致闪烁。

因为使用的是SDWebImage加载框架加载，我们合理的怀疑是加载图片的SDWebImage框架，进入后台的处理逻辑导致的,因此我们先使用imageCacheDict字典写下图片加载和缓存逻辑:

经测试，进入后台，再返回App刷新不会出现闪烁现象。

因此可以肯定UITableView调用reloadData方法闪烁原因是SDWebImage，在进入后台的时候对内存缓存做了相关操作导致。

我们都知道SDWebImage，默认是使用NSCache来做内存缓存，而NSCache在进入后台的时候，默认会清空缓存操作，导致返回App调用UITableView调用reloadData方法时候，SDWebImage需要根据图片地址重新去磁盘获取图像数据，然后解压解码渲染，因为是从缓存磁盘直接获取图像数据，没有渲染流程，因此会造成闪烁。

为了验证这个猜想，我们使用YYWebImage加载框架来做对比实验:

首先注释掉YYWebImage进入后台清空内存缓存的逻辑: 

然后进入后台，返回App调用UITableView调用reloadData刷新，发现一切正常。

原因总结:

• 第一个原因是UITableView调用reloadData方法，由于UITableViewCell的复用，会出现Cell位置调整现象

• 由于SDWebImage使用了NSCache做内存缓存，当App进入后台，NSCache会清空内存缓存，导致返回App后调用UITableView调用reloadData，刷新去加载图片的时候，需要从SDWebImage的磁盘中重新获取图片数据，然后重新解压解码渲染，因为从磁盘中读取速度快，两者原因导致了闪烁。

三. 解决方案

因为该现象是由如上两个原因导致，因此针对这两个原因，有如下两种解决方案:

1. 解决UITableViewCell复用问题

可以通过设置ReusableCellWithIdentifier不同，保证广告cell不进行复用。

 NSString *cellId = [NSString stringWithFormat:@"%ld-%ld-FJFAdTableViewCell", indexPath.section, indexPath.row];

2. 从后台返回后，提早进行刷新操作

当从后台返回App前台的时候或者视图添加到父视图的时候，先执行下UITableView调用reloadData方法，提前通过SDWebImage去从磁盘中加载图片。

从后台返回前台:

[NSNotificationCenter.defaultCenter addObserver:self selector:@selector(willEnterForeground) name:UIApplicationWillEnterForegroundNotification object:nil];

- (void)willEnterForeground {

    [self.tableView reloadData];

    NSLog(@"--------------------------willEnterForeground");

}

视图添加到父视图:

- (void)willMoveToParentViewController:(UIViewController *)parent {

    [self.tableView reloadData];

}

在iOS开发中，RunLoop是一个非常重要的概念，它提供了一个事件循环机制，用于处理各种事件，例如用户交互、网络请求、定时器等等。RunLoop不仅是iOS开发中的核心之一，而且在其他平台的开发中也有广泛的应用。本文将为您介绍Swift中RunLoop的基本概念和使用方法。

什么是RunLoop？

RunLoop是一个事件循环机制，它用于在iOS应用程序中处理各种事件。RunLoop在应用程序的主线程中运行，它负责管理该线程中的事件，并确保UI更新等重要任务能够顺利执行。RunLoop还负责处理其他线程发送的事件，例如网络请求等等。

RunLoop的基本思想是循环地处理事件。当RunLoop启动时，它会进入一个无限循环，等待事件的发生。当有事件发生时，RunLoop会调用相应的处理方法来处理该事件，并继续等待下一个事件的发生。RunLoop会一直运行，直到被手动停止或应用程序退出。

RunLoop与线程

在iOS中，每个线程都有一个RunLoop，但默认情况下，RunLoop是被禁用的。要使用RunLoop，必须手动启动它，并将其添加到线程的运行循环中。

例如，要在主线程中使用RunLoop，可以使用如下代码：

RunLoop.current.run()

这将启动主线程的RunLoop，并进入一个无限循环，等待事件的发生。

RunLoop模式

RunLoop模式是RunLoop的一个重要概念，它定义了RunLoop在运行过程中需要处理的事件类型。一个RunLoop可以有多个模式，但在任何时刻只能处理一个模式。每个模式都可以包含多个输入源（input source）和定时器（timer），RunLoop会根据当前模式中的输入源和定时器来决定下一个事件的处理方式。

RunLoop提供了几个内置模式，例如：

1. NSDefaultRunLoopMode：默认模式，处理所有UI事件、定时器和PerformSelector方法。
2. UITrackingRunLoopMode：跟踪模式，只处理与界面跟踪相关的事件，例如UIScrollView的滚动事件。
3. NSRunLoopCommonModes：公共模式，同时包含NSDefaultRunLoopMode和UITrackingRunLoopMode。 RunLoop还允许开发者自定义模式，以满足特定需求。

定时器

在iOS开发中，定时器是一种常见的事件，例如每隔一段时间刷新UI、执行后台任务等等。RunLoop提供了定时器（timer）机制，用于在指定时间间隔内执行某个操作。

例如，要在主线程中创建一个定时器并启动它，可以使用如下代码：

let timer = Timer(timeInterval: 1.0, repeats: true) { timer in // 定时器触发时执行的操作 } RunLoop.current.add(timer, forMode: .common)

这将创建一个每隔1秒钟触发一次的定时器，并在公共模式下添加到主线程的RunLoop中。

在添加定时器时，需要指定它所属的RunLoop模式。如果不指定模式，则默认为NSDefaultRunLoopMode。如果需要在多个模式下都能响应定时器事件，可以使用NSRunLoopCommonModes。

输入源

输入源（input source）是一种与RunLoop一起使用的机制，用于处理异步事件，例如网络请求、文件读写等等。RunLoop在运行过程中，会检查当前模式下是否有输入源需要处理，如果有则会立即处理。

输入源可以是一个Port、Socket、CFFileDescriptor等等。要使用输入源，必须将其添加到RunLoop中，并设置回调函数来处理输入事件。

例如，要在主线程中使用输入源，可以使用如下代码：

let inputSource = InputSource()

inputSource.setEventHandler {

    // 输入源触发时执行的操作

}

RunLoop.current.add(inputSource, forMode: .common)

这将创建一个输入源，并在公共模式下添加到主线程的RunLoop中。

Perform Selector

Perform Selector是一种调用方法的方式，可以在RunLoop中异步执行某个方法。在调用方法时，可以设置延迟执行时间和RunLoop模式。该方法会在指定的时间间隔内执行，直到被取消。

例如，要在主线程中使用Perform Selector，可以使用如下代码：

RunLoop.current.perform(#selector(doSomething), target: self, argument: nil, order: 0, modes: [.default])

这将在默认模式下异步执行doSomething方法。

RunLoop的常用操作

除了上述基本操作之外，RunLoop还提供了其他常用操作，例如：

1. stop：停止RunLoop的运行。
2. runUntilDate：运行RunLoop直到指定日期。
3. runMode：运行RunLoop指定模式下的事件处理循环。
4. currentMode：获取当前RunLoop的运行模式。

RunLoop与线程安全

在iOS开发中，多线程是一个常见的问题。RunLoop在处理异步事件时，可能会导致线程不安全的问题。为了保证RunLoop的线程安全，可以使用以下方法：

1. 使用RunLoopQueue，在队列中使用RunLoop来执行异步操作。
2. 在主线程中使用RunLoop来处理异步事件，避免跨线程操作。

结论

RunLoop是iOS开发中非常重要的一个概念，它提供了一种事件循环机制，用于处理各种事件。RunLoop的基本思想是循环地处理事件，当有事件发生时，RunLoop会调用相应的处理函数来处理事件。RunLoop还提供了定时器、输入源、Perform Selector等机制来处理异步事件。了解RunLoop的工作原理，可以帮助我们更好地理解iOS应用的运行机制，避免出现一些奇怪的问题。

最后，我们再来看一下RunLoop的一些注意事项：

1. 不要在主线程中阻塞RunLoop，否则会导致UI卡顿。
2. 避免使用RunLoop的NSDefaultRunLoopMode模式，因为这个模式下会处理大量UI事件，可能会导致其他事件无法及时处理。
3. 在使用RunLoop的过程中，需要注意线程安全问题。

RunLoop是一种事件循环机制，通过它，我们可以很方便地处理各种事件，避免出现一些奇怪的问题。在日常开发中，我们需要经常使用RunLoop，所以建议大家多多练习，掌握RunLoop的各种用法。

这里抛出一个问题

作为一个前端为什么要去学习 Rust ？

这是个好问题，有人可能觉得前端学习 Rust 意义不大，学习成本高，投入产出比低啥的，JavaScript、TypeScript 这些前端语言还没搞明白呢，为什么还要去学一门这么难的新语言？

那么今天我就谈谈我自己对于这个问题的看法~，主要是分为 5 点：

• 性能
• 跨平台特性
• 安全性
• 职业视野
• 职业竞争力

性能

Rust 可以给 Node.js 提供一个性能逃生通道，当我们使用 Node.js 遇到性能瓶颈或 CPU 密集计算场景的时候，便可以使用 Rust 编写 Native Addon 解决这个问题了，Native Addon 就是一个二进制文件，也就是 xxx.node 文件，比如 swc(对应 babel)、Rspack(对应Webpack)、Rome(对应 eslint、prettier、babel、webpack 等，目标是代替我们所熟悉的所有前端工具链...)，上面提到的工具链就都是使用 Rust 编写的，性能比 Node.js 对应功能的包都有了极大的提高，同时 Rust 也是支持多线程的，你编写的多线程代码在 Node.js 中一样可以跑，这就可以解决了 Node.js 不擅长 CPU 密集型的问题。在前端架构领域目前 Rust 已经差不多是标配了，阿里、字节内部的前端基建目前都开始基于 Rust 去重构了。

跨平台

可以编写高性能且支持跨平台的 WebAssembly 扩展，可以在浏览器、IOT 嵌入式设备、服务端环境等地方使用，并且也拥有很不错的性能；和上面提到的 Native Addon 不一样， Native Addon 在不同的平台上都需要单独的进行编译，不支持跨平台；但是 WebAssembly 不一样，虽然它的性能没 Native Addon 好，但是跨平台成本很低，我编写的一份代码在 Node.js 中执行没问题，在 Deno 中跑也没问题，在 Java 或者 Go 中跑也都没问题，甚至在单片机也可以运行，只要引入对应的 Wasm 运行时即可。现在 Docker 也已经有 WebAssembly 版本了；同时 Rust 也是目前编写 WebAssembly 最热门的语言，因为它没有垃圾回收，性能高，并且有一个超好用的包管理器 cargo。

安全

Rust 编译器真的是事无巨细，它保证你编写的代码不会出低级错误，比如一些类型上的错误和内存分配上的错误，基本上只要 Rust 代码能够编译通过，就可以安心上线，在服务端、操作系统等领域来说这也是个很好的特性，Linux 系统和安卓系统内核都已经开始使用 Rust ，这还信不过嘛？

视野

Rust 可以提升自己在服务端领域的视野，Rust 不同于 Node.js 这个使用动态 JS 语言的运行时，它是一门正儿八经的静态编译型编程语言，并且没有垃圾回收，可以让我们掌握和理解计算机的一些底层工作机制，比如内存是如何分配和释放的，Rust 中使用所有权、生命周期等概念来保证内存安全，这对我们对于编程的理解也可以进一步提升，很多人说学习了 Rust 之后对自己编写其它语言的代码也有了更深的理解，毕竟计算机底层的概念都是相通的，开阔自己的编程思维。

职业竞争力

这个问题简单，你比别人多一门技能，比如 WebAssembly 和 Native Addon 都可以作为 Node.js 性能优化的一种手段，面试的时候说你会使用 Rust 解决 Node.js 性能问题，这不是比别人多一些竞争力吗？面试官那肯定也会觉得你顶呱呱~ 另外虽然目前 Rust 的工作机会比较少，但是也不代表没有，阿里和字节目前都有关于前端基建的岗位，会 Rust 是加分项，另外 Rust 在 TIOBE 编程语言榜排名中已经冲进了前 20，今年 6 月份是第 20 名，7 月份是第 17 名，流行度开始慢慢上来了，我相信以后工作机会也会越来越多的。

总结

不过，总的来说，这还是得看自己个人的学习能力，学有余力的时候可以学习一下 Rust，我自己不是 Rust 吹啊，我学习 Rust 的过程中真的觉得很有趣，因为里面的很多概念在前端领域中都是接触不到的，学了之后真的像是打开了新世界的大门，包括可以去看 Deno 的源码了，可以了解到一个 Js 运行时是怎么进行工作的，这些都是与我们前端息息相关的东西，即使哪天不做前端了，可以去转服务端或嵌入式方向，起码编程语言这一关不需要费多大力气了，Rust 是目前唯一一门从计算机底层到应用层都有落地应用的语言。不多说了，学就完事了，技多不压身嘛

大家好，我是 Zhero！

作为程序员，在我们的日常工作中，会花费大量时间在编码和阅读代码上。为了减轻眼睛的疲劳并提高工作效率，选择一个优秀的代码编辑器主题非常重要。今天我向大家推荐一款备受欢迎的 JetBrains IDE 主题插件 - Dracula。它采用深色调和高对比度的设计风格，成为黑暗系编程主题的杰出代表。Dracula 主题的界面清晰简洁，代码高亮显示明确鲜明，使得代码结构更加清晰易读。使用 Dracula 主题不仅能减少眼睛的疲劳，还能让我们更专注于代码的编写和理解。如果你正在寻找一个优秀的代码编辑器主题，不妨给 Dracula 一试，相信它会给你带来全新的编程体验。

来源

Dracula 主题源自于一种热门的色彩风格，也被称为“Dracula”。它最初由 Zeno Rocha 在 TextMate 编辑器上设计和实现。随着其受欢迎程度的不断增加，Dracula Color Scheme 成为一个跨平台的开源项目，并得到了许多编辑器和 IDE 的支持。

JetBrains 公司注意到了 Dracula 这种深色调和高对比度的设计，并将其引入了他们的 IDE 产品线。现在，IntelliJ IDEA、PyCharm、WebStorm 等 JetBrains 的 IDE 都提供了官方支持的 Dracula 主题插件。这款黑暗炫彩的主题受到了广大程序员的喜爱，成为了他们工作中常用的选择之一。无论是在日常编码还是阅读代码时，Dracula 主题都能为程序员带来舒适的使用体验。

设计风格

Dracula 主题的设计具有以下魅力：

1. 高对比度的前景和背景： Dracula 主题使用高对比度的前景和背景色，使得代码内容的层次分明，易于阅读和理解。
2. 强调重要内容的语法高亮： Dracula 主题使用明亮的绿色进行语法高亮，能够清晰地强调代码中的重要部分，帮助程序员更好地理解代码逻辑。
3. FLAT 扁平化设计风格： Dracula 主题采用简洁大方的 FLAT 扁平化设计风格，界面整洁清晰，让代码更加突出。
4. 黑客文化与美学融合： Dracula 主题融合了黑客文化中的深色基调和对于对比度和视觉冲击的美学追求。它既展现了黑客式的科技感，又兼具艺术家般的美学气质。

通过这些设计特征，Dracula 主题确保了代码的可读性，提供了令人愉悦的编程体验，并为开发者们带来了独特的视觉享受。

优点

Dracula 主题在技术上具有以下优势：

• 明暗分明的前景和背景： Dracula 主题使用明暗分明的前景和背景色，使得代码的视觉层次感强，识别度高，提高了代码的可读性和理解效率。
• 温暖色菜单栏和标识色边框： Dracula 主题在菜单栏和标识色边框上采用温暖色，增加了页面元素的识别度，帮助用户更好地找到所需功能。
• 强调重要内容的明亮色彩： Dracula 主题使用明亮的色彩来突出重要的内容，提高了可关注点的辨识度，使开发者能够更快速地定位和理解关键代码部分。
• 条件颜色支持： Dracula 主题提供了适应不同环境光照条件的条件颜色支持，确保在不同的工作环境中都能有良好的显示效果。

Dracula 主题带来的用户体验提升包括：

• 提高代码可读性和理解效率： 明暗分明的视觉层次感和明亮色彩的使用使得代码更易于阅读和理解，提高了开发者的工作效率。
• 丰富的语法色彩增强趣味性： Dracula 主题提供丰富的语法色彩，使得编程过程更具趣味性和乐趣，激发开发者的工作热情。
• 酷炫的外观满足个性化追求： Dracula 主题具有独特的外观设计，满足技术宅对个性化的追求，让开发环境更具魅力和个性。
• 对色弱用户友好： Dracula 主题经过精心设计，在保证美观的同时也考虑到了色弱用户的需求，不会造成视觉障碍。

正因为这些优势，Dracula 主题备受码农的青睐。它极大地提升了 JetBrains IDE 的美观性和可用性，无论是初学者还是老手，都能够享受到 Dracula 主题带来的舒适的用户体验。

支持产品

到目前为止，Dracula 主题已经广泛支持341+款应用程序，涵盖了各个平台和工具。除了 JetBrains IDE，Dracula 还适用于许多其他知名的应用程序，其中包括但不限于以下几个：

• Notepad++： Dracula 主题为 Notepad++ 提供了独特的外观，使得文本编辑器更加美观和舒适。
• iTerm： Dracula 主题为 iTerm 终端应用程序带来了独特的配色方案，提升了终端界面的可视性和使用体验。
• Visual Studio Code： Dracula 主题为 Visual Studio Code 提供了一套酷炫且易于辨识的代码颜色方案，让开发者能够更好地编写和调试代码。
• Vim： Dracula 主题为 Vim 编辑器提供了一种简洁而又优雅的配色方案，使得代码在终端中的显示更加清晰明了。
• Terminal.app： Dracula 主题为 macOS 上的 Terminal.app 终端应用程序提供了一种时尚和易于识别的配色方案，提升了终端的可用性和美观性。
• Zsh： Dracula 主题兼容 Zsh 终端的配色方案，使得命令行界面更加美观和个性化。

这些应用程序只是 Dracula 主题所支持的众多应用程序中的一部分，它们的加入使得 Dracula 主题在各个平台和工具上都能够提供一致的视觉体验，满足开发者对于美观和可用性的追求。

查看更多支持产品：

draculatheme.com

使用

下面我用 IDEA 实例给大家展示一下如何使用吧！

1. 前往插件市场，搜索Dracula，点击安装

2. 前往 Preferences > Appearance & Behavior > Appearance，从下拉菜单中选择Dracula

3. 前往 Preferences > Editor > Color Scheme，从下拉菜单中选择Dracula

通过上述步骤，您可以启用Dracula主题啦！

总结

Dracula 主题为 JetBrains IDE 带来了卓越的高对比度黑暗风格，本文我为大家介绍一下它的优点。如果你还没有尝试过这款插件，快去试试吧！

这是一个职业生涯三叶草模型，它分为兴趣、价值、能力三个维度，完美的主职业最好同时满足这三项。但事情往往未必那么如意，如果主职业没能同时满足，那么剩下的部分，完全可以用副业填充。

或者，通俗点说，做副业的第一目标一般是赚钱，想大幅度增加“价值”尤其是物质价值这个维度，那就让我们进入正题，看看程序员可以做的副业都有哪些。

内容变现

特点：高投入、门槛中等、长期主义

公众号

现在短视频更为吸引流量的时代，做公众号可能已经不是最优解，但做公众号的思路可以推广到一切内容副业上。认真写的内容也终将被看到，现在获取的粉丝反而更为核心、粘性更高。

公众号的赚钱途径主要有三个：流量主、接受打赏、接广告。

到达一定流量后，官方会邀请开通“流量主”功能，每篇推文末尾会有广告卡片，被点击即可获得收益。也就是说，开通该功能后，不需要做额外动作，发送推文就有收入。



第二种是接受打赏，是很直观的读者对作者的物质激励。不过引导比较少的情况下，很少有读者自行去做打赏这个动作的，这部分收入就当做运营公众号的额外小激励吧。

公众号积累粉丝，长期下来阅读量和粉丝比较好会有广告商找来做广告，俗称“恰饭”，这种收入相比前面两者来说就是“大单子”了，一单一般来说根据公众号质量和流量，会上百、上千、甚至上万、几十万不等。那这种收入就比较可观了，而且有广告主找到，也往往意味着，这个公众号质量还不错。

为什么说公众号的思路可以推广到一切内容副业呢？因为内容可复用，就可以搭建自己的技术博客网站、分发到其他技术社区，而获利思路也是一致的，无非是流量和知名度的获益。具体的平台运营方式可能不会完全相同，还需要自己提前学习，不断在使用中进行探索。

知识专栏

如果你的写作水平还可以，也有可以成体系、系统化的知识输出，那可以尝试整理一个系列课程，以付费知识专栏的形式推出。

极客时间、掘金小册、慕课网……非常多技术社区都推出了付费专栏，除了内容创作者自发上传的零散内容，一般也有这种成体系的、可以系统性掌握一部分技术的课程，大多数价格不高，一般在百元以内，正因为如此付费门槛也很低，用户乐意为此支付。这种付费专栏如果是线上分成形式，相当于是一个一劳永逸持续入账的项目。

视频博主

同样地，如果内容足够好的话，也可以考虑做视频博主，这分两个方向，个人博主和视频教程。不过相比于图文内容的专栏，视频的门槛会更高，对表达能力、授课能力、互动能力都有要求，还可能需要学习相应的录制、剪辑、运营知识。

做个人视频博主，有平台本身给到内容创作者的流量收益，也有接广告恰饭的收益，一个细水长流，一个来得快但未必持久。长期下来还是需要持续更新、长久维护，小流量不断的同时，打广告有规律。出视频教程，则是与对应平台签约，看自己的版权要求、价格要求、付费机制，自行选择即可。

技术变现

特点：技术门槛低、项目导向、投入一般

接外包

说起程序员赚外快、副业来，一般最容易想到的就是接私活接外包，比如有很多外包服务平台如猪八戒、一品威客、解放号、码客帮、码市、程序员客栈等等，不过看起来价格并不很美好，大家可以自行筛选。比较靠谱的是熟人介绍，这样需求确认、尾款交付时都会比单纯陌生人更顺利。所以重要的还是积累技术、积累资源、积累人脉，逐渐打造自己的渠道和核心竞争力。

自主开发项目

如果技术水平不错，有想法有新意，但不想写文章、不愿录视频，依然只想跟代码打交道，那就可以自主开发项目来变现。根据自己的技术栈还有创意想法，可以是不同的产品，如桌面应用程序、手机APP、小程序、各种插件等。当然，产品要做到通过付费来盈利，门槛确实比较高了，而且除了技术，对运营能力也有一定的要求。做得好的完全可以做独立开发者来养活自己。

比如这样在禅道插件市场上传插件的用户，已经获得了很高的持续性收益。

其他方向

特点：门槛高低不一、收入不一、形式灵活

 除了前面的内容导向和技术导向，其实还有很多跟技术、跟主业完全没有任何关系的方向。比如培训师，往往是按天收费，费用很高，不过当然也需要极高的知识壁垒；比如经常调侃的跑滴滴、送外卖，也能见证一些人生百态；比如有的人做手绘涂鸦、游戏陪玩这种兴趣驱动的副业，满足兴趣爱好的同时还能获得收入；比如很多脑力劳动者跑去做的轻体力活，如便利店收银、酒店前台、快餐店兼职，在机械操作的体力活中解放大脑。

总之一句话：副业形式千千万，还是得靠实力干。短期的在线刷单、杀猪盘投资等等都被翻来覆去地反诈骗讲烂了，但任何宣称短期的、高回报率，都可能是带着引号的“副业”，需要擦亮眼睛加以鉴别。

大多数副业还是有门槛的，需要投入精力和时间，找好方向，坚持长期主义，去做吧！

在上一篇《单枪匹马程序员，月营收从 0 到 1 万刀，近 90% 的毛利》里有掘友评论，这样的产品只有国外有，国内缺乏生态。

这篇文章主要是分享一下为什么我认为作为国内的开发者，应该多关注海外市场、做面向海外用户的产品。

早在 2000 年（点 com 泡沫那阵），国外就有了 indie hacker / indie maker 这个名词来称呼做“独立”产品的人。这里的 indie 是 independent 的意思，意在独立（解脱）于各种束缚，比如：朝九晚五的工作时间、固定的办公室、领导、或者是投资人。

而国内在最近几年也涌现了一拨独立开发者，多数以工程师为主，当然做的产品也是面向国内的市场。有做地不错的，像 Baye 的熊猫吃短信、vulgur 的极简时钟、Kenshin 的简阅等；但综合我这两年来对海外一些独立产品的研究，海外市场或许是更好的选择。

当然凡是都有个前提，就是你没有一个豪华的创始团队或者是顶级投资人的背书，就是个人或者两三人的小团队。这个条件我觉得可以覆盖 90% 的中国的开发者；对于另外 10% 的拥有资源或者金主爸爸靠山的个人或者团队，不仅“可以”还“应该”去磕中国市场。但这不是今天要讨论的主题。

在 BAT TMD 等巨头和背靠资源的精英创业者们的夹缝里，我觉得只有做面向海外市场的小产品是更有胜率一点；做国内市场面临的四个问题：

第一、不存在足够的空间给个人/小团队做独立产品存活。

Slack 大家应该都知道，在美国已经上市了，市值 200 亿刀。Slack 一直是被 qiang 的，但是为什么国内没有出现 Slack 这样的产品作为一个信息中心来连接各个办公工具？

其实有，还不少，但都没活太久。一部分原因是腾讯阿里都非常重视这个“商业流量入口”，不想有可能被对方占有了。另外是国内互联网生态，从 BAT TMD 巨头到小软件公司，都太封闭；不仅不开放，还相互制约，都想把自己流量的守住，所以就同时出现了三个 Slack：

• 微信出个企业微信（还封杀了 wetools）
• 阿里出个钉钉
• 字节出个飞书

在这种巨头虎视眈眈且相互对抗的格局里，作为三缺（缺钱、缺资源、缺核心门槛）的个人或者团队是无法存活的。或许在 2010 年至 2016 年间还有草根产品团队依靠“热钱”注入有爆发的可能性，时至今日，特别是这个蜜汁 2020 的局势，是不太可能的了。

即使，你找到了一个空白的利基市场（niche），你接下来面对三个问题：需求验证（试错）、推广、和商业化。

第二点、需求验证或者叫“试错”成本高。

由于国情不同，咱们需要经过一些不可避免的审核流程来保证互联网的干净。这个没话说，在哪做事就守哪的规矩。但这“需求验证”的门槛可就提高了不少。

比如要做个网站吧，备案最快也两周。做游戏？有没有版号？做 app ？有没有软著？小程序（从用户端来讲）是个不错的创新，但是你最烦看到的是不是“审核不通过，类目不符合”？稍微做点有用户互动的功能都需要公司主体。公司注册、银行开户、做帐、以及各种实名制等；这些虽然都不是不可达到的门槛，但是去完成这些要耗费大量的精力，对于本身就单打独斗的开发者来说 - 太累了。

再看看海外，简直不要太爽。做 app 还是需要经过苹果和谷歌的审核，但几乎不会对程序本身以外的东西设置门槛。网站注册个域名，30 秒改个 DNS 指到你的 IP，Netlify 或 Vercel 代码一推，就自动构建、部署、上线了。哪怕你不会写代码或者会写代码但是想先验证一下需求，看看潜在用户的响应如何，国外有不少非常值得一样的 no code 或 low code 平台。这个以后可以单独写一篇。

OK，国内你也通过重重难关项目终于上线了，你面临剩下的两个问题：推广和商业化。

第三点、推广渠道少 && 门槛高。

海外市场的推广渠道更多元，比如 ProductHunt, IndieHackers, BetaList 等。这些平台不仅国内没有，我想表达的更重要一点是，这些平台用户都比较真诚和热心会实在地给你提建议，给你写反馈。国内也有几个论坛/平台，但是用户氛围和友好度就和上述几个没法比了。

在付费推广方面，国内门槛（资质、资金）都挺高，感觉只有大品牌才能投得起广告，这对于缺资金的团队来讲，又是闭门羹。而国外，facebook 和 google 拿个 50、100 刀去做个推广计划都没问题。

可以以非常低的成本来获取种子用户或者验证需求。

行吧，推广也做得不错，得到了批种子用户并且涨势还不错；就最后一步了，商业化。

第四点、商业化选择少。

说商业化选择少可能说过了。国内是由于巨头间的竞争太激烈，出现各种补贴手段，导致互联网用户习惯于免费的互联网产品，甚至觉得应该倒贴给他来使用；伸手党、白 piao 党挺多；付费以及版权意识都还有改善空间。

想想你都给哪些浏览器插件付费过？“插件还需要付钱？！”

而海外用户的付费意愿足够强烈，在以后的案例分享中就能体会到。一个小小的浏览器插件，做得精美，触碰到了用户的购买欲望，解决了他一个痛点，他就愿意购买。

下一篇就分享国外浏览器插件的产品案例。

顺便再说一个「免费 vs 付费」的问题，这个不针对哪个国家，全世界都一样。免费（不愿意付费）的用户是最难伺候的，因为他们不 value 你的产品，觉得免费的就是创造者轻易做出来的、廉价的。如果依着这部分不愿意付费的客户来做需求，产品只会越做越难盈利。

掘友们，下一篇文章见了

最近项目有个时间倒计时的功能，网上也有很多优秀的第三方。这个功能应用还是比较广泛的，就稍微研究了一下。有好几种方法实现，笔者选取较简单一种。

原理其实很简单，就是一个的绕X轴的翻转动画，只是在翻转过程中针对特殊情况做 特殊处理就行，下面也会讲到。

效果图

思路

以一次完整动画为例，分步骤解析：

第一步：

新建3个UILable，分别是正在显示(currentLabel)、下一个显示(nextLabel)、做动画的(animationLabel)。

第二步：

首先在每次动画前给nextLabel设置默认的X轴起始角度翻转，这样处理是为了能够只显示上半部分，下半部分被隐藏（zPosition不改动的情况下），如下图，红色的是nextLabel，绿色的是currentLabel，灰色的是animationLabel。

代码：

// 设置默认的X轴起始角度翻转，为了能够只显示上半部分，下半部分被隐藏（zPosition不改动的情况下）

func setupStartRotate() -> CATransform3D {

    var transform = CATransform3DIdentity

    transform.m34 = CGFLOAT_MIN

    transform = CATransform3DRotate(transform, .pi*kStartRotate, -1, 0, 0)

    return transform

}

第三步：

使用CADisplayLink做动画，笔者这里设置固定的刷新帧率为60（因为存在不同的刷新帧率设备），且动画执行时间0.5s，即每次刷新帧率时动画执行了2/60进度。

接下来使用CATransform3DRotate将animationLabel沿着X轴进行翻转动画，这时候我们会发现动画的进度超过一半时，会存在如下问题：

上图这个是倒计时 2 变为 1 的过程，且动画进度超过一半时的显示画面。我们换个角度看看：

可知在当前情况下，灰色的标签显示的是 2 的上部分的背面，但是应该显示的是 1 的下部分，这显示是有问题的。这么说有点拗口，简单来说就是一个物体在3D空间中沿X轴翻转大于90度时，我们看到的实际是物体的上下和前后均颠倒的二维平面，所以才会出现如此的不和谐。

所以解决这个问题，使动画更和谐流畅，我们需要物体翻转的动画在临界点翻转到90度时，即与屏幕垂直的时候，为了正确显示，即需要将动画的animationLabel同时沿着Y和Z轴翻转，并切换文字，将2切换成1。即：

if animateProgress >= 0.5 {

   t = CATransform3DRotate(t, .pi, 0, 0, 1);

   t = CATransform3DRotate(t, .pi, 0, 1, 0);

   animationLabel.text = nextLabel.text

 }else{

   animationLabel.text = currentLabel.text

 }

此时的过程就是 2 在翻转超过90时，将之沿着Y和Z轴翻转，并切换为1，看到的就是动图显示的过程了。

到这里一个完整的翻转动画就结束了，后面使用CADisplayLink定时重复上述动画就可以了。

后续也使用这个动画写了一个时间显示的和倒计时的demo，具体的代码在下面的链接，感兴趣的可以查阅指导下。

RCFoldAnimation

若存在什么不对的地方，欢迎指正！

简介

平时在使用 Mac 的过程中，经常会使用终端输入命令来执行一些操作。在越狱开发的过程中，同样需要在 iOS 系统上输入一些命令来执行一些任务。那么如何才能在 iOS 系统上输入命令呢，在 iOS 上安装一个终端命令行工具，然后在 iPhone 那小小的屏幕上用触摸屏输入命令吗？虽然说理论上和实际上都是可行的，但是通过手指触摸屏幕来输入命令的方式效率比较低，也不是很方便。这里还是推荐在 Mac 上远程登录到 iOS 系统，这样就可以使用 Mac 的键盘输入命令到 iOS 上去执行，更加方便，快捷。

SSL、openSSL、SSH、openSSH

SSL（Secure Sockets Layer）是一种用于在计算机网络上进行安全通信的协议。SSL 最初由 Netscape 开发，后来发展为 TLS（Transport Layer Security）。SSL/TLS 用于在客户端和服务器之间建立安全的加密连接，以保护敏感数据的传输，例如在网页浏览器和服务器之间的数据传输。

OpenSSL 是一个强大的、商业级的、功能齐全的开源工具包，它提供了一组库和命令行工具，用于处理 SSL/TLS 协议和加密算法，是 SSL 协议的一款开源实现工具。OpenSSL 可以用于创建和管理数字证书、实现安全传输和通信，以及进行加密和解密等操作。它不仅支持 SSL/TLS 协议，还支持多种加密算法和密码学功能。

SSH（Secure Shell）是一种用于安全远程登录和数据传输的网络协议。它为计算机之间的通信提供了加密和身份验证，以确保通信的机密性和完整性。SSH 使用公钥密码体制进行身份验证，并使用加密算法来保护数据的传输。

OpenSSH 是一个开源的 SSH 实现，它提供了 SSH 客户端和服务器的功能，用于安全远程登录、命令执行和文件传输。它包括客户端 ssh 和服务器 sshd、文件传输实用程序 scp 和 sftp 以及密钥生成工具 (ssh-keygen)、运行时密钥存储 (ssh-agent) 和许多支持程序。它是 Linux 和其他类 Unix 系统中最常见的 SSH 实现，也支持其他操作系统。

SSL 最早出现于 1994 年，用于 Web 浏览器和服务器之间的安全通信。OpenSSL 和 SSH 都起源于 1995 年，OpenSSL 是一个加密工具包，而 SSH 是用于安全远程登录和数据传输的协议。OpenSSH 是 SSH 协议的开源实现，起源于 1999 年，为 SSH 提供了广泛使用的实现。

OpenSSH 通常依赖于 OpenSSL。OpenSSH 使用 OpenSSL 库来实现加密和安全功能，包括加密通信、密钥生成、数字证书处理等。OpenSSL 提供了各种加密算法和密码学功能，使 OpenSSH 能够建立安全的 SSH 连接，并保护通信数据的机密性和完整性。在大多数情况下，安装 OpenSSH 时，系统会自动安装或链接到已经安装的 OpenSSL 库。这样，OpenSSH 就能够使用 OpenSSL 的功能来实现加密和安全性，而不必重新实现这些复杂的加密算法和协议。

因此，可以说 OpenSSH 依赖于 OpenSSL，OpenSSL 提供了 OpenSSH 所需的加密和安全功能，使得 OpenSSH 成为一种安全、可靠的远程登录和数据传输工具。这些安全协议和工具对于保护通信和数据安全至关重要。

实践

对以上名词概念有了基本的了解之后，我们可以进行实践操作。如果感觉还是迷迷糊糊也不要紧，实践起来就会感觉简单多了。主要是对 OpenSSH 这个开源库提供的常用命令的使用。Mac 系统自带了这个工具所以不需要进行配置，而 iOS 系统上默认是没有安装这个工具的，包括越狱之后的 iOS 也没有，所以需要先下载安装这个工具。

安装过程很简单，如下图所示，在 Cydia 上搜索 OpenSSH 下载并按照提示进行安装就好了。

安装好之后，就可以在 Mac 上远程登录到越狱 iOS 了。iOS 系统默认提供了两个用户，一个是 root 用户，是 iOS 中最高权限的用户，我们在逆向开发过程中基本都是使用这个用户。还有一个是 mobile 用户，是普通权限用户，iOS 平时进行 APP 安装，卸载基本都是使用这个用户，但是我们在逆向开发中很少或者基本不会使用到这个用户，这里有个了解就够了。

Cydia 首页有 OpenSSH 访问教程，这个文档详细的记载了如何从 Mac 远程登录到 iOS 设备上，并且也提供了修改默认密码的方法。建议英文不错的同学直接阅读这篇文档，不想看的就看我后面的介绍也可以。文档位置如下图所示

通过默认账号密码登录到 iPhone

ssh 提供了两种登录到服务器的方式，第一种是使用账号和密码。第二种是免密码登录。下面先介绍第一种

1. 越狱 iPhone 在 Cydia 上安装 OpenSSH
2. 确认 iPhone 和 Mac 电脑在同一个局域网下，在 Mac 打开终端，输入以下命令

   ssh root@iPhone的IP地址
   
   

   第一次连接会出现 Are you sure you want to continue connecting (yes/no/[fingerprint])? 提示，输入 yes 确认进行连接
3. 输入默认的初始密码 alpine ,这里终端为了安全并不会显示密码的明文
4. 之后就会看到终端切换到了 iPhone:~ root# 用户，代表成功登录到远程 iPhone 手机的 root 用户上了。这个时候，你在 Mac 终端输入的指令都会被发送到 iPhone 上，如下图 
   
    如果你觉得还不过瘾，可以输入 reboot 命令，体会一下远程操纵手机的快乐（重启之后，你可能需要重新越狱一下 iPhone 了😶）
5. 输入 exit 退出登录

刚刚我们登录的是 root 用户。在 iOS 中，除了 root 用户，还有一个 mobile 用户。其中 root 用户是 iOS 中最高权限的用户。mobile 是普通权限用户，其实平时越狱调试过程中，很少会使用这个 mobile 用户，这里只是介绍一下。

能够成功登录 iPhone 之后，建议修改一下用户的默认密码，既然做逆向开发了，当然对安全也要注意一点。在登录 root 用户之后，输入：passwd 可以修改 root 用户的密码，输入 passwd mobile 可以修改 mobile 用户的密码。

通过免密码方式登录到 iPhone

OpenSSH 除了默认的账号密码登录的方式，还提供了免密码登录的方式。需要进一步完成一些配置才可以实现。服务器（在当前情况下，iPhone是服务器，Mac是客户端）的 ~/.ssh 目录下需要添加一个 authorized_keys 文件，里面记录可以免密登录的设备的公钥信息。当有客户端（Mac）登录的时候，服务器会查看 ~/.ssh/authorized_keys 文件中是否记录了当前登录的客户端的公钥信息，如果有就直接登录成功，没有就要求输入密码。所以我们要做的就是将 Mac 设备的公钥信息追加到 iPhone 的 authorized_keys 文件内容的最后面。追加是为了不影响其他的设备。完成这个操作需要先确保我们的 Mac 设备上已经有 ssh 生成的公钥文件。

打开 Mac 终端，输入 ls ~/.ssh 查看是否已经存在 id_rsa.pub 公钥文件，.pub就是公钥文件的后缀

如果没有看到公钥文件，需要使用 ssh-keygen 命令生成该文件。按回车键接受默认选项，或者根据需要输入新的文件名和密码。这将生成一个公钥文件（id_rsa.pub）和一个私钥文件（id_rsa）。

使用 SSH 复制公钥到远程服务器。使用以下命令将本地计算机（Mac）上的公钥复制到远程服务器（iPhone）。请将user替换为您的远程服务器用户名，以及remote_server替换为服务器的域名或IP地址。

ssh-copy-id user@remote_server

在远程服务器（iPhone）上设置正确的权限。确保远程服务器上的~/.ssh文件夹权限设置为 700，并将~/.ssh/authorized_keys文件的权限设置为 600。这样可以确保SSH可以正确识别公钥并允许免密码登录。如下图所示：

.ssh 文件夹前面的 drwx------ 是 Linux 和类 Unix 系统中表示文件或目录权限的一种格式。在这个格式中，每一组由10个字符组成，代表文件或目录的不同权限。让我们逐个解释这些字符的含义：

所以，drwx------ 表示这是一个目录，并且具有以下权限：

• 文件所有者具有读、写和执行权限。
• 文件所有者所在组没有任何权限。
• 其他用户没有任何权限。

后面 9 个字符分为三组，每组从左至右如果有对应的权限就是421相加起来就是 7 后面都是0。所以 .ssh 文件夹的权限是正确的值 700，如果不是 700 的使用 chmod 700 .ssh 进行提权。authorized_keys 文件的权限是 rw 就是 420 相加起来就是 6 。后面都是 0，所以 authorized_keys 的权限也是正确的值 600。同样如果不是 600，使用 chmod 600 authorized_keys 命令修改权限。

配置完成后，您现在可以使用 SSH 免密码登录到远程服务器（iPhone）。在 Mac 上，使用以下命令连接到远程服务器：

ssh root@10.10.20.155

这将直接连接到远程服务器，而无需输入密码。

通过 USB 有线的方式登录到 iPhone

配置为免密码登录之后，还可以进一步使用 USB 有线连接的方式登录到手机。如果你经常使用 WiFi 这种方式远程登录调试就会发现偶尔会碰到指令输入，响应卡顿，反应慢的情况，这样的体验显然让人感到不爽。所以，在大部分情况下，更推荐使用 USB 有线连接登录到 iPhone 上，这样使用的过程中，就像在本地输入命令操作一样流畅。

iproxy 是一个用于端口转发的命令行工具。它通常用于在 iOS 设备和计算机之间建立端口映射，从而将 iOS 设备上运行的服务暴露到计算机上。这对于开发者来说非常有用，因为可以通过本地计算机访问 iOS 设备上运行的服务，而无需将服务部署到公共网络上。

iproxy 是 usbmuxd 的一部分，后者是一个用于连接和管理 iOS 设备的 USB 通信的守护进程。usbmuxd 允许通过 USB 连接与 iOS 设备进行通信，并且iproxy 则负责在本地计算机和iOS设备之间建立端口转发。

通常，您可以在命令行中使用 iproxy 命令来建立端口转发，例如：

iproxy local_port device_port

其中，local_port 是本地计算机上的端口号，device_port 是 iOS 设备上的端口号。执行此命令后，iOS 设备上的服务将通过 device_port 映射到本地计算机上的 local_port。

请注意，使用 iproxy 需要先安装 libusbmuxd 包。在 macOS 上，您可以使用 Homebrew 来安装 libusbmuxd：

brew install libusbmuxd

安装好之后，就可以使用 iproxy 命令了，使用 iproxy 将本机 10010 端口和 USB 设备的 22 端口进行映射的命令如下：

iproxy 10010 22

这里本机的端口 10010 可以设置为你想要的其他端口，但是不能是系统保留的端口（系统保留的端口有哪些，可以看百度的介绍）。端口转发设置完成之后，这个终端就不要关闭，也不要管它了，新建另一个端口进行 ssh 登录。此时，需要给 ssh 加上指定端口参数，命令如下：

ssh -p 10010 root@localhost

同样第一次使用这种方式建立连接会给出提示，输入 yes 确认

之后，在 iPhone 设备上输入命令调试时，再也不会遇到卡顿，慢，延迟的现象啦。玩得开心~

前言

最近公司提出了一个有趣的新需求，需要开发一个功能来自动识别用户前置摄像头中的人脸，并且能够对其进行截图。

话不多说，直接开整...

• 技术点：
• AVCaptureSession：访问和控制设备的摄像头，并捕获实时的视频流。
• Vision：提供了强大的人脸识别和分析功能，能够快速准确地检测和识别人脸。

效果

开始

首先，工程中引入两个框架

import Vision

import AVFoundation

接下来，我们需要确保应用程序具有访问设备摄像头的权限。先判断是否拥有权限，如果没有权限我们通知用户去获取

let videoStatus = AVCaptureDevice.authorizationStatus(for: .video)

switch videoStatus {

case .authorized, .notDetermined:

    print("有权限、开始我们的业务")

case .denied, .restricted:

    print("没有权限、提醒用户去开启权限")

default:

    break

}

然后，我们需要对摄像头进行配置，包括确认前后置摄像头、处理视频分辨率、设置视频稳定模式、输出图像方向以及设置视频数据输出

配置

确认前后置摄像头：

使用AVCaptureDevice类可以获取设备上的所有摄像头，并判断它们是前置摄像头还是后置摄像头

// 获取所有视频设备

let videoDevices = AVCaptureDevice.DiscoverySession(deviceTypes: [.builtInWideAngleCamera], mediaType: .video, position: .unspecified).devices



// 筛选前置摄像头和后置摄像头

var frontCamera: AVCaptureDevice?

var backCamera: AVCaptureDevice?



for device in videoDevices {

    if device.position == .front {

        frontCamera = device

    } else if device.position == .back {

        backCamera = device

    }

}



// 根据需要选择前置或后置摄像头

let cameraDevice = frontCamera ?? backCamera

处理视频分辨率：

可以通过设置AVCaptureSession的sessionPreset属性来选择适合的视频分辨率。常见的分辨率选项包括.high、.medium、.low等。

let captureSession = AVCaptureSession()

captureSession.sessionPreset = .high

输出图像方向：

可以通过设置AVCaptureVideoOrientation来指定输出图像的方向。通常，我们需要根据设备方向和界面方向进行调整。

if let videoConnection = videoOutput.connection(with: .video) {

    if videoConnection.isVideoOrientationSupported {

        let currentDeviceOrientation = UIDevice.current.orientation

        var videoOrientation: AVCaptureVideoOrientation



        switch currentDeviceOrientation {

        case .portrait:

            videoOrientation = .portrait

        case .landscapeRight:

            videoOrientation = .landscapeLeft

        case .landscapeLeft:

            videoOrientation = .landscapeRight

        case .portraitUpsideDown:

            videoOrientation = .portraitUpsideDown

        default:

            videoOrientation = .portrait

        }



        videoConnection.videoOrientation = videoOrientation

    }

}

视频数据输出：

可以使用AVCaptureVideoDataOutput来获取摄像头捕捉到的实时视频数据。首先，创建一个AVCaptureVideoDataOutput对象，并将其添加到AVCaptureSession中。然后，设置代理对象来接收视频数据回调。

let videoOutput = AVCaptureVideoDataOutput()

captureSession.addOutput(videoOutput)



let videoOutputQueue = DispatchQueue(label: "VideoOutputQueue")

videoOutput.setSampleBufferDelegate(self, queue: videoOutputQueue)

视频处理、人脸验证

接下来，我们将对视频进行处理，包括人脸验证和圈出人脸区域。我们将在AVCaptureVideoDataOutputSampleBufferDelegate 的代理方法中来实现这些功能

func captureOutput(_ output: AVCaptureOutput, didOutput sampleBuffer: CMSampleBuffer, from connection: AVCaptureConnection) {

        

        guard let bufferRef = CMSampleBufferGetImageBuffer(sampleBuffer) else {

            return

        }

        

        let detectFaceRequest = VNDetectFaceRectanglesRequest()

        let detectFaceRequestHandler = VNImageRequestHandler(cvPixelBuffer: bufferRef, options: [:])

        

        do {

            try detectFaceRequestHandler.perform([detectFaceRequest])

            guard let results = detectFaceRequest.results else {

                return

            }

            

            DispatchQueue.main.async { [weak self] in

                guard let self = self else {

                    return

                }

                

                // 移除先前的人脸矩形

                for layer in self.layers {

                    layer.removeFromSuperlayer()

                }

                self.layers.removeAll()

                

                for observation in results {

                    let oldRect = observation.boundingBox

                    let w = oldRect.size.width * self.view.frame.size.width

                    let h = oldRect.size.height * self.view.frame.size.height

                    let x = oldRect.origin.x * self.view.bounds.size.width

                    let y = self.view.frame.size.height - (oldRect.origin.y * self.view.frame.size.height) - h

                    

                    // 添加矩形图层

                    let layer = CALayer()

                    layer.borderWidth = 2

                    layer.cornerRadius = 3

                    layer.borderColor = UIColor.orange.cgColor

                    layer.frame = CGRect(x: x, y: y, width: w, height: h)

                    

                    self.layers.append(layer)

                }

                

                // 将矩形图层添加到视图的图层上

                for layer in self.layers {

                    self.view.layer.addSublayer(layer)

                }

            }

        } catch {

            print("错误: \(error)")

        }

    }

结尾

识别单个人脸的时候没有太大问题，但是多个人脸位置不是很准确，有知道原因的小伙伴告知一下

在Activity间传递的数据一般比较简单，但是有时候实际开发中也会传一些比较复杂的数据，尤其是面试问道当遇到需要在Activity间传递大量的数据怎么办？

Intent 传递数据的大小是有限制的，它大概能传的数据是1M-8K，原因是Binder锁映射的内存大小就是1M-8K.一般activity间传递数据会要使用到binder，因此这个就成为了数据传递的大小的限制。那么当activity间要传递大数据采用什么方式呢？其实方式很多，我们就举几个例子给大家说明一下，但是无非就是使用数据持久化，或者内存共享方案。一般大数据的存储不适宜使用SP， MMKV，DataStore。

Activity之间传递大量数据主要有如下几种方式实现：

• LruCache
• 持久化（sqlite、file等）
• 匿名共享内存

使用LruCache

LruCache是一种缓存策略，可以帮助我们管理缓存，想具体了解的同学可以去Glide章节中具体先了解下。在当前的问题下，我们可以利用LruCache存储我们数据作为一个中转，好比我们需要Activity A向Activity B传递大量数据，我们可以Activity A先向LruCache先写入数据，之后Activity B从LruCache读取。

首先我们定义好写入读出规则：

public interface IOHandler {

    //保存数据

    void put(String key, String value);

    void put(String key, int value);

    void put(String key, double value);

    void put(String key, float value);

    void put(String key, boolean value);

    void put(String key, Object value);



    //读取数据

    String getString(String key);

    double getDouble(String key);

    boolean getBoolean(String key);

    float getFloat(String key);

    int getInt(String key);

    Object getObject(String key);

}

我们可以根据规则也就是接口，写出具体的实现类。实现类中我们保存数据使用到LruCache，这里面我们一定要设置一个大小，因为内存中数据的最大值是确定，我们保存数据的大小最好不要超过最大值的1/8.

LruCache<String, Object> mCache = new LruCache<>( 10 * 1024*1024);

写入数据我们使用比较简单：

@Override

public void put(String key, String value) {

    mCache.put(key, value);

}

好比上面写入String类型的数据，只需要接收到的数据全部put到mCache中去。

读取数据也是比较简单方便：

@Override

public String getString(String key) {

    return String.valueOf(mCache.get(key));

}

持久化数据

那就是sqlite、file等方式。将需要传递的数据写在临时文件或者数据库中，再跳转到另外一个组件的时候再去读取这些数据信息，这种处理方式会由于读写文件较为耗时导致程序运行效率较低。这种方式特点如下：

优势：

（1）应用中全部地方均可以访问

（2）即便应用被强杀也不是问题了

缺点：

（1）操做麻烦

（2）效率低下

匿名共享内存

在跨进程传递大数据的时候，我们一般会采用binder传递数据，但是Binder只能传递1M一下的数据，所以我们需要采用其他方式完成数据的传递，这个方式就是匿名共享内存。

「Anonymous Shared Memory 匿名共享内存」是 Android 特有的内存共享机制，它可以将指定的物理内存分别映射到各个进程自己的虚拟地址空间中，从而便捷的实现进程间内存共享。

Android 上层提供了一些内存共享工具类，就是基于 Ashmem 来实现的，比如 MemoryFile、 SharedMemory。

今日分享到此结束，对你有帮助的话，点个赞再走呗，每日一个面试小技巧

关注公众号：Android老皮

解锁  《Android十大板块文档》 ，让学习更贴近未来实战。已形成PDF版

内容如下：

1.Android车载应用开发系统学习指南（附项目实战）

2.Android Framework学习指南，助力成为系统级开发高手

3.2023最新Android中高级面试题汇总+解析，告别零offer

4.企业级Android音视频开发学习路线+项目实战（附源码）

5.Android Jetpack从入门到精通，构建高质量UI界面

6.Flutter技术解析与实战，跨平台首要之选

7.Kotlin从入门到实战，全方面提升架构基础

8.高级Android插件化与组件化（含实战教程和源码）

9.Android 性能优化实战+360°全方面性能调优

10.Android零基础入门到精通，高手进阶之路

相信这个特效你和你的朋友（或对象）一定玩过


当你发送一个便便的表情，对方如果扔一个炸弹表情，就会立刻将这个便便炸开，实现满屏粑粑的“酷炫”画面。可谓是“臭味十足”，隔着屏幕都能感受到来自微信爸爸的满满恶意。

不清楚大家对这个互动设计怎么看，反正一恩当时是喜欢的不行，拉着朋友们就开始“炸”得不亦乐乎。

同样被虏获芳心的设计小哥哥在玩到尽兴后，突然灵感大发，连夜绘制出了设计稿，第二天就拉上产品和研发开始脑暴。

“微信炸💩打动我的一点是他满屏的设计，能够将用户强烈的情绪抒发出来；同时他能够与上一条表情进行捆绑，加强双方的互动性。”设计小哥哥声情并茂道。

“所以，让我们的表情也‘互动’起来吧！”

这不，需求文档就来了：

改掉常见的emoji表情发送方式，替换为动态表情交互方式。即，

当用户发送或接收互动表情，表情会在屏幕上随机分布，展示一段时间后会消失。

用户可以频繁点击并不停发送表情，因此屏幕上的表情是可以非常多且重叠的，能够将用户感情强烈抒发。


（暂用微信的聊天界面进行解释说明，图1为原样式，图2是需求样式）

这需求一出，动态表情在屏幕上的分布方案便引起了研发内部热烈讨论：当用户点击表情时，到底应该将表情放置在屏幕哪个位置比较好呢？

最直接的做法就是完全随机方式：取0到屏幕宽度和高度中随机值，放置表情贴纸。但这么做的不确定因素太多，比如存在一定几率所有表情都集中在一个区域，布局边缘化以及最差的重叠问题。因此简单的随机算法对于用户的体验是无法接受的。

我们开始探索新的方案：

因为目前点的选择依赖于较多元素，比如与屏幕已有点的间距，与中心点距离以及屏幕已有点的数目。因此最终决定采用点权随机的方案，根据上述元素决策出屏幕上可用点的优度，选取优度最高的插入表情。

基本思路

维护对应屏幕像素的二维数组，数组元素代指新增图形时，图形中心取该点的优度。

采用懒加载的方式，即每次每次新增图形后，仅记录现有方块的位置，当需要一个点的优度时再计算。

遍历所有方块的位置，将图形内部的点优度全部减去 A ，将图形外部的点按到图形的曼哈顿距离从 0 到 max (W,H)，映射，减 0 到 A * K2。

每次决策插入位置时，随机取 K + n * K1 个点，取这些点中优度最高的点为插入中心

A, K, K1, K2 四个常数可调整

一次选择的复杂度是 n * randT，n 是场上方块数， randT 是本次决策需要随机取多少个点。 从效率和 badcase来说，这个方案目前最优。

代码展示

```cpp

#include <iostream>

#include <vector>

using namespace std;

 

const int screenW = 600;

const int screenH = 800;

 

const int kInnerCost = 1e5;

const double kOuterCof = .1;

 

const int kOutterCost = kInnerCost * kOuterCof;

 

class square

    int x1;

    int x2;

    int y1;

    int y2;

};

 

int lineDist(int x, int y, int p){

    if (p < x) {

        return x - p;

    } else if (p > y) {

        return p - y;

    } else {

        return 0;

    }

}

 

int getVal(const square &elm, int px, int py){

    int dx = lineDist(elm.x1, elm.x2, px);

    int dy = lineDist(elm.y1, elm.y2, py);

    int dist = dx + dy;

    constexpr int maxDist = screenW + screenH;

    return dist ? ( (maxDist - dist) * kOutterCost / maxDist ) : kInnerCost;

}

 

int getVal(const vector<square> &elmArr, int px, int py){

    int rtn = 0;

    for (auto elm:elmArr) {

        rtn += getVal(elm, px, py);

    }

    return rtn;

}

 

int main(void){

    

    int n;

    cin >> n;

 

    vector<square> elmArr;

    for (int i=0; i<n; i++) {

        square cur;

        cin >> cur.x1 >> cur.x2 >> cur.y1 >> cur.y2;

        elmArr.push_back(cur);

    }

 

 

    for (;;) {

        int px,py;

        cin >> px >> py;

        cout << getVal(elmArr, px, py) << endl;

    }

 

}

优化点

1. 该算法最优解偏向边缘。因此随着随机值设置越多，得出来的点越偏向边缘，因此随机值不能设置过多。
2. 为了解决偏向边缘的问题，每一个点在计算优度getVal需要加上与屏幕中心的距离 * n * k3

效果演示

最后就是给大家演示一下最后的效果啦！


圆满完成任务，收工，下班！