笔记|滴滴iOS客户端的架构，组件化，技术选型

笔记来源infoq：滴滴iOS客户端的架构演变之路

1，状态机，把订单中的阶段，例如：出租车的等待抢单、出租车的等待接驾、专车的等待抢单、专车的等待接驾，都当成一种独立的状态，每个状态机只需要知道可能要导向的状态机，从而做到了相对独立，状态机满足了出租车、专车双业务线的需求。
状态机是什么？简单的概括为：用一个枚举类型的变量（它通常是单例全局变量或本文件有效的静态局部变量），根据这个变量当前的状态进行对应处理。
状态机不只用在数据再加工，视图（UIView）加载和变换,页面跳转，业务线切换，也用在连续操作或处理控制。
状态机都可以画出对应的状态机切换图。在状态机切换图上，它通常都是从不稳定状态向稳定状态定向迁移，状态机都有方向性。
状态机在复杂逻辑具有很大的使用空间，看了状态机迁移图，让人一看就知道它的处理逻辑。能形象的表达复杂逻辑。
像【长篇高能】ReactiveCocoa 和 MVVM 入门这篇文章说的能替换状态机，那是它不知道状态机的真正使用范围有多广，并非它理解的仅仅是数据加工那么简单。
2，“代码治理”，可以“分而治之”的目标。

在各个业务线各自开发的情况下防止代码大面积腐化，方便未来再做更加细致的架构重构，采用CocoaPods的方式进行拆分；组件化之后，公共部分拆分为技术组件、公用业务组件，每个业务线是单独组件，如出租车组件、专车组件、快车组件；通过把不同功能的组件代码拆分到不同的 pod 里，实现了业务线仅依赖于公共就可以迭代开发，改善了功能开发和协同发版。组件化只是做了治理的第一步，后面的架构优化还任重而道远。

3，目前滴滴的 iOS 架构采用 MVCS 和 MVVM 的架构方式。MVCS 的 S 是 Store 的意思，包括服务器访问接口控制、数据共享、数据缓存的能力，每个 Store 处理一类情况，例如：订单 Store 会包括发单、取消订单、结束订单、评价订单等，常用地址 Store 会包含编辑常用地址、删除常用地址、拉取常用地址等。MVCS 这种方式的思考逻辑是希望做到组件无状态，完全依赖于 Store 所返回的各种状态信息，这种思想是非常类似于 React Native + Redux 的思路。

4，滴滴iOS客户端的组件化是如何划分的，采用什么技术实现？

我们在15年后半年实施了组件化，组件包括技术组件和业务组件，技术组件是可以跨 App 使用的，例如：网络组件（长连接和短连接）、界面导航管理组件（统一界面转场方式，模块间界面转场，通过openURL方式解耦）；根据业务功能，已经实现了支付、登录、消息、定位、广告SDK、数据统计、分享等组件，每个组件是独立的CocoaPods。

组件采用私有 CocoaPods 来实现，并采用了 Local Pods 的方式，可以在本地不提交代码的情况下，组件与调用方实现调试。组件间的页面间跳转支持 openURL 的方式，由 ONERoute 模块进行管理，页面在 +(void)load 方法中完成注册，ONERoute 内部保存一份 URL 与 Class 的对应表，当调用 openURL 时，会查找到对应的类，然后生成对应的实例对象。这种方式可以通过 URL 解耦具体的类名称，方便从 H5 拉起 Native 页面，未来还可以实现流程的可配置化。在设置页面里，还是直接依赖类的方式，避免过度使用 openURL。为了增加安全性，每个页面会设置是否允许外部打开，仅有允许外部打开的页面才可以通过系统的 openURL 方式打开。

笔记来源infoq：滴滴出行技术总监：关于技术选型的那些事儿

技术选型要谨慎。

技术选型关键需要思考三个角度：技术、业务和人。

技术

第一，要取其长避其短；第二，要关注技术的发展前景。

技术的“前景”可以从几个维度来判断，有没有长期规划、有没有持续投入的人或者社区、问题解决的速度如何、业界使用案例及口碑、源码质量。

新技术实践后的积累，有案例和背后的细节，踩的坑，和避免这些坑。

业务

新技术往往被早期创业团队或大公司的新兴业务使用

人

技术选型也非常依赖于人的能力。选型是一件很难被标准化的过程，选型的决策质量跟人的眼界、经验、业务敏感度、逻辑性等息息相关。就我自己来说，我在面临一个选型问题时首先考虑的是去学习，看看公司内外类似的问题如何解决的，避免自己闭门造车，然后思考所有的可能性，列举最核心需要考虑的因素，心里列一个方案优劣对比，最后将这些逻辑整理清楚，落地成一个决策。

想做好技术选型还是挺难的，要想做好得有足够的知识积累和实际踩坑的经历才行。

