在「 Swift接入例子 」中介绍了Swift项目如何接入SOT。但是要求SDK解压到特定目录中，编译配置的路径也是绝对路径，不适合多人协作合开。文本介绍适合多人开发协作的接入方法。

还是以开源的「 SwiftMessages 」Demo为例，该工程全部用Swift语言开发。这里把修改好的版本上传到了git上，分支为 「 sotcollaboration 」，SotDebug接入免费版，SotRelease接入网站版，读者只需要进行下面的 Step1.配置编译环境 就可以直接用该分支测试。

现在开始从头讲解，git clone原本的工程后(我的路径为/Applications/SwiftMessages)，命令行cd /Applications/SwiftMessages进入根目录，使用版本切换命令：git checkout 1e49de7b3780b699（因本文档制作于21年10月21号，以当日版本为准）。首先进入Demo目录，打开Demo.xcodeproj工程，scheme默认就已经选中了Demo：

我使用的是Xcode12.4，可以直接编译成功，启动APP能看到画面（模拟器）：

点击最上面的MESSAGE VIEW控件，会弹出一个错误提示窗口，今天我们就来用SOT热更的方式修改错误提示的文案：

Step1: 配置编译环境

「 下载SOT的SDK 」，解压到项目目录下 /Applications/SwiftMessages/Demo/sotsdk

在terminal运行命令：sh /Applications/SwiftMessages/Demo/sotsdk/compile-script/install.sh安装SOT编译工具链，需要输入密码。

用文本编辑器打开 /Applications/SwiftMessages/Demo/sotsdk/project-script/sotconfig.sh，修改EnableSot=1:新版SDK已经不会再使用sotconfig.sh里的sdkdir，sotbuilder和objbuilder路径了，所以不用修改这些配置了，删掉也可以。

Step2: 增加Configuration

增加两个Configuration，只有切换到这两个Configuration才使用SOT编译模式，平时还是用原来的Configuration做开发，步骤如下：

1. 选中Demo Project，然后选择Info面板，点击Configurations的下面加号，复制Debug的编译配置，并且命名为SotDebug，用来接入免费版的SOT。再选择复制Release编译配置，命名为SotRelease，用来配置网站版的SOT，注意名字都不要留有空格：加完就是：


2. 给SwiftMessages也加上这两个Configuration：

注意：读者应用到自己项目中时，需要把所有的工程都加上这两个Configuration，否则编译会报找不到文件等等的错误。所以加完这两个Configuration的之后，就马上切换到它们去Build和Run一下，看是否有编译错误，如果没有再进行下面的操作，如果有，请检查是否漏了一些工程没有添加上。

Step3: 修改编译选项

添加热更需要的编译选项，添加SOT虚拟机静态库等，步骤如下：

1. 
   

   选中Demo工程，然后选择Demo这个Target，再选择Build Settings:

   
   


2. 
   

   在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。

   
   

   每个选项的意义如下：

   
   
   
   
   • -sotmodule是module的名字，可以直接用$(PRODUCT_NAME)，也可以自定义名字，名字不要有空格
   
   
   • -sotsaved是编译中间产物保存的目录，补丁自动化生成需要对比前后编译的产物来生成补丁
   
   
   • -sotconfig指定了项目sotconfig.sh的路径，该脚本控制sot编译器的工作
   
   
   • sotsdk/libs/libsot_free.a是SOT虚拟机静态库的路径，链接的是免费版的虚拟机
   
   
   • sotsdk/libs/libsot_web.a是SOT虚拟机静态库的路径，链接的是网站版的虚拟机
   
   
   
   


3. 
   

   在Other C Flags以及Other Swift Flags的SotDebug和SotRelease下添加-sotmodule $(PRODUCT_NAME) -sotconfig $(SRCROOT)/sotsdk/project-script/sotconfig.sh，意义跟上一步是一样的，需要保持一致。经过上面两步，相关的编译配置结果如下图：

   
   


4. 
   

   在Preprocessor Macros添加USE_SOT=1，后面用来控制是否编译调用SDK的代码

   
   


5. 
   

   因为SOT SDK库文件编译时不带Bitcode，所以也需要把Enable Bitcode设为No。

   
   


6. 
   

   为了模拟器架构时不编译arm64，给SotRelease增加如下配置或者把Build Active Architecture Only设为Yes

   
   

Step4: 增加拷贝补丁脚本

SDK里提供了一个便利脚本，路径在sdk目录的project-script/sot_package.sh，它会把生成的补丁拷贝到Bundle文件夹下，在每次项目编译成功时调用该脚本，添加步骤如下：

脚本内容为：

    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" Demo

    fi

    

复制代码

把Based on dependency analysis的勾去掉。

Step5: 链接C++库

SOT需要压缩库和c++标准库的支持，还是在这个页面下，打开Link Binary With Libraries页

点击加号，分别加入这两，libz.tbd和libc++.tbd

Step6: 调用SDK API

需要用Swift代码调用OC代码，已经提供了一个样例代码在SDK的swift-call-objc目录中，先把callsot.h和callsot.m拷贝到Demo目录下

再添加到Demo工程中。点击Xcode软件的File按钮，找到Demo目录下的callsot.h和callsot.m，接着点击Add Files to "Demo"，如下图所示：

点击Add按钮，添加后会弹出询问：是否创建桥接文件。点击按钮Create Bridging Header：

然后可以看到项目中多了3个文件，分别是callsot.h，callsot.m和Demo-Bridging-Header.h：

打开Demo-Bridging-Header.h，加入一行代码#import "callsot.h"

打开callsot.m，修改代码为

#import <Foundation/Foundation.h>

#import "callsot.h"

#import "../sotsdk/libs/SotWebService.h"

@implementation CallSot:NSObject

-(void) InitSot

{

#ifdef USE_SOT

#ifdef DEBUG

    [SotWebService ApplyBundleShip];

#else

    

    [SotWebService Sync:@"1234567" is_dev:false cb:^(SotDownloadScriptStatus status)

  {

    if(status == SotScriptStatusSuccess)

    {

      NSLog(@"SotScriptStatusSuccess");

    }

    else

    {

      NSLog(@"SotScriptStatusFailure");

    }

  }];

    

#endif

#endif

}

@end

复制代码

注意SotWebService.h的头文件路径不再依赖于绝对路径，并且代码里用了#ifdef USE_SOT宏来隔开API调用代码，不影响正常编译：

打开AppDelegate.swift，加入两行代码let sot = CallSot()和sot.initSot()

注意：读者在应用到自己项目中时，以上这些配置的路径不要生搬硬套。例如找不到SotWebService.h文件，找不到sotconfig.sh文件等等，读者自己要清楚SDK的目录与自己工程目录的相对关系，灵活调整这些配置的路径。

测试热更-免费版

按上面配置完之后，先测试免费版热更功能

Step1: 热更注入

1. 将Build Configuration切换到SotDebug


2. 确保sotconfig.sh的配置是，EnableSot=1以及GenerateSotShip=0，先Clean Build Folder一下，然后再Build：

然后看编译日志的输出，Link日志可以看到run sot link等输出，会告诉你每个文件里哪些函数可以被热更等信息：

项目编译成功了，该APP可以正常启动。同时它具备了热更能力，可以加载补丁改变程序的代码逻辑，下面介绍如何生成补丁来测试它。

Step2: 生成补丁

上一步进行了热更注入的编译，当时的代码保存到了Demo/sotsaved这个文件夹下，用来和新代码比较生成补丁。生成补丁步骤如下：

1. 首先启动SOT生成补丁模式，修改sotconfig.sh为EnableSot=1，GenerateSotShip=1


2. 


3. 接下来直接在Xcode里修改源代码，把ViewController.swift文件的”Something is horribly wrong!“改成了”SOT is great“，修改前：修改后：


4. Swift项目生成补丁，每次都需要先Clean项目，再Build项目。然后查看编译日志输出，可以看到生成了补丁并且被脚本拷贝到了Bundle目录下，可以展开Link Demo（x86_64)的编译日志：点击展开后，可看到生成补丁的Link日志，日志里显示了函数demoBasics被修改了：


5. 生成出来的补丁原始文件保存到了Demo/sotsaved/SotDebug/x86_64/ship/ship.sot，还记得之前加了一个script到Build Phase中吗？它会每次编译结束时，会把这个补丁拷贝到了Bundle目录中，并且添加CPU架构到文件名中。可以在Bundle中看到这个补丁，至此完毕。

Step3: 加载补丁

启动APP，API会判断Bundle内是否有补丁，有则加载，加载成功的日志大概如下，提示有一个模块加载了热更补丁：之后点击最上面的MESSAGE VIEW控件，发现弹出的文案变成了SOT is great：

如果去Xcode断点调试demoBasics，会发现无法断住了，因为实际执行补丁代码的是SOT虚拟机。

顺便提一嘴，GenerateSotShip=1时，编译APP用的是保存在sotsaved目录下的代码，所以无论怎么修改Xcode里的代码，如果没有把补丁拷贝到Bundle目录里，那么APP都是最后一次GenerateSotShip=0热更注入时的样子。

如果怀疑，可以把拷贝补丁的Script脚本从Build Phases删除，可以发现GenerateSotShip=1怎么改代码都不会生效了。

注意：如果读者接入自己的一个很简单项目进行测试，例如设置某个控件的颜色，热更前是红色，修改后是绿色，发现无法生效。那是因为这样的项目太过于简单，寥寥几行代码。热更前没有访问过绿色的这个全局变量，在热更时也无法访问到了，SOT只能利用原有的能力，无法无中生有。所以不要这样测试，更具体的原因在「 热更能力-语言特性 」说明。通常完整的项目代码比较多，所以就不会有这样的缺陷。

接入网站版

按上面的教程，已经对APP实现了免费版和网站版的接入。它俩区别只是链接的库不一样，具体就是Other Linker Flags根据Configuration区别配置，SotRelease下接入了网站版。但除了APP接入了网站版SDK，还需要用配合网站来管理补丁的发布。

Step1: 注册网站

1. 第一步当然是注册网站，成为会员。点击跳转注册页面，免费注册，注册需要验证邮箱，然后登录。


2. 从导航栏进入我的APP：


3. 点击创建APP，弹出弹窗填写APP的名字：


4. 进入APP页面，点击右上角的创建新版本按钮，会弹出弹窗，需要选择网站版，SDK版本选择1.0，目前只有1.0版本，然后输入版本号，版本号可以是随意字符串，方便区分就行。


5. 创建版本成功后，点击版本，进入版本页面，左上角是唯一标识该版本的VersionKey，后面API接口需要这个Key。

Step2: 修改VersionKey

打开callsot.m，修改网站版的Sync接口，第一个参数填入你在网站创建的版本的VersionKey。至此，网站版热更就算接入完成了。

Step3: 测试网站热更

• 
  

  网站版生成补丁的步骤免费版是一样的，需要经历热更注入->出包->修改代码->生成补丁，这里不再赘述。

  
  

  唯一不同的是，生成出来的补丁要上传到网站上，然后才能通过网络同步到手机上实现热更。通过之前的免费版教程，知道生成的补丁会被拷贝到Bundle目录下，所以去Bundle目录里就能找它，在Xcode导航栏里右键选择Products下的Demo.app，选择Show in Finder：

  
  


• 
  

  右键Demo文件，选择Show Package Contents:

  
  


• 
  

  找到目录下的sotship_arm64.sot，这里用手机测试，cpu是arm64类型，补丁名字带有cpu后缀，这就是补丁了：

  
  


• 
  

  回到网站的版本页面，点击右侧上传补丁按钮：

  
  


• 
  

  弹出页面里，真机的架构一般选择arm64，除非是老的armv7的机器，并把补丁文件拖到框里，点击上传：

  
  


• 
  

  上传成功并且补丁文件无异常（补丁最大支持5MB)，则会添加成功，补丁默认是停用状态，需要点击编辑来启用它：

  
  


• 
  

  这里选择全量启用，点击下面的提交按钮，然后补丁就会成功启用了：

  
  


• 
  

  上一步更新了补丁状态，通常很快生效，但CDN有时也需要1到2分钟才能生效。之后手机打开APP，如果成功下载补丁和加载的话，就能看到下面的日志：这里输出的md5也跟网站上的补丁md5是一致的。

  
  


• 
  

  打开APP后，点击最上面的MESSAGE VIEW控件，发现弹出的文案变成了SOT is great：

  
  

注意：使用网站版，需要考虑到网络传输延迟的问题，只有看到了下载补丁和成功加载补丁的日志之后，调用的函数才会使用热修后的函数。例如有的开发问我，首屏代码怎么无法热更生效？那是因为首屏代码调用的时机太早了，SOT去网站上拿补丁，是异步的，不会一直卡住等着，而且在异步线程中等待结果。在补丁没传输回来之前，首屏的代码都已经调用结束了，这种情况下当然调用的还是老的代码了。而免费版没有这个问题，因为免费版是同步加载补丁的，直接去Bundle里加载，不是异步的。

构建热更注入版本和构建补丁必须是同一台机器，同一个Xcode版本。例如上架前APP用Xcode12进行了热更注入，而之后用Xcode13来构建补丁，那么将得到无效甚至错误的补丁。请使用同一个版本Xcode。

Step4: 几点提示

• 网站版跟免费版主要接入流程差不多，可以用免费版测试，功能通过测试之后再接入网站版。


• 网站版需要有网络的情况下才能生效，如果手机没有网，即使之前已经下载过了补丁，也无法加载。


• 网站版费用很低，日活10万的APP，一个月几百块就够了。


• 网站版补丁和配置都放在CDN上，支持高并发。

非主Target接入热更

上面的教程都是针对主Target，也就是Demo。这个工程还有一个名为SwiftMessages的Framework，也可以热更，下面介绍如何配置。

可以看到SwiftMessages的Mach-O Type是Dynamic Library，通过下图方式查看得到：

这种类型的话，配置相对麻烦些。还有一种是Static Library，配置起来会简单得多。但本例改成Static Library启动会崩溃，所以按Dynamic Library的方式来介绍。

Step1: 修改编译选项

1. 选中SwiftMessages.xcodeproject工程，然后选择SwiftMessages这个Target，再选择Build Settings:


2. 在Other Linker Flags的SotDebug中添加-sotmodule $(PRODUCT_NAME) $(SRCROOT)/Demo/sotsdk/libs/libsot_free.a -sotsaved $(SRCROOT)/Demo/sotsaved/$(CONFIGURATION)/$(CURRENT_ARCH) -sotconfig $(SRCROOT)/Demo/sotsdk/project-script/sotconfig.sh


3. 在Other Linker Flags的SotRelease中添加-sotmodule $(PRODUCT_NAME) $(SRCROOT)/Demo/sotsdk/libs/libsot_web.a -sotsaved $(SRCROOT)/Demo/sotsaved/$(CONFIGURATION)/$(CURRENT_ARCH) -sotconfig $(SRCROOT)/Demo/sotsdk/project-script/sotconfig.sh


4. 在Other C Flags以及Other Swift Flags的SotDebug和SotRelease中，添加-sotmodule $(PRODUCT_NAME) -sotconfig $(SRCROOT)/Demo/sotsdk/project-script/sotconfig.sh，意义跟上一步是一样的，需要保持一致。经过上面两步，相关的编译配置结果如下图：这一步跟Demo的配置差不多，区别在于有些路径写法不一样，以达到复用Demo配置的目的，读者可以仔细比较一下。


5. 在Preprocessor Macros添加USE_SOT=1，后面用来控制是否编译调用SDK的代码


6. 需要把Target的Enable Bitcode设为No。


7. 为了模拟器架构时不编译arm64，给SotRelease增加如下配置

Step2: 链接C++库

点击Build Phases页面，打开Link Binary With Libraries页，点击加号，分别加入这两，libz.tbd和libc++.tbd

Step3: 调用SDK API

因为SwiftMessages是动态库，所以需要在它的编译文件中调用SDK的热更初始化接口。跟Demo一样，添加OC文件。先从Demo文件夹中复制callsot.h和callsot.m文件到SwiftMessages文件夹中

选中SwiftMessages工程，点击Xcode软件的File按钮，接着点击Add Files to "SwiftMessages.xcodeproject"，如下图所示：

选择到SwiftMessages目录，同时选中callsot.h和callsot.m两个文件，勾选下面的Copy items if needed，勾选Add to targets：中的SwiftMessages target，如下图所示：

点击Add按钮，然后可以看到项目中多了2个文件，分别是callsot.h，callsot.m，修改CallSot类名为CallSotMessage：

去到右边面板，把文件属性改成public：

打开callsot.m，做相应路径和类名的修改：

打开Demo-Bridging-Header.h，加入一行代码#import "SwiftMessages/callsot.h"：

打开AppDelegate.swift，加入两行代码let sot1 = CallSotMessage()和sot1.initSot()

因为这时候有两个Target都可以生成补丁，Demo和SwiftMessages，需要修改拷贝补丁的脚本，加入SwiftMessages：

Step4: 测试热更

1. 
   

   测试热更的流程跟之前是一模一样的，只是输出的日志可能会有所区别，我们过一遍。EnableSot=1和GenerateSotShip=0热更注入，先Clean后Build，如果去看编译日志的Link SwiftMessages，也可以看到热更注入的信息。

   
   


2. 
   

   然后修改MessageView.swift的代码，错误提示的文案会加上“SOT is great”：

   
   


3. 
   

   GenerateSotShip=1开启生成补丁模式，Clean后Build，查看Link SwiftMessages日志，有提示该函数被热更：

   
   


4. 
   

   接下来可以看到补丁拷贝脚本日志输出的信息，这里它检测到有两个Target都生成了补丁文件，会把它们两个合成一个，拷贝到Bundle目录下：

   
   


