共计 2637 个字符，预计需要花费 7 分钟才能阅读完成。
导言
从 2017 年开始，GMTC“挪动技术大会”就更名为“大前端技术大会”。倒退至今，混合开发、原生开发、前端开发等概念正在深度交融，组成“大前端”团队。
大前端团队如何选型技术？如何疾速上手？如何高效协同？让咱们看看快成科技如何解决这一问题。
缘起两地三团队
快成科技是网络货运畛域的领军科技企业，畛域排名市场前三，平台有 3w+ 大宗商品货主，将货单公布到平台，由 60w+ 的卡车司机接单承运，每年产生 120 亿 的运费交易额。
以司机端为例，须要承载从发单抢单到从进出场治理，从在途门路监控到金融白条加油加气等一系列互相强关联、流程链条长的业务。这些工作由两地三个研发团队，独特分工协作实现。
在 7*24 小时不间断的客户服务和每月 2-3 次发版的高度迭代中，技术框架瓶颈逐步凸显，具体包含：
- 在零碎框架方面，初始框架是原生 App+HTML5，传统 web 存在启动白屏和性能响应不晦涩，大大降低了用户体验；
- 在发版周期方面，研发部门多，产品链条长，局部企业须要更多的共性定制化服务导致发版期待周期不统一，频繁的发包更新不仅升高了经营效率，也给客户带来了频繁更新的困扰；
- 在体验一致性方面，原生开发依赖零碎框架，因为原生个性不同，而导致各厂商多渠道平台中差异化凸显，多平台性能、体验差异较大；
- 在多部门合作方面，罕用开发语言、前端 JavaScript 框架等不尽相同，不能及时依据需要张弛和上线 DDL 来灵便调配技术人员合作开发。
在快成科技业务继续高速倒退的背景下，优良的技术架构是“提质增效”的保障，零碎重构势在必行。快成的小伙伴们开始寻找优良的架构，解决场景问题。
选型四维度
快成小伙伴针对发现的问题，探讨出四个选型维度：
- 框架成熟度：简略来说，就是这个新技术是否靠谱，百亿的业务压力，没有太多的试错空间；
- 迁徙老本：如果想得到新技术带来的收益，须要咱们付出什么代价，例如新技术的学习老本、原来架构的革新老本等；
- 社区气氛：次要是看跟进这个技术的人够不够多、文档资料是否丰盛、遇到问题是否失去帮忙等；
- 考量根底上兼顾性能、跨平台和动态性。
定好技术选型考量指标之后，团队对常见的跨平台计划诸如 React Native、Weex、Flutter 和小程序进行了一系列的调研以及 Demo 制作，横向比拟如下：
| 技术选型 | 调研后果 |
|---|---|
| React Native 和 Weex | • 启动工夫慢、帧率不如原生； • 迁徙老本较大，开发者需封装一层较重的中间层，对研发人员要求较高。 |
| Flutter | 性能和效率至上然而动态化能力十分无限。 |
| 小程序 | 自身并非一种跨平台开发计划，无奈利用自身 app 关上，更看重渠道劣势。 |
正在进入技术选型窘境的时候，快成物流科技偶尔接触到了源自支付宝技术框架的 mPaaS，通过应用 mPaaS 小程序容器，整合 mPaaS 框架、离线包和复用 h5 插件，依靠于性能强劲的 web 渲染引擎，完满合乎了咱们对技术选型的冀望与要求。
入手试试看
选定技术选型之后，在重构初期，针对我的项目工程建设以及划分上，咱们共事之间进行了一场强烈的头脑风暴，最终选定了在多部门合作前提下进行轻量组件化并行开发多个小程序并进行动静下发的计划。
快成团队从协同、技术等多角度，进行框架的逐渐导入。
🎞如需理解残缺内容详情，欢送观看 CodeHub#5 全程回放
1. 多团队协同
2. 实在场景测试
真机预览与调试问题，首先要设置好白名单，设置形式可参考文档，而后在原生端依据文档进行相应的配置和代码书写，最初须要留神的是 IDE 生成的二维码须要应用咱们 App 的扫码能力扫描（可接入 mPaaS 的扫码组件），用支付宝扫一扫是打不开的。
ScanService service = LauncherApplicationAgent.getInstance().getMicroApplicationContext()
.findServiceByInterface(ScanService.class.getName());
ScanRequest scanRequest = new ScanRequest();
scanRequest.setScanType(ScanRequest.ScanType.QRCODE);
service.scan(this, scanRequest, new ScanCallback() {
@Override
public void onScanResult(boolean success, Intent result) {if (result == null || !success) {showScanError();
return;
}
Uri uri = result.getData();
if (uri == null) {showScanError();
return;
}
// 启动预览或调试小程序，第二个参数为小程序启动参数
MPTinyHelper.getInstance().launchIdeQRCode(uri, new Bundle());
}
});3. 外围问题解决
在同一小程序不同页面跳转传参的时候咱们遇到了大参数传递被截断的问题。
通过剖析是小程序对路由跳转 API 进行了参数携带长度的限度，起初咱们抉择应用缓存 my.setStorage 来进行大批量参数的存取应用，这里须要留神的是同一小程序缓存下限为 10MB，在适合的中央应用 my.clearStorage 革除缓存尤为重要。
4. 优雅的交互晋升
在 UI 开发上，咱们心愿小程序页面更靠近于原生，所以咱们进行了小程序的自定义导航栏的开发，这部分是须要原生端来实现的，倡议下载官网 Demo 配合文档来进行开发。
咱们还遇到过一个令人印象比拟粗浅的 UI 问题，在 iOS 设施上进行表单类多 input 组件页面开发时，会呈现输出错行的状况：
通过查阅文档，发现这是个兼容性问题，对于须要启动键盘的组件，如 input、textarea 等，目前默认应用的是原生键盘。
如果键盘和组件的交互存在异样，可在组件中增加 enableNative=”{{false}}” 属性，即可复原到应用 WKWebview 的键盘。
同时因为应用的是零碎键盘，也就不能应用 mPaaS 提供的数字键盘等，键盘相干目前不再专门适配。
将来可期
随着技术的一直演进和降级，看似开发变得越来越简略便捷，缩小了反复无意义的工作，理论反而特地考验开发人员剖析定位解决问题的能力，创新能力和学习能力。
但目前 mPaaS 小程序比照支付宝小程序还是存在肯定的差距，在兼容性和 H5 框架上还存在一些小问题，也心愿 mPaaS 及小程序框架能一直演进，将来可期！
E · N · D