如何学习

最后难在信息究竟如何存入知识索引，知识太零散形成不了体系，建不了索引怎么办。最入门的做法是看书，看别人是怎么将知识变成一个个章节的信息。要想掌握建立索引背后的方法论，我的经验是先从两个相近的技术开始，找到建索引的感觉，然后再铺开去学习更多知识。有这样困惑的开发者往往在学习方面有些贪心，觉得自己记性好可以囫囵吞枣式的将知识强行内化，这样做短期可以，长期还是会遗忘，也形成不了经验。

其实技术知识之间非常像，有很多共性的点可以挖掘。比如客户端和前端开发，各个框架在 View 生命周期管理、消息派发机制等方面非常像，后端开发则更加的套路化，无论用那种语言，最基本的分布式服务原理、缓存、队列、数据库等基础组件原理，都万变不离其宗。

如果我们更宏观的看每个领域，甚至于都能发现领域之间的知识体系划分也很类似。作为表现层的前端和客户端，知识体系都可以分为语言、API、工程化、框架和设计模式。比如前端的语言包括 HTML、CSS、Java 和一些稍小众的 Type、Coffee 等，API 就是各种标准、接口的使用、能够实现的效果、平台限制等，工程化就是各种打包工具、代码转化工具、辅助开发工具等，框架就是像 Vue、React 等，设计模式就是像 PWA、redux 等。

相应的，刚刚说的这些知识都能找到在 iOS 或 Android 里几乎对应的知识，无非换了一些细节，这里我就不继续展开了。服务端也是这样，知识体系最顶层的部分也很少，具体到细节，只是要了解每一个实现背后的优劣。

我在创业阶段，每一年写十万行代码。但我进入滴滴后，写代码的价值可能就不是那么多了，但我还是喜欢写代码。

笔记|滴滴iOS客户端的架构，组件化，技术选型相关推荐

58 同城 iOS 客户端搜索模块组件化实践
[编者按]58 同城 App 自从 1.0 版本开始,便已经提供了搜索功能.随着版本的迭代.业务的复杂,搜索框架也在不断受到挑战.诸如代码不能复用.耦合度高.业务功能接入成本高等问题日积月累,成为需要 ...
iOS架构-组件化入门（1）
iOS架构组件化 https://www.jianshu.com/p/2d89f55fc2c4 iOS架构组件化此篇为iOS组件化研究的基础篇,主要是一些组件化的认识,以及益处,必要性. 1.手机淘宝 ...
阿里曾文旌：Greenplum和Hadoop对比，架构解析及技术选型-CSDN公开课-专题视频课程...
阿里曾文旌:Greenplum和Hadoop对比,架构解析及技术选型-6397人已学习课程介绍本主题通过介绍 Greenplum 架构实现,及其亮点特性,辅之对比传统关系型数据库, ...
安卓开发fragment之间的切换_Android开发必会的组件化技术—Android架构和提升必备...
很多时候我们开发的时候,都需要新建项目,然后一个个底层模块去写,比如各种常见View,工具类,缓存模块等,经常进行这种重复的搬砖工作.主要还是因为我们在平时的开发过程中就没有注意分层.分模块.资源随意 ...
iOS 基于CTMediator的组件化方案
目录 1.创建私有 Spec Repo 2.新建工程(New Project) 3.你需要创建podspec文件 4.设置podspec文件 5.创建提交update.sh脚本 6.CTMediato ...
iOS架构-组件化（Carthage管理工具）
一.Carthage项目管理工具使用? Step 1:安装/更新Homebrew工具 1./usr/bin/ruby -e "$(curl -fsSL https://raw.githubu ...
宜人贷-iOS客户端组件化介绍
文章简介: 本文将从三个方面讲解我们组件化项目.第一部分,我们将介绍组件化的意义和业内组件化的进程:第二方面我们将具体介绍组件化所使用的技术,以及组件化过程中所面对的问题:而第三方面,我们会展示我们组 ...
蘑菇街、滴滴、淘宝、微信的组件化架构解析，附Demo和PDF
前段时间公司项目打算重构,准确来说应该是按之前的产品逻辑重写一个项目?.在重构项目之前涉及到架构选型的问题,我和组里小伙伴一起研究了一下组件化架构,打算将项目重构为组件化架构.当然不是直接拿来照搬,还 ...
iOS开发之组件化架构漫谈
前段时间公司项目打算重构,准确来说应该是按之前的产品逻辑重写一个项目.在重构项目之前涉及到架构选型的问题,我和组里小伙伴一起研究了一下组件化架构,打算将项目重构为组件化架构.当然不是直接拿来照搬,还是 ...

笔记|滴滴iOS客户端的架构，组件化，技术选型

笔记|滴滴iOS客户端的架构，组件化，技术选型相关推荐

最新文章

热门文章