iOS SDK开发流程
项目开展
1、框架搭建：
SDK库搭建，本地静态库搭建、远端Pod库搭建。
数据传输底层封装。
统一调用类，回调给外部使用接口、方法名、数据类型定义、数据处理。
2、业务分组：
账户信息、绑定。
设备管理、功能。
业务扩展。
3、提前准备事项
1）SDK的名称 ___________
萤石（EZOpenSDK）,涂鸦（ThingSmartSDK），阿里（IMSIotSmart）
2）SVN本地代码仓库文件地址创建。
3）托管账户（提供注册邮箱）
因为墙的缘故，考虑是否用github。目前参考的几家都是GIthub，Coding、GitHub、Gitee、Gitlab都是代码托管，规则基本相同。不影响pod库的创建。
4）对于企业用户选择GitHub还是GitLab
选择在GitHub还是GitLab上开发三方库取决于各种因素，包括个人偏好、项目需求和团队要求。
以下是一些比较关键的因素：
a、社区和流行度：
GitHub是全球最大的开源代码托管平台之一，拥有庞大的开发者社区。在GitHub上发布你的三方库可能会更容易引起关注和贡献。
GitLab也是一家受欢迎的平台，尤其在一些企业和组织中使用较多。它提供了完整的DevOps工具链，适用于一体化的开发和部署流程。
b、功能和集成：
GitLab提供了更广泛的集成，包括CI/CD、代码审查、容器注册表等，这使得它成为一种更全面的解决方案，特别是对于需要集成DevOps工具链的项目。
GitHub也提供了CI/CD工具，但GitLab的集成可能更为紧密。
c、私有仓库：
GitLab允许免费创建私有仓库，而GitHub通常需要订阅付费计划以获得相同的功能。如果你的项目需要私有存储库，GitLab可能更具吸引力。
d、地理位置：
GitHub在全球范围内都有快速的访问，但如果你的团队或用户主要在中国，GitLab可能因其在中国的镜像站点而更为受欢迎。
e、安全性和合规性：
如果你的项目需要更高级的安全性和合规性，GitLab可能更适合，因为它提供了更多关于安全性和合规性的功能。
f、自托管：
如果你更喜欢自托管你的代码仓库，GitLab可能是更好的选择，因为它提供了一个免费的自托管版本。
4、pod信息
s.name // 这是默认的，不用改s.version // 版本号，输入你准备的版本号，可以不用改
s.summary // 简介，最好写一个，不改后面会有警告
s.description // 详细说明，可写可不写。
s.homepage // 依赖库的介绍页的地址，随便放，没要求
s.license // 不用改
s.author // 作者信息
s.source // 远端依赖库的地址，下一步我们就会创建远端地址。不能写错
s.ios.deployment_target = '10.0' // 依赖库支持的最低iOS系统版本现在基本都是10.0了
s.source_files // 引用库的文件目录，不用改
s.resource_bundles // 依赖库如果需要icon的话，要打开
s.frameworks // 用到的系统框架
s.dependency //用到的第三方的依赖库，用到多个的话就写多个，OC一般问题不大，Swift问题会多一点，swift库支持的版本不稳定导致的。
一、SDK命名规范
sdk名称：XJHEngine
1、文件命名
framework： XJH...SDK
file：XJH...
2、方法命名
.h：XJH_开头；外部方法大写
.m：xjh_开头；内部函数使用小写
方法回调：XJH_resp开头
例：
开始播放
XJH_startPlay:(Camera *) dev
回调：XJH_respPlayState:
截图
XJH_screenShot
回调：XJH_respScreenShot：
3、其他命名
XJH_typeScope_Subject
XJH_业务类型+使用范围_内容描述
业务类型：
Account+Login、Register
Live+Connect、Ptz、Audio
Message+
Set+
错误代码 （推荐使用枚举）按范围区分枚举
枚举命名
例：枚举使用位运算，节省内存空间，提高运算
/// 直播中云台方向控制
typedef NS_OPTIONS(NSUInteger, XJH_LivePtzDirection) {
XJH_LivePtzDirection_UP = 0, // 0
XJH_LivePtzDirection_BOTTOM = 1 << 1, // 2
XJH_LivePtzDirection_LEFT = 1 << 2, // 4
XJH_LivePtzDirection_RIGHT = 1 << 3, // 8
XJH_LivePtzDirection_STOP = 1 << 4 // 16
};
日志打印
例：
NSLog(@"XJHLivePtzDirection-StarUP“);
NSLog(@"XJHLivePtzDirection-StopUP“);
二、业务划分
跟进自己的业务模块来
三、远端库制作
1、制作三方库步骤
1、大致步骤
制作一个支持CocoaPods依赖库共需要四个仓库： 远端仓库 本地仓库 远端索引库 本地索引库
其中本地仓库用来测试及调整源码，远端仓库用来保存本地仓库的所有文件，远端索引库用来支持CocoaPods安装，本地索引库用来和远端索引库进行绑定，并把本地仓库的.podspec文件推送到远端索引库。
源码的每次变动都必须要打tag标签，并且推送tag的时候必须和.podspec文件中的version一致。
只要远端仓库和远端索引库存在，可以随时随地维护自己的依赖库。
2、步骤总结：
1、创建本地代码库：pod lib create 仓库名
2、创建远端代码库，拿到远端代码库git地址，回到本地代码库目录下打开.podspec文件替换掉source地址和homepage地址，修改summary内容
3、cd到Example目录下，更新本地代码库：pod update --no-repo-update（此步骤可跳过）
4、cd到本地代码库目录下，验证：pod lib lint --allow-warnings
5、将本地代码库推送到远端代码库并打标签（tag标签版本号和.podspec中版本号一致）
git remote add origin 远端代码库git地址
git add.git commit-m 'commit'
git pull origin master（新仓库推送代码，此步骤可跳过）
git push--force 远端代码库git地址（强制推送合并代码）
git tag0.0.1git push origin0.0.1
6、创建远端索引库
7、重新打开终端或cd ~，创建本地索引库：pod repo add 本地索引库名 远端索引库git地址
8、验证本地索引库：pod repo（或直接查看本地索引库是否创建成功：～/.cocoapods/repos）
9、cd到本地代码库目录，将本地代码库的.podspec文件和索引库邦的：pod repo push 索引库名 本地代码库.podspec --allow-warnings
10、在Demo项目中，pod引入组件库
指定分支：pod'代码库名', :git => '代码库git地址', :branch => 'master'
指定commit：pod'代码库名', :git => '代码库git地址', :commit => '******'
可将代码库本地引入，修改代码库中源码：clone代码库到Demo项目同级目录，podfile文件改为：pod'代码库名', :path => '../代码库名'
11、创建远端代码库和索引库时，保证仓库中有文件存在，避免push不成功
12、查看你的注册信息 pod trunk me
13、注册cocoapods账号： pod trunk register 'git邮箱' 'git用户名'
2、动态库的制作和静态库的区别
动态库（Dynamic Library）和静态库（Static Library）是两种库的不同形式，它们在制作、使用和链接方式上有一些区别。以下是动态库和静态库之间的一些主要区别：
1. 库的定义：
动态库： 动态库是在运行时加载到内存的库。它的代码在应用程序运行时被动态地链接到应用程序中。
静态库： 静态库是在编译时链接到应用程序的库。它的代码在编译时就被复制并链接到应用程序的可执行文件中。
2. 文件格式：
动态库： 在大多数操作系统中，动态库通常以共享对象文件（Shared Object，通常是.so或.dylib）的形式存在。
静态库： 静态库以归档文件（Archive，通常是.a）的形式存在。
3. 加载时机：
动态库： 动态库在应用程序运行时动态加载到内存。加载发生在应用程序启动时，或者在需要使用动态库的时候。
静态库： 静态库在编译时被链接到应用程序，因此它的代码在应用程序启动时已经存在。
4. 文件体积：
动态库： 动态库通常比静态库小，因为它们可以在多个应用程序之间共享。
静态库： 静态库会增加应用程序的大小，因为它们的代码被复制到每个应用程序中。
5. 运行时更新：
动态库： 动态库可以在运行时更新，应用程序可以加载新的库版本而无需重新编译。
静态库： 静态库的更新需要重新编译应用程序，因为库的代码被静态地复制到应用程序中。
6. 共享性：
动态库： 动态库可以被多个应用程序共享，减少了内存占用。
静态库： 静态库的每个应用程序都有其自己的库副本，可能导致内存占用增加。
7. 链接方式：
动态库： 动态库在链接时（编译或运行时）不会与应用程序的代码进行完全的静态链接。相反，只有在运行时才进行动态链接。
静态库： 静态库在链接时会完全地被复制并链接到应用程序中，生成一个完整的可执行文件。
8. 运行环境要求：
动态库： 动态库需要在运行环境中找到，否则应用程序将无法启动或执行。
静态库： 静态库的代码被完全复制到应用程序中，因此不需要在运行时查找外部库。
9. 加载速度：
动态库： 动态库的加载发生在运行时，可能会引入一些额外的启动时间。
静态库： 静态库的加载是在编译时完成的，不会增加应用程序的启动时间。
3、制作二进制框架的库通常包括以下步骤：
创建动态库或静态库：
在 Xcode 中，创建一个新的 Framework 项目。
在项目中添加源代码、资源文件以及其他所需的文件。
选择库的类型：
动态库（Dynamic Library）：拓展名为 .framework，在运行时加载。
静态库（Static Library）：拓展名为 .a，在编译时链接到主应用程序。
配置构建设置：
配置构建设置以生成适当类型的库（动态库或静态库）。
确保设置适当的目标架构和编译选项。
构建库：
在 Xcode 中，选择对应的 Scheme，并使用 "Build" 命令构建你的库。
打包库：
将生成的库文件（.framework 或 .a）放入适当的文件夹中。
如果是动态库，确保它包含所需的头文件和资源。
创建 Podspec 文件：
在项目目录下创建一个名为 YourLibrary.podspec 的文件，定义你的库的元数据，如名称、版本、依赖关系等。
rubyCopy code
Pod::Spec.new do |s| s.name ='YourLibrary's.version ='1.0.0's.summary ='A brief description of YourLibrary.'# ... 其他元数据 ...s.source = {:git => 'https://github.com/your_username/YourLibrary.git', :tag=> s.version.to_s } s.source_files ='YourLibrary/**/*.h's.vendored_frameworks ='YourLibrary/YourLibrary.framework'end
注意 vendored_frameworks 字段的设置，用于指定库文件的位置。
验证 Podspec 文件：
在终端中运行 pod spec lint YourLibrary.podspec 验证 Podspec 文件。
发布到仓库：
将你的库的源代码和 Podspec 文件推送到远程版本控制系统，如 GitHub。
注册并发布到 CocoaPods 仓库，可以使用 pod trunk push YourLibrary.podspec。
其他开发者就可以通过 CocoaPods 引用你的库，使用 pod 'YourLibrary' 来集成你的二进制库到他们的项目中。
请注意，制作二进制库需要谨慎，因为一些开源许可证可能要求你公开源代码。确保遵守所有相关法规和许可证，并在 Podspec 文件中适当地指明许可证信息。
4、选择使用静态库还是动态库
取决于你的项目需求、应用场景以及个人或团队的偏好。每种类型都有其优势和劣势，以下是一些考虑因素：
静态库（Static Library）：
优势：
易于集成： 静态库直接被编译进应用程序中，使得集成过程相对简单。
依赖管理： 所有的依赖都包含在库中，减少了在应用程序中引入不同版本库的复杂性。
稳定性： 库的版本一旦发布，它的接口和行为就不会轻易变化，提供了相对的稳定性。
适用于嵌入式系统： 静态库适用于一些嵌入式或移动设备，因为它们不需要在运行时加载。
劣势：
体积增大： 每个应用程序都包含库的完整拷贝，可能导致应用程序体积较大。
更新困难： 如果库的更新，应用程序需要重新编译以使用新版本。
动态库（Dynamic Library）：
优势：
共享： 动态库可以在运行时共享，多个应用程序可以共用同一份库，减少了内存占用。
更新简便： 库的更新不需要重新编译应用程序，只需替换库文件。
灵活性： 库可以在运行时加载和卸载，提供了更大的灵活性。
劣势：
依赖管理： 应用程序需要确保系统上存在所需的动态库版本，可能会导致一些依赖问题。
版本兼容性： 动态库的版本兼容性需要更加小心，因为应用程序和库可能在不同的时间和地点被编译。
部署复杂性： 一些平台或商店可能对动态库的部署有一些限制。
综合考虑：
如果你希望简化集成过程、减小应用程序体积，并且对库的稳定性有较高的要求，可以选择使用静态库。
如果你追求灵活性、共享库、并希望简化库的更新过程，可以选择使用动态库。
在某些情况下，也可以选择混合使用静态库和动态库，根据具体情况决定。
5、处理项目中多个库应用同一个库的不同版本（首选动态库）
需要仔细规划和协调，以确保不同版本的库能够和各个库应用协同工作。以下是一些建议：
依赖管理工具的版本约束：
使用现代的依赖管理工具，如 CocoaPods、Carthage 或 npm，它们都支持版本约束。在每个库应用的依赖配置中，可以指定对于共享库的版本范围，以确保不同的库应用使用的版本不会发生冲突。
例如，对于 CocoaPods，可以使用如下方式指定版本范围：
rubyCopy code
pod 'SharedLibrary', '~> 1.0'
这表示使用 1.x.x 系列的版本。
使用不同的命名空间或模块：
如果语言支持命名空间或模块系统，将不同版本的库放置在不同的命名空间或模块中，以防止命名冲突。
静态链接或动态库的选择：
静态库和动态库对于版本管理有不同的影响。静态库将依赖项嵌入到应用程序中，可能导致冲突，而动态库则允许共享库的不同版本。考虑选择适合你项目需求的方式。
通过编译选项区分版本：
在编译时通过预处理宏或其他编译选项来区分不同版本的库。这样，可以在不同版本的库中使用条件编译，以适应不同的应用场景。
协调升级策略：
如果需要升级共享库的版本，确保所有使用这个库的库应用都经过了测试，并且能够适应新版本的变化。在升级时，可以通过逐步迁移的方式，先更新一个库应用，验证稳定性后再逐步更新其他应用。
定期同步：
定期同步库应用的版本，以确保它们使用的共享库版本保持一致。可以通过定期的代码审查、版本控制工具的合并等方式来实现。
