iOS APP产品流水线----- 模块化开发及组件化模块化的讨论（解耦、面向接口调用、面向页面调用、封装SDK）

多少年前，我有一个梦想：让世界充满漂亮小妹。。不！让世界充满便捷！

作为一个程序猴，我是多么想只要在屏幕上滑动手指拖动控件和功能代码包，就可以组装出一个NB APP，成为开发效率极高的窜天猴！

虽然没有实现，但是代码编程还是要向这个方向发展，也一定会向这个方向发展，这就是所谓的“开发平民化”、“开发0门槛化“！

（题外话：机器编程在未来一定会成为主流，而其核心就是 “ 独立的代码功能块” 集群。往深点开发，配上手脚，这就是一个可以实现主人愿望的机器人了，但是区别于深度学习型机器人。

什么，啥是集群？

举个栗子?：现在的无人驾驶汽车依赖于高速网，这就是为啥5G NB。但是一旦断网，汽车计算机就必须在单机模式下行驶到安全区。NB变草鸡。。。

这就有了两种模式：联网模式和单机模式

单机模式：依赖于自己存储区的嵌入式代码，好比单机游戏。

联网模式：有集群模式和分布模式。好比联网的游戏。

参考链接：https://www.cnblogs.com/xingxia/articles/distribution_concentration.html

机器编程发展方向：你只需要输入需求，计算机会根据需求来搜寻并组装代码块，完成你的项目）

-------------------------- 回到主题分隔线 ------------------------------

扯远了，让我们回到主题！要走这条YY出的康庄大道，方向是什么呢？呵呵呵，这就到了我们的主题：模块化开发

1 什么是模块化开发？

把单一功能进行封装，使其成为易用的可复制型代码，只要暴露的接口OK，写好文档就OK。

其耦合性低，方便解耦处理，如：项目A到项目B有相同的功能区，就可以直接拿过去用，不用重复造轮子。

当然，每个公司都自己的代码库，公司前辈们已经做好的那些带接口的代码块就可以理解成一个所谓的功能单元模块了。

再次当然，每个人也都有自己的代码库，这个就有个人特色一些了。

大伙在看Java或者其他编程语言源码的时候，会发现一个封装好的功能有很多的接口，而且做了很详细的说明与实例讲解。

模块化开发，说细了就是要做到如底层代码一样，不过形式上更像一些小型的、方便易用的SDK。

2 怎么实现模块解耦？

解耦要有自己的指导原则，就像八路军的指导原则是跟党走一样。

*模块功能单一化

一个模块实现了多个功能固然好用，但是，一旦出bug，代码纠错花费的时间和精力都是惊人的！在下作为一个搞过软件测试的人，告诫各位一句：多个功能一时爽，一旦出错火葬场！

举例：难用的一批的微信支付和百度地图，功能倒是多种多样，但是很不人性。

由于其功能多样，接口复杂，在程序出错时，你只能一个个的去排查，但是，排查的很多功能都是你用不到的！

*越底层的模块，应该越稳定，越抽象(具有普适性)，越具有高复用度。

底层基础决定上层建筑。越是底层的SDK，就应该越稳定，不要总是改来改去。

什么是底层模块？

底层模块包含了总体功能的具体实现方法，也就是说将总体模块功能解体，分在各个模块中实现，上层模块调用底层模块。

什么是抽象？

我理解的是考虑到适配各种机型，各种调用情况，具有广泛适用性。比如多版本APP，不同种类APP，在不同手机系统上都可以调用它，不存在排异性。俗称：全民老公！

怎么算是稳定？

稳定的最直观表现就是API很久都不用变化，所有的变化因子不要暴露出来，避免传递给依赖它的模块。但是要做到设计一套API且很久都不用改变，那么就需要设计的时候抽象化, 即需要我们有抽象总结的能力。

稳定性 还有一个特点就是会传递，比如 B 模块依赖了 A 模块，如果 B 模块很稳定，但是 A 模块不稳定，那么B模块也会变的不稳定了，因此下一个原则：

*提升模块的复用度，自完备性有时候要优于代码复用

什么是自完备性，就是尽可能的依赖少的模块来达到代码可复用。

举个例子，我有个模块 Utils 里面放了大量的category工具方法等，在日常UI产品开发中，依赖这个Utils会很方便，但是我现在要写一个比较基础的模块，应该就要求复用度更高一些，这个时候需要用到Utils里面的几个方法，那这个时候还适合直接依赖Utils吗，当然不合适了，这与我们上面的设计原则相悖了啊，因此我们这时候为了这个模块的自完备性，就可以重新实现下这几个方法，而不是依赖Utils模块。

