因为公司要提供sdk对外用。 第三方比较多二十来个 要求将第三方也打包进framework
1：为什么选择cocopods的方式来打包静态库？
首先因为当前项目中的第三方是用cocopods来管理的， 这时候有两个问题 1：打静态库能否将cocopods中的第三方打进去 2：如果能打进去会和用户本身当前引入的第三方冲突吗？
以Masonry举例，不知道对方是否集成了Masonry，我们提供的sdk是抽取的以前的代码 包含几个页面是Masonry布局 。可能会出现 冲突
原工程是用cocopods来管理 担心两点1：cocopods中的第三方会被打入framework吗 2：如果能打入framework 会和用户引入的重复吗？ 基于这个选择cocopods.png
参考文章：http://www.cnblogs.com/brycezhang/p/4117180.html
选型cocopods来打包framework
打framework过程 和私仓流程几乎一样
走完私仓流程后
打包
命令很简单，执行
pod package JingLib.podspec --force
--force是指强制覆盖。
这是我打的流程和踩得坑
https://www.jianshu.com/p/93c4b5eb3fb3
打出来的framework.png
网上大部分流程到这就没了 大部分是私仓流程 打包的也到这就没了
用的时候运行闪退 开始怀疑人生。。。 开始怀疑是不是没把Masonry打进去
一不小心又踩了个坑
如图：
不加-ObjC闪退.png
1：这个图上半部分是framework内部的ClickTextView追加了个addTestView方法用来测试能否正常运行 能运行说明framework内部有Masonry
添加测试方法.png
加不加Masonry包大小变化.png
解决静态库.png
-ObjC.png
加objc后正常了
打出来的framework.png
验证支持的架构.png
使用framework的demo地址：https://gitee.com/heyuefengyun/JingLibUseTestDemo
