静态库

因为static library,静态库或静态链接库是一组例程(编译好的二进制代码0和1组成),外部函数和变量,会暴露一些想暴露的头文件,具体实现不公开,也就是半开源软件),它们在编译时在调用者中解析,并由编译器,链接器或绑定器复制到目标应用程序中,生成对象文件和支架 独立可执行文件[1] 这个可执行文件和编译它的过程都被称为程序的静态构建。 历史上,库只能是静态的。 在构建/链接期间,静态库与其他静态库和对象文件合并,以形成单个可执行文件,或者在运行时将其加载到相应可执行文件的地址空间中,并以编译时/链接时间确定的静态内存偏移量。它的缺点也很明显:会使得目标程序的体积增大,像很多国内的知名第三方高德地图都采用的是静态库的方式。
 为什么我们会用到库呢?因为许多App不便的库能被呈现,它们是正确的版本,这消除了依赖问题,最为知名的就是DLL hell 也就是依赖地域,静态链接能允许App在单一可执行文件中包含,安装,因为它已经编译过了,所以会节省编译时间,当一个项目很大的时候,可能编译都要一杯水的时间甚至更长,静态库文件通过链接加载器或许在运行时链接,这过程就是静态链接。
 链接分为静态链接,动态链接。
 对应mac下的静态库.a就是静态库,之所以称之为静态,是因为静态库在编译的时间会直接copy一份,复制到目标程序里,这段代码在目标程序内不会再改变。

动态库

dylib-dynamic library的简写方式,这是动态库,与静态库截然相反,动态库在编译的时候不会被拷贝到目标程序中,目标程序中只会存储指向动态库的引用,等到程序运行时,动态库才会被真正加载起来。

优点:

1,因为不会拷贝到目标程序中,所以不会影响目标程序的体积增大,同一份库可以被多个程序使用,所以又称为共享库,同时,因为编译时才载入所以我们可以随时替换库,而不需要重新编译代码。

缺点:如果环境缺少某个动态库或者库的版本不正确,则会造成程序无法运行。

Framework

ios、Mac OS 可以使用framework。framework就是一种打包方式,将库的二进制文件,头文件,相关文件资源打包到一起,方便管理与分发。
 ios8之前不允许使用动态framework,开发者使用最多的是UIKit.framework,限制是因为出于安全考虑。当ios程序都运行在沙盒当中,不同的程序之间无法共享代码,同时动态下载代码也是苹果明令禁止的,动态库的优势被削弱了,所以动态库就没有必要了。
 开发人员如果想要共享代码,唯一的选择就是打包为静态库.a文件,同时附上头文件,但是这种打包方式还是很麻烦。。ios8 以后可以添加动态库的支持,因为swift的出现,因为swift中的extension和App是分开的可执行文件,同时需要共享代码,不支持动态库是不行了。系统的Framework不需要拷贝到目标程序中,而我们做出来的framework即使是动态的,最后还是要拷贝到App,苹果把它又称为embeded framework。

如何制作一个静态库呢?

新建一个project,选择 Framework/library,static cocoa touch library,创建成功,然后选择如图所示中的工程名,再选择build phases

屏幕快照 2017-05-25 下午9.28.38

然后点击+,选择 “new header phase”

屏幕快照 2017-05-25 下午9.14.44

然后选择将所要对应的文件拷到目标中,然后选择build phases中的header,选择对应想公开的.h文件(不全暴露是为了保护知识产权)。
 Ok,选择开始build(选择模拟器开始编译,编译成功后,则选择设备为general device再进行编译,编译成功,这是因为真机上呈现需要运行,而模拟器上也要运行,以前那会二个文件还得合并,现在好像不必了)。此时.a文件红色消失。然后新建一个文件夹将.a拷入,顺便拷入public的header file。(点击control 选择show in finder后进入后会在.a下方看到一个local文件夹,文件夹有个usr,usr内就包含了头文件,直接将其拖到文件夹就好,至此静态库制作完毕,创建一个工程试试效果,OK

屏幕快照 2017-05-25 下午9.41.44

软件Bug多,今天Xcode没有提示了,一怒之下将其卸载,重新安装后成了这样,以为屏幕碎了呢

屏幕快照 2017-05-25 下午9.42.57

SVN随着迭代时间越久,工程越来越大。(这个问题是当时经理问我的,因为对于SVN不是很明白,我是Github党)

我自己测试了,新建了一个工程,文件大小如图所示:

屏幕快照 2017-05-24 下午5.47.02

通过cocoapods导入了一个第三方库后,大小成了这样了

屏幕快照 2017-05-24 下午5.52.17


 而后上传SVN后,update后大小成了这样(我没有写一行代码)

屏幕快照 2017-05-24 下午5.54.04

随着产品迭代的时间越久SVN上的工程大小与日俱增,我思考了一天左右,觉得问题有如下方法解决:
 把之前的一些版本备份后清除掉,这样就能好些。
 关于App瘦身的方案:

消除无用的方法:
 以i快收为例,我发现有如下方法无用,很多时候当产品迭代越久,尤其是架构不是很合理的情况下,重构的时候对于删除是慎之又慎,因为谁也不知道这段代码会不会和某个文件耦合,这也是为什么好的架构它总是遵循对扩展开放,对修改关闭的原则。

fullsizeoutput_fa4

当然关于App瘦身有很多方面都是细节要处理,通过App 的构成去从每个部分分析就可以使得App瘦身成功。
 问了业内的一个做智能硬件的朋友,他给我的一些意见,确实很有参考意义。
 蓝牙数据传输:由于客户端所需要通讯的智能硬件设备中的CPU以及内存等资源没有手机终端这么丰富,再加上BLE传输速度也比较慢,所以通讯时使用应用层比较常见的json和xml格式显然不太现实。因此我们使用自定义的二进制协议进行数据的传输。协议中规定了包头、包尾、功能字、数据字段、控制字符以及扩展格式等内容。根据协议的内容并结合CoreBluetooth框架封装出了一个用于蓝牙连接以及数据打包、传输、解包以及完整性校验的库。如此就可以像发送http请求一样简单地发送命令到智能硬件。
 — — — — — From Marc Zhao

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.