5. 
   

   启动APP，会看到两条加载补丁的日志，因为我们Demo Target和SwiftMessages Target都调用了API接口：

   
   


6. 
   

   点击MESSAGE VIEW控件，可以看到错误提示文案后面多了“SOT is great”，热更成功：

   
   

   网站版的测试跟以前也是一样的，这里不再重复了。

   
   

Step5: 几点提示

1. Dynamic Library的热更编译改法其实跟主Target，也就是Mach-O Type为Executable的改法是一样，只是这里复用了主Target的一些配置，例如sotsaved目录和sotconfig.sh的路径。增加再多的Target也可以按同样的改法修改它们。


2. 补丁拷贝脚本只需要主Target有就行了，把要热更的sotmodule对应的名字加上即可，条件就是sotsaved目录必须是同一个。


3. 如果需要接入网站版，那么每个需要热更的Target都需要调用API跟网站同步，它们的消耗是独立计费的。

Static Library的改法

上面说到Dynamic Library的改法步骤比较多，而且有诸多缺点，如果能把Framework的Mach-O Type改成Static Library是最好的，会少很多步骤和配置。由于本例无法修改，这里简单说一下步骤：

1. 在Other Libraian Flags添加-sotmodule $(PRODUCT_NAME) -sotsaved $(SRCROOT)/Demo/sotsaved/$(CONFIGURATION)/$(CURRENT_ARCH) -sotconfig $(SRCROOT)/Demo/sotsdk/project-script/sotconfig.sh ，注意是Other Libraian Flags而不是Other Linker Flags了。还有这里比Dynamic Library加的配置少一个，即没有链接SDK的.a库文件了。


2. 在Other C Flags以及Other Swift Flags添加-sotmodule $(PRODUCT_NAME) -sotconfig $(SRCROOT)/Demo/sotsdk/project-script/sotconfig.sh，这步跟之前是一模一样的。


3. 需要把Target的Enable Bitcode设为No。


4. 修改拷贝补丁的脚本，加入该Target的名字，例如本例加入SwiftMessages，跟之前也是一模一样的：

然后就配置完了，如果是使用网站版，同步一次消耗，就能实现所有Target的热更，修改简单，对包体影响最小。

总结

本文完整介绍Swift项目如何接入免费版和网站版。

本文的方式是把SDK拷贝到了工程文件夹里，让它可以跟随项目一起进行版本管理，路径也配置成了相对路径，更加灵活。

通过新增Configuration的方式，也做到了不影响原来的开发，Debug和Release相当于没有接入SOT，适合大多数开发平时使用。只需上线前改成SotRelease出包，就能让APP就得到热更能力。

本文章分析怎么实现这种卡片效果以及都有哪些功能，基于这些功能是否可以完善，让框架更加灵活，可拓展等。现已封装成通用框架。效果图如下：

代码地址

1、功能分析

不管是探探还是陌陌的点点匹配模块，都是对卡片的左滑右滑进行的操作，那么以陌陌的点点匹配模块分析，所涉及的功能有：

• 卡片复用机制


• 拖拽卡片时的动画
  
  
  
  • 卡片拖拽左上方、左下方、右上方、右下方都会有相应的旋转动画
  
  
  
  


• 喜欢功能
  
  
  
  • 喜欢功能又分为拖拽卡片向右侧滑出、点击下方的喜欢按钮控制卡片滑出。
  
  
  
  


• 不喜欢功能
  
  
  
  • 不喜欢功能也是和喜欢功能逻辑一样，只是方向不同。
  
  
  
  


• 超级喜欢功能
  
  
  
  • 超级喜欢功能跟喜欢功能一样，只不过是针对的vip用户，普通用户需要充值vip才能使用，vip用户触发超级喜欢，会有一个炫丽的动画特效，并进行其它业务处理
  
  
  
  


• 回退功能
  
  
  
  • 回退功能也是针对vip用户设计的，vip用户单次只能回退一张卡片。我们实现回退多张功能，让外界控制是否可以回退功能，更加灵活。
  
  
  
  


• 预加载功能
  
  
  
  • 卡片可以无限的滑走，那么数据源获取就得支持加载更多数据。
  
  
  
  


• 无数据的处理功能
  
  
  
  • 卡片数据操作完了，就得处理无数据的情况，显示占位图等等。
  
  
  
  


• 触发卡片喜欢功能时，需要检测是否允许此次操作
  
  
  
  • 这个功能也是根据业务去做，探探里面，好像对喜欢的操作是有限制的，如果超出了这个限制，再次触发喜欢功能就会提示充值vip同时拖拽的卡片也会恢复原位。
  
  
  
  

2、功能实现

完成了上面的功能分析之后，接下来就可以一个一个的去实现了。

• 
  

  卡片复用机制

  
  

  这里用了4张卡片，最上面的卡片划走之后，会被放在最下面一层，达到复用。

  
  


• 
  

  拖拽卡片时的动画

  
  

  卡片拖拽左上方、左下方、右上方、右下方都会有相应的旋转动画。我们可以确定用户手势触发的点的位置，根据方位进行设置相关的旋转角度，左右是相反的。

  
  


• 
  

  喜欢、不喜欢功能

  
  

  1、通过拖拽手势划走卡片
  给每个卡片添加一个拖拽手势，当拖拽卡片的时候，根据拖拽的距离和卡片原始的中心点X值进行判断卡片是向左还是向右，拖拽结束的时候，通过改变卡片的位置并加上动画，达到卡片划走的效果。

  
  

  2、通过按钮触发划走卡片
  按钮触发的时候，指定卡片的x位置。然后内部统一走手势结束的方法。

  
  


• 
  

  超级喜欢功能
  超级喜欢功能，其实也是喜欢的一种，通过按钮触发喜欢操作，之后加上自己的炫丽动画以及业务逻辑.

  
  


• 
  

  回退功能

  
  

  卡片回退的实现，将最底下的卡片放到最上面的卡片上面并加上入场动画，同时更新对应的索引数据。
  陌陌vip用户只支持回退一张，我们可以设计支持多张，有多少张不喜欢卡片，默认回退多少张，如果想要实现一张也可以，外界可以控制。相关的方法如下：
  
  这里回退操作的场景很多，比如：左滑10次，然后右滑4次，回退5次，在一次次的滑动，那么怎么保证卡片是按照正常的顺序显示的呢。这里用了2个数组处理的，第一个数组保存左滑的数据index，第二个数组保存回退的index。具体的思路看下截图：
  

  
  


• 
  

  预加载功能
  每次划走一个卡片，都会代理回调对应的数据源Index供上层更新底部的卡片显示内容， 卡片划走的时候，也会做校验，看看当前的index相对于数据源总数是否小于一个值，这个值我们称为阀值。小于这个阀值会触发加载更多的代理回调。
  

  
  


• 
  

  无数据的处理功能
  每次划走一个卡片，都会更新底部卡片显示内容，如果内部卡片的数据index超出了外界的数据源总数，则将卡片内容隐藏，也会做无数据的检测。
  

  
  


• 
  

  触发卡片喜欢功能时，需要检测是否允许此次操作
  可以在拖拽手势结束的时候，通过代理去询问是否允许滑走，如果不允许则内部更改拖动的距离x值，走复位逻辑。

  
  

3、总结

卡片交互的细节很多，很多控制的地方也很多，封装的框架现已支持上面的所有功能， 使用的时候，可以自定义卡片cell实现自己的样式。提供的有示例demo. 欢迎预览。

废话开篇：新手引导功能就是简单的告诉用户某一模块下能够进行什么样的操作，起到指引用户的作用，那么就简单的实现一下这样的功能模块。

一、实现效果展示

可以从效果图中看到，对新用户的必要模块都会进行简单的功能解释。

二、调用代码

添加待引导功能视图到管理类

管理类进行展示

三、工具类解析

1、KDSGuideMannager 类

（1）统一管理全局下需要进行 “引导” 的功能区域（UIView）的保存。

（2）控制引导界面的显示与消失。

（3）控制下一个功能区域（UIView）圈定及描述展示。

2、KDSGuideView 类

（1）整体的蒙板视图层。

（2）对当前所选引导功能区域（UIView）进行镂空标注

（3）调整气泡（KDSGuideBubbleView）位置。

3、KDSGuideBubbleView 类

（1）气泡标注视图。

4、KDSGuideModel 类

（1）保存功能区域（UIView）视图及功能描述文字

四、实现代码

1、KDSGuideMannager 类

KDSGuideMannager.h

KDSGuideMannager.m

2、KDSGuideView 类

KDSGuideView.h

KDSGuideView.m

3、KDSGuideBubbleView 类

KDSGuideBubbleView.h

KDSGuideBubbleView.m

4、KDSGuideModel 类

KDSGuideModel.h

KDSGuideModel.m

五、其他效果展示

个人总结，代码拙劣，大神勿笑。

简介

SDWebImage提供的简洁的获取远程URL图片的API；平时开发中使用最多场景就是列表中的cell中要显示远程图片的需求，在具体的实现中要避免加载图片造成的界面卡顿，列表卡顿等现象的出现；所以需要编码实现如下功能：

• 使用占位图片显示UI界面，异步线程加载图片成功后刷新控件
• 缓存机制，下载过的图片做内存缓存和磁盘缓存
• app内存吃紧的状态下移除缓存的内容

SDWebImage的框架结构

SDWebImage的图片下载分类，只要一行代码就可以实现图片异步下载和缓存功能。

功能简介

1. 一个添加了web图片加载和缓存管理的UIImageView分类
2. 一个异步图片下载器
3. 一个异步的内存加磁盘综合存储图片并且自动处理过期图片
4. 支持动态gif图
   • 4.0 之前的动图效果并不是太好
   • 4.0 以后基于 FLAnimatedImage加载动图
5. 支持webP格式的图片
6. 后台图片解压处理
7. 确保同样的图片url不会下载多次
8. 确保伪造的图片url不会重复尝试下载
9. 确保主线程不会阻塞

实现原理

1. 架构图（UML 类图）

2. 流程图（方法调用顺序图）

目录结构

• Downloader
  ○ SDWebImageDownloader
  ○ SDWebImageDownloaderOperation
  

• Cache
  ○ SDImageCache

• Utils
  ○ SDWebImageManager
  ○ SDWebImageDecoder
  ○ SDWebImagePrefetcher
  

• Categories
  ○ UIView+WebCacheOperation
  ○ UIImageView+WebCache
  ○ UIImageView+HighlightedWebCache
  ○ UIButton+WebCache
  ○ MKAnnotationView+WebCache
  ○ NSData+ImageContentType
  ○ UIImage+GIF
  ○ UIImage+MultiFormat
  ○ UIImage+WebP
  

• Other
  ○ SDWebImageOperation（协议）
  ○ SDWebImageCompat（宏定义、常量、通用函数）
  

相关类名与功能描述

SDWebImageDownloader：是专门用来下载图片和优化图片加载的，跟缓存没有关系

SDWebImageDownloaderOperation：继承于 NSOperation，用来处理下载任务的

SDImageCache：用来处理内存缓存和磁盘缓存（可选)的，其中磁盘缓存是异步进行的，因此不会阻塞主线程

SDWebImageManager：作为 UIImageView+WebCache 背后的默默付出者，主要功能是将图片下载（SDWebImageDownloader）和图片缓存（SDImageCache）两个独立的功能组合起来

SDWebImageDecoder：图片解码器，用于图片下载完成后进行解码

SDWebImagePrefetcher：预下载图片，方便后续使用，图片下载的优先级低，其内部由

SDWebImageManager ：来处理图片下载和缓存

UIView+WebCacheOperation：用来记录图片加载的 operation，方便需要时取消和移除图片加载的 operation

UIImageView+WebCache：集成 SDWebImageManager 的图片下载和缓存功能到 UIImageView 的方法中，方便调用方的简单使用

UIImageView+HighlightedWebCache：跟 UIImageView+WebCache 类似，也是包装了 SDWebImageManager，只不过是用于加载 highlighted 状态的图片

UIButton+WebCache：跟 UIImageView+WebCache 类似，集成 SDWebImageManager 的图片下载和缓存功能到 UIButton 的方法中，方便调用方的简单使用

MKAnnotationView+WebCache：跟 UIImageView+WebCache 类似

NSData+ImageContentType：用于获取图片数据的格式（JPEG、PNG等）

UIImage+GIF：用于加载 GIF 动图

UIImage+MultiFormat：根据不同格式的二进制数据转成 UIImage 对象

UIImage+WebP用于解码并加载 WebP 图片

工作流程

• 入口 setImageWithURL:placeholderImage:options: 会先把 placeholderImage 显示，然后 SDWebImageManager 根据 URL 开始处理图片。

• 进入 SDWebImageManager-downloadWithURL:delegate:options:userInfo:交给 SDImageCache 从缓存查找图片是否已经下载 queryDiskCacheForKey:delegate:userInfo:。

• 先从内存图片缓存查找是否有图片，如果内存中已经有图片缓存，SDImageCacheDelegate 回调 imageCache:didFindImage:forKey:userInfo: 到 SDWebImageManager。

• SDWebImageManagerDelegate 回调 webImageManager:didFinishWithImage: 到 UIImageView+WebCache 等前端展示图片。

• 如果内存缓存中没有，生成 NSInvocationOperation 添加到队列开始从硬盘查找图片是否已经缓存。

• 根据 URLKey 在硬盘缓存目录下尝试读取图片文件。这一步是在 NSOperation 进行的操作，所以回主线程进行结果回调 notifyDelegate:。

• 如果从硬盘读取到了图片，将图片添加到内存缓存中（如果空闲内存过小，会先清空内存缓存）。SDImageCacheDelegate 回调 imageCache:didFindImage:forKey:userInfo:进而回调展示图片。

• 如果从硬盘缓存目录读取不到图片，说明所有缓存都不存在该图片，需要下载图片，回调 imageCache:didNotFindImageForKey:userInfo:。

• 共享或重新生成一个下载器 SDWebImageDownloader 开始下载图片。

• 图片下载由 NSURLConnection(3.8.0之后使用了NSURLSession)，实现相关 delegate 来判断图片下载中、下载完成和下载失败。

• connection:didReceiveData: 中利用 ImageIO 做了按图片下载进度加载效果。connectionDidFinishLoading: 数据下载完成后交给 SDWebImageDecoder 做图片解码处理。

• 图片解码处理在一个 NSOperationQueue 完成，不会拖慢主线程 UI。如果有需要对下载的图片进行二次处理，最好也在这里完成，效率会好很多。

• 在主线程 notifyDelegateOnMainThreadWithInfo: 宣告解码完成，imageDecoder:didFinishDecodingImage:userInfo: 回调给 SDWebImageDownloader。

• imageDownloader:didFinishWithImage: 回调给 SDWebImageManager 告知图片下载完成。

• 通知所有的 downloadDelegates 下载完成，回调给需要的地方展示图片。

• 将图片保存到 SDImageCache 中，内存缓存和硬盘缓存同时保存。写文件到硬盘也在以单独 NSInvocationOperation 完成，避免拖慢主线程。

• SDImageCache 在初始化的时候会注册一些消息通知，在内存警告或退到后台的时候清理内存图片缓存，应用结束的时候清理过期图片。

• SDWebImagePrefetcher 可以预先下载图片，方便后续使用。

常见面试题

1. 图片文件缓存的时间有多长：1周

_maxCacheAge ＝ kDefaultCacheMaxCacheAge

2. SDWebImage 的内存缓存是用什么实现的？

NSCache

3. SDWebImage 的最大并发数是多少？

maxConcurrentDownloads ＝ 6

• 是程序固定死了，可以通过属性进行调整！

4. SDWebImage 支持动图吗？GIF

1. #import <ImageIO/ImageIO.h>

2. [UIImage animatedImageWithImages:images duration:duration];

复制代码

5. SDWebImage是如何区分不同格式的图像的

   • 根据图像数据第一个字节来判断的！
   • PNG：压缩比没有JPG高，但是无损压缩，解压缩性能高，苹果推荐的图像格式！
   • JPG：压缩比最高的一种图片格式，有损压缩！最多使用的场景，照相机！解压缩的性能不好！
   • GIF：序列桢动图，特点：只支持256种颜色！最流行的时候在1998～1999，有专利的！

6.SDWebImage 缓存图片的名称是怎么确定的！

• md5

• 如果单纯使用 文件名保存，重名的几率很高！

• 使用 MD5 的散列函数！对完整的 URL 进行 md5，结果是一个 32 个字符长度的字符串！

7. SDWebImage 的内存警告是如何处理的！
   • 利用通知中心观察
   • - UIApplicationDidReceiveMemoryWarningNotification 接收到内存警告的通知
   • 执行 clearMemory 方法，清理内存缓存！
   • - UIApplicationWillTerminateNotification 接收到应用程序将要终止通知
   • 执行 cleanDisk 方法，清理磁盘缓存！
   • - UIApplicationDidEnterBackgroundNotification 接收到应用程序进入后台通知
   • 执行 backgroundCleanDisk 方法，后台清理磁盘！
   • 通过以上通知监听，能够保证缓存文件的大小始终在控制范围之内！
   • clearDisk 清空磁盘缓存，将所有缓存目录中的文件，全部删除！

实际工作，将缓存目录直接删除，再次创建一个同名空目录！

青山不改，绿水长流，后会有期，感谢每一位佳人的支持！

采访嘉宾 | 于佳（宗心）

编辑 | Tina

闲鱼在 2017 年引入 Flutter，当时的 Flutter 还远未成熟，行业内也没有把 Flutter 放入已有工程体系进行开发的先例。

