iOS开发高手课
戴铭
前滴滴出行技术专家
立即订阅
11464 人已学习
课程目录
已完结 46 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 锚定一个点,然后在这个点上深耕
免费
基础篇 (20讲)
01 | 建立你自己的iOS开发知识体系
02 | App 启动速度怎么做优化与监控?
03 | Auto Layout 是怎么进行自动布局的,性能如何?
04 | 项目大了人员多了,架构怎么设计更合理?
05 | 链接器:符号是怎么绑定到地址上的?
06 | App 如何通过注入动态库的方式实现极速编译调试?
07 | Clang、Infer 和 OCLint ,我们应该使用谁来做静态分析?
08 | 如何利用 Clang 为 App 提质?
09 | 无侵入的埋点方案如何实现?
10 | 包大小:如何从资源和代码层面实现全方位瘦身?
11 | 热点问题答疑(一):基础模块问题答疑
12 | iOS 崩溃千奇百怪,如何全面监控?
13 | 如何利用 RunLoop 原理去监控卡顿?
14 | 临近 OOM,如何获取详细内存分配信息,分析内存问题?
15 | 日志监控:怎样获取 App 中的全量日志?
16 | 性能监控:衡量 App 质量的那把尺
17 | 远超你想象的多线程的那些坑
18 | 怎么减少 App 电量消耗?
19 | 热点问题答疑(二):基础模块问题答疑
20 | iOS开发的最佳学习路径是什么?
应用开发篇 (12讲)
21 | 除了 Cocoa,iOS还可以用哪些 GUI 框架开发?
22 | 细说 iOS 响应式框架变迁,哪些思想可以为我所用?
23 | 如何构造酷炫的物理效果和过场动画效果?
24 | A/B 测试:验证决策效果的利器
25 | 怎样构建底层的发布和订阅事件总线?
26 | 如何提高 JSON 解析的性能?
27 | 如何用 Flexbox 思路开发?跟自动布局比,Flexbox 好在哪?
28 | 怎么应对各种富文本表现需求?
29 | 如何在 iOS 中进行面向测试驱动开发和面向行为驱动开发?
30 | 如何制定一套适合自己团队的 iOS 编码规范?
31 | iOS 开发学习资料和书单推荐
32 | 热点问题答疑(三)
原理篇 (6讲)
33 | iOS 系统内核 XNU:App 如何加载?
34 | iOS 黑魔法 Runtime Method Swizzling 背后的原理
35 | libffi:动态调用和定义 C 函数
36 | iOS 是怎么管理内存的?
37 | 如何编写 Clang 插件?
38 | 热点问题答疑(四)
原生与前端共舞 (5讲)
39 | 打通前端与原生的桥梁:JavaScriptCore 能干哪些事情?
40 | React Native、Flutter 等,这些跨端方案怎么选?
41 | 原生布局转到前端布局,开发思路有哪些转变?
42 | iOS原生、大前端和Flutter分别是怎么渲染的?
43 | 剖析使 App 具有动态化和热更新能力的方案
用户故事 (1讲)
用户故事 | 我是如何学习这个专栏的?
结束语 (1讲)
结束语 | 慢几步,深几度
iOS开发高手课
登录|注册

04 | 项目大了人员多了,架构怎么设计更合理?

