交付背景下的移动端脚手架-思考与设计

背景

交付技术平台部，是一个面向项目交付的前线技术，项目交付质量和效率是我们要持续解决优化的服务内容，我们作为一个项目服务群体，从移动端交付的角度去看，面临两个问题：

1. 如何能更好的指导isv进行架构/组件设计，功能开发
2. 如何更好的把产研雄厚的技术沉淀应用到每个需要的项目中去

脚手架可以很好的解决，一方面脚手架可以帮助项目进行初期架构搭建和基础的共性模块开发，同事大量的样例、模板代码可以极大程度的在项目间复用，降低对isv等开发者的架构经验要求，可专注于业务开发或遵循现有的架构逻辑进行合理的扩展和维护；其次对产研产品哪些移动中间件的包装，也可消除SA、TM或者客户对移动中间件技术选型的顾虑，缩短这些产品落地到项目的路径，同时也能加强交付能力所需要的技术体系。

建设目标

• 交付提效

• 提高项目交付的速度和质量
• 不断提高不同项目间的代码复用

• 交付开发指导

• 通过部分样例引导进行规范化开发

• 云产品的集成和包装

• 适度的包装和封装，可解耦项目业务层和paas层的直接依赖，对复杂部分做隔离和统一配置，提高业务的开发效率

• 行业交付模板基座

• 不变的是底座，变化的是业务，基座要能承载和支撑各种形态的业务属性

思考&建设

面临的问题

1. 高效：脚手架设计的初衷，提高生产效率，减少重复劳动，降低人工成本。
2. 安全 ：从开发层面，通过架构规范安全开发行为。
3. 成熟：基于成熟的技术方案，快速开发，有效避坑。
4. 稳定：保证APP线上运行的稳定性，健壮性，事故处理的效率
5. 扩展/维护：合理的架构可有效的支撑和响应业务的快速迭代和变化。

核心点建设分析

以下对所有建设模块做简单的功能描述，技术分析，后续会出单独的文章讲解

分层设计

框架层(Framework)设计

这一层为整体脚手架核心架构层，通过以下几个模块，支撑起APP整个框架，

• Launcher 启动模块，用于管理APP启动任务，以达到APP启动任务可监控，可管理目的
• Facade 通信模块，一般用于业务模块间信息提供，通过接口形式对外暴露，面向接口编程
• Router  路由模块，基于ARouter封装，主要用于页面跳转统一管理，降级，安全策略配置
• Window 页面容器框架，统一的容器基类，管理状态栏，标题栏，主题，色表等基础资源
• Service 服务模块，常驻或非常驻服务管理类

中间件封装

这里中间件一般指的是类似崩溃、诊断日志、性能监控等APM产品，统计及行为分析系统、推送平台、运营配置平台等云产品。

这些产品对于一般的项目甲方是不具备自建能力的，所以一般项目都是从各大移动PaaS厂商的云产品中做技术选型决策，有些在项目由于历史原因，启动前就已经确定了使用的厂商，而大部分可能到了方案设计阶段还没有决策下来，因为客户不懂或者开发承接方理解也不深。

所以，我们这里设计的这一层，主要是解决两个核心问题：

1. 打消技术选型的顾虑
2. 项目实际情况的适配

1. 打消技术选型顾虑

各大PaaS厂家云产品的功能范围大同小异，而且大部分都是基于自家一方的产品沉淀而来，所以这里首推基于淘系的EMAS产品，经过手淘等多款亿万级产品的打磨和沉淀而来，不论从技术底蕴还是功能范围来评估，都能保证客户的需求满足以及稳定性的保障。

2. 项目情况历史适配

有些项目，可能客户再开新产品线之前，历史项目或许已经采购了其他的产品，比如mPaaS，那么，我们脚手架也需要有着包容适配的能力，这里的处理方案如下：

从工程结构图看，设计一个PaaS层，该层下有对每个中间件产品的单独module，这里拿App更新升级的功能为例，如图所示：paas层是在framework层之上的，依赖framework层能力并受launcher启动器的管理，所以在做适配的时候，只需要替换对应的paas.update依赖库，然后再代码层面做相关的适配即可（目前版本需要做手动修改，后续可扩展脚手架模板），其他模块和工程结构不用做修改，以达到最小范围修改的适配目的。

通用层

隔离业务接入层和PaaS层的一个适配层，封装配置PaaS层、Framework层等项目相关特性，提供ToolKit工具集

业务集成层

整个架构最顶层

1. 内部模块采用组件化方式进行开发，模块间相互隔离，不直接依赖，通过Framework层进行必要的通信和调用，依赖Framework：window层进行页面框架搭建，router模块进行跳转等，
2. 集成部分，主要负责合DevOps打通（下节讲述），同时管理整个APP的依赖关系，组件集成等能力

devops打通

这里的devops打通一般流水线打通为主要功能点，这里展开一下，一般情况，为了满足开发->测试->发布->迭代等各阶段的出包需求，流水线一般会包含一些定制化能力，比如：

1. 参数传递：版本号、构建号、渠道号、环境（测试、验收、预发、生产···）等
2. 构建类型：包类型（debug、release；通过构建命令控制`assemble$flavorName$type`，不展开）
3. falvor类型：（渠道包概念，通过构建命令控制`assemble$flavorName$type`，不展开）

参数传递方式

Android构建基于gradle插件，所以在流水线参数到gradle构建参数传递一般有两种方式：

1. -Pxxx 传参：这个方式属于gradle脚本语言参数，可通过

./gradlew assembleDebug -PBUILD_ID='1781181'

/*** 获取gradle执行通过-P传递的参数信息* @param key -PKey* @param defValue 默认值* @return 传入值*/getPropertyValue= (key, defValue) -> {
returnString.valueOf(project.hasProperty(key) ?project.getProperty(key) : defValue)
}
/*** 写入到BuildConfig中*/buildConfigField'String', 'BUILD_ID', '"'+getPropertyValue("build_id", "123") +'"'

2. 环境变量：通过环境变量设置在本地，gradle构建时通过读取本地环境变量进行获取

exportBUILD_ID='1314123'

/*** 获取环境变量，后续可以考虑都用这种方式，更简单些* @param key* @param defValue* @return*/getEnvValue= (key, defValue) -> {
defval=System.getProperty(key);
if (null!=val) {
returnval;
}
val=System.getenv(key);
if (null!=val) {
returnval;
}
returndefValue;
}
/*** 写入到BuildConfig中*/buildConfigField'String', 'BUILD_ID', '"'+getEnvValue("build_id", "123") +'"'

展望

脚手架的建设只是个开始，是云巧移动端解决方案的基础技术底座，随着交付项目的使用越来越多，以及对脚手架所赋予的能力，我们会沉淀出越来越多的行业交付模板，完整的场景化解决方案以及源代码、超级APP解决方案。