序文
淘宝網からの長い時間のためのプログラムのコンポーネントは、All in 无线、バラバラにThe oneして、キノコストリート道路のコンポーネント、より多くのインターネット企業は、流行に対処するために、コンポーネントベースのビジネスソリューションを使用し始めました。
我々は、Appを使用している单工程+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自動的にテストパッケージ、公式のバッグを構築するためのスクリプトを使用して、管理の依存関係を。