머리말
Taobao의에서 오랜 시간 동안 프로그램의 구성 요소, All in 无线조각, The one다음 버섯 스트리트 도로의 구성 요소, 점점 더 많은 인터넷 기업이 발발 처리하는 컴포넌트 기반의 비즈니스 솔루션을 사용하기 시작했다.
우리는 응용 프로그램을 사용하는 单工程+MVVM대부분의 비즈니스 요구 사항을 충족하지만,. 그러나 최근이 회사의 사업 개발은 빠른 속도로, 기존의 인프라 수요를 충족 할 수 없었다. 각 회사의 사업에 대해 서로 다른 프로그램의 많은 구성 요소가 있는데, 특정 프로그램이 다를 수 있습니다. 이 글은 블로그의 위대한 하나님의 일부를 수행하는 몇 가지 생각과 함께 우리 회사의 프로젝트의 상태입니다.
왜 컴포넌트 화
기존의 비즈니스 아키텍처의지도를 봐
- 비즈니스 상호 의존적 인 모듈, 더 심각한 결합
1 멀티 서비스에 대한 수요가에 직접적으로 의존하는 경우 일부 트래픽 엔지니어로 이어질 초기 공회전에서 레이어의 상단에 의존, 개발 시간을 필요로 할 때, 하위 계층은 엔지니어의 무거운 작업에 따라 달라집니다 및 완료의 속도를 느리게합니다 전체 수요가 미치는 영향은 팀 개발 반복 속도;
당신은 당신이 이미 사업을 직접 따라 새로운 사업 및 기존 사업에 의존 사이에있는 경우, 새로운 사업을 개척하려는 경우 2, 당신은 모든 관련 사업을 넣어해야하기 때문에 어려운 구축 신규 사업 개발 환경에 주도 개발 환경을 압착 한 새로운 사업은 개발 될 수있다. 새로운 비즈니스의 응답 속도의 영향;
하나 다소 이러한 바꾸기와 같은 페이지에 의존하는 다른 기업에 의해 변형되는 경우도 3은 관련된 변경, 특히 큰 직면 할 것이다. 결과는 작업 및 유지 보수 비용의 양에 의해 영향을받는이 증가하고있다.
- 병렬 개발 APP의 복수의 비즈니스 증가 기존 코드의 다수는 높지 않다
- 사업 개발 효율은 충분히 높지 않다
비즈니스 계층 만 구성 요소에 대해 신경, 전체 프로젝트를 컴파일 관련없는 다른 코드와 함께 혼합해야합니다.
- 편리한 테스트
모듈이나 기능을 테스트하는 프로젝트로 작성된 코드의 모든 모듈은, 당신은 프로젝트를 컴파일하고 실행해야합니다.
해결 방법
의존도가 침몰하자!
의존성이 침몰 할 방법은? 소개 中间件모드.
소위의 도입 中间件모델은 너무 오래 각 사업이에 중개인을 따라로서, 중개인의 역할은 비즈니스 계층에있을 것입니다, 다른 페이지로 중개인에 의해 소환 할 때 기본적으로 각 페이지를 호출 종속 싱크를 만들려면 종속성 싱크되는 다음 층.
비즈니스는 비즈니스 B의 페이지에 대한 요청 때 호출해야 中间件하고 만든 中间件선에 다시 B 비즈니스 페이지의 인스턴스에 어떤 수단을 통해 가능합니다. 이 메커니즘의 실현 과정에서 해결해야 할 몇 가지 문제점이있다 :
- 페이지 요청 다른 서비스가 될 수 있도록, 서비스 릴리스 메커니즘을 요청할 필요성, 일반적인 요청 메커니즘을 디자인
中间件처리 - 디자인
中间件메커니즘의 요청에 따라 어떻게 다른 비즈니스를 얻기 위해,中间件요청을 처리하는 방법을 알아야 여기서 원하는 페이지를 찾기 위해 이동
컴포넌트 화는 문제를 해결할 수
- 사업 부문 더 명확 부부는 구성 요소에 의해 개발 작업을 할당 할 수 있습니다, 더 쉽게 점령;
- 프로젝트 유지 보수 강화, 개발 효율성을 향상;
- 더 나은 직접 조립 처리에 문제 구성 요소 문제를 해결;
- 개발 및 테스트 프로세스는, 당신은 단지 코드의 일부는, 코드가 전체 프로젝트를 컴파일 할 필요가 없다는 자신을 컴파일 할 수 있습니다.
구성 요소 설계 원칙
- 어셈블리의 바닥보다 더 추상적 안정 다중의 높은 수준이어야한다.
안정적인 성능 종속 구성 요소를 통과하지 않도록하지 노출 요인의 모든 변경 사항을 변경하지 않는 긴 시간 동안 가장 직관적 인 API이다. 전달 안정성 특성을 가지고있는 구성 요소의 B 구성 요소가 의존 등의 B-구성 요소가 안정적이지만, 불안정한 구성 요소 A가 구성 요소 B는 원칙적으로, 그래서 불안정해질 경우 :
- 의존도를 줄이고, 안정적인 구성 요소가 불안정 요소를 따라하지 마세요
B 성분은 필수 소스 내부는 A 구성 요소에 실제로 의존하는 경우 어떻게 할까? X는 다중화 높을 수 있다면 가정하자 X는 X의 특성 이제 종속 코드 섹션 코드 부이고, 그 다음 단일 성분 X 이루어지는 안팎에서는 X 어쨌든의 조립체 (A)의 X 종속 성분 B 추천 구성 요소, 다른 경우에, X는 그것이 안정된 어셈블리를 보장 할 수 있기 때문에, 그리고, OK 내부 코드 X의 B 성분의 복사 방법 또는 기능이며, 하나의 요소를 만들기 위해 적합하지 않다 자기 완전성.
- 구성 요소의 재사용 성을 향상, 자기 완전성은 코드 재사용 것보다 때로는 더
什么是自完备性，就是尽可能少的依赖组件来达到代码可复用。 举个例子，工具类 Utils 里面放了大量的工具方法等。在日常UI产品开发中，依赖这个 Utils 会很方便，但是我现在要写一个比较基础的组件，应该就要求复用度更高一些，这个时候需要用到Utils里面的几个方法，那这个时候还适合直接 大专栏 组件化方案依赖 Utils 吗？当然不合适了，这与我们上面的设计原则相悖了啊，因此我们这时候为了这个组件的自完备性，就可以重新实现下这几个方法，而不是依赖 Utils 组件。
- 每个组件只做好一件事情，不要让Common出现
组件化结构是让工程结构更清晰，每个组件都只做一件事情，都有自己的一个命名，这样这个组件才能良性发展。
组件化方案选择
组件化方案有多种，公司业务不同，方案也不同。但有一个共同点，就是单工程拆成多工程。下图是根据我们公司的业务设计的一套方案：
1.每个组件都是一个单独的repo，单独维护；
2.模块下层是公共基础库，基础库负责提供基础功能，与业务层无关；
3.所有组件通过cocoapod管理；
4.第三方库跟公共基础库是平行的，位于模块的下层；
5.每个APP表现为一个主工程，主工程负责组装各个业务模块。每个业务模块在Podfile中配置。
中间件
如前文所述，中间件的职责是让依赖下沉，将业务层之间的依赖交由中间件调度。中间件的架构见下图：
1.本地调用：本地组件A向中间件发起跨组件调用，中间件根据获得到的target和action信息，在底层通过objective-C的runtime转化为target实例和action选择子，最终完成调用逻辑。
2.远程调用：AppDelegate接收到URL之后，调起中间件的openURL：方法将接收到的URL信息传入。然后中间件通过解析URL，将请求路由到target和action，进入本地调用流程，完成调起逻辑。
组件暴露Action为中间件提供调用接口
所有组件自带target-action，将调度接口固化在target-action层，以避免对业务层的侵入。
中间件以category方式实现调度组件。
去Model
组件内部全部采用去Model化设计，使用字典+key表征数据模型。组件间以字典形式传递参数。
为什么不使用对象模型呢？使用对象模型在转化时成本是很大的，主要表现在：
1.数组内容的转化成本较高：数组里面每项都要转化成Item对象，如果Item对象中还有类似数组，就很头疼。
2.转化之后的数据在大部分情况是不能直接被展示的，为了能够被展示，还需要第二次转化。
3.只有在API返回的数据高度标准化时，这些对象原型（Item）的可复用程度才高，否则容易出现类型爆炸，提高维护成本。
4.调试时通过对象原型查看数据内容不如直接通过NSDictionary/NSArray直观。
5.同一API的数据被不同View展示时，难以控制数据转化的代码，它们有可能会散落在任何需要的地方。
开始
1.搭建私有库
私有Pod库用来保存所有的基础库和业务模块，每个组件是一个单独的 repo，单独开发，单独测试。
2.网络库选择
网络库不多介绍，直接选取猿题库开源的网络库。
3.数据存储方案选择
考虑到客户端数据量不大，数据层可采取 key-value 方式存储。可以满足绝大多数的业务需求。
4.视图层布局
视图层的布局采取 xib 和 storyboard 方式，这也与苹果的理念相符。
5.资源文件管理
对于一些确定只在固定模块内使用的资源文件，可单独放在该模块内。其他资源文件放在公共的地方，以组件的形式存在。
6. 원격 강제 및 통계 및 공유
서비스를 제공하는 방식으로 균일 한 구성 요소
지점 관리
직접지도 :
유통 및 연속 통합 테스트
사용하여 격리 된 환경을 만들기 위해 번들을 사용하여 cocoapods자동으로 테스트 패키지, 공식 가방을 구축하는 스크립트를 사용, 관리 종속성을.