之后这支不到 15 人的闲鱼团队从工程架构、混合栈调用、打包构建、协同模式上都做了一些创新，保证了 Flutter 能融入到闲鱼已有的客户端工程体系内。在 2017 年到 2019 年期间，闲鱼也不断的修正 Bug 提高 Flutter 的稳定性并同步给 Google，并在实践中沉淀出一套自己的混合技术方案，开源了 Flutter Boost 引擎。

2019 年，闲鱼开始大规模落地，推进 Flutter 在闲鱼的应用。2020 年，闲鱼线上的主链路几乎已经完全拥抱 Flutter。这两年，Flutter 也逐渐在其他企业里落地，但同时也不断有质疑的声音发出。甚至有传言表示“闲鱼的新业务已经放弃 Flutter”、“相信闲鱼遇到了很大的难题”......

那么，作为 Flutter 先驱和探路者，闲鱼在过去几年的摸索过程中是否有走弯路？闲鱼现在到底面临着什么样的挑战？是否会放弃 Flutter？新业务选择了什么技术？对应的技术选型原则是什么？针对这些疑问，闲鱼技术团队客户端负责人于佳（宗心）逐一给了我们解答。

国内第一个引进 Flutter 的团队

InfoQ：闲鱼当时引进 Flutter 时主要是为了解决什么问题？

于佳（宗心）：闲鱼在 17 年调研的时候，客户端团队只有不到 15 人，而闲鱼的业务场景可以称得上是一个 “小淘宝”，相对比较复杂。这种场景下我们首先需要解决的是多端人力共享的问题。多端人力带来的好处不只是可以一人开发双端，也代表着更好的研发资源调配灵活性（这意味着团队的 iOS：Android 的比例不再需要 1:1，而市面上 Android 的工程师基数远大于 iOS）。

另外我们希望这个技术是贴合移动端研发技术栈的，而非前端技术栈，本身对于 RN 和 Weex 来说，工具链和研发习惯还是有比较大的差异的。最后我们希望这个技术的体验可以做到接近原生，AOT 下的 Flutter 基本满足我们当时的要求，在实际测试过程中，同样未深度优化的详情页面，Flutter 在低端机的表现比 Native 更好。因此当时基于这三个条件选择了 Flutter。

2018 年的尝试投入过程中，整个基建和探索带来了一定的成本。2019 年，团队开始正式大量使用 Flutter 进行研发，目前整个团队 70% 的 commit 来自 Dart，可以说基本完成了我们当初的期望。在实际的研发过程中，基本可以完成一个需求一个客户端投入的目标。

InfoQ：很多人质疑 Dart 语言，认为这个语言独特小众，还存在比如说多层嵌套的问题，您们怎么看待新语言的应用？

于佳（宗心）：语言是我们选择技术方案的其中一个因素，但是相对比较弱的因素。

我们会从几个角度去看：

• 语言的背景，从我们的角度来看 Dart 是大厂研发的，也有比较久的历史。

• 语言的学习成本，从语法糖和学习曲线上来看，Dart 成本都比较低，首先 Android 同学的上手率很快。另外熟悉 swift 的 iOS 同学，上手也很快。现代语言的特性有很多是相通的。这部分是它的优势。

• 语言带来的其他优势，如编译产物支持 AOT 和 JIT，比较灵活。AOT 有明显的性能优势。

• 语言的未来的趋势。Dart 在 2020 年第四季度 Github Pull Request 的排名已经到了全网第 13 位，超过了 Kotlin（15 位），Swift（16 位），Objective-C（18 位）。作为移动技术领域的新语言成长性还是非常不错的。

对于像多层嵌套的问题，可以通过进一步抽象一些控件类或方法解决，并不是特别大的问题。

InfoQ：闲鱼引入 Flutter 之后做了哪些关键创新？在使用 Flutter 上有哪些收益？

于佳（宗心）：闲鱼在这部分创新非常多，并在内部申请了非常多专利。

• 我们的开源项目 Flutter Boost 彻底改变了 Flutter 官方的一些 RoadMap。目前 Add2ExistApp 是行业最主流的研发方式。混合开发一方面帮助了业务更平滑的迁移到了新的技术栈，另一方面可以更好的利用已有的 Native 能力，大幅减少了重复开发的工作。

• 针对音视频的外接纹理方案，也是目前行业大厂常见的解决方案，在外接纹理方案下，Native 和 Flutter 侧的缓存管理得到了统一，在性能上也有一定的提升。

• Flutter APM，基于 Flutter 技术栈的性能稳定性数据采集和加工方案，目前在集团内部也是跟多个 BU 一起共建，为大的 AliFlutter 组织提供服务。

• Flutter 相关的动态模版方案，Flutter DX，兼容集团的已有的 Native 模版，保证了业务的平滑迁移，并为 Flutter 提供了部分业务动态性。

• 其他还有很多，包括内部的高性能长列表容器 PowerScrollView，动画框架 Fish-Lottie，游戏引擎 Candy，我们现在还有一些新的方向在沉淀，在基于 Flutter 的研发流程和研发工具上也有投入，未来大家如果感兴趣可以去 InfoQ 组织的行业大会与我们交流。

闲鱼有想过放弃 Flutter 吗？

InfoQ：最近一两年，您们在 Flutter 开发上，遇到的最大挑战是什么？跟最初使用 Flutter 时的挑战一样吗？

于佳（宗心）：早先几年闲鱼作为整个行业的先驱，主要的挑战是整个技术生态太差，都需要自己做。另外就是前期引擎的稳定性有比较大的问题。

最近几年随着整个技术的深度使用，以及闲鱼这两年业务快速发展背后，越来越多的体验问题被大家提及，因此我们从去年开始进行了整个产品的大改版，同时客户端的目标就是全面优化，打造更好的用户端产品体验。

因此在生态逐渐完善后，我们的挑战是，怎么通过 Flutter 来实现更加精细化的用户体验。去年，这部分确实花了我们比较多的精力。基于这个命题，我们在内存和卡顿上内部也开发了较多的基于 Flutter 的检测工具，在内存优化和卡顿优化上也有一些比较具体的方法，但不得不说，所有的细节优化都是比较耗人力的，不管是 Native 还是 Flutter 都要投入相当的精力，所以我们目前也面向全行业进行客户端的招聘，希望有志在 Flutter 领域进行探索的同学联系我。

InfoQ：在混合研发体系下，闲鱼还进行了引擎定制，那么官方提供的方案主要问题是什么？对于一般小企业来说，混合开发复杂度会不会太高？

于佳（宗心）：闲鱼在前期有不少修改引擎的动作，我针对当时有一些 自己的反思，一方面是确实因为 Flutter 不太完善，另一方面在 18 年左右，我们自己引擎的理解也不够深刻，很多时候可以通过更上层的方案解决，这也间接导致了我们的很多引擎定制修改难以合入主干。

所以这部分我想说的是，目前官方的方案可以解决 90% 的问题，如果一定要说定制，目前在性能侧还是有一些问题的。比如闲鱼目前首页还是 native 没有使用 Flutter，就是因为替换以后启动加载体验不佳，另外在长列表侧大家一直诟病的卡顿问题，我们有尝试通过上层框架解决了一部分，接下来可能还需要底层引擎帮忙优化。另外一些包括双端字体不一致的问题，还有输入框体验不一致的问题，都需要官方进行长期的优化。

目前我们主要还是希望跟随主干分支，尽量不修改 Flutter 的代码，闲鱼团队会储备一些引擎侧的专家，同时也会依靠集团 AliFlutter 的生态做事情。在整个 AliFlutter 的组织里不同的 BU 擅长的也不同，如 UC 同学更擅长引擎定制，闲鱼团队有大量的上层应用框架，淘宝团队提供基于构建相关的基础设施。这样在大型公司中通过内部开源社区的方式就可以解决大部分的问题，放心开发了。

对于中小企业来说，要明确下大家面临的场景，如果前期快速迭代跑起来，对细节问题可以有一部分妥协，选择 Flutter 是一个比较明确的路径。今天大家所处的环境比闲鱼当年所处的环境要完善的多。推荐使用 Flutter Boost 进行混合开发，在部分场景下遇到问题无法快速响应时，也可以通过混合工程使用 native 进行兜底。复杂度方面，单纯引入混合栈能力，整体复杂度一般。

InfoQ：有传言，闲鱼有新业务没采用 Flutter，这给很多人造成了闲鱼放弃 Flutter 的观念，那么您们在新业务的技术选型上，考虑了哪些因素？

于佳（宗心）：作为技术决策者，是应该避免自己被某一个技术绑架而在落地过程中产生谬误的。Flutter 和其他技术一样，最终是为了帮助团队实现业务价值，同时它也只是移动端的一种技术，捧杀和谩骂都是不合适的。这也是我特别不想在公众面前回应这个事情的原因，因为 技术本身要看适用场景。

从目前闲鱼的人员规模和业务规模来看。对于架构设计，我的理念是尽量追求一致性和架构的简洁。

整个客户端组织未来从语言的方向来看是 Dart First，尽量减少双端的研发投入。而对其他容器的选择，主要以 H5 为主，在未来的路径上尽量减少其他容器的接入，让前端开发也回归到标准路线来。

这里有两个好处：

1. 组织成本最低，组织成本包括了同学们的学习成本、协同成本等等，多技术栈和容器多会带来额外的成本，这是我不愿意看到的。

2. 架构的一致性对研发效能和质量都有帮助。举个例子，随着业务复杂性加大，多容器带来的内存飙升和包大小的问题是非常致命的，而且几乎是无解的，这就需要架构师作出决策，干掉什么留下什么。回到研发效能上，配套的工具，流程一定是围绕一类容器和语言来扩展的，如果方案特别多，每个方向都需要做额外的配套设施，成本收益很低，研发的幸福感也很低。

从这个设计的角度出发，我们会有几个明确的选择：

• 在默认场景下使用 Flutter 作为首选的方案；

• 在投放活动、前台导购、非常不确定的新业务、以及管理后台等使用 H5 作为首选实现方案；

• 在极少场景下，比如已有完整的 SDK 附带 UI 的支持如直播，以及未来中台的拍摄功能 SDK 也是自带 UI 的部分，如要切换，Native 成本最低，选择 Native。另外目前 Flutter 在首页加载还有一定的性能问题，因此还在使用 Native。从长远发展来看，未来到一定程度可能随改版直接改为 Flutter。

关于未来发展

InfoQ：使用 Flutter 多年后，现在回过头去看，您认为哪些公司哪些场景适合 Flutter？

于佳（宗心）：目前看起来有几个典型场景比较适合：

• 中台战略下的小前台产品，从大公司的组织里看阿里、头条、美团都有相对完善的 Flutter 组织或内部技术社区可以提供一些基础服务，保证了基于 Flutter 基础设施在前期投入过程中的成本均摊，在未来落地过程中，业务团队可以更加专注于业务研发，而更少的担心过程中填坑的成本。

• 中小型企业的初创 App，在人力成本资源都不够的情况下，希望先跑通流程上线验证的团队，可以尝试使用 Flutter 进行研发，在我自己实际的面试和行业交流过程中，这一类情况也比较典型。这种方式可以避免前期成本过度投入，在人员调配上也更加灵活。

• 另外这个观点还没有验证，但是逻辑上应该可行。未来面向企业内部流程工具，政府部门的部分工具属性较强的 App，可以尝试使用 Flutter。因为目前我了解的情况来看，在企业这边的应用来看，整体 ToB（美团商家端）和 ToD（比如饿了么骑手端）的场景的 App 特别多。横向比较来看，场景比较类似，也就是说更多中长尾应用有可能是 Flutter 技术的主要场景。

InfoQ：您认为未来 Flutter 急需改善的地方是什么？

于佳（宗心）：从 Flutter 2.0 发布后我跟一些一线开发者交流的感受来看，Flutter 还是需要推进跨端性能和细节体验的优化。去年一年在大的战略方向上（跨终端），Flutter 做的不错，在 PC 和 Web 侧都有建树，跟车企以及操作系统厂商合作都有一定进展。但回归到产品体验和开发者体验上，还有不少路要走，很多时候对于一个严苛的业务方来说，小到字体和控件的体验都会成为最后不选择这门技术的原因。这部分希望整个开源社区在新的一年能有一些进步。我们 AliFlutter 组织内部，以 UC 内核团队为首的同学们，在这方面就有非常多的沉淀以及 PR，在内部引擎制定上有很多体验的提升。未来在 AliFlutter 组织内，我们也会除了完善整个公司的基建外，进一步关注细节体验，沉淀一些最佳实践给到其他的开发同学。大家会在2个月内看到我们最新出版的书籍，欢迎交流。

InfoQ：Flutter2.0 来了，那么 Flutter 会成为主流选择吗？

于佳（宗心）：可以讲一下我对 Flutter 未来的判断。一方面在未来操作系统有可能走向分裂，多终端的场景下，Flutter 会有比较不错的发展，跨平台本身的对企业来说在成本侧是有很大的诉求的，尤其是互联网公司。但是从历史的经验来看，Flutter 只是渲染引擎，即使今天的游戏开发，在游戏引擎和配套工具完善的情况下，有部分的功能模块（比如社区 / 直播的功能）依然还是混合的框架，所以混合开发最后一定是一直存在的。能不能成为未来整个移动研发的主流这件事情上看，我无法给出答案，但可以肯定的是，在生态更加完善后，会在一定的历史阶段成为客户端研发的另一种常见的技术选择。

嘉宾介绍：

于佳，花名 宗心，闲鱼技术团队客户端负责人。2012 年应届毕业加入阿里巴巴，经历集团无线化转型的重要时期，参与过集团多款重量级 App 以及移动中间件的设计与开发，多年客户端老兵。2014 年参与了手机淘宝的 iOS 客户端的架构升级，该架构首次完成了对百人团队并行开发的支持，同年主导了手机天猫客户端基础架构以及交易链路向手淘架构的归一，为手机淘宝作为未来集团无线中台奠定了坚实的基础。2015 年加入闲鱼客户端团队负责端架构和团队建设，工作期间完成了基于 Flutter 混合架构的闲鱼客户端的整体架构设计，在工程体系上完善了针对 Flutter 的持续集成以及高可用体系的支撑，同时推进了闲鱼主链路业务的 Flutter 化。未来将持续关注终端技术的演变及发展趋势。

引言

SwiftUI 于 2019 年度 WWDC 全球开发者大会上发布，它是基于 Swift 建立的声明式框架。该框架可以用于 watchOS、tvOS、macOS、iOS 等平台的应用开发，等于说统一了苹果生态圈的开发工具。

本人最早开始 iOS 开发时选择了 OC（Objective-C，一种编程语言），当时 OC 不但拥有各种知名的第三方库和完善的社区支持，同时 Swift 语言本身都还在不断颠覆性改进中。但当我看了 2020 年 WWDC 关于 SwiftUI 一系列课程之后，便从 Swift 语言的学习开始，逐步了解并掌握 SwiftUI，并果断抛弃了OC，将新项目全部迁移到了 SwiftUI 框架。

SwiftUI 到底有没有苹果宣传的那么理想化？资深的 iOS 开发者是否有必要转型，以及如何转型？SwiftUI 在实际使用的过程中真实体验如何？这些问题就是这篇文章希望探讨的话题。

在最后，我会分享一些自己的学习心得和材料顺序，借开源的精神与大家共同进步。

什么是 SwiftUI

对于 Swift UI，官方的定义很好找到，也写得非常明确：

SwiftUI is a user interface toolkit that lets us design apps in a declarative way.

可以理解为 SwiftUI 就是⼀种描述式的构建 UI 的⽅式。

单单通过描述，大部分人其实很难对抽象的编程方法，和其中的改进有直观的认识。这篇文章也希望通过尽量口语化的叙述，减少专业词汇和代码的出现来降低阅读门槛，让更多人了解计算机科学，了解程序的世界。

下面是我手头正在做的一个项目，定位是一个原生全平台的电子阅读应用，正在使用 SwiftUI 构建用户界面。

为什么苹果要推出 SwiftUI

SwiftUI 的两个组成部分，Swift + UI，即是这个问题的答案。

Swift：编程语言和体验的一致性

Swift 代表苹果推出的一种现代编程语言

很多苹果用户之所以喜欢苹果的产品，其中一个原因，是不同产品之间由内而外的统一感和协调感。这一点在硬件层面的感知是最明显的，从早期开始苹果出的硬件就是「果味十足」的。即使是新品迭代或者是开发全新的品类，也一定会带有烙印很深的「果味」工业设计。

仅仅外观的统一还不够，苹果真正追求的是内外一致，也就是体验的统一。

然而工业设计可以交给自家精英团队，系统可以相互借鉴，但用户使用的软件是由广大的开发者自由创造的。让人意外的是，这一点苹果做的也很不错，与别家相比，质量精良是很多人对苹果系统上软件的印象。

为了实现这一目标苹果做了大量不为普通消费者所感知的工作。

在设计上，苹果提供了一整套不断在更新的 Human Interface Guidelines，详细规定了与视觉相关的各个方面。在完成开发，准备上架分发之前，苹果的审核团队会对每一款应用进行审核，根据 App Store Review Guidelines 的条款判断应用是否允许上架 App Store，即使是知名的应用违反规定也是说下架就下架，绝不含糊。对于不越狱的移动设备而言，App Store 是唯一可以安装应用的途径，控制了其中的准入也就等于替整个平台做了筛选。

除了控制终端以外，苹果也在想方设法增加开发者的数量，提升单个应用质量。方式也非常符合第一性思维原则——降低开发的难度。所以先有了Swift，紧接着又推出了 SwiftUI。苹果希望直接优化语言本身，并统一所有设备的开发体验，让开发者更容易上手，也更容易将心里的想法转化为运行的程序。

