此方案经过实际测试，包含免费版和网站版两种合并接入方法以及补丁调试和注意事项。
环境配置
1.DownLoad SDK，并将sdk文件加入到项目根目录下。需要确认SDK文件名为sotsdk，因为后面部分的编译都是基于引用的路径正确
2.终端执行sh /Applications/SwiftMessages/Demo/sotsdk/compile-script/install.sh，安装sot的编译工具链
3.打开SDK目录，检查project-script/sotconfig.sh文件，设置EnableSot=1。
[EnableSot=0] 表示不启用热更模式
[EnableSot=1] 表示开启热更，同时当=1时，会记录代码并生成补丁，使我们可以调试和下发补丁
4.增加项目增加configuration，为SOT指定编译模式；需要创建sotDebug、sotRelease两个环境
5.增加Build Settings相关配置
Other Linker Flags
SotDebug添加
-sotmodule
$(PRODUCT_NAME)
sotsdk/libs/libsot_free.a
-sotsaved
$(SRCROOT)/sotsaved/$(CONFIGURATION)/$(CURRENT_ARCH)
-sotconfig
$(SRCROOT)/sotsdk/project-script/sotconfig.sh
复制代码SotRelease添加
-sotmodule
$(PRODUCT_NAME)
sotsdk/libs/libsot_web.a
-sotsaved
$(SRCROOT)/sotsaved/$(CONFIGURATION)/$(CURRENT_ARCH)
-sotconfig
$(SRCROOT)/sotsdk/project-script/sotconfig.sh
复制代码以上有两个静态库文件，libsot_free.a表示本地，libsot_web.a表示网站下发
Other C Flags、Other Swift Flags
选择SotDebug和SotRelease添加
-sotmodule
$(PRODUCT_NAME)
-sotconfig
$(SRCROOT)/sotsdk/project-script/sotconfig.sh
复制代码Preprocessor Macros
SotDebug添加USE_SOT=1、DEBUG=1
SotRelease添加USE_SOT=1
复制代码Enable Bitcode
SotDebug和SotRelease为No
复制代码Build Active Architecture Only=YES
6.新增building脚本文件
代码
if [[ "$CONFIGURATION" == "SotDebug" || "$CONFIGURATION" == "SotRelease" ]];then
sh "$SOURCE_ROOT/sotsdk/project-script/sot_package.sh" "$SOURCE_ROOT/sotsdk/project-script/sotconfig.sh" "$SOURCE_ROOT/sotsaved/$CONFIGURATION" Sot_demo
fi
复制代码7.增加基本库libz.tbd和libc++.tbd
8.找到swift-call-objc/callsot，copy并拖入到根目录下。同时，在头文件import 引用 SotWebService.h
9.Demo-bridging-Header.h中加入#import "callsot.h"
10.callsot.m中替换项目使用的version_key，并设置is_dev（是否需要开启调试模式）
热更注入
热更预编译
由于该热更的实现方式是基于代码文件间的比较，区分差异并生成补丁文件，本地编译或远程下发，那么在进行热更的第一步就是确定代码，意思就是对具备热更能力，且需要用到热更的代码做一个缓存
1.检查sotconfig.sh文件配置，确保EnableSot=1以及GenerateSotShip=0
2.切换SotDebug - clean - building
3.切换SotRelease - clean - building
若两次编译通过，则表示当且环境下的代码已具备热更能力，经过上一步操作,会保留原有的代码到根目录sotsaved文件下，说明代码缓存已成功
生成补丁文件
对比两次编译的结果，自动化生成一个完整可用的补丁
1.修改sotconfig.sh文件配置GenerateSotShip=1
2.更改代码上的内容，调试运行
3.通过run script自动化生成补丁
4.切换SotDebug/SotRelease - clean - building
SotRelease会生成一份拷贝的.sot文件附带上CPU架构,放入.app项目的bundle包里
加载补丁
运行应用获得补丁，执行动态更改
当GenerateSotShip=1时，补丁文件会放置于sotsaved下，run project项目，打印更新log结果：成功或失败。如果是web加载，需要创建应用 - 选择模式。也就是在Xcode导航栏里右键选择Products下的Demo.app，找到包内容中的sotship_arm64.sot文件上传，同时选择模式，默认是未开启
热更调试
好的，现在来梳理一下流程。一套完整的开发流程是：开启热更能力 - 打包ipa - 更新代码和调试 - 生成补丁 - 下发补丁
第一步，使项目具备热更能力。因该热更方案是生成差异补丁，差异从何而来，首先要有旧代码，其次要有更改后的新代码。那第一步就是生成旧代码文件，分别在SotDebug和SotRelease两个环境下编译，能够保证在这两个环境下是一套代码，后面GenerateSotShip=1时，编译不会出问题。
第二步，代码打包，需要注意的是Archive才是打包，且需要在SotRelease环境下打包
第三步，更新代码及调试。设置GenerateSotShip=1，可以切换到Debug环境下，修改代码然后运行调试，等看到改动有效果后，再切换回sot环境。注意：只有在系统环境下，修改代码和编译才有代码提示，sot环境没提示；其次，这里从debug切换回sot环境不会影响原有部署
注意事项
关于调试。免费版调试信息可以在build中查看，包括最后补丁下发的成功失败结果也可以在log打印中看到；而网站版的调试信息可以在控制台定位信息查到结果。
关于检验热更。在免费版中，当GenerateSotShip=1时，run代码的改变才有效果，并且每次改动后都需要clean一下，才能看到最新一次的改动效果。另外，前面也说了run script脚本很重要，它代表了本地热更编辑的大部分操作，如果我们想知道是因为补丁产生的效果，还是因为代码产生的效果，可以将run script删除，删除以后无论怎么改动代码，都不会有效果。
关于热更能力。在免费版中，当改变了某些代码后，运行代码产生了崩溃，说明 你使用了某个成员变量或系统变量，这个这个变量在此前并没有被创建或者使用过，也就是文档中说的，新加的代码能力不可能超越已上架App的能力 - 不能无中生有，那么这个补丁在网站版中下发，并不会产生崩溃，但也不会有任何改变效果，具体排查就需要查看控制台中的打印数据。
关于调用时机。只有在SOT虚拟机初始化以后，也就是sync接口方法输出log以后，才开始载入热更补丁，也就是我们代码调用一定要放到它初始化的后面，在发布前需要测试。如果调用时机太早，本地测试的结果可能和网站下发的结果有些出入，原因是网站下发是异步接口调用，最后走到网站同步，中间会有延迟；而免费版走的是本地sot，不用担心这个问题。
另外，sotsaved文件是可以不用删除的，如果不小心删除了这个文件，需要重新将GenerateSotShip改为0并编译，使代码重新具有热更能力。目前我测试得到的结果，在class中，是可以新增@objc的，对于函数中的代码可以修改，但不可新增，成员变量的操作要基于此前有，不可增加文件，其它的方面以后我还会继续测试。虽然SDK的集成是一次性的，可能以后很难再集成第二次，更重要的是把功能的流程总结梳理清楚，这些才是和我们日常开发息息相关的。关于开发和发布的流程，可根据公司的业务分工自己制定一个，也可以参考我上面的开发流程，发布流程可以先本地测试，然后发线上模式：调试-灰度-全局，仅供交流参考。