ios开发整理

iOS组件化方案调研

2018-03-07  本文已影响56人  iOS雯Ping

一.1.什么是组件化

指旨在让用户自由组合原生页面表现,令APP页面布局版式更加多样和个性化。通过对组件的搭配使用,您可以将列表化组件(幻灯片、左右图、大图加文字、混合)、菜单化组件和Native SDK化组件随意组合到同一个界面中形成DIY个性聚合首页和列表页。

2.什么是组件

组件(Component)是对数据和方法的简单封装。C++ Builder中,一个组件就是一个从TComponent派生出来的特定对象。组件可以有自己的属性和方法。属性是组件数据的简单访问者。方法则是组件的一些简单而可见的功能。使用组件可以实现拖放式编程、快速的属性处理以及真正的面向对象的设计。VCL和CLX组件是C++ Builder系统的核心。

组件分为List UI组件和Native SDK组件两种,您可以点击右上角蓝色按钮【新增组件】找到它们,两者的使用方法相同。

3.组件的使用:

根据用户设置需求,平台添加了“幻灯片”、“左右图”、“大图加文字”、“混合”四种列表组件类型。

1.    组件库——新增组件

创建您所需要的组件类型

点击高级设置可以对组件的列表项,标题,扩展字段等进行设置。

2.    模块设置——当前模块类型——组件设置

上述设置完成后,请点击【去模块设置】,因为只有当您在相应栏目的【模块类型】中,选择 “DIY组件”、“左右图”、“大图加文字”、“混合”三种模块类型时,组件设置才成立,否则即为无效。

DIY:

其他:

3.    内容——权重 1、组件化是为了解决什么问题?

一个 APP 有多个模块,模块之间会通信,互相调用,如我们的证券app,有首页、行情、资讯、我的等模块。这些模块会互相调用,例如 首页底部需要展示部分资讯、行情;行情底部需要展示个股资讯;资讯详情页需要跳转到行情,等等。

一般我们是怎样调用呢,以首页调用资讯为例,会这样写:

问题1.业务方的开发效率不够高(只关心自己的组件,却要编译整个项目,与其他不相干的代码糅合在一起)

问题2.多人同时开发时,容易出现冲突(尤其是Xcode Project文件)

问题3.每个模块都离不开其他模块,互相依赖粘在一起成为一坨:

描述组件化有哪些好处:数据和方法的简单封装

二.什么情况下进行组件化比较合适?

当然组件化也有它的缺点:

学习成本高,对于开发人员对各种工具的掌握要求也比较高,对于新手来说入门较为困难。

由于工具和流程的复杂化,导致团队之间协作的成本变高,某些情况下可能会导致开发效率下降。

当项目App处于起步阶段、各个需求模块趋于成熟稳定的过程中,组件化也许并没有那么迫切,甚至考虑组件化的架构可能会影响开发效率和需求迭代。

而当项目迭代到一定时期之后,便会出现一些相对独立的业务功能模块,而团队的规模也会随着项目迭代逐渐增长,这便是中小型应用考虑组件化的时机了。这时为了更好的分工协作,团队安排团队成员各自维护一个相对独立的业务组件是比较常见的做法。

在这时这个时候来引入组件化方案,是比较合适的时机。长远来看,组件化带来的好处是远远大于坏处的,特别是随着项目的规模增大,这种好处会变得越来越明显

三、如何组件化?

组件化的开展需要解决以下几个层次的问题:

1、组件化的架构目标?

借用Limboy的图:

2、如何划分组件?

基础功能组件

基础产品组件

个性化业务组件

对于一个没有实施过组件化拆分的工程来说,其中很可能充满了大量不合理的类、方法、头文件和各种错乱的依赖关系,因此首先要进行的第一步是模块拆分。

模块拆分可以分成两个部分,基础模块拆分和业务模块拆分。基础模块通常是稳定的依赖代码,业务模块是涉及到业务的需要频繁改动的代码。

(1).基础模块拆分:

基础模块是任何一个App都需要用到的,如:性能统计、Networking、Patch、网络诊断、数据存储模块。对于基础模块来说,其本身应该是自洽的,即可以单独编译或者几个模块合在一起可以单独编译。所有的依赖关系都应该是业务模块指向基础模块的。

基础模块之间尽量避免产生横向依赖。

(2).业务模块拆分

对于业务模块来说,考虑到旧有代码可能没有相关的横向解耦策略,业务模块之间的依赖会非常复杂,难以单独进行拆分,因此我们采用的方法是首先从 group 角度进行重新整理。

对业务量很大的工程来说,我个人更加推荐“业务-分层”这样的结构,而不是“分层-业务”,即类似下面的 group 结构:

而非目前项目中采用的:

3、组件化的技术难点?

组件化的实施,直观上看,只是需要将各业务组件的代码放到各自的文件夹或者 jar包里就行了。

这里引出的是:

(1)、组件的拆分方式问题:

可以利用CocoaPods 配合 git 做代码版本管理,独立业务模块单独成库。

但这仅仅是物理上拆分了,拆分后的代码编译是肯定通不过的,因为如下:

MainViewController 会找不到依赖的其它各个模块的头文件而报错。这里引出的又是另一个问题:

(2)、组件间如何解耦?

组件间解耦,是组件化必须解决的一个问题。换句话说,就是如何解除业务模块间的横向依赖。还是拿上边举得例子来说:

App的根视图MainViewController需要管理首页、新闻、我的等等页面时,如何做到MainViewController中,不用去import这一大堆XXViewController?

很简单,按软件工程的思路,下意识就会加一个中间层Mediator:

这样一来,各个模块直接都不需要再互相依赖,而是仅需要依赖 Mediator 层即可。

可直观上看,这样做并没有什么好处,依赖关系并没有解除,Mediator 依赖了所有模块,而调用者又依赖 Mediator,最后还是一坨互相依赖,跟原来没有 Mediator 的方案相比除了更麻烦点其他没区别。

我们希望最终能过实现的是单向的依赖,即:

(3)、对此,可以参考业内的流行方案:

基于 URL Router、ModuleManager

代表:蘑菇街 Limboy

基于 Target-Action、Runtime、Category

代表:安居客 casa

具体实现方案较为抽象,这里暂时先不详细展开论述,可以参见Demo:

Demo1 基于 Target-Action

Demo2 基于 URL Router

此篇文章有参照作者:yehot

链接:https://www.jianshu.com/p/34f23b694412

來源:简书

著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

今天小编给大家的分享就到这吧!有收获,或者喜欢小编的可以关注小编同时也欢迎大家加入小编的iOS开发技术交流群 493025485 ,大家一起交流成长!!

上一篇下一篇

猜你喜欢

热点阅读