虽说在 2015 年推出 Swift2.0 的时候就进行了开源。但这些年 Swift 在后端或是跨平台的发展上并不是非常顺利。提起 Swift，圈内还是会被默认为特指苹果平台内使用的编程语言，地位有些类似 OC 的接班者。其实为了推广这门语言，苹果本身也做了非常多的工作，像是推出SwiftUI，基本就可以看做苹果在推广新语言的过程中一个里程碑式的节点。

SwiftUI 使用了大量 Swift 的语言特性，特别是 5.0 之后新增的特性。Swift 5.1 的很多特性几乎可以说都是为了 SwiftUI 量身定制的，比如 Opaque return types、Property Delegate 和 Function builder 等。

UI：开发的困局

在 SwiftUI 出现之前，苹果不同的设备之前的开发框架并不互通，移动端的⼯程师和桌⾯端的⼯程师需要掌握的知识，有很⼤⼀部分是差异化的。

从 iOS SDK2.0 开始，移动端的开发者⼀直使⽤ UIKit 进⾏⻚⾯部分的开发。UIKit 的思想继承了成熟的 AppKit 和MVC（Model-View-Controller）模式，作出了⼀些改进，但本质上改动不⼤。UI 包括了⽤⼾能看到的⼀切，包括静⽌的显⽰和动态的动画。

再到后来苹果推出了Apple Watch，在这块狭小屏幕上，又引入了一种新的布局方式。这种类似堆叠的逻辑，在某种程度上可以看做 SwiftUI 的未完全体。

截止此时，macOS 的开发需要使用 AppKit，iOS 的开发需要使用 UIKit，WatchOS 的开发需要使用堆叠，这种碎片化的开发体验无疑会大大增加开发者所需消耗的时间精力，也不利于构建跨平台的软件体验。

即使单看 iOS 平台，UIKit 也不是完美的开发⽅案。

UIKit 的基本思想要求 ViewController 承担绝⼤部分职责，它需要协调 model，view 以及⽤⼾交互。这带来了巨⼤的 sideeffect 以及⼤量的状态，如果没有妥善安置，它们将在 ViewController 中混杂在⼀起，同时作⽤于 view 或者逻辑，从⽽使状态管理愈发复杂，最后甚⾄不可维护⽽导致项⽬崩溃。换句话说，在不断增加新的功能和⻚⾯后，同⼀个ViewControlle r会越来越庞杂，很容易在意想不到的地⽅产⽣ bug。⽽且代码纠缠在⼀起后也会⼤⼤降低可读性，伤害到维护和协作的效率。

SwiftUI的特点

在很多地方都能看到 SwiftUI 针对现有问题的一些解决思路，而且现在的编程思想经过不断以来的演化，也一直就软件工程在开发过程中的各种问题在寻找答案。

近年来，随着编程技术和思想的进步，使用声明式或者函数式的方式来进行界面开发，已经越来越被接受并逐渐成为主流。SwiftUI 不是第一个，也不会是最后一个使用声明式界面开发的框架。

声明式的界面开发方式

在计算机科学的世界内，抽象是一个很重要的概念。从底层的二进制逻辑门，到人类可以阅读和理解的编程语言之间，是由很多层的抽象将它们关联起来的。所谓抽象，简单解释就是通过封装组件，将底层细节打包并隐藏起来，从而明确逻辑降低复杂度。就像把晶体管打包成逻辑门，以及软件工程中的函数对象。在软件开发的过程中，工程师只需负责某个具体功能的实现，而其他人则通过开放的 api 使用该功能。

与曾经的布局方式相比，声明式的页面开发无疑又加了一层抽象。

在 UIKit 框架中，界面上的每一个元素都需要开发者进行布置，期间有不少计算工作，例如长宽的改变或是屏幕可视面积的变化等。这种线性的方式被称为指令式 (imperative) 编程。以一行文字为例，放置在哪个坐标、宽度多少、在哪里换行、怎么断句、字形字号是多少、最终高度多少、是否需要缩小字号来完全显示等，这些都是开发者在制作界面时要考虑和计算妥当的问题。到了第二年，用户可能会换更大屏幕的手机，系统支持动态字体调节等新功能，此时原先的程序不进行适配就可能出现显示问题，开发者就需要回头进行程序的重新调试。

换做 SwiftUI 之后，上述的很多变量就被系统接管了。开发者要做的就是直观的告诉系统放置一个图像，上面加一行文字，右边加一个按钮。系统会根据屏幕大小、方向等自动渲染这个界面，开发者也不再需要像素级的进行计算。这被称为声明式 (declarative) 编程。

对比同一个场景界面的实现

作为常用的列表视图，在UIKit中被称为 TableView，而在 SwiftUI 中被叫做 List 或 Form。同样是实现一个列表，在 SwiftUI 仅需要声明这里有一个 List 以及每个单元的内容即可。而在UIKit 中，需要使用委托代理的方式定制每个单元的内容，还需要事无巨细的设置行和组的数量、对触摸的反应、点击过程等各方面。

在我的另一个早期项目 Amos 时间志中就可以看到，为了绘制主页就需要几千行代码。

智能适配不同尺寸的屏幕

除了不同尺寸的屏幕，SwiftUI 还能根据运行平台的区别，将按钮、对话框、设置项等渲染成匹配的样式。由于声明的留白是很大的，当开发者不需要事无巨细的安排好每一个细节时，系统可操作的空间也会变大。

可以想象，假如苹果推出新品例如眼镜，或许同样的界面代码会被展示成与 iPhone 中完全不同的样式。

提高了解决问题时所需要着手的层级，这可以让开发者可以将更多的注意力集中到更重要的创意方面。

链式调用修改属性

链式调用是 Swift 语言的一种特性，就是用来使用函数方法的一种方式。可以像链条那样不断地调用函数，中间不需要断开。使用这种方式开发者可以给界面元素添加各种属性，只要愿意，同样能够事无巨细的安排页面元素的各种细节。

除了系统预制的属性可以调节外，开发者也可以进行自定义。例如将不同字体、字号、行间距、颜色等属性统合起来，可以组合成为一个叫「标题」的文字属性。之后凡是需要将某一行文字设置成标题，直接添加这个自定义的属性即可。

使用这种方式进行开发无疑能够极大的避免无意义的重复工作，更快的搭建应用界面框架。

界面元素组件化

理论上来讲，每一个复杂的视图，都是由大量简单的单元视图构成。但是函数方法可以包装起来，做到仅在有需要的时候进行调取使用。在 UIKit 框架下的页面元素解耦却不太容易，一般都是针对某种特定情境，很难进行移植。有时候可能手机横屏就会让页面元素混乱，就更别论页面元素的组件化了。

不过 SwiftUI 在布局上的特点，却可以便捷的拆分复杂的视图组件。单一的组件不仅可以自由组合，而且在苹果的任意平台上都可以使用该组件，达到跨平台的实现。

一般我个人会将视图组件区分为基础组件、布局组件和功能组件。因为 SwiftUI 的界面不再像 UIKit 那样，用 ViewController 承载各种 UIVew 控件，而是一切都是视图。这种视图的拼装方式提高了界面开发的灵活性和复用性。

响应式编程框架 Combine

在构建复杂界面的过程中，数据的流通一直是指令式编程中相当让人头疼的部分。

在 UIKit 框架下时，会配合 Target-Action 或者 protocol-delegate 模式来交换信息，使用 Key-Value Observing (KVO) 或者 Key-Value Coding (KVC) 来监测变化和读写属性。但即便开发者熟练地使用这些工具，面对日益增长的应用复杂性，掉坑里的可能性还是非常大。因为有太多需要开发者妥善处理的数据流动，例如数据改动后需要通知相关的页面进行刷新，或是让关联数据重新计算等。

像是 React Native 和 Flutter 这样的移动端跨平台方案，由于采用了声明式 UI 的编写方式和严格的数据流动方向，就能够大幅减轻开发者的思考负担。

SwiftUI 很明显也吸收了这些现代的编程思想，在另一个重量级系统框架 Combine 的协助下，实现了单一数据源的管理。

响应式编程的核心是将所有事件转化成为异步的数据流，这刚好就是 Combine 的主要功能。Combine 采用观察者模式，对应多个观察者，可以分别订阅感兴趣的内容。在 SwiftUI 的界面布局过程中，不同的 View 就是观察者，分别订阅了相关联的属性，并在数据发生变化之后就能够自动的重新渲染。

单一数据源

在 WWDC 的介绍视频中，「Source of truth」这个词反复出现，中文可以将这个词理解为单一数据源。

一直以来复杂的UI结构都会创造更为复杂的数据和逻辑管理需求，每次在用户交互，或是数据来源发生变化的时候，能否及时更新相关界面组件，不然就会引起显示问题。

但是在 SwiftUI 中，只要在属性声明时加上 @State 等关键词，就可以将该属性和界面元素联系起来，在每次数据改动后，都有机会决定是否更新视图。这样就可以将所有的属性都集中到一起进行管理和计算，也不再需要手写刷新的逻辑。因为在 SwiftUI 中，页面渲染前会将开发者描述的界面状态储存为结构体，更新界面就是将之前状态的结构体销毁，然后生成新的状态。而在绘制界面的过程中，会自动比较视图中各个属性是否有变化，如果发生变化，便会更新对应的视图，避免全局绘制和资源浪费。

使用这种方式，读和写都集中在一处，开发者就能够更好地设计数据结构，比较方便的增减类型和排查问题。而不用再考虑线程、原子状态、寻找最新数据等各种细节，再决定通知相关的界面进行刷新

与UIKit彼此相容

一般开发者学习新技术有一个最大的障碍就是原先的项目怎么办。但 SwiftUI 在这一点上做的相当不错。由于是一个新发布的框架，UI 组件并不齐全，当 SwiftUI 中并没有提供类似的功能时，就可以把 UIKit 中已有的部分进行封装，提供给 SwiftUI 使用。需要做的仅仅是遵循UIViewRepresentable协议即可。相反，在已有的项目中，也可以仅用 SwiftUI 制作一部分的 UI 界面。

当然两种代码的风格是截然不同的，但在使用上却基本没有性能的损失。到最终成品时，用户也无法分辨出两种界面框架的不同。

从开发者的⻆度看 SwiftUI

回到开头的问题：SwiftUI 到底有没有苹果宣传的那么理想化？

在 WWDC 发布 SwiftUI 时，有一句话让我印象深刻：「不论多复杂，原先布局的 99% 现在都可以使用 SwiftUI 进行构建」。当我查询 SwiftUI 是否可以承担大型项目开发时，又一次从资深开发者那里看到了这句话。

在我实际体验一段时间，并最终将一款全 SwiftUI 开发的应用上架后，认为这句话并没有什么问题，但前提是对编程这件事需要有比较基础且深入的理解。

这有点像我们学习一些优秀的第三方库时候的感受，同样是用 Xcode 写代码，有些人写出来就是白开水，而另一些人就是黑魔法。学习同样的语言特性，但由于理解的深刻程度不同，在使用时也会大不一样。仅仅依靠一些标准的自带组件无法做出一款出色的应用，即使如 UIKit 那样拥有如此丰富的组件也不行。很多时候还是要根据业务需要，或者是一些独特的脑洞做出最合适的界面。

对于个⼈开发者而言，意味着什么？

SwiftUI 的上限有多高，还要看未来一年一度的更新。但与之前的 UIKit 相比，下限被大大拉低已是不争的事实。这里的所谓下限，指的是学习的难度。由于描述性的布局方式与我们平时的阅读习惯非常接近，告诉系统在页面中间放一个图片就像告诉别人在桌子中间放一个苹果那么直观。我认识的好多 UI 设计师就通过短时间的自学掌握了 SwiftUI，并且搭建起可以直接在真机上使用的 Demo。

降低学习成本这件事是非常有意义的，不仅可以增加开发者数量，降低学习门槛，而且就学习本身而言，让初学者感受到成就感和明确学习方向，长久而言是比短时间的学习效率更重要的事情。只有开始的时候培养足够的兴趣，在后期才可能自主自发的研究更深入更困难的问题。

SwiftUI 和 Combine 大量借助了 Swift 的语法特性，尤其是 5.0 之后的几个更新，新特性就仿佛是为了这两个系统及框架量身定做的一般。虽然将 Swift 开源，但苹果无疑还是牢牢地把握着这门语言的发展。这两个框架和编程语言之间的配合默契，也仿佛让开发者体会到了软硬件一体带来的发展潜力。无论 Swift 出圈后的成果能有多少，在苹果的体系内，无疑是能够将各种消费层面的软件体验整合统一。

只要使用 SwiftUI，系统会默认支持白天和黑夜模式的自动切换；在各种尺寸的屏幕间自动适配；为任意控件添加 Haptic Touch 或是动画；在 Apple Watch 上带来独立而完整的体验；将iOS 的应用转换为 macOS 的原生应用，会以最快的速度支持第一方的各种新特性。这种对苹果硬件的深入支持是那些跨平台方案无论如何无法实现的。可以看一些采用第三方框架的知名应用，像是横屏、黑夜模式、小组件等基础的特性，到现在都迟迟没有适配。

所以 SwiftUI 对小工作室或是独立开发者来说是件好事，可以让新的想法快速落地并且接受市场验证，真正的做到敏捷开发。以这种方式在市场中的细分领域获得一席之地，也能让更多人体会到编写程序的感受，甚至是创造财富。

开源我的学习心得

在最后的部分我会分享一些自己学习 SwiftUI 的过程和介绍相关的资源，给一些也对开发感兴趣的小伙伴们做个参考。

首先要学习的是 Swift 编程语言，它与 OC 之间的差别还是挺大的，学习也没有什么捷径，直接阅读官方教程，对照着实例自己写一遍就行。国内有几个非常好的汉化网站，可以一起对照学习。基本上没有必要特意买书，反而不如直接电脑上看了就敲来的方便。

1. 官网


2. SwiftGG


3. GitHub 汉化库

对语言有了大概的了解后，就可以开始对 SwiftUI 的学习，假如遇到问题可以反复回去查看之前的资料。很多被忽略的细节，或是当时初看没概念的部分，结合具体的案例就能够有比较透彻的理解。

1. 斯坦福公开课 CS193P·2020 年春：该课程强推，我当年学习 OC 看的就是它，现在到SwiftUI了还是先看这个，系统且细致，结合案例和编程过程中的小技巧介绍，是很好的入门课程。


2. 苹果官方 SwiftUI 课程：打开Xcode，照着官方的教学，从头到尾学着做一遍应用。


3. Hacking with swift：这是国外一个程序员用业余时间搭建的分享网站，有大量的文章可以阅读，还有推荐初学者跟着做的「100 Days of SwiftUI」课程。


4. 苹果官方文档：文档是必读的，虽然很多文档缺乏工程细节，但是文档涉及很多概念性的内容，你可以知道官方是怎么思考的，并且有很多具体的机制参数。我本人有一个习惯，要是工程涉及某个框架，会把相关的文档都翻译一遍。


5. Stack Overflow：有问题查询专用，在谷歌中搜索错误代码或者关键词基本都会由该网站给答案。


6. 阅读 SwiftUI 库的源代码。

基本到此假如能够顺利完成下来，就可以开启自己的项目。开发想要提高的关键就是亲自写代码和不断地阅读学习。初期学习的关键能力就是英语，而到后期需要的就是真正的兴趣和一些数学能力。

这是我参与更文挑战的第4天，活动详情查看： 更文挑战

何为基石库？

做一个App无外乎两大要素：

• 获取数据

• 通过数据驱动页面

也许你的App没有网络请求或者网络请求少，你可以不需要Alamofire。

也许你的App的UI不是特别复杂，简单的xib和storyboard就可以胜任。

但是在当下一个App中，图片资源、字符串资源等，作为一个App开发者，你是不得不用的。

举个栗子，传统的获取一个image资源我们都是这么写：

let image = UImage(named: "saber")

这么写的最大弊端就是saber这是一个字符串硬编码，靠的的是纯手工敲打，一旦出错，界面就会出现异常。

在开发中，需要尽量避免这种硬编码，如何高效将这种硬编码的表达方式更换为高效安全的方式，就由本次的主角出场了--R.swift。

统和所有的资源，以现代化的方式引用资源，项目中使用它，虽然不会让你的App上升一个层次，不过却给你的编码极度舒适。

let image = R.image.saber()

同样是Ex咖喱棒，味道却完全不同，哈哈。

基石库就是那些你无法避免不得不用的库，而R.swift恰恰就是。

R.swift

何为R，即Resource的缩写，我们先看看官方给出的一些例子：

使用R.swift函数前：

let icon = UIImage(named: "settings-icon")

let font = UIFont(name: "San Francisco", size: 42)

let color = UIColor(named: "indicator highlight")

let viewController = CustomViewController(nibName: "CustomView", bundle: nil)

let string = String(format: NSLocalizedString("welcome.withName", comment: ""), locale: NSLocale.current, "Arthur Dent")

使用R.swift函数后：

let icon = R.image.settingsIcon()

let font = R.font.sanFrancisco(size: 42)

let color = R.color.indicatorHighlight()

let viewController = CustomViewController(nib: R.nib.customView)

let string = R.string.localizable.welcomeWithName("Arthur Dent")

所有的资源都函数化后，编写过程想出错都难，特别需要注意的是最后一个涉及国际化的函数R.string.localizable.welcomeWithName("Arthur Dent")，Arthur Dent这个字符串需要自己具体制定，可以通过在做国际化时，通过info.strings进行处理。

R.swift目前支持下面这些资源文件管理：

• Images
• Fonts
• Resource files
• Colors
• Localized strings
• Storyboards
• Segues
• Nibs
• Reusable cells

基本上覆盖了绝大多数的App中的资源管理。

安装和使用

安装

R.swift使用其他特别舒服，不过它的安装确实比其他的第三方库稍微麻烦一点，正所谓工欲善其事必先利其器，这一点麻烦是值得的。