(注意:

- 按照你架构的层数从上到下依赖，不要出现下层模块依赖上层模块的现象业务模块之间也尽量不要耦合；

- 自完备性和功能单一性有时候会相互矛盾，一个模块功能太多和不完善都不是好事，需要自己掌握一个度）

3 面向接口调用

什么是接口？

接口的特征为：只声明方法，不实现方法。简单来说，接口是某些行为的抽象表达，也是一组协议或约定，我们不关心某个具体类，而只关心这个类是否遵守并实现了这些约定。

就像Java 源码：我们平时调用的方法其实很多就是调用的功能接口，这些个接口给你注明了各个参数和调用的方法。

开发APP的时候，我们发现无论如何解耦，模块间总是有一些耦合，比如页面跳转啊，数据传递啊，这就好比你想在街上裸奔，却总有一撮毛挡住了你的胴体，当然是指你的头发。想彻底摆脱这些束缚，你就需要面向接口调用了。

因为只要直接引用代码就会有依赖。比如

所以我们可以实现一个 getSomeDataFromB 的接口，让 A 只依赖这个接口，而 B 来实现这个接口，这样就实现了 A 与 B 的解耦。

这样就可以实现了即满足了模块之间调用，也实现了解耦。

至于其优缺点，引用一位同行的总结：

优点：接口可以非常灵活的定义函数和回调等

缺点：

*接口文件需要放在一个模块以供依赖。（这个不明白他说的是啥）

*使用麻烦，每个调用都需要一个service,对一些普适性情况不适用，比如页面统一跳转。

其实我觉得面向接口调用并不适合用来快速开发，在编写代码的前期这项工作会非常耗费你的时间。但是如果你想拥有个人代码库，或者你们公司眼光长远，知道造工具才能干更多的活计，那你应该坚持这种编程模式。

4 面向页面调用:

面向接口调用的缺点导致并不能满足所有的需求，也解耦的不够彻底，那么终极手段就是通过定义一套协议来实现模块间的通信，协议现成的，那就是 “URL跳转协议”，基本满足需要，简单易上手，基本上现在很多的App架构里面都会有“统一跳转” 这一套东西的，这个不光是对模块解耦有帮助，对于统一化运营都是有极好的帮助的，比如app里面的任何页面，或者任何操作都是通过一个URL来唤起的话，这样是不是就把各个复杂的业务之间解耦了呢，通信都使用URL。

关于页面跳转可以参考 https://blog.csdn.net/weixin_33832340/article/details/87474026

（这类似于平常我们用到的 APP之间的跳转，比如微信，你可以通过它暴露的接口直接跳转到聊天页面；你也可以在队列里面设置自己APP的属性来供他人调起只要注册好就OK。但是2018年苹果禁止了很多直接的跳转页面：比如蓝牙、WiFi。估计是因为越狱后苹果手机使用风险加大，所以这些年陆续关闭了很多功能，强行会因风险大被拒。也就是说包含prefs:root以及App-Prefs:root的代码得全部删除，在info.plist文件中的prefs和App-Prefs的URLSchemes配置也要删掉。统一使用UIApplicationOpenSettingURLString，会跳转到对应app的设置页。）

异议：（蘑菇街APP在模块通信和跳转方案中，使用了URL作为key，用openURL的形式调用模块。首先，URL的可读性很差，而且在OC编程中，openURL常作为App之间的跨进程调用形式，如果作为App内部模块间调用用途，则会让用户感觉很奇怪。关于蘑菇街的方案，在其他博客里面也有很多的异议，参考链接在底部）

5 封装SDK

本来想讲一讲的，后来发现一哥们讲的特别细致特别好，总之就是好！我就把他的帖子奉献给大伙。绝对不是因为我写累了想去撩妹子的原因！！！

参考链接：https://www.jianshu.com/p/b91f6d297543

6 模块化的优缺点：

优点：

1、不只提高了代码的复用度，还可以实现真正的功能复用，比如同样的功能模块如果实现了自完备性，可以在多个app中复用

2、业务隔离，跨团队开发代码控制和版本风险控制的实现

3、模块化对代码的封装性、合理性都有一定的要求，提升开发同学的设计能力。

缺点：

1、入门门槛较高，新手入门需要的成本也更高

2、工具的使用成本，团队间和模块间的配合成本升高，开发效率短期会降低。

3、大型SDK，多功能模块的纠错成本高

（模块化看起来是降低了编程的复杂程度及APP开发的成本和时间，但是，却在一定程度上提高了代码的复杂程度。

这就在一定程度上带来了问题：在APP出现Bug的时候，代码的纠错复查范围会更大，举例：假如一个封装好的SDK有A、B、C三个功能，你只用到了其中的A、B两个，那么当该处代码出现问题的时候，你需要复查所有的相关代码区，C功能的代码区由于和AB区有关联，你也需要复查。但是，我们用的时候往往只会重点看实际应用到的功能的代码部分，这就会忽略隐藏的风险。）

不过，从长期的影响来说，模块化带来的好处远大于坏处，因此其仍然是最佳的架构选择。

参考链接：https://blog.cnbluebox.com/blog/2015/11/28/module-and-decoupling/

---------------------------被识破后的补偿-------------------------

7 练习与干货：

好吧第5步我确实偷懒了，没有写出个人观点，当然是因为肚子痛没写啦，绝对不是：因懒生累想撩妹，被人发现急补位。。。为了补偿大家，我决定把我想要收费的项目公开给大家，聊表心意。。。

链接：

---------------------最新： 8 关于组件化和模块化的探究------------------

最近浏览到一位骚年的帖子，有些感悟，特来更贴。

该贴中探究了啥是组件化，什么是模块化。个人认为颇有道理，but,我们如果纠结于一个功能区到底是叫组件还是叫模块就有些玩文字游戏，钻牛角尖了，毕竟我天朝文化博大精深，一个词可能代表不同的意思。

如果非要规定叫什么，我们可以按照功能应用范围来划分，统一把这些叫做四种模块。

小模块:单个功能模块，所谓的组件等都可以归为这一类

特点：解决某个问题-----功能单一，体量小，接口简单

中模块：如百度地图、支付宝微信支付等SDK，或者你们做的单个业务的功能模块。

特点：解决某块的问题------功能全面，里面可能集成了很多的小模块

大模块：集成了其他的APP，可直接叫做“XXAPP模块”。比如：淘宝集成了其他的APP（天猫、飞猪旅行等），那么该模块就可以直接叫做天猫模块、飞猪旅行模块。

特点：解决某方面问题-----这些模块中可能又有很多的中型模块，或者其他小模块。

超大模块：APP类移动端模块、PC类电脑端模块、服务器类模块

特点：解决某类问题----一个公司就可以由这些模块的开发人员组成，这已经跳出了技术范畴，直接指向一个行业了。

参考链接：https://blog.csdn.net/u013378438/article/details/85702346

iOS APP产品流水线----- 模块化开发及组件化模块化的讨论（解耦、面向接口调用、面向页面调用、封装SDK）相关推荐

模块化开发，组件化开发定义及其区别
组件化: 小型组件组成中型组件,中型组件组成大型组件.在整个系统的代码层次上位于最底层,被其他代码所依赖,所以说组件化是纵向分层. 组件化是指一个一个的功能,一个组件包含html,css,js,简单来 ...
iOS开发之组件化架构漫谈
前段时间公司项目打算重构,准确来说应该是按之前的产品逻辑重写一个项目.在重构项目之前涉及到架构选型的问题,我和组里小伙伴一起研究了一下组件化架构,打算将项目重构为组件化架构.当然不是直接拿来照搬,还是 ...
App 组件化/模块化之路——如何封装网络请求框架
App 组件化/模块化之路--如何封装网络请求框架在 App 开发中网络请求是每个开发者必备的开发库,也出现了许多优秀开源的网络请求库.例如 okhttp retrofit android-asyn ...
Android 基于注解IOC组件化/模块化的架构实践
当前参与的项目历史也很久远,第一行代码据说是写于2014年的某一天,那时Android用的ide还是Eclipse.那时Android还没有很好的架构指导(mvp.mvvm).那时Android最新的 ...
大型Android项目架构：基于组件化+模块化+Kotlin+协程+Flow+Retrofit+Jetpack+MVVM架构实现WanAndroid客户端
前言:苟有恒,何必三更眠五更起:最无益,莫过一日曝十日寒. 前言之前一直想写个 WanAndroid 项目来巩固自己对 Kotlin+Jetpack+协程等知识的学习,但是一直没有时间.这里重新行 ...
Node.js模块化开发||Node.js中模块化开发规范
JavaScript开发弊端 a.js b.js JavaScript在使用时存在两大问题,文件依赖和命名冲突. 生活中的模块化开发软件中的模块化开发 app.j user.一个功能就是一个模块,多 ...
单独组件_iOS组件化/模块化的方案总结
一.为什么要组件化 1.实现之间解耦.减少项目的编译时间,提升业务开发效率. 通常一个工程中会有多个模块,而模块之间会有依赖关系,比如A调用B,那么在A模块中就会引用B模块的头文件,同时可能B模块又会 ...
前端开发中组件化的优点
前端开发中组件化的优点解耦的思想,函数封装到组件内部执行模块化,代码清晰,易于维护,迭代更新复用性高屏蔽逻辑,可以迅速定位问题
iOS应用组件化/模块化探究
组件化是近几年流行起的概念,它是当代码扩张到一定程度时,所采取的一种代码组织架构策略.阿里.蘑菇街等大厂也在近几年陆续完成了其代码组件化的过程. 提到组件化,给人的感觉似乎很高大上,很神秘的感觉.但是 ...
android pod 组件化_使用 Pod 实现私有模块化管理（组件化 Pods 实现方案）
概况众所周知组件化是个好东西,它把项目拆分成多个模块,让每个模块能够独立出来解除各个模块之间的耦合性,作为每个独立的模块不仅仅能够使用组合的方式去组建各个不同的功能组合(前提是各个组件划分的颗粒度只 ...

iOS APP产品流水线----- 模块化开发及组件化模块化的讨论（解耦、面向接口调用、面向页面调用、封装SDK）

iOS APP产品流水线----- 模块化开发及组件化模块化的讨论（解耦、面向接口调用、面向页面调用、封装SDK）相关推荐

最新文章

热门文章