从零开始架构一个中大型App

一、业务理解

技术服务于业务，必须要了解业务，才能更好的服务业务。

二、赋能业务

建立在业务理解基础上，了解业务痛点，通过技术来赋能驱动业务

三、研发效率

• 多人多团队写作：解耦、模块间相互独立、单独仓库、jar、*AAR依赖
• 复杂度控制：复杂度控制在组件内部，对外简单可依赖
• 复用：为矩阵产品输出轮子
• 编译速度：组件单独编译、maven私服、构建加速

四、技术选型

4.1 语言

反：单Java或单Kotlin
正：Kotlin + Java

4.2 架构模式

反面：只MVC
正：MVP、MVVM

4.3 工程架构

反：单一工程
正：组件化+模块化

4.4 混合架构

Native+Flutter/RN(RN个人非常不喜欢)+H5

4.5 网络

反：拿来直接用
正：封装统一的网络接口，不直接依赖网络库

4.6 数据持久化

反：SP + SQLite
正：File + SP +SQLite/Room

4.7 如何做好技术选型

4.7.1 技术选型的方法论

• 技术判断：目标/问题–>影响因素–>识别风险/利弊–>整体最优/次优
• 影响因素：业务阶段–>技术趋势–>行业趋势–>未来趋势–>切换成本
• 理性决策：自己想清楚
  • 听多数人的意见，和少数人商量，最后自己做决定
  • 5W2H：WHAT + WHY + WHEN + WHERE + WHO + HOW +HOW MUCH

4.7.2 仰望星空与脚踏实地

• 仰望星空：技术与产业发展
• 脚踏实地：业务与技术的匹配与融合

4.7.3业务重点与技术重点

• 了解业务是什么，技术如何服务于业务，赋能业务
  • 自己商业/业务的重点就是技术的重点
  • 核心技术自建，避免关键技术依赖

4.7.4 跟风与寻找适合自己的

反面案例：

• 微软在用Xamarin，我们也要用
• Facebook在用Cassandra，我们也要用
• LinkedIn在用Kafka，我们也要用
• 阿里巴巴在搞中台，我们也要搞
• …

4.7.5 科学与大数据

• 使用科学的技术，结合大数据进行技术选型
  • The Hype Cycle 技术成熟度曲线
  • Google趋势
  • Github star 趋势
  • 团队技术栈

4.7.6 技术选型取舍之道

选型的核心在于取舍，取舍也是提现一个架构师技术视野和综合判断力的关键因素。

• 成本上的取舍：技术方面需要投入的时间成本和人力成本
• 技术选型取舍：技术选型 + 定制开发
• 技术管理取舍：在技术选型时，维护团队的稳定性、产品的稳定性等因素的重要性要远大于较低的迁移成本的重要性

五、数据层设计

5.1 网络层

• restful风格
• 提供统一的API接口
• 支持底层网络框架切换，对上层业务无感

5.2 本地数据

• 提供ORM数据操作框架，减少对SQLite的直接操作
• 提供统一的数据缓存框架

六、容灾能力

• 监控与预警
  • 自研平台
  • umeng、bugly、firebase
• 动态发布
• 热修复

七、开发工具支持

• 开发规约
  • 代码规范
  • CR机制
• DebugTool
• 自动构建与持续集成

八、架构大图

• 底层基础库(基础库、工具库)
• 业务层设计
• 工程结构设计
  

九、移动开发套件

9.1 HiLibrary

• HiLog：日志系统，支持日志打印、日志缓存、日志可视化、堆栈追踪
• HiUtil：工具类
• HiRESTful：简洁易用低耦合网络层框架
• HiStorage：基于ROOM的本地缓存组件
• HiExecutor：Java并发与kotlin协程任务处理组件
• HiBridge：混合开发通信桥梁
• HiConfig：配置中心系统，更细力度产品功能灵活配置和动态更新

9.2 HiAbility

• 支付
• 分享
• 扫码
• 推送
• 统计

9.2 HiUI

• HiTabTop：顶部导航组件
• HiTabBottom：底部导航组件
• HiRefresh：下拉刷新组件
• HiBanner：轮播图组件
• HiDataItem：列表组件
• HiNavigationBar：顶部导航条相关组件
• HiSearchBar：搜索组件
• HiSearchTag：标签组件
• HiCity：城市选择组件

9.3 HiDebugTool

• 构建信息
• 网络切换
• 外部跳转
• 应用信息
• 接口mock
• 数据清除