1.添加'R.swift' 在工程的Podfile文件中，并运行pod install。 2.如下图所示。添加脚本：

3.如下图所示，移动脚本的位置，让它在Compile Sources phase和Check Pods Manifest.lock之间：

4.添加脚本：

在shell，下面这一栏添加"$PODS_ROOT/R.swift/rswift" generate "$SRCROOT/R.generated.swift"

在input Files通过+号添加$TEMP_DIR/rswift-lastrun

在Output Files通过+号添加$SRCROOT/R.generated.swift

5.运行添加R.generated.swift：

完成第4步后，进行command + B编译，然后在工程的根目录下面会找到R.generated.swift文件： 

将这个文件拖入到工程中，并且不要勾选Copy items if needed

这样，R.swift就安装完成啦。

使用

每一次添加了新的资源文件，就运行一次command + B一次，这样R.generated.swift文件就将新加入的资源文件更新，使用使用的时候只用通过R.来进行引用了。

更多用法，参考上面写的例子，以及官方文档

明天周末怎么破？

最怕周末更文，因为作为一个奶爸，休息都不是自己的，我争取做到不水文，至少讲一些知识点，明日继续，大家加油。

本文已参与好文召集令活动，点击查看：后端、大前端双赛道投稿，2万元奖池等你挑战！

RxSwift编写wanandroid客户端现已开源

目前RxSwift编写wanandroid客户端已经开源了——项目链接。记得给个star喔！

附上一张效果图片：

本篇文章是从6月更文中热心网友的留言中进行的开发与探索：

6月确实因为日更的原因，这个功能没有实现，趁着7月的时候，解决了。

废话了这么多，那么我们进入主题吧。

什么是无感知上拉加载更多

什么是无感知，这个这样理解：在网络情况正常的情况下，用户对列表进行连续的上拉时，该列表可以无卡顿不停出现新的数据。

如果要体验话，Web端很多已经做到了，比如掘金的首页，还有比如掘金iOS的App，列表都是无感知上拉加载更多。

说来惭愧，写了这久的代码，还真的没有认真思考这个功能怎么实现。

如何实现无感知上拉加载更多

我在看见这位网友留言的时候，就开始思考了。

在我看来，有下面几个着手点：

• 列表滑动时候的是如何知道具体滑动的位置以触发接口请求，添加更多数据？

• 从UIScrollView的代理回调中去找和scrollView的位置（contentOffset）大小（contentSize）关系密切的回调。

• 网络上有没有比较成熟的思路？

顺着这条线，我先跑去看了UIScrollViewDelegate的源码：

public protocol UIScrollViewDelegate : NSObjectProtocol {



    

    @available(iOS 2.0, *)

    optional func scrollViewDidScroll(_ scrollView: UIScrollView) // any offset changes



    @available(iOS 3.2, *)

    optional func scrollViewDidZoom(_ scrollView: UIScrollView) // any zoom scale changes



    .

    .

    .

    .

    .

    .

    /// 代码很多，这里就不放上来，给大家压力了。

}

直接上结论吧：看了一圈，反正没有和contentSize或者位置相关的回调代理。scrollViewDidScroll这个回调里面虽然可以回参scrollView，但是对于我们需要的信息还不够具体。

思考：既然UIScrollViewDelegate的代理没有现成的代理回调，自己使用KVO去监听试试？

网上的思路（一）

就在我思考的同时，我也在网络上需求实现这个功能的答案，让后看到这样一个思路：

实现方法很简单，需要用到tableView的一个代理方法，就可轻松实现。- (void)tableView:(UITableView *)tableView willDisplayCell:(UITableViewCell *)cell forRowAtIndexPath:(NSIndexPath *)indexPath就是这个方法，自定义显示cell。这个方法不太常用。但是这个方法可在每个cell将要第一次出现的时候触发。然后我们可设置当前页面第几个cell将要出现时，触发请求加载更多数据。

我看了之后，心想着，多写一个TableView的代理，总比写KVO的代码少，先试试再说，于是代码撸起：

extension SwiftCoinRankListController: UITableViewDelegate {

    

    func tableView(_ tableView: UITableView, willDisplay cell: UITableViewCell, forRowAt indexPath: IndexPath) {

        let row = indexPath.row

        let distance = dataSource.count - 25

        print("row: \(row), distance:\(distance)  ")

        if row == distance {

            loadMore()

        }

    }

}

本代码可以在开源项目中的SwiftCoinRankListController.swift文件查看具体的逻辑，其主要就是通过cell显示的个数去提前请求加载数据，然后我们看看效果：

Gif可能看起来还好，我说我调试的感受：

虽然做到了上拉无感知，但是当手滑的速度比较快的时候，到底了新的数据没有回来，就会在底部等一段时间。

功能达到了，但是感受却不理想，果然还是监听的细腻程度不够。

网上的思路（二）

然后在继续的搜索中，我看到了另外一个方案：

很多时候我们上拉刷新需要提前加载新数据，这时候利用MJRefreshAutoFooter的属性triggerAutomaticallyRefreshPercent就可以实现，该属性triggerAutomaticallyRefreshPercent默认值为1，然后改成0的话划到底部就会自动刷新，改成-1的话，在快划到底部44px的时候就会自动刷新。

MJRefresh？使用MJRefreshAutoFooter，这个简单，我直接把基类的footer给替换掉就可以了，本代码可以在开源项目中的BaseTableViewController.swift文件查看：

/// 设置尾部刷新控件,更新为无感知加载更多

let footer = MJRefreshAutoFooter()

footer.triggerAutomaticallyRefreshPercent = -1

tableView.mj_footer = footer

再来看看效果：

直接说感受：

代码改动性少，编写简单，达到预期效果，爽歪歪。比方案一更丝滑，体验好。

到此，功能就实现，难道就完了？

当然，不会，我们去看看源码吧。

MJRefresh代码的追根朔源

首先我们看看MJRefreshAutoFooter.h文件：

这里有个专门的属性triggerAutomaticallyRefreshPercent去做自动刷新，那么我们去MJRefreshAutoFooter.m中去看看吧：

注意看喔，这个.m文件有一个- (void)scrollViewContentOffsetDidChange:(NSDictionary *)change方法，并且还调用了super，从这个方法名中我们可以明显的得到当scrollView的contentOffset变化的时候进行回调的监听。，我们顺藤摸瓜，看看super是什么，会不会有新的发现：

稍微跟着一下源代码，MJRefreshAutoFooter的继承关系如下：

MJRefreshAutoFooter => MJRefreshFooter => MJRefreshComponent

所以这个super的调用我们就去MJRefreshComponent.m里面去看看吧：

通过上面的截图我们可以得到下面的一些信息与结论：

• MJRefreshComponent是通过KVO去监听scrollView的contentOffset变化，思路上我们对齐一致了。

• 该类并没有实现其具体方法，而是将其交由其子类去实现，这一点通过看MJRefreshComponent.h的注释可以得到：

• MJRefreshComponent从本质上更像虚基类。

总结

如果不是掘友提出这个问题，我可能都不会太仔细的去研究这个功能，也许继续普普通通的使用一般的上拉加载更多就够了。

这次的实践，其实是从思路到寻找方法，最后再到源码阅读。

思路也许不困难，但是真正一点点实现并完善功能，每一步都并不容易，这次我也仅仅是继续使用了MJRefresh这个轮子。

想起有一天，在群里吹水看见的一张图：

灵魂拷问，直击人心，大部分时间我们不也是云程序员呢？

知行合一方能开拓新的天地。

写在前面： iOS底层原理探究是本人在平时的开发和学习中不断积累的一段进阶之

路的。 记录我的不断探索之旅，希望能有帮助到各位读者朋友。

内容的总结专栏

• iOS 底层原理探索 之 阶段总结

序

作为一名iOS开发人员，在平时开发工作中，所有的对象我们使用最多的是alloc来创建。那么alloc底层做了哪些操作呢？接下来我会一步一步探究alloc方法的底层实现。

初探

我们先来看下面的代码

    SMPerson *p1 = [SMPerson alloc];

    SMPerson *p2 = [p1 init];

    SMPerson *p3 = [p1 init];

    

    NSLog(@"%@-%p-%p", p1, p1, &p1);

    NSLog(@"%@-%p-%p", p2, p2, &p2);

    NSLog(@"%@-%p-%p", p3, p3, &p3);

打印内容：

    <SMPerson: 0x600000710400>-0x600000710400-0x7ffee6f15088

    <SMPerson: 0x600000710400>-0x600000710400-0x7ffee6f15080

    <SMPerson: 0x600000710400>-0x600000710400-0x7ffee6f15078

可见，在 SMPerson 使用 alloc 方法从系统中申请开辟内存空间后 init方法并没有对内存空间做任何的处理，地址指针的创建来自于 alloc方法。如下所示：

注：细心的你一定注意到了，p1、p2、p3都是相差了8个字节。 这是因为，指针占内存空间大小为8字节，p1、p2、p3 都是从栈内存空间上申请的，且栈内存空间是连续的。同时，他们都指向了同一个内存地址。

那么， alloc 是如何开辟内存空间的呢？

首先，第一反应是，我们要Jump to Definition，

结果，Xcode中并不能直接跳转后显示其底层实现，所以 并不是我们想要的。

中探

接下来，我们通过三种方法来一探究竟：

方法1

既然不可以直接跳转到API文档来查看alloc的内部实现，那么我们还可以通过下 符号断点 来探寻 其实现原理。

接下来我们就来到此处

一个名为 libobjc.A.dylib 的库，至此，我们就应该要去找苹果开源的库，以寻找我们想要的答案。

点击查看苹果开源源码汇总

方法2

我们也可以直接在alloc那一行打一个断点，代码运行到此处后，按住control键 点击 step into， 接下来，就来到里这里

 我们可以看到一个 objc_alloc 的函数方法到调用，此时，我们再下一个符号断点，同样的，我们还是找到了 libobjc.A.dylib 这个库。

方法3

此外，我们还是可以通过汇编来调试和查找相应的实现内容，断点依然是在alloc那一行。

Debug > Debug Workflow > Always Show Disassembly

找到 callq 方法调用那一行， 

接着， step into 进去， 我们找到了 objc_alloc 的调用， 之后的操作和 方法2的后续步骤一样，最终，可以找到 libobjc.A.dylib 这个库。 

深探

下载源码 objc4-818.2

接下来对源码进行分析，

alloc方法会调用到此处

接着是 调用 _objc_rootAlloc

之后调用 到 callAlloc

跟着断点会来到 _objc_rootAllocWithZone

之后是 _class_createInstanceFromZone

此方法是重点

_class_createInstanceFromZone 方法中，该方法就是一个类初始化所走的流程，重点的地方有三处

第一处是：

    // 计算出开辟内存空间大小

    size = cls->instanceSize(extraBytes);

内部实现如下：  其中在计算内存空间大小时，会调用 cache.fastInstanceSize(extraBytes) 方法，

最终会调用 align16(size + extra - FAST_CACHE_ALLOC_DELTA16) 方法。 align16 的实现如下：

static inline size_t align16(size_t x) {

    return (x + size_t(15)) & ~size_t(15);

}

可见, 系统会进行 16字节 的对齐操作,也就是说，一个对象所占用的内存大小至少是16字节。

在这里 我们举个例子： size_t x = 8； 那么 align16操作后的大小计算过程如下：

    (8 + 15) & ~15;

    

    0000 0000 0000 1000     8

    0000 0000 0000 1111     15  

    

=   0000 0000 0001 0111     23

    1111 1111 1111 0000     ~15

    

=   0000 0000 0001 0000     16

第二处是：

    ///向系统申请开辟内存空间，返回地址指针；

    obj = (id)calloc(1, size);

第三处是：

    /// 将类和指针做绑定

    obj->initInstanceIsa(cls, hasCxxDtor);

总结：

所以，最后我们总结一下， alloc的底层调用流程如下：

就是这样一个流程，系统就帮我们创建出来一个类对象。

补充

• lldb 如何打印实力对象中成员为 double 类型的数值： e -f f -- <值>

这是我参与8月更文挑战的第7天，活动详情查看：8月更文挑战

我的专栏

1. iOS 底层原理探索
2. iOS 底层原理探索 之 阶段总结

意识到我的问题

平时使用手机的时间不算少，每天阅读新闻的时候会感觉到新闻类的app优化的还是很好的，TableView的Cell滚动的时候不会去加载显示图片内容，当一次滑动结束之后，Cell上的新闻图片便开始逐个的加载显示出来，所以整个滑动的过程是很流畅的。这中体验也是相当nice的。

我最开始的做法

开发中TableView的使用是非常值频繁的，当TableViewCell上需要加载图片的时候，是一件比较头疼的事。因为，用户一边滑动TableView，TableView需要一边从网络获取图片。之前的操作都是放在 cellForRowAtIndexPath 中来处理，这就导致用户在滑动TableView的时候，会特别的卡（尤其是滑动特别快时），而且，手机的CPU使用率也会飙的非常的高。对于用户来说，这显然是一个十分糟糕的体验。

糟糕的图片显示 代码

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {

    

    ImageTableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:@"cell"];

    cell.index = indexPath;

    

    NSMutableDictionary *info = [self.dataSource objectAtIndex:cell.index.row];



    NSString *url = [info objectForKey: @"img" ];

    NSData *iData = [NSData dataWithContentsOfURL:[NSURL URLWithString: url ]];

    cell.img.image = [UIImage imageWithData:iData];

    cell.typeL.text = [NSString stringWithFormat:@"%ld-%ld", cell.index.section, cell.index.row];



    return cell;

}

糟糕的手机CPU飙升率

糟糕的用户滑动体验

不只是用户，对于开发这来讲，这也是不可以接受的体验。

平时接触并使用的app也非常的多，发现他们多处理方式就是，当用户滑动列表的时候，不再加载图片，等用户的滑动结束之后，会开始逐一的加载图片。这是非常好的优化思路，减轻了CPU的负担，也不会基本不会让用户感觉到页面滚动时候的卡顿。这也就是最开始我描述的我看新闻app的使用体验。

收到这个思路的启发，我们开始着手将上面糟糕的体验作一下优化吧。

总结思路开启优化之路

那么，带着这个优化思路，我开始了对于这个TableView 的优化。

• 首先，我们只加载当前用户可以看到的cell上的图片。
• 其次，我们一次只加载一张图片。

要完成以上两点，图片的加载显示就不能在cellForRowAtIndexPath中完成，我们要定义并实现一个图片的加载显示方法，以便在合适的时机，调用刷新内容显示。

loadSeeImage 加载图片的优化

#pragma mark load Images

- (void)loadSeeImage {



    //记录本次加载的几张图片

    NSInteger loadC = 0;

    

    // 用户可以看见的cells

    NSArray *cells = [self.imageTableView visibleCells];

    

    // 调度组

    dispatch_group_t group = dispatch_group_create();

    

    for (int i = 0; i < cells.count; i++) {

        

        ImageTableViewCell *cell = [cells objectAtIndex:i];

        

        NSMutableDictionary *info = [self.dataSource objectAtIndex:cell.index.row];

        NSString *url = [info objectForKey: @"img" ];

        

        NSString *data = [info objectForKey:@"data"];

        

        if ([data isKindOfClass:[NSData class]]) {

            

            

        }else {

            

            // 添加调度则到我们的串行队列中去

            dispatch_group_async(group, self.loadQueue, ^{

                

                NSData *iData = [NSData dataWithContentsOfURL:[NSURL URLWithString: url ]];

                NSLog(@" load image %ld-%ld ", cell.index.section, cell.index.row);

                if (iData) {

                // 缓存

                    [info setValue:@"1" forKey:@"isload"];

                    [info setValue:iData forKey:@"data"];

                }

                NSString *isload = [info objectForKey:@"isload"];

                

                if ([isload isEqualToString:@"0"]) {

                    

                    dispatch_async(dispatch_get_main_queue(), ^{



                        cell.img.image = [UIImage imageNamed:@""];

                    });                }else {

                    

                    if (iData) {

                      

                        dispatch_async(dispatch_get_main_queue(), ^{

                     //显示加载后的图片       

                            cell.img.image = [UIImage imageWithData:iData];

                        });

                    }

                }

                

            });

 

            if (i == cells.count - 1) {



                dispatch_group_notify(group, dispatch_get_main_queue(), ^{

                    // 全部加载完毕的通知

                    NSLog(@"load finished");

                });

            }

            

            loadC += 1;

        }

    }

  

    NSLog(@"本次加载了 %ld 张图片", loadC);

}

其次就是 loadSeeImage 调用时机的处理，我们要做到用户在滑动列表之后加载，就是在下面两处加载：

- (void)scrollViewDidEndDecelerating:(UIScrollView *)scrollView   {  

    

    [self loadSeeImage];

}



- (void)scrollViewDidEndDragging:(UIScrollView *)scrollView willDecelerate:(BOOL)decelerate {

    

    if (scrollView.isDragging || scrollView.isDecelerating || scrollView.isTracking) {

        return;

    }

    [self loadSeeImage];

}

当然，首次进入页面，列表数据加载完毕后，我们也要加载一次图片的哦。 好的下面看下优化后的结果：

CPU占用率比之前最高的时候降低了一半多，app在滑动的时候也没有明显卡顿的地方。 完美。

前言

开发规范的目的是保证统一项目成员的编码风格，并使代码美观，每个公司对于代码的规范也不尽相同，希望该份规范能给大家起到借鉴作用。本文为原创，如需转载请说明原文地址链接。

命名规约

