1、单项目阶段

为了项目的快速开发，一般是所有的代码都会放在一个 App 模块里。

开发人员：1-2人

2、抽象基础库阶段

沉淀基础能力，这些基础能力一旦开发完成，基本很少改动。

开发人员：2-3人

3、拓展核心能力阶段

开发人员：20-30人

在这个时候往往非常关键，随着业务增长、客户使用量增大、迭代需求增多等各方面挑战。如果项目没有一套良性的架构设计，开发的人效会随着团队规模的扩大而反向降低，之前单位时间内1个人能开发5个需求，现在10个人用同样的时间甚至连20个需求都开发不完，单纯的依靠加人是很难彻底解决这个问题的。这时候着重需要做的两件事

开发职责分离，团队成员需要分为两部分，分别对应业务开发和基础架构。业务开发组负责完成日常业务迭代的支撑，以业务交付为目标；基础架构组负责底层基础核心能力建设，以提升效率、性能和核心能力拓展为目标；
项目架构优化，基于1，要在应用层和基础层之间，抽象出核心架构层，并将其连带基础层一起交由基础架构组负责，如图；

基础团队和业务团队人员的比例，到底是多少合适呢？1:5，基础组的人员在精不在多，业务组如果有很多通用业务，也可以成立业务基础组，同样是1:5

4、模块化阶段

开发人员：50-100人

随着业务规模继续扩大，App的产品经理（下简称PD）会从一个变为多个，每个PD负责独立的一条业务线，比如App中包含首页、商品和我的等多个模块，则每个PD会对应这里的一个模块。但该调整会带来一个很严重的问题项目的版本迭代时间是确定的，只有一个PD的时候，每个版本会提一批需求，开发能按时交付就上线，不能交付就把这个迭代适当顺延，这样不会有什么问题；

但如今多个业务线并行，很难在绝对意义上保证各个业务线的需求迭代都能正常交付，就好像你组织一个活动约定了几点集合，但总会有人会遇到一些特殊的情况不能及时赶到。同理，这种难以完全保持一致的情况在项目开发中也会遇到。在当前的项目架构下，业务上虽然拆分了业务线，但我们工程项目的业务模块还是一个整体，内部包含着各种错综复杂的依赖关系网，即使每个业务线按分支区分，也很难规避这个问题。这时候我们需要在架构层面做项目的模块化，使得多业务线不相互依赖，如图

这个时候项目的结构其实就是彻底的模块化阶段，那么对于需要定期上架的App来说，不可能所有的需求都能在同一个节点完成，这个时候就所有的模块就需要有版本的概念，人力充足的情况下，需要搭建自己的持续构建和持续交付平台

5、跨平台开发阶段

业务规模和用户体量继续扩大，为了应对随之而来的是业务需求暴增，整个端侧团队开始考虑研发成本问题。
为什么每个业务需求都至少需要Android和iOS两端都实现一遍？有没有什么方案能够满足一份代码能运行在多个平台？这样岂不是既降低了沟通成本，又提升了研发效率。答案当然是肯定的，此时端侧部分业务开始进入了跨平台开发的阶段。

跨平台开发对具体的人数并没有要求，有些公司出于成本考虑，只招很少人做跨平台开发，跨平台的难点在于技术选型，一旦考虑不周，后期的切换成本会很高

类型	Weex	React Native	Uniapp	Flutter
性能	中	较高	高	高
语言	JavaScript	JavaScript	JavaScript	Drat
社区	活跃度中目前托管Apache	活跃度高 Facebook维护	活跃度高 Dcloud维护	活跃度高 Google维护
支持平台	Android、iOS、Web	Android、iOS、Web	Android、iOS、Web小程序、快应用	Android、iOS、WebMacOS、LinuxWindows、Fuchsia

Android项目架构设计深入浅出-阅读笔记

1、单项目阶段

2、抽象基础库阶段

3、拓展核心能力阶段

4、模块化阶段

5、跨平台开发阶段

相关链接