简述CTMediator   CTMediator按照功能的结构来讲,使用时需要实现CTMediator的个三部分. 1.CTMediator类:承担总枢纽,总调度的责任 2.Target_(ModuleName)类:承担组件对外暴漏接口功能,组件要提供什么服务,主要在它的接口声明上进行体现 3.CTMediator+(ModuleName)分类:主要供客户端使用,里面声明了可以调用的组件接口. 下面详细讲解   Part1: CTMediator核心功能实现: CTMediator主要采用ta…
Lightning Web Components 是一个轻量,快速,企业级别的web 组件化解决方案,官方网站也提供了很全的文档 对于我们学习使用还是很方便的,同时我们也可以方便的学习了解salesforce 在web 组件化中的实践 参考资料 https://lwc.dev/guide/introduction https://github.com/salesforce/lwc…
1. 认识组件化 1.1 什么是组件化 人面对复杂问题的处理方式 任何一个人处理信息的逻辑能力都是有限的,所以当面对一个非常复杂的问题时我们不太可能一次性搞定一大堆的内容. 但是我们人有一种天生的能力就是将问题进行拆解.如果将一个复杂的问题拆分成很多个可以处理的小问题再将其放在整体当中,你会发现大的问题也会迎刃而解. 组件化也是类似的思想 如果我们将一个页面中所有的处理逻辑全部放在一起,处理起来就会变得非常复杂,而且不利于后续的管理以及扩展. 但如果我们将一个页面拆分成一个个小的功能块,每个功能…
转载: iOS应用架构谈 组件化方案 简述 前几天的一个晚上在infoQ的微信群里,来自蘑菇街的Limboy做了一个分享,讲了蘑菇街的组件化之路.我不认为这条组件化之路蘑菇街走对了.分享后我私聊了Limboy,Limboy似乎也明白了问题所在,我答应他我会把我的方案写成文章,于是这篇文章就出来了. 另外,按道理说组件化方案也属于iOS应用架构谈的一部分,但是当初构思架构谈时,我没打算写组件化方案,因为我忘了还有这回事儿...后来写到view的时候才想起来,所以在view的那篇文章最后补了一点内容…
原文 前言 随着用户的需求越来越多,对App的用户体验也变的要求越来越高.为了更好的应对各种需求,开发人员从软件工程的角度,将App架构由原来简单的MVC变成MVVM,VIPER等复杂架构.更换适合业务的架构,是为了后期能更好的维护项目. 但是用户依旧不满意,继续对开发人员提出了更多更高的要求,不仅需要高质量的用户体验,还要求快速迭代,最好一天出一个新功能,而且用户还要求不更新就能体验到新功能.为了满足用户需求,于是开发人员就用H5,ReactNative,Weex等技术对已有的项目进行改造.项…
随着应用需求逐步迭代,应用的代码体积将会越来越大,为了更好的管理应用工程,我们开始借助CocoaPods版本管理工具对原有应用工程进行拆分.但是仅仅完成代码拆分还不足以解决业务之间的代码耦合,为了更好的让拆分出去的业务工程能够独立运行,必须进行组件拆分并且实现组件服务化. 下面是最近在行业内几个大神的博客辩论对战,具体资料如下: 2016.03.10 蘑菇街App的组件化之路 2016.03.13 iOS应用架构谈 组件化方案 2016.03.14 蘑菇街App的组件化之路·续 2016.03.…
前段时间公司项目打算重构,准确来说应该是按之前的产品逻辑重写一个项目.在重构项目之前涉及到架构选型的问题,我和组里小伙伴一起研究了一下组件化架构,打算将项目重构为组件化架构.当然不是直接拿来照搬,还是要根据公司具体的业务需求设计架构. 在学习组件化架构的过程中,从很多高质量的博客中学到不少东西,例如蘑菇街李忠.casatwy.bang的博客.在学习过程中也遇到一些问题,在微博和QQ上和一些做iOS的朋友进行了交流,非常感谢这些朋友的帮助. 本篇文章主要针对于之前蘑菇街提出的组件化方案,以及cas…
一.大神博客研读 随着应用需求逐步迭代,应用的代码体积将会越来越大,为了更好的管理应用工程,我们开始借助CocoaPods版本管理工具对原有应用工程进行拆分.但是仅仅完成代码拆分还不足以解决业务之间的代码耦合,为了更好的让拆分出去的业务工程能够独立运行,必须进行组件拆分并且实现组件服务化. 下面是最近在行业内几个大神的博客辩论对战,具体资料如下: 2016.03.10 蘑菇街App的组件化之路 2016.03.13 iOS应用架构谈 组件化方案 2016.03.14 蘑菇街App的组件化之路·续…
在组件化之前,蘑菇街 App 的代码都是在一个工程里开发的,在人比较少,业务发展不是很快的时候,这样是比较合适的,能一定程度地保证开发效率. 慢慢地代码量多了起来,开发人员也多了起来,业务发展也快了起来,这时单一工程开发模式就会显露出一些弊端 耦合比较严重(因为没有明确的约束,「组件」间引用的现象会比较多) 容易出现冲突(尤其是使用 Xib,还有就是 Xcode Project,虽说有 脚本 可以改善) 业务方的开发效率不够高(只关心自己的组件,却要编译整个项目,与其他不相干的代码糅合在一起)…
概述 近一年iOS业界讨论组件化方案甚多,大体来说有3种. Protocol注册方案 URL注册方案 Target-Action runtime调用方案 URL注册方案据我了解很多大公司都在采用,蘑菇街 App 的组件化之路(http://limboy.me/tech/2016/03/10/mgj-components.html)蘑菇街的Limboy在这篇博客中做了很详尽的阐述 Target-Action runtime调用方案Casa在 iOS应用架构谈 组件化方案(http://casatw…