• 代码中的命名严禁使用拼音及英文混合的方式，更不允许直接出现中文的方式，最好也不要使用下划线或者美元符号开头；
• 文件名、class、struct、enum、protocol 命名统一使用 UpperCamelCase 风格；
• 方法名、参数名、成员变量、局部变量、枚举成员统一使用 lowerCamelCase 风格
• 全局常量命名使用 k 前缀 + UpperCamelCase 命名；
• 扩展文件，用“原始类型名＋扩展名”作为扩展文件名，其中原始类型名及扩展名也使用 UpperCamelCase 风格，如UIView+Frame.swift；
• 工程中文件夹或者 Group 统一使用 UpperCamelCase 风格，一律使用单数形式；
• 命名中出现缩略词时，缩略词要么全部大写，要么全部小写，以首字母大小写为准，通用缩略词包括 JSON、URL 等；如class IDUtil {}、func idToString() { }
• 不要使用不规范的缩写，如 AbstractClass“缩写”命名成 AbsClass 等，不怕名称长，就怕名称不明确。
• 文件名如果有复数含义，文件名应使用复数形式，如一些工具类；

修饰规约

• 能用 let 修饰的时候，不要使用 var；
• 修饰符顺序按照 注解、访问限制、static、final 顺序；
• 尽可能利用访问限制修饰符控制类、方法等的访问限制；
• 写方法时，要考虑这个方法是否会被重载。如果不会，标记为 final，final 会缩短编译时间；
• 在编写库的时候需要注意修饰符的选用，遵循开闭原则；

格式规约

• 类、函数左大括号不另起一行，与名称之间留有空格
• 禁止使用无用分号
• 代码中的空格出现地点
  • 注释符号与注释内容之间有空格
  • 类继承, 参数名和类型之间等, 冒号前面不加空格, 但后面跟空格
  • 任何运算符前后有空格
  • 表示返回值的 -> 两边
  • 参数列表、数组、tuple、字典里的逗号后面有一个空格
• 方法之间空一行
• 重载的声明放在一起，按照参数的多少从少到多向下排列
• 每一行只声明一个变量
• 如果是一个很长的数字时，建议使用下划线按照语言习惯三位或者四位一组分割连接。
• 表示单例的静态属性，一般命名为 shared 或者 default
• 如果是空的 block，直接声明{ }，括号之间不需换行
• 解包时推荐使用原有名字，前提是解包后的名字与解包前的名字在作用域上不会形成冲突
• if 后面的 else\else if, 跟着上一个 if\else if 的右括号
• switch 中, case 跟 switch 左对齐
• 每行代码长度应小于 100 个字符，或者阅读时候不应该需要滚动屏幕，在正常范围内可以看到完整代码
• 实现每个协议时, 在单独的 extension 里来实现

简略规约

• Swift 会被结构体按照自身的成员自动生成一个非 public 的初始化方法，如果这个初始化方法刚好适合，不要自己再声明
• 类及结构体初始化方法不要直接调用.init，直接直接省略，使用()
• 如果只有一个 get 的计算属性，忽略 get
• 数据定义时，尽量使用字面量形式进行自动推断，如果上下文不足以推断字面量类型时，需要声明赋值类型
• 省略默认的访问权限（internal）
• 过滤, 转换等, 优先使用 filter, map 等高阶函数简化代码，并尽量使用最简写
• 使用闭包时，尽量使用最简写
• 使用枚举属性时尽量使用自动推断，进行缩写
• 无用的代码及时删除
• 尽量使用各种语法糖
• 访问实例成员或方法时尽量不要使用 self.，特殊场景除外，如构造函数时
• 当方法无返回值时，不需添加 void

注释规约

• 文档注释使用单行注释，即///，不使用多行注释，即/***/。 多行注释用于对某一代码段或者设计进行描述
• 对于公开的类、方法以及属性等必须加上文档注释，方法需要加上对应的Parameter（s）、Returns、Throws 标签，强烈建议使用⌥ ⌘ /自动生成文档模板
• 在代码中灵活的使用一些地标注释，如MARK、FIXME、TODO，当同一文件中存在多种类型定义或者多种逻辑时，可以使用Mark进行分组注释
• 尽量将注释另起一行，而不是放在代码后

其他

• 不要使用魔法值(即未经定义的常量)；
• 函数参数最多不得超过 8 个；寄存器数目问题，超过 8 个会影响效率；
• 图形化的字面量，#colorLiteral(...), #imageLiteral(...)只能用在 playground 当做自我练习使用，禁止在项目工程中使用
• 避免强制解包以及强制类型映射，尽量使用if let 或 guard let进行解包，禁止try！形式处理异常，避免使用隐式解包
• 避免判断语句嵌套层次太深，使用 guard 提前返回
• 如果 for 循环在函数体中只有一个 if 判断，使用 for where 进行替换
• 实现每个协议时, 尽量在单独的 extension 里来实现；但需要考虑到协议的方法是否有 override 的可能，定义在 extension 的方法无法被 override，除非加上@objc 方法修改其派发方式
• 优先创建函数而不是自定义操作符
• 尽可能少的使用全局命名空间，如常量、变量、方法等
• 赋值数组、字典时每个元素分别占用一行时，最后一个选项后面也添加逗号；这样未来如果有元素加入会更加方便
• 布尔类型属性使用 is 作为属性名前缀，返回值为布尔型类型的方法名使用 is 作为方法名作为前缀
• 类似注解的修饰词单独占一行，如@objc，@discardableResult 等
• extension 上不用加任何修饰符，修饰符加在 extension 内的变量或方法上
• 使用 guard 来提前结束条件，避免形成判断嵌套；
• 善用字典去减少判断，可将条件与结果分别当做 key 及 value 存入字典中；
• 封装时善用 assert，方便问题排查；
• 在闭包中使用 self 时使用捕获列表[weak self]避免循环引用，闭包开始判断 self 的有效性
• 使用委托和协议时，避免循环引用，定义属性的时候使用 weak 修饰

工具

SwiftLint 工具 提示格式错误

SwiftFormat 工具 提示并修复格式错误

两者大部分格式规范都是一致的，少许规范不一致，两个工具之间使用不冲突，可以在项目中共存。我们通过配置文件可以控制启用或者关闭相应的规则，具体使用规则参照对应仓库的 REAMME.md 文件。

相关规范

Swift 官方 API 设计指南

google 发布的 Swift 编码规范

有一个技术的圈子与一群同道众人非常重要，来我的技术公众号及博客，这里只聊技术干货。

• 微信公众号：CoderStar
• 博客：CoderStar's Blog

链接：https://juejin.cn/post/6976282985695969294

我是独立开发者熊大，最近一年尝试了独立开发的滋味，也想和大家聊一聊独立开发的心历路程。 如果你也有开发一款app的想法，那你可以看一看我的独立开发的故事。

• 我做过直播、相机、社交类APP。
• 个人独立app 《imi》《今日计划》
• 2020年，我想要尝试一下独立开发的方向。

第一款app的开发周期

做第一款软件《今日计划》时，周一到周六工作，大小周，晚上会有一些开发时间。

总体如下：

• 每天1小时写app代码 * 60 = 60小时
• 每周周日有4个小时 * 8 = 32小时
• 清明节三天 （按照8小时/天tian计算）：3*8 = 24小时

一共约120个小时：完成了设计到上线。

我也买了阿里云的ECS，用vapor搭建了后台，维护成本有点高，果断放弃了。

当我开心的把它分享给朋友时，朋友们都说他很丑，于是被贴上一系列标签『丑』、『直男审美』、『搭配有问题』、『太简单了吧』····，总而言之，没什么好的形容词。

(PS:T M D 我自己都感觉有点坑)

 报着期望，又紧急改版一次，更换了icon，改了一些设计。也就是现在的这一版。我在圈子里又推广了一波，登顶效率榜Top20（其实是各位兄弟给面子）。

后来陆陆续续也有一些下载，但由于工作紧张，没能持续更新迭代。

离职风波

《水印相机》这款app目前，摄影榜Top20，很荣幸是我从零带到百万日活的，深知好产品的指数爆发增长。我内心真的想去外边看看，想见识更多优秀的、有趣的人，于是世界那么大，我想出去看看，真的成为了我离职的最主要理由。

从上家公司收获的最大的便是经验，一份让我受用很多年的经验。

离职后，并不缺少内推的机会，但我还没想好该怎么走接下来的路，我在思考，是去大厂深造，还是开启自由职业呢？自己一直是个骄傲的人，毕业时我的薪资就是 xx k，不能为五斗米而折腰，干脆做个自由职业好了。于是把想法讲给周围的人，最后还是找了份工作，公司就在我家的旁边，上下班5分钟。

于是从7月份开始，我就几乎每天晚上有两个小时的时间为开启我的自由职业之路做准备，只要副业收入过万，就开始全职独立开发。

新app上线

2020.08 一个小伙伴，会飞的猪，加入了开发阵营。

2020.10 小满 加了开发阵营。

（由于特殊原因，名字保密）

2021年1月上线了新的免费App《imi-成就最好的自己》，这次的app，至少在UI上取得了程序员的好评，我们还没有正式推广，只是在小圈子里发了一下动态试试水。

我们小团队也开了个新的公·众·号：《独立开发者基地》，感兴趣额可以关注。

惭愧的是，由于新公司较忙，进行了几次通宵加班后，我严重的拖累了小团队的开发进度，本来应该是2020年底就应该上线的。

《imi》

这是一款风格可爱简单的规划、计划类软件，致敬自己，致敬青春。

imi寓意：我就是我，我们一定是不完美的，也许不成功，也许不漂亮，但这就是我，与众不同。

给张图看看：

这个idea是我想的，简单说就是一个计划类软件，里边有

• 人生节点
• 座右铭
• 成就
• 笔记
• 喜欢的人
• 倒计时
• 指纹解锁
• 云同步。

设计这款软件希望能让大家觉得有用，不知道软件的初衷是不是个伪命题。让时间见证吧。

独立开发者应该都知道霸榜很久的《时间规划局》，这次《imi》就是冲着它去的，她将作为我们的竞品之一，我想我们这么有情怀的app对标这样的工具类软件，是有点希望的（怕怕）。

希望大家下载： imi-成就 给予我们支持 ^_^

给独立开发者的福利

这个应该算是福利吧，我们小团队，整理出了app的加速库，《今日计划》《imi-成就》两款app都是基于这个加速库开发的。接下来的其他app也会基于这个加速库开发，意味着我们会持续完善、维护这个加速库。里边有很多实用的功能，欢迎star🌟。

加速库SpeedySwift仓库：https://github.com/Tliens/SpeedySwift

imi 中用到的第三方库：

  # Pods for App1125

  pod 'HWPanModal', '~> 0.8.1'

  pod 'RealmSwift', '~> 10.5.0'   

  pod 'ZLPhotoBrowser', '~> 4.1.2'

  pod 'SwiftDate', '~> 6.3.1'

  pod 'IceCream',:path =>'Dev-pods/IceCream'                  # 数据同步icloud

  # pod 'FSPagerView'               # 轮播图

  # pod 'SwiftyStoreKit'            # 内购组件

  pod 'Schedule', '~> 2.1.0'

  pod 'Hero', '~> 1.5.0'

  pod 'BiometricAuthentication'

  #依赖库

  pod 'UMCCommon', '~> 2.1.4'

  #统计 SDK

  pod 'UMCAnalytics', '~> 6.1.0'

回顾2020

get的技能：

• 有幸能主导组件化开发
• 函数响应式编程
• go服务端

展望2021

希望大家健康、开心

我们会继续维护，维护今日计划、imi。也会有新的app出现。

最后

天行健君子以自强不息，地势坤君子以厚德载物。

虽大部分努力都没有收获，但热爱诞生创造的婴孩。

与君共勉！！！

写于 2021.01.13 北京·安贞门

链接：https://juejin.cn/post/6917058456184684557

先看看这个路由的使用吧

1. 如果是网络地址，会直接自动跳转到 OtherWKWebViewController
2. 如果是应用内部的手动调用跳转

• 直接跳转视图控制器
  • EPRouter.pushViewController(EPSMSLoginViewController())
• 先在 RouteDict 注册映射关系再跳转
  • EPRouter.pushAppURLPath("goods/detail?spellId=xxx&productId=xxx")

3. 又服务器来控制跳转 也得在 RouteDict 注册映射关系，只不过多加了一个 scheme
   • EPRouter.pushURLPath("applicationScheme://goods/detail?spellId=xxx&productId=xxx")

**！！！支持Swift、OC、Storyboard的跳转方式，可以在 loadViewController 看到实现方式 **

EPRouter的全部代码

class EPRouter: NSObject {



    private static let RouteDict:[String:String] = [

        "order/list"            :"OrderListPageViewController",   // 订单列表 segmentIndex

        "order/detail"          :"OrderDetailViewController",     // 订单详情 orderId

        "goods/detail"          :"GoodsDetailViewController",     // 商品详情productId

        "goods/list"            :"GoodsCategoryViewController",   // type brandId 跳转到某个分类；跳转到某个品牌

        "goods/search"          :"SearchListViewController",      // 搜索商品 text

        "coupon/list"           :"CouponListViewController",      // 优惠券列表

        "cart/list"             :"CartViewController",            // 购物车列表

        "address/list"          :"AddressListViewController",     // 收货地址列表

    ]

    

    

// 返回首页，然后指定选中模块

public static func backToTabBarController(index: NSInteger, completion:(()->())?=nil) {



    guard let vc = EPCtrlManager.getTopVC(), let nav = vc.navigationController, let tabBarCtrl = nav.tabBarController  else {

        return

    }



    nav.popToRootViewController(animated: false)

    DispatchQueue.main.asyncAfter(deadline: DispatchTime.now()+0.1) {

        tabBarCtrl.selectedIndex = index

        completion?()

    }

}





// 销毁n个界面 不建议使用这个方法 可以在pushAppURLPath方法中设置destroyTime达到一样的效果，又可以避免用户侧滑返回

public static func popViewController(animated: Bool, time:NSInteger=1) {



    guard let nav = EPCtrlManager.getTopVC()?.navigationController else {

        return

    }

    let vcs = nav.viewControllers

    let count = vcs.count

    let index = (count - 1) - time

    if index >= 0 {

        let vc = vcs[index]

        nav.popToViewController(vc, animated: true)

    } else {

        nav.popViewController(animated: true)

    }

}





    /// 回到目标控制器

    public static func popViewController(targetVC: UIViewController.Type, animated: Bool, toRootVC: Bool=true) {



        popViewController(targetVCs: [targetVC], animated: animated, toRootVC: toRootVC)

    }



    



    /// 回到目标控制器[vc],从前到后 没有目标控制器是否回到根视图

    public static func popViewController(targetVCs: [UIViewController.Type], animated: Bool, toRootVC: Bool=true) {



        guard let nav = EPCtrlManager.getTopVC()?.navigationController else {

            return

        }

        let vcs = nav.viewControllers

        var canPop = false

        for vc in vcs {

            for tvc in targetVCs {

                if vc.isMember(of: tvc) {

                    canPop = true

                    nav.popToViewController(vc, animated: animated)

                    break

                }

            }

        }

        if !canPop && toRootVC {

            nav.popToRootViewController(animated: animated)

        }

    }



    /// push 一个vc --- destroyTime: push之前要销毁的几个压栈vc

    @objc public static func pushAppURLPath(_ path: String, query: [AnyHashable: Any]=[:], animated: Bool=true, destroyTime:NSInteger=0) {



        var urlString = "applicationScheme://"+path

        if path.contains("http://") || path.contains("https://") {

            urlString = path

        }

        pushURLString(urlString, query: query, animated: animated, destroyTime: destroyTime)

    }





    @objc public static func pushURLString(_ urlString: String, query: [AnyHashable: Any]=[:], animated: Bool=true, destroyTime:NSInteger=0) {



        guard let tvc = loadViewControllerWitURI(urlString, query: query) else {

            return

        }

        pushViewController(tvc, animated: animated, destroyTime: destroyTime)

    }





    @objc public static func pushViewController(_ tvc: UIViewController, query: [AnyHashable: Any]=[:], animated: Bool=true, destroyTime:NSInteger=0) {



        guard let vc = EPCtrlManager.getTopVC() else {

            return

        }



        if let _ = tvc.pushInfo {

            tvc.pushInfo?.merge(query, uniquingKeysWith: { (_, new) in new })

        }else {

            tvc.pushInfo = query

        }

        guard let nav = vc.navigationController else {

            vc.present(tvc, animated: true, completion: nil)

            return

        }

        tvc.hidesBottomBarWhenPushed = true



        if destroyTime > 0 {

            let vcs = nav.viewControllers

            let count = vcs.count

            var index = (count - 1) - destroyTime

            if index < 0 { // destroyTime 很多时，直接从根视图push

                index = 0

            }



            var reVCS = [UIViewController]()

            for vc in nav.viewControllers[0...index] {

                reVCS.append(vc)

            }

            reVCS.append(tvc)

            nav.setViewControllers(reVCS, animated: animated)

        }else {

            nav.pushViewController(tvc, animated: animated)

        }

    }



    public static func loadViewController(_ className: String, parameters: [AnyHashable: Any]? = nil) -> UIViewController? {



        var desVC: UIViewController?

        let spaceName = (Bundle.main.infoDictionary?["CFBundleExecutable"] as? String) ?? "ApplicationName"



        if let vc = storyboardClass(className) { // storyboard

            desVC = vc

        }else if let aClass = NSClassFromString("\(spaceName).\(className)") { // Swift

            if aClass is UIViewController.Type {

                let type = aClass as! UIViewController.Type

                desVC = type.init()

            }

        }else if let aClass = NSClassFromString("\(className)") { // OC

            if aClass is UIViewController.Type {

                let type = aClass as! UIViewController.Type

                desVC = type.init()

            }

        }



        desVC?.pushInfo = parameters

        return desVC

    }





