笔记来源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 里几乎对应的知识，无非换了一些细节，这里我就不继续展开了。服务端也是这样，知识体系最顶层的部分也很少，具体到细节，只是要了解每一个实现背后的优劣。
我在创业阶段，每一年写十万行代码。但我进入滴滴后，写代码的价值可能就不是那么多了，但我还是喜欢写代码。