尝试学习RxSwift已经是很久之前的事情了，今年通过掘金的活动才基本落地。
之前版本的README写的乱七八糟的，一直想找个机会重新整理一下。
拖拖拉拉的一直推迟到现在，真是不好意思。
这是我第一个Swift的MVVM项目，依旧通过WanAndroid开放API制作。
我已经写了Flutter和uni-app版本，所以Swift版本更看重是对逻辑与RxSwift的理解。
曾经的我更看重在单个UI页面上的编写与实现，现在经常想的是这个有没有现成的轮子可以，更偏向于思路与思考。我不是说UI不需要思考，如果有好用的轮子何乐而不为呢？
欢迎大家star、pr和一起讨论！！！
感谢大家的厚爱，有很多同学反馈提出了Xcode的编译问题，这里统一回复一下，这个项目目前在持续迭代，虽然可能没有太多的功能变化，目前是使用Xcode14，并且使用了部分Swif5.7的简化语法，if let与guard let，所以还请编译有异常的朋友升级Xcode或者自己处理一下。
 |
 |
 |
 |
|---|---|---|---|
 |
 |
 |
 |
- 首页、项目、公众号、体系、我的，五大模块
- 登录注册功能
- 搜索功能：热门搜索、输入搜索
- 文章列表，普通的TableView布局
- Tab切换功能
- 自动轮播图
- MJRefresh的下拉刷新，无感知上拉加载更多
- RxMoya的使用，Moya插件的使用
- RxSwift、RxCocoa的响应式编程，ViewModel的绑定
- 适配iOS 16，Swift语法更新到5.7
- 适配黑暗模式
- 常用扩展封装
- 详细的注释与思考过程
target 'RxStudy' do
# Comment the next line if you're not using Swift and don't want to use dynamic frameworks
use_frameworks!
# Rx Core
pod 'RxSwift'
pod 'RxCocoa'
# Rx Extensions
pod 'RxDataSources'
pod 'NSObject+Rx'
# 在BaseViewController中有尝试使用,对于添加手势与调用会更加简单
pod 'RxGesture'
# 本质上是将异步操作转换为同步操作,这样使得测试代码更简单,
# 我在Moya转模型中进行了分类编写,可以直接转为可以使用的Result类型,同时BlockingObservable的注释也说了,它用于测试与演示,并不适合用于App的生产环境,当你在程序逻辑中使用BlockingObservable,也许是该反省自己写的代码逻辑的时候了
pod 'RxBlocking'
# 可以做主题优化,但是现在基本上适配黑暗模式即可,尝试做了全局主题,但是我想的太简单了
pod 'RxTheme'
# 对序列的操作符的扩充,让序列从一种类型转换到另一种类型变得更加快捷 https://github.com/RxSwiftCommunity/RxSwiftExt
# 使用subscribeNext(weak:...)这个方法来避免循环引用,详细可以见HotKeyController,同时_ onNext: @escaping (Object) -> (Element) -> Void 这种并不是特别好理解, 可以理解为 (Object) -> ((Element) -> Void),闭包嵌套闭包的写法
pod 'RxSwiftExt'
# Networking
pod 'Moya/RxSwift'
# AlamofireNetworkActivityLogger的版本很久都没有升级,导致其绑定Alamofire无法升级,直接移除拖入,保证Alamofire和Moya可以向上升级
#pod 'AlamofireNetworkActivityLogger'
# Image
pod 'Kingfisher'
# R函数
pod 'R.swift'
# UI
pod 'DZNEmptyDataSet'
pod 'AcknowList'
pod 'MJRefresh'
pod 'FSPagerView'
pod 'JXSegmentedView'
pod 'MarqueeLabel'
pod 'SVProgressHUD'
# 被SVProgressHUD替代了
pod 'MBProgressHUD'
# SFSymbols的安全引用
pod 'SFSafeSymbols', '~> 2.1.3'
# Keyboard
pod 'IQKeyboardManagerSwift'
# Auto Layout
pod 'SnapKit'
# Combine 学习
pod 'Moya/Combine'
pod 'CombineExt'
pod 'CombineCocoa'
# 调试
pod 'LookinServer', :configurations => ['Debug']
pod 'CocoaDebug', :configurations => ['Debug']
pod "SwiftPrettyPrint", "~> 1.2.0", :configuration => "Debug"
# 注意,以下是没有使用的库
# Rx Extensions
pod 'RxViewController'
pod 'RxOptional'
# Date
pod 'SwiftDate'
# Keychain
pod 'KeychainAccess'
end之前跑去学了Flutter和简单的Vue入门。
说实话Vue的学习成本是最低的，因为它的MVVM框架开箱即用，你不需要做太多的操作，也非常容易理解。
Flutter的学习曲线稍微难一点，但是学会了Provider之后，基本上MVVM的思想也上路了。
反观RxSwift的学习曲线真的是陡峭啊，虽然我理解Oberveral其实就是异步的stream，但是使用起来的时候还是一脸懵逼，偶尔想要使用绑定，还需要自己做Rx的扩展，需要理解大量非原生的API，成本非常的高。
你说为啥不直接上Combine，我只是想说，RxSwift学了，理解Combine还会难么？
SwiftUI+Combine联合起来才能展现威力，不过在苹果这一侧，成熟好用的响应式和状态管理都还没有出世。
而RxSwift系列的一些框架已经在向大前端的实现了，可惜对原生的支持不够好的，学习成本也太高了。
因为RxSwift的响应式学习，鼓起勇气学习了GetX，重构了Flutter版wanandroid客户端。也希望大家喜欢和支持。
详细可以看SwiftUIExample这个文件夹的内容,我已经编写了SwiftUI的积分排名页面,包括上下拉,网络请求,异常等处理. 可以说,基本上通过这个页面,CoinRankListPage可以看到交互->数据请求->数据驱动页面等一系列操作.
如果下面这个FuckingSwiftUI都看懂了,基本上SwiftUI布局基本上明白. 我目前是按照Flutter的思路在写SwiftUI的布局,但是其实很多细节还是不明白.
下拉与上拉
轮播
我在这个项目的module分支上面进行了简单的组件化尝试。
所有的pod目前都是进行的本地化管理，也是放在当前项目下的DevelopmentPods文件夹下面。
我之前很天真的以为自己写的代码很好解耦，应该一会就可以进行组件化，但是当我尝试拆解HttpRequest的时候就吃瘪了。
我发现，我的HttpRequest中使用了Moya的插件，到请求开始与结束的使用了蒙层的loading与dismiss，于是乎，我优先去组件化了HUD。
然后我的HttpRequest要先去依赖HUD才能进行正常的组件化与编译，结果发现HttpRequest实际上和登录状态也是有关联的，在wanandroid的API中，登录和未登录在有几个API里面的请求头是有差别的，登录后不将数据塞入请求头是拿不到数据的，于是乎就在我考虑是将AccountManager独立作为个组件还是放在HttpRequest里面，纠结了半天，然后还是考虑封装的网络请求层其实也算是业务层了，我个人理解Moya已经算是纯粹的网络请求层了，于是乎AccountManager和HttpRequest就放在一起了。
没有组件化之前，虽然我也知道public修饰的重要性，结果进行组件化后，才更能理解，小心慎重的时候这些修饰符是多么的重要。
如果大家有兴趣，可以切到module分支上面去看看。