    public static func loadViewController(_ viewController: UIViewController, parameters: [AnyHashable: Any]? = nil) -> UIViewController {



        viewController.pushInfo = parameters

        return viewController



    }



    public static func loadViewControllerWitURI(_ urlString: String, query: [AnyHashable: Any]? = nil) -> UIViewController? {



        



        // 先进行编码，防止有中文的带入, 不行进行二次编码

        var urlString = urlString

        if (URLComponents(string: urlString) == nil) {

            urlString = urlString.addingPercentEncoding(withAllowedCharacters: .urlQueryAllowed) ?? urlString

        }



        guard let url = URLComponents(string: urlString), let scheme = url.scheme else {

            HGLog("无效的地址:\(urlString)")

            return nil

        }



        if scheme == "http" || scheme == "https" {



            let webVC = OtherWKWebViewController()

            webVC._urlStr = urlString

            return webVC



        } else if String(format: "%@://", scheme) == "appcationScheme://" {

            let path = (url.host ?? "") + url.path

            guard  var vcClassName = RouteDict[path] else {

                HGLog("没有配置视图控制器呢。。。:\(urlString)")

                return nil

            }



            var info: [AnyHashable: Any]?

            if query?.count ?? 0 > 0 {

                info = [AnyHashable: Any]()

                for (key, value) in query! {

                    info![key] = value

                }

            }



            if let queryItems = url.queryItems {

                if info == nil {

                    info = [AnyHashable: Any]()

                }

                for item in queryItems {

                    if let value = item.value {

                        info![item.name] = value

                    }

                }

            }

            return loadViewController(vcClassName, parameters: info)

        }



        HGLog("未知scheme:\(urlString)")

        return nil



    }



    



    private static func storyboardClass(_ className: String) -> UIViewController? {



        if className == "VIPWithdrawViewController" { // 提现

            let vc = UIStoryboard.init(name: "VIP", bundle: nil).instantiateViewController(withIdentifier: "withdrawTVC")

            return vc

        }else if className == "VIPRecordListViewController" { // 提现记录

            let vc = UIStoryboard.init(name: "VIP", bundle: nil).instantiateViewController(withIdentifier: "recordListVC")

            return vc

        }

        return nil

    }

}

用来跳转传递数据的扩展属性

extension UIViewController {



    private struct PushAssociatedKeys {

        static var pushInfo = "pushInfo"

    }



    @objc open var pushInfo: [AnyHashable: Any]? {

        get {

            return objc_getAssociatedObject(self, &PushAssociatedKeys.pushInfo) as? [AnyHashable : Any]

        }

        set(newValue) {

            objc_setAssociatedObject(self, &PushAssociatedKeys.pushInfo, newValue, .OBJC_ASSOCIATION_RETAIN_NONATOMIC)

        }

    }

}

可见视图控制器的获取

class EPCtrlManager: NSObject {



    public static let `default`: EPCtrlManager = {

        return EPCtrlManager()

    }()



    // MARK: **- 查找顶层控制器、**

    // 获取顶层控制器 根据window

    @objc public static func  getTopVC() -> UIViewController? {



        var window = UIApplication.shared.keyWindow

        //是否为当前显示的window

        if window?.windowLevel != UIWindow.Level.normal{

            let windows = UIApplication.shared.windows

            for  windowTemp in windows{

                if windowTemp.windowLevel == UIWindow.Level.normal{

                    window = windowTemp

                    break

                }

            }

        }

        let vc = window?.rootViewController

        return getTopVC(withCurrentVC: vc)

    }



    ///根据控制器获取 顶层控制器

    private static func  getTopVC(withCurrentVC VC :UIViewController?) -> UIViewController? {



        if VC == nil {

            print("🌶： 找不到顶层控制器")

            return nil

        }



        if let presentVC = VC?.presentedViewController {

            //modal出来的 控制器

            return getTopVC(withCurrentVC: presentVC)

        }else if let tabVC = VC as? UITabBarController {

            // tabBar 的跟控制器

            if let selectVC = tabVC.selectedViewController {

                return getTopVC(withCurrentVC: selectVC)

            }

            return nil

        } else if let naiVC = VC as? UINavigationController {

            // 控制器是 nav

            return getTopVC(withCurrentVC:naiVC.visibleViewController)

        } else {

            // 返回顶控制器

            return VC

        }

    }

}

这是我参与11月更文挑战的第8天，活动详情查看：2021最后一次更文挑战

引言

作为一名开发人员，当我们编写代码时，我们会更多地关注逻辑和算法，而不是拼写和语法。但它也是我们编码的一个重要部分，特别是当我们从注释生成文档的时候。

拼写检查帮助我们找出拼写错误，让我们有更多的时间关注代码逻辑。

拼写检查能识别什么

答案就是代码中与Spelling and Grammer相关的所有内容

• 变量名
• 方法
• 类
• 注释
• 字符串的字面量(包括本地化)

先来看一段代码：

在上面的代码中，包括类、方法、变量和注释，但没有启用Spelling and Grammer。猛一看去，好像没啥问题，但如果我们仔细检查，就会发现很多拼写错误。

现在让我们启用Spelling and Grammer，看看会发生什么-

在上面的代码中我们可以看到，当我们启用拼写检查时，它能检测到所有的拼写错误，并用红色高亮显示。现在我们就省去了找错误的时间，可以直接去修改了。

如何开启

Edit > Format > Spelling and Grammar

可以看到有三个可用的选项，我们依次来看下：

Check Spelling While Typing

启用后，会把项目中的所有输入错误一次性、全部以红色高亮显示，就像上面的例子一样。

另外，开启这个选项后，还可以选中要修改的单词，然后右键，菜单中会出现 Xcode 建议的单词。

Check Document Now

它将在当前文件中逐个显示输入错误。为了检查当前文件中的所有错误，可以重复这个命令
Edit > Format > Spelling and Grammar > Check Document Now

或者使用快捷键
command 和分号（;）的组合

Show Spelling and Grammar

它会打开所有建议的更改。我们可以单击其中任何一个进行替换。 使用命令
Edit > Format > Spelling and Grammar > Show Spelling and Grammar

或者使用快捷键
command 和冒号（:）的组合

Learn Spelling 和 Ignore Spelling

有时候我们需要使用一些在系统词典中没有定义的独特词汇，比如应用程序前缀、开发者名称、公司名称等。Xcode 也会检查这些单词的错误。

所以就用Learn Spelling或者Ignore Spelling处理这些特殊的单词。

通过菜单

右键选中要处理的单词

通过 command + ：

结语

快去探索一下 Edit > Format > Spelling and Grammar 下面的三个选项吧~

这是我参与11月更文挑战的第5天，活动详情查看：2021最后一次更文挑战

引言

Swift 有很多其他语言所没有的独特的结构和方法，因此很多刚开始接触 Swift 的开发者并没有发挥它本身的优势。

所以，我们就来看一看那些让你的 Swift 代码更 Swift 的写法吧~

有条件的 for 循环

现在，我们要对view.subviews中的UIButton做一些不可描述的事情，用 for 循环怎么来遍历呢？

在下面的写法中，更推荐后面两种写法：

❌

for subView in view.subviews {

    if let button = subView as? UIButton {

        //不可描述的事情

    }

}



✅

for case let button as UIButton in view.subviews {

    //不可描述的事情

}



✅

for button in view.subviews where button is UIButton {

    //不可描述的事情

}

enumerated()

在 Swift 中进行 for 循环，要拿到下标值，一般的写法要么定义局部变量记录下标值，要么遍历 0..<view.subviews.count。其实还有个更方便的写法：enumerated()，可以一次性拿到下标值和遍历的元素。

• ❌ 第一种肯定是不推荐的，因为还要定义额外的局部变量，容易出错，pass

• ✅ 第二种在只需要用到下标值的时候，是可以用的，但如果还要用到下标值对应的元素，就还得再取一次，麻烦，pass

• ✅ 第三种就比较完美，虽然一次性可以拿到下标值和元素，但其中一个用不到就可以用 _

❌

var index: Int = 0

for subView in view.subviews {

    //不可描述的事情

    index += 1

}



✅

for index in 0..<view.subviews.count {

    let subView = view.subviews[index]

    //不可描述的事情

}



✅

//index 和 subView 在循环体中都能使用到

for (index, subView) in view.subviews.enumerated() {

    //不可描述的事情

}



//只用到 index

for (index, _) in view.subviews.enumerated() {

    //不可描述的事情

}



//只用到 subView

for (_, subView) in view.subviews.enumerated() {

    //不可描述的事情

}

first(where: )

filter 是 Swift 中几个高级函数之一，过滤集合中的元素时非常的好用，不过在某些情况下，比如获取集合中满足条件的第一个元素时，有一个更好的选择first(where: )

let article1 = ArticleModel(title: "11", content: "内容1", articleID: "11111", comments: [])



let article2 = ArticleModel(title: "11", content: "内容2", articleID: "22222", comments: [])



let article3 = ArticleModel(title: "33", content: "内容3", articleID: "3333", comments: [])



let articles = [article1, article2, article3]



❌

if let article = articles.filter({ $0.articleID == "11111" }).first {

    print("\(article.title)-\(article.content)-\(article.articleID)")

}



✅

if let article = articles.first(where: {$0.articleID == "11111"}) {

    print("\(article.title)-\(article.content)-\(article.articleID)")    //11-内容1-11111

}

contains(where: )

这个和上面的first(where: )几乎一样，比如这里要判断文章列表里是否包含 articleID 为 11111 的文章：

❌

if !articles.filter({ $0.articleID == "11111" }).isEmpty {

    //不可描述的事情

}



✅

if articles.contains(where: { $0.articleID == "11111"}) {

    //不可描述的事情

}

forEach

当循环体内的逻辑比较简单时，forEach 往往比 for...in...来的更加简洁：

func removeArticleBy(ID: String) {

    //删库跑路

}



❌

for article in articles {

    removeArticleBy(ID: $0.articleID)

}



✅

articles.forEach { removeArticleBy(ID: $0.articleID) }

计算属性 vs 方法

我们知道计算属性本身不存储数据，而是在 get 中返回计算后的值，在 set 中设置其他属性的值，所以和方法很类似，但比方法更简洁。一起来看下面的示例：

❌

class YourManager {

    static func shared() -> YourManager {

        //不可描述的事情

    }

}



let manager = YourManager.shared()



❌

extension Date {

    func formattedString() -> String {

        //不可描述的事情

    }

}



let string = Date().formattedString()





✅

class YourManager {

    static var shared: YourManager {

        //不可描述的事情

    }

}



let manager = YourManager.shared



✅

extension Date {

    var formattedString: String {

        //不可描述的事情

    }

}



let string = Date().formattedString

协议 vs 子类化

尽量使用协议而不是继承。协议可以让代码更加灵活，因为类可同时遵守多个协议。

此外，结构和枚举不能子类化，但是它们可以遵守协议，这就更加放大了协议的好处

Struct vs Class

尽可能使用 Struct 而不是 Class。Struct 在多线程环境中更安全，更快。

它们最主要的区别， Struct 是值类型，而 Classe 是引用类型，这意味着 Struct 的每个实例都有它自己的唯一副本，而 Class 的每个实例都有对数据的单个副本的引用。

这个链接是苹果官方的文档，解释如何在 Struct 和 Class 之间做出选择。 developer.apple.com/documentati…

结语

让我们的 Swift 代码更 Swift 的方法远不止上面这些，这里要说的是，平时写代码时，要刻意的使用 Swift 强大的特性，才能发挥它本身的价值。

而这些特性就需要大家去多看看官网的例子，或者一些主流的 Swift 第三方库，看看他们是如何运用 Swift 的特性的。

截至 2021 年 8 月，Android 和 iOS 平台占据移动操作系统市场份额的 99.15%。这些平台多年来一直主导着移动应用市场。结果是各种移动开发技术的兴起，包括跨平台框架。  

React Native 是其中最受欢迎的一种。 

为什么？

React Native 允许开发人员跨平台共享多达 70% 的代码库。更快的开发、降低的成本和易于调试是该框架的一些好处。Facebook 的支持还确保 React Native 保持最佳运行状态。但是，就像其他所有框架一样，它也有其局限性。  

React Native 工程师经常面临兼容性问题和缺乏自定义模块。此外，使用此框架构建的应用程序因其近乎原生的功能而受到的性能影响较小。考虑到这一点，React Native 是一个不错的选择吗？这个问题的答案取决于您的产品要求。为了帮助您做出决定，我们编制了一份 React Native 替代方案列表，这些替代方案可为您的应用程序提供强大、便捷的功能。最后，您将能够知道要使用哪种技术。 

让我们开始吧！

需要考虑的 React Native 替代方案

原生平台：

本机应用程序编程语言是一些最流行的替代方案。它们是用于为操作系统开发移动应用程序的特定于平台的技术。此类操作系统的示例包括 Android、iOS 或 Windows。使用这些语言构建的本机应用程序往往会提供更好的性能和用户体验。开发人员对 Apple 应用程序使用 Swift 和 Objective-C，对原生 Android 应用程序使用 Java 和 Kotlin。

优点：

• 
  

  出色的性能

  
  

这些编程语言直接与平台的底层资源交互。有了这个，开发人员可以充分利用系统的图形元素、计算功能或其他组件来构建快速执行的应用程序。 

• 
  

  易于扩展  

  
  

在扩展应用程序的功能时，总会有遇到乏味问题的风险。本机代码减少了出现此问题的可能性。它们受 iOS 和 Android IDE 以及 SDK 工具包的支持。利用这一优势，您可以为每个平台实施基本、高级甚至最新的功能，而无需担心兼容性问题。  

• 
  

  更容易使用

  
  

根据2021 年 Stack Overflow 开发人员调查，Swift 在其他 38 种编程语言中排名第 8。在类似的列表中，React Native 是 13 个框架中的第 9 个选择。Java 在最常用的语言中排名第 5。React Native 在 13 个最常用的框架中排名第 6。这表明这两个原生代码更易于使用和学习。使用它们来构建应用程序可以减轻中级和有经验的开发人员可能遇到的复杂性。

缺点

• 
  

  开发成本高

  
  

Native 主要基于“一个产品，两个应用程序”的概念。因此，它可能会很昂贵，因为您需要两个对 iOS 和 Android 本机代码具有广泛知识的专业开发团队。

• 
  

  耗时

  
  

Android 和 iOS 应用程序需要不同的代码库，这使得跨平台重用代码变得不可能。相反，每个产品都需要单独构建、测试、更新和管理。对于时间敏感的项目，这种缓慢的开发和部署过程是一个主要缺点。 

• 
  

  稀缺人才库

  
  

尽管 Java 甚至在本机应用程序开发之外也被广泛采用，但该类别中的其他语言则相反。Stack Overflow 发现，Swift 和 Kotlin 分别被 5.1% 和 8.32% 的开发人员使用。或许，这可能归功于这些编程语言的年轻化。Objective-C 以 2.8% 位居榜首。但 React Native 遥遥领先，为 14.51%。因此，找到Swift 开发人员或其他对 Kotlin 和 Objective-C 具有广泛知识的编码人员可能会令人望而生畏。 

想阅读 React Native 和 Swift 之间的详细比较吗？阅读这篇文章。

可以使用 Native Tech Stack 构建哪些应用程序/产品？

本机技术非常适合游戏应用程序、特定于操作系统的媒体播放器或其他需要完全访问设备功能的应用程序。

Flutter

Flutter 是 Google 于 2018 年创建并正式推出的一项年轻的开源技术。与 React Native 类似，Flutter 支持使用一个代码库来构建跨平台的类原生应用程序。它是用 Dart 开发的，Dart 是一种同样由 Google 提供的面向对象语言。多年来，Flutter 的受欢迎程度稳步上升，超过了其主要竞争对手 React Native。

优点

• 
  

  更快的开发

  
  

与 React Native 一样，Flutter 允许更快的开发和部署时间。您可以从一个代码构建两个应用程序（iOS 和 Android）。它的小部件和交互式资产（例如，热重载）减轻了诸如测试和调试之类的繁琐任务。此外，Dart 是 Flutter 的编程语言。它快速、简洁，并且无需额外的抽象即可编译为本机代码。这总结了通过更短的上市时间实现快速开发和竞争优势。 

• 
  

  优质的跨平台体验

  
  

Flutter 的 Material 和 Cupertino 小部件与 Apple 和 Google 的设计指南兼容。开发人员可以利用这些现成的 UI 元素在两个平台上构建具有令人印象深刻的界面的应用程序。更重要的是，Flutter 的渲染引擎 Skia 允许对每个像素进行完整的管理。这反过来又确保了使用 Flutter 构建的 UI 在多个平台或操作系统版本上启动时保持一致。

• 
  

  轻松调试

  
  

使用热重载，无需重新启动整个应用程序即可查看更改。相反，Flutter 开发人员可以进行和查看实时更改，而无需在此之后重新编译代码。只需为两个平台构建一个应用程序这一事实确保检测到和修复的任何错误都将反映在两个版本中。

• 
  

  低成本

  
  

就像使用 React Native 一样，使用 Flutter 开发应用程序的成本低于使用原生应用程序。这是因为您可以使用小型开发团队在更短的时间内为 iOS 和 Android 构建一个应用程序。  

缺点

• 
  

  重量级应用

  
  

使用 Flutter 构建的应用程序文件很大。这些应用程序可能加载缓慢并占用空间和电池性能。为了扩大规模，开发人员可能经常使用较少的包和库，从而在某些功能上妥协。结果是质量低劣的产品。 

• 
  

  技术不成熟

  
  

作为一个年轻的框架，Flutter 还没有广泛的资源基础。这意味着您可能找不到开发所需的第三方库和包。Flutter 不成熟的另一个缺点是它的增长潜力。未来不太有利的变化可能会给框架带来一些复杂性，使其更难管理。鉴于谷歌终止项目的历史，Flutter 也有可能不会持续下去。  

