锁
为什么需要在应用层管理多线程读写？应用层可以根据实际的业务逻辑和需求，有选择性地选择lock和unlock的时机，从而更有效地管理并发，这个管理的过程和业务强绑定。抽象出来描述类似，你正在写的代码，写到一半停下来去打水，不希望别人动你的代码，你打水的时候决定把电脑锁屏。这是一个普遍的处理多个任务需要考虑的问题。
现代计算机已经从各个层面支持锁的实现，包括CPU的总线锁，缓存锁，汇编的Lock前缀等。总的来说，有多线程多进程的场景就需要用到锁来管理资源访问。
最简单的自旋锁的实现？1234567891011121314151617181920212223242526272829303132333435363738#include <stdio.h>#include <stdatomic.h>// 定义自旋锁类型typedef struct spinlock { atomic_flag locked;} spinlock;// 初始化锁void spinlock_init(spinlock *lock) { atomic_f ...
在AppIcon上显示version buildnum configure信息
场景：测试测出bug，经常出现包没装对，环境错了，开发要他们去确认是不是下对包了。
解决方案：干脆把这些信息打在Icon上，思路比较简单，在fastlane自动生成buildnum后，buildapp调用前。插入一个脚本调用，用的是python。传入版本号，buildnum以及configure类别，生成一个新Icon方法替换原本的，用到Python内置的PIL库处理图片。
脚本地址在这里
WorkSpace下多Project依赖管理
场景：使用pod做依赖管理的老项目，需要把一些功能模块抽出去做framework，要求抽出去的代码最好不要再手动处理资源引用类似的问题。一、不同类型库最终生成的包 .dylib动态库被弃用，.a的静态库可以创建，但是建议用framework，framework有命名空间和更好的封装性。这里讨论的都是framework处理的情况，创建framework默认是动态的，可以在mach-o type选成静态库。
静态framework：可执行二进制文件最终会和主项目链接在一起，framework只类似一个中间产物。framework中包含的资源文件，需要手动编写脚本挪到主bundle中，被引用的framework不需要设置成embed & sign也可以正常运行；
动态framework：framework会被挪到主bundle中的frameworks文件夹中。查看链接信息会发现@rpath/FrameworkDynamic.framework/FrameworkDynamic，其中@rpath就是包内的frameworks路径，在程序运行的时候动态 ...