戴铭 2019-03-19
你好,我是戴铭。今天,我要跟你说说怎么设计一个能够支持大型 iOS 工程的架构。
记得以前所在的团队,规模大了以后,客户端团队也被按照不同业务拆分到了不同的地方。当时,所有的代码都集中在一个仓库,团队里面一百多号人,只要有一个人提交错了,那么所有要更新代码的人都得等到修复后提交。这样一天下来,整个团队的沟通和互相等待都浪费了大量时间。同时,开发完成要进行测试时,由于代码相互耦合、归属不清,也影响到了问题排查的效率,并增加了沟通时间。
后来,我们痛定思痛,花了很大力气去进行架构整治,将业务完全解耦,将通用功能下沉,每个业务都是一个独立的 Git 仓库,每个业务都能够生成一个 Pod 库,最后再集成到一起。这样经过架构整治以后,也就没再出现过先前的窘境,开发效率也得到了极大的提升。由此可见,合理的架构是多么得重要。
其实,这并不是个例。当业务需求量和团队规模达到一定程度后,任何一款 App 都需要考虑架构设计的合理性。
而谈到架构治理,就需要将老业务、老代码按照新的架构设计模式进行重构。所以,架构重构考虑得越晚,重构起来就越困难,快速迭代的需求开发和漫长的重构之间的矛盾,如同在飞行的飞机上换引擎。及早考虑架构设计就显得尤为重要。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《iOS开发高手课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(99)

  • 五天几年
    我现在做的项目就很好的做了模块化设计,将一些常用功能抽出构建成了单独模块banner(横幅广告)、network(网络连接)、window(界面相关)、validator(响应式校验),还有一个通用基础模块,封装了一些常用工具和MVP系统架构。MVP架构和泛型一起使用,好的不要不要,哈哈哈。最厉害的是,我们的封装模块Android端和iOS端类、接口、方法一模一样,文档注释非常清晰,方便两端开发者沟通交流,更方便快速定位错误,只要一端出了问题,另一端可以快速检查测试,查找是否错误重现。
    2019-03-19
    2
    69
  • Ripper
    SOLID 原则全称:
    1. Single responsibility principle
    2. Open–closed principle
    3. Liskov substitution principle
    4. Interface segregation principle
    5. Dependency inversion principle
    2019-03-20
    17
  • 曾剑南
    老师,这里面讲到了架构方面的知识,有什么入门的资料可以推荐一下吗

    作者回复: 入门我推荐阮一峰老师的《软件架构入门》http://www.ruanyifeng.com/blog/2016/09/software-architecture.html

    2019-03-19
    11
  • Geek_麟凤来思
    对于架构我感觉这几篇很有营养
    https://casatwy.com/iosying-yong-jia-gou-tan-kai-pian.html
    iOS应用架构谈 开篇
    iOS应用架构谈 view层的组织和调用方案
    iOS应用架构谈 网络层设计方案
    iOS应用架构谈 本地持久化方案及动态部署
    iOS应用架构谈 组件化方案

    2019-03-27
    9
  • Kai
    希望能在每篇文章的最后推荐一些相关的资料阅读,这样能更好地帮助理解内容
    2019-03-21
    8
  • Sasori
    协议化的方式有两个好处,一是可以明确知道组件提供了哪些服务,二是组件一旦修改了接口会立刻引发编译错误,而CTMediator会推迟到运行时。

    作者回复: 是的,CTMediator会在运行时进行管控。其实在中间者那一层加上记录,还能够进行运行时代码覆盖率统计

    2019-03-19
    8
  • wang
    组件化架构的目的主要是解耦各个具体业务模块的耦合,而在业务模块的内部也还是需要用到像MVC、MVP、MVVM这些设计模式。 大神,我的理解是没错吧

    作者回复: 是的

    2019-03-19
    7
  • huangjianke
    CT的扩展值得一试
    2019-03-19
    7
  • 唐鹏
    之前在两个公司都用过CTMediator,个人感觉也是最好的解耦方式,虽然有硬编码的问题,但是层次结构非常清楚,十分利于维护.但是目前感觉还是router或者协议化用的比较多,router就不提了,缺点比较明显.协议化除了后面需要严格控制接口输出之外,会造成维护上的困难,另外协议如果不进行严格的判断,也容易造成崩溃问题,也需要额外的开发成本去判断.
    2019-03-19
    6
  • 9527
    希望越来越多的demo提供给大家学习呀,感谢!
    2019-03-19
    5
  • 彭序猿
    大家好,我先说下我的疑问:
    关于组件化的实现方案有协议或者中间人两种:
    1.协议解耦:Runtime+Protocol
    2.中间人解耦:Runtime+TargetAction

    我用协议来解耦的时候:
    1.我有一个管理类是作为调度层,这样子就可以方便统一调用
    2.我的 Protocol 头文件,Model 都已经沉淀到底层基础框架了,整个 App 模块默认引用了

    这里用协议来解耦,也是有一个管理类统一调度的,这种情况是不是跟中间人调用差不多了?
    跟 CTMediator 相差的就是使用 protocol 还是 TargetAction 的区别?

    在这种场景下,我觉得两种方案优劣是差不多的。
    2019-03-20
    4
  • Paul
    目前也是采用了casatwy的CTMediator组件化方案,项目采用了基础组件+功能组件+业务组件进行架构分层,根据实际业务需求合理选择设计模式,合理遵守六大原则,不要拔出萝卜带出泥
    2019-03-19
    4
  • Link
    CTMediator其实是有几个缺点的:
    1.如果因为组件找不到而产生一些error,这里虽然不会崩溃,但是调用方其实并不知道,虽然可以对CT进行一些扩展让调用方通过回调知道,这其实也有利于一些UT的编写.
    2.大量的通过字符串进行调度,实际上很硬核,后期的维护由于没有IDE能帮你做检查,其实复杂了不少.
    3.CT其实是命名域上的解耦,但我认为项目还是应该更仔细认真的去设计组件和组件间的依赖,毕竟比如你这个功能实际上比如是依赖a和b两个模块,你只导入了b,虽然能够运行,但是实际上功能是不完善的,没有什么意义
    关于戴老师说的组件只是把能通用的部分才进行组件化还是很赞同的,还有拆分的思路,和人员的搭配,目前也是这么做的,现在的swift项目,想的是就利用cocoapods加协议进行了大量的业务依赖设计,如果你需要导入这个业务模块,他会将相应的业务模块也进行导入,这样无论是类型检测还是相关业务的导入都比较方便.

    我认为CT这样的做法还是比较偷懒的.但是CT其实也能学到不少,自己仿照着写了个,主要是作为一个利用runtime消息安全发送机制.另外casa老师的将内部和外部调用区分开也很值得学习.
    2019-03-24
    3
  • drunkenMouse
    我之前参与过的项目架构,本质都是MVC。要么根据Tabbar的功能模块,分到不同的文件夹里,然后每个文件夹对应一个功能组件,第三方与也分到一个单独的文件夹,但本质上还是MVC。要么业务与业务分开的项目,其架构模式也就是各个业务负责各自的业务功能解决,每周开会确认各个业务间所需要的配合,但还是MVC。根本牵扯不到模块力度的划分、团队的合作方式就是当面或者微信聊、唯一可以谈的分层也就是对网络请求、数据库的处理、ViewController的底层封装,然后各自如何使用全看自己。。只要Bugly没有收集到崩溃、测试与产品没有页面卡顿与BUG修复等需求、美工没有页面布局的调整,就算是合格完成任务了。。。
    2019-03-20
    3
  • 今天美德华仔
    我们目前使用的是 url scheme + router ,服务器可以直接返回 url 做跳转。url 使用plist 预先配置好。大家给提点意见。
    2019-03-20
    3
  • asynclog
    协议化也可以引入统一调度层管理,维护category和protocol的区别,而且有编译检查
    2019-03-19
    3
  • 莫在一思停
    大神,我问下目前使用WKWebview的cookie丢失问题能处理吗?
    2019-03-19
    3
  • 流氓兔
    现在负责的是一个很小的项目,用的还是普通的MVC模式,是否也需要改变架构,就是说,在小型项目中(没有变成大项目的可能性),使用中间者架构会不会更麻烦了

    作者回复: 小型项目其实是可以用中间者架构的,也是为了做大做准备

    2019-03-19
    3
  • 吃蘑菇的大灰狼
    这篇讲到了痛点,但感觉还不够解渴,待我细细品味demo,期待铭神的后续😍
    2019-03-19
    3
  • 安森👣
    个人感觉 CTMediator 框架其实还是硬编码方式的,只是通过类别包装了一下,将硬编码调用这块转嫁到库者手中。当然对外是没有这个硬编码的,对内的话,该有的问题仍然存在。
    2019-04-16
    2
收起评论
99
返回
顶部