• 
  

  对 iOS 功能的支持不佳

  
  

Flutter 允许快速、无缝地开发 Android 应用程序。但 iOS 的情况并非如此。访问平台的本机组件可能会出现问题。这使得几乎不可能实现特殊的 iOS 功能，例如引导访问或默认页面转换等简单功能。 

想阅读 React Native 和 Flutter 的详细比较吗？阅读这篇文章。

Flutter 可以构建哪些应用/产品？

您可以使用 Flutter 开发需要快速或实时访问的产品。它包括客户服务、金融服务提供商、电子商务公司或任何接受当面付款的商家的应用程序。

Xamarin

另一种常见的 React Native 替代方案是 Xamarin。它是微软提供的跨平台技术。它始于 2011 年的 MonoTouch 和 Mono for Android，直到微软于 2016 年收购它。 Xamarin 使用 C# 语言和 .NET 框架来开发 iOS、Android 和 Windows 移动应用程序。 

优点

• 
  

  快速发展

  
  

借助 Xamarin 的一种产品、一种技术堆栈方法，开发人员可以跨平台重用多达 90% 的代码。您无需在开发环境之间切换，因为您可以在 Visual Studio 中构建 Xamarin 应用程序。更重要的是，该框架允许访问所有支持平台上的公共资源。总而言之，开发时间更短，成本更低。 

• 
  

  灵活的

  
  

Xamarin 的组件存储使开发人员可以访问跨平台的标准化 UI 控件、集成的开源库和第三方服务。借助这些广泛的资源，您可以选择多个元素或在您的应用中实现所需的功能。 

• 
  

  出色的性能

  
  

Xamarin.Essentials 库提供对本机组件的访问。程序员可以使用 Xamarin.iOS 和 Xamarin.Android 分别构建 iOS 和 Android 应用程序。这些导致产品在性能上接近本机应用程序。React Native 在这方面并不接近。您还可以在运行时将应用程序的 UI 转换为原生元素，以确保接近原生的设计和性能。

• 
  

  易于扩展

  
  

调试和维护更容易，因为开发人员可以从一个源代码跨平台发现和更改。此外，Xamarin 与其支持平台的 SDK 和 API 集成。一旦更改可用，这使得在 iOS 和 Android 应用程序中更新或实施新功能变得容易。  

• 
  

  广泛的技术支持

  
  

Microsoft 提供学习资源和综合解决方案，使开发人员能够测试、监控和保护他们的应用程序。它包括 Azure 云、Xamarin Insights 和 Xamarin TestCloud。

缺点

• 
  

  不适合图形繁重的应用程序 

  
  

在 Xamarin 中，开发人员主要可以共享业务逻辑而不是 UI 代码。这只是意味着您需要为每个平台构建一个单独的 UI。考虑到这一点，构建需要复杂动画或大量交互 UI 的游戏应用程序或其他产品会更慢且乏味。 

• 
  

  有限的社区 

  
  

在最近的 Stack Overflow 开发人员调查中，只有 5.8% 的受访者使用 Xamarin。因此，可能很难聘请具有丰富经验和知识的Xamarin 开发人员。但是，随着框架的不断发展，这种劣势可能不会持续很长时间。如果您有紧急需求，请联系我们，让您与经过预先审查的 Xamarin 专家联系。 

• 
  

  昂贵的许可证

  
  

Xamarin 加快了开发时间，降低了成本。但是，考虑到其 IDE（Microsoft Visual Studio）的价格，这种优势可能不那么令人印象深刻。对于商业项目，Enterprise 和 Professional 许可证是理想的选择。Enterprise 第一年的年度定价为每位用户 5,999 美元，然后续订 2,569 美元。首次专业订阅者将在以后支付 1,999 美元和 799 美元。 

• 
  

  固有限制

  
  

尽管 Xamarin 是为原生应用开发量身定制的，但它并不是纯粹的原生应用。因此，它有几个限制。这包括对开源库的限制访问、更新或集成特定于平台的新 API 的延迟以及更大的应用程序大小。 

可以使用 Xamarin 构建哪些应用程序/产品？

Xamarin 在具有繁重逻辑或简单 UI 的应用程序上表现良好。它包括用于调查、项目管理、旅行、杂货或跟踪的应用程序。 

NativeScript

与 React Native 类似，该框架使用 JavaScript 为 iOS 和 Android 构建跨平台移动应用程序。它还支持 TypeScript、Angular 和相关框架。使用 NativeScript 构建的应用程序会生成完全原生的应用程序。 

优点

• 
  

  原生功能

  
  

NativeScript 将 iOS 和 Android API 注入到 JS 虚拟机中，以便更容易地与原生资源集成。这使开发人员可以快速访问插件、Android SDK、iOS 依赖项管理器——Cocoapods 和其他相关技术，以构建具有本机性能的应用程序。它还带来了直观的用户界面和更好的用户体验。

• 
  

  更广泛的开发人才

  
  

NativeScript 使用 JS 和 CSS 的一个子集，它们都是成熟的。对这些技术有一定了解的开发人员可以更快地构建本机应用程序。此外，这个 NativeScript 支持各种 JS 框架，例如 Angular、Vue.js 或 TypeScript。 

• 
  

  更少的开发时间

  
  

使用 NativeScript 构建时，开发人员可以在模拟器屏幕上实时查看代码更改。因此，此后您无需重新编译应用程序。再加上 NativeScript 中的单一代码库方法，这意味着每次修改都可以应用于其他平台。因此，该框架提高了开发速度。 

缺点

• 
  

  本土专业知识

  
  

根据您的项目范围，您可能需要实现高级本机功能。这需要在特定于平台的 UI 标记和元素方面具有专业知识的软件顾问。

• 
  

  插件质量不确定

  
  

虽然 NativeScript 上有几个免费插件，但并不是全部都经过验证。这使开发人员面临使用有问题的开源插件的风险，这些插件可能会导致严重的瓶颈或更糟糕的最终产品。

• 
  

  比本机更大的应用程序大小

  
  

无论 NativeScript 应用程序与真正的 Native 多么接近，它们的大小都相对较大。NativeScript 上空白 android 项目的默认大小为 12MB。但这仍然低于 React Native 的默认 APK 大小，它可以高达 23MB 

可以使用 NativeScript 构建哪些应用程序/产品？

NativeScript 最适合需要利用硬件组件功能的实时应用程序或产品。它包括用于流媒体、实时馈送和简单游戏的应用程序。 

Ionic

Ionic 是一种 React Native 替代方案，可让您构建跨平台应用程序。这个开源 SDK 最初是基于 Apache Cordova 和 AngularJS 构建的。但后来，它增加了对 React、Vue.js 和 Angular 等其他 JS 框架的支持。 

优点

• 
  

  原生功能

  
  

使用 Apache Cordova 和 Capacitor 插件，Ionic 可以访问移动操作系统的相机、蓝牙、麦克风、指纹扫描仪、GPS 等功能。此外，Ionic 的 UI 组件及其内置的自适应样式通过对设计进行轻微更改来确保应用程序保持原生的感觉。 

• 
  

  跨平台体验

  
  

Ionic 利用网络标准和通用 API 为任何平台构建应用程序。有了这个，开发人员可以构建一个应用程序，然后使用一个代码库将它定制到所有支持的平台。 

• 
  

  更短的开发时间

  
  

使用 Ionic 的预构建功能，无需为每个开发构建 UI 组件。相反，开发人员可以重用或自定义每个元素，在更短的时间内构建功能性应用程序。 

缺点

• 
  

  不适合游戏应用

  
  

与大多数跨平台框架一样，Ionic 可能不适合具有高级图形的应用程序。这是因为 Ionic 使用 CSS，这在开发 3D 游戏应用程序时受到限制。在这种情况下，本地化可能是最好的选择。 

• 
  

  兼容性问题

  
  

集成的本机插件可能会相互冲突，从而产生大大减慢开发过程的问题。 

• 
  

  安全问题

  
  

开发跨平台意味着您需要同时考虑 Web 和本机移动应用程序的安全性。尽管现有解决方案可以解决此问题，但对于需要高端安全性的应用程序而言，这可能既乏味又昂贵。 

想要阅读 React Native 和 Ionic 之间的详细比较吗？阅读这篇文章

可以使用 Ionic 构建哪些应用程序/产品？

Ionic 可用于需要即时信息或类似本机功能的应用程序。这包括用于新闻、生活方式、流媒体和金融服务的应用程序。 

Apache Cordova

Apache Cordova 由 Nitobi 创建，于 2011 年被 Adobe 收购，并更名为 PhoneGap。随后，它作为 PhoneGap 的开源版本发布。Apache Cordova 使开发人员能够使用 HTML、CSS 和 JavaScript 构建移动应用程序。可以通过命令行界面 (CLI) 使用此 React Native 替代方案开发跨平台应用程序。对于接近本机的应用程序，您可以使用 Cordova 以平台为中心的工作流程。 

优点

• 
  

  丰富的插件集

  
  

开发人员在使用 Apache Cordova 进行构建时有大量插件可供选择。这些插件提供对本机设备 API 的访问，从而更轻松地在应用程序中实现广泛的功能，以获得更好的性能和用户体验。 

• 
  

  无障碍技能集

  
  

Cordova 使用的标准技术 JS、CSS 和 HTML 已经成熟。具有这些技术编程背景的移动开发人员可以快速适应构建 Apache Cordova 应用程序。易于找到开发人员、温和的学习曲线和快速的上市时间潜力是直接的好处。

• 
  

  跨平台支持

  
  

本着“一次编写，随处运行”的原则，代码可以跨平台重用。这确保了应用程序可以适应任何平台的UI。此外，无需将特定于平台的编程语言作为一个代码库来学习可以胜任。

缺点

• 
  

  特定于平台的限制

  
  

因为 Apache Cordova 应用程序不是纯原生的，它们依赖插件来利用设备的功能。这些第三方自定义插件可能不容易获得、更新或跨平台兼容。 

• 
  

  可能需要本地开发人员

  
  

如前所述，使用 Cordova 构建的应用程序可能会遇到某些插件的兼容性问题。您可能需要可以从头开始编写自定义插件的专业本机开发人员。这转化为延长的开发时间和成本。 

• 
  

  潜在的性能问题

  
  

使用 Cordova 的默认功能构建高性能应用程序可能很困难。这是因为其技术中存在的限制会减慢应用程序的速度。此类缺点在于其 WebView 和移动浏览器组件以及 JavaScript 中缺乏多线程功能。

可以使用 Apache Cordova 构建哪些应用程序/产品？

您可以使用 Cordova 开发结合本机组件和 WebView 以访问设备 API 的应用程序。它包括用于健身、运动、跟踪和市场的应用程序。 

Framework 7

Framework 7 是您应该考虑的另一个 React Native 替代方案。它是一个开源 HTML 框架，用于构建具有近乎本机功能的混合 Web 和移动应用程序。Framework 7 兼容 Android 和 iOS 平台。

优点

• 
  

  反应灵敏

  
  

从基本元素到高级元素，Framework 7 具有广泛的 UI 组件。开发人员可以访问诸如延迟加载、无限滚动、复选框列表等控件。使用这些资源构建具有干净、本机界面的动态应用程序。

• 
  

  多框架支持

  
  

Framework 7 可以与 Angular、React 和 Vue.js 等 JS 框架一起使用。这些结构为开发过程贡献了它们的力量和简单性

• 
  

  对开发者友好

  
  

开发人员不仅限于自定义标签。在使用 Framework 7 时，他们可以轻松地使用由 JS 和 CSS 补充的纯 HTML 代码。这意味着至少具有这些语言甚至 jQuery 中级知识的程序员可以扩展。 

缺点

• 
  

  有限的平台支持

  
  

目前，Framework 7 仅支持 iOS 和 Android 平台。希望为其他平台开发应用程序的开发人员可能会评估其他框架。

• 
  

  iOS 专用

  
  

Framework 7 最初是为 Apple 环境开发的。这开辟了在为 Android 开发时遇到渲染问题的可能性。

• 
  

  最少的文档

  
  

用户可以轻松找到有关如何在此框架中实现任何元素集的资源。然而，大多数高级需求可能没有现成的答案，因为文档不像其他框架那样广泛。  

Framework 7 可以构建哪些应用程序/产品？

Framework 7 可用于构建依赖于设备硬件的渐进式 Web 应用程序或 iOS 和 Android 应用程序。 

jQuery Mobile

jQuery Mobile 是一个开源 JavaScript 库，用于开发跨平台移动应用程序和网站。它利用了 jQuery 的特性，jQuery 以实现动画、AJAX 和文档对象模型 (DOM) 操作的简便性和快速性而闻名。  

优点

• 
  

  较低的学习曲线

  
  

这项技术建立在 jQuery Core 之上，大多数程序员可能已经在过去使用过它。这使得它更容易学习和使用。

• 
  

  跨平台、跨浏览器兼容性

  
  

使用 jQuery Mobile 框架，您可以构建与流行的桌面浏览器和平台兼容的高度响应的应用程序和网站。其支持的平台包括 iOS、Android、Windows、WebOS 和 Blackberry。 

• 
  

  出色的动画页面过渡效果

  
  

基于渐进式增强原理，jQuery Mobile 导航系统允许页面通过 Ajax 加载到 DOM。这确保了页面得到改进，然后以高质量的过渡显示。

• 
  

  简单方便

  
  

开发人员只需几行代码即可处理 HTML 事件、AJAX 请求和 DOM 操作。这在 JavaScript 中需要更长的行。 

• 
  

  轻量级

  
  

由于其有限的图像依赖性，jQuery Mobile 的最小大小为 40 KB。这有助于它的速度。 

缺点

• 
  

  最小主题

  
  

jQuery 移动版中可用的 CSS 主题使自定义应用程序变得容易。然而，它们是有限的。开发人员可能会构建与使用此技术构建的其他产品不同的应用程序。

• 
  

  使用其他框架非常耗时

  
  

jQuery Mobile 与 PhoneGap 等其他移动应用程序框架相结合，以获得更好的性能。但这会减慢开发过程。 

• 
  

  移动设备运行速度较慢

  
  

即使在最新的 iOS 和 Android 平台上，这项技术也明显变慢。如果您希望开发一个快速的移动应用程序，您可能需要考虑其他替代方案。

可以使用 jQuery Mobile 构建哪些应用程序/产品？

jQuery Mobile 是针对旧浏览器、内容管理系统或其他需要一些动画和较少用户交互的产品的应用程序的理想选择。 

PhoneGap

渐进式 Web 应用程序 (PWA)

渐进式 Web 应用程序是应用程序软件，可以像常规网站一样在 Web 浏览器上加载和执行。它结合了 Web 功能和本机应用程序的功能（例如推送通知和对硬件功能的访问），以提供出色的用户体验。与传统应用程序不同，PWA 无法从应用程序商店安装到设备中。相反，它可以添加为用户的主屏幕。渐进式 Web 应用程序使用 HTML、JavaScript 和 CSS 等标准 Web 技术构建。 

优点：

• 
  

  反应灵敏

  
  

PWA 可以轻松适应多种设备的屏幕尺寸，无论是平板电脑、台式机、Android 和 iOS 移动设备，还是其他直接尺寸。 

• 
  

  安全的

  
  

利用 HTTPS，在 PWA 上广播的信息被加密。在大多数情况下，如果没有安全连接，用户将无法访问某些功能，例如地理定位。这提供了高端安全性和针对路径攻击或其他网络威胁的更多保护。 

• 
  

  极具吸引力的用户体验

  
  

PWA 是使用渐进改进原则构建的。这些应用程序在符合标准的浏览器上提供更好的用户体验，在不符合标准的浏览器上至少提供可接受的界面。此外，这些应用程序通过现代网络标准提供本机应用程序功能和感觉。这些功能进一步丰富了移动体验。 

• 
  

  减少对网络的依赖

  
  

构建渐进式 Web 应用程序的最大优势之一是它们能够在连接速度缓慢的情况下运行。如果用户访问过某个站点，即使没有网络，他们也可以访问该内容。这可以通过 Service Workers、缓存 API 和离线存储站点资产的客户端存储技术实现。也就是说，PWA 利用这一点来享受更快的加载速度。 

• 
  

  易于访问和维护

  
  

作为一个基于网络的应用程序，PWA 享有更高的知名度，因为它可以被搜索引擎发现和排名，给他们更多的知名度。此外，用户无需额外安装即可轻松进行测试和升级，因为这些应用程序可以在线访问。 

缺点

• 
  

  对硬件组件的访问受限

  
  

虽然它可以访问相当多的功能，但 PWA 无法完全使用设备的大量硬件组件。对高级相机控制、通话功能、蓝牙的支持，并且某些功能在某些设备中仍然不发达。

• 
  

  弱 iOS 支持

  
  

iOS 设备中 PWA 的一个常见缺点是缺乏推送通知支持。这使得无法通过新内容或更新重新吸引 iOS 用户，从而导致转化次数减少。 

• 
  

  没有可靠的第三方控制

  
  

因为 PWA 不能从应用商店下载，所以没有监管标准。因此，其大多数类本机应用程序的 UI 质量可能不一致。 

哪些应用程序/产品可以构建为渐进式 Web 应用程序？

PWA 最适用于由于网络缓慢而易于失败的软件、需要更高流量的应用程序或很少使用的应用程序。它包括为电子商务公司、叫车服务、市场代理等提供的产品。

Bootstrap

Bootstrap 是一个结合了 Javascript、CSS 和 HTML 的工具包。它广泛用于开发响应式、移动优先的网页和完全嵌入浏览器的渐进式 Web 应用程序 (PWA)。