从0到1构建"跨平台"应用

❝

偶然翻到去年2月份内部分享的 PPT ，主要是关于内部推广 React Native，当时自我感觉良好，现在看来简直就像小丑的表演，为了不遗忘这段表演，特地回顾一下并记录下来，也希望各位多多指教！

❞

自我介绍

大家好，我是来自互联网应用产品部的前端开发，今天给大家分享的主题是 『从0到1构建"跨平台"应用』。国际惯例，首先先自我介绍一下，我叫胡琦，江湖 人称“Copy攻城狮”，百度"Copy攻城狮"或者谷歌“胡琦”应该都能找到我。我的经历 和经验都很简单，精通JavaScript、Java、Python、PHP各种语言的“Hello World”写法，熟练掌握“CV”技能，因此被称为“Copy攻城狮”。虽然做了快4年的前端，依旧也只懂皮毛，基本没有形成自己的技术体系，真·前端打杂，还恳请各位大佬多多指教，当然我也会争取早日摆脱CV大法，实现技术积累质的飞跃。

Github: https://github.com/hu-qi
公众号: 胡琦

前端"跨平台"发展史

"跨平台"我特意加了引号；提到跨平台，可能1000个程序员会有1000种看法。有人认为“跨平台”指支持多种操作系统的软件，如MYSQL、Apache；也有人认为”跨平台”指可在不同操作系统上进行软件开发的编程语言，如Java。我今天提到的“跨平台”仅仅是我对前端开发过程中的“跨平台”的认识，随着大前端技术的突飞猛进，jQuery成为了万千前端开发调侃的最佳对象，因此，我对前端“跨平台”发展史的研究也将jQuery作为时间轴标志。前jQuery时期，主要是跨浏览器，因为微软没有遵循ECMA-262（JavaScript规范文档）与W3C（HTML与CSS的规范文档）另起炉灶，导致前端兼容问题的出现，典型的相信早期前端面试都会问到的CSS Hack，属性级Hack（如IE6能识别下划线“”和星号“”，IE7能识别星号“”，但不能识别下划线” ”，而firefox两个都不能认识）、选择符级Hack（比如IE6能识别html .class{}，IE7能识别+html .class{}或者*:first-child+html .class{}）、IE条件注释Hack等等。jQuery时期面临的”跨平台”问题依旧是浏览器兼容问题，只不过更偏向于DOM兼容，前期也很多解读jQuery源码的教程，很大一部分会提到一些兼容谷歌、火狐、IE不同版本的实现。后jQuery时期，随着HTML5的发展和移动web的流行，”跨平台”开始要解决PC端和移动web端的兼容问题，Bootstrap.js、响应式布局、REM布局解决方案遍地开花。到今天，三大前端框架Angular.js、Vue.js、React，前端开发开始涉及到Android、IOS、PC桌面应用等，前端“跨平台”迎来了新的机遇和挑战。未来，大前端技术涵盖JavaScript、小程序，甚至Flutter，前端“跨平台”将会延伸到智慧屏、智能手表等等。

技术选型脱离实际业务需求场景，谈技术选型都是耍流氓！现在我们的需求是什么？构建“跨平台”应用！就我们现在的项目而言，前期的需求就很明确—开发某应用的Android和IOS版本， 鉴于团队之前在历史项目上的积累，以及对现有移动端跨平台方案的调研分析和实践，我们选用React Native作为应用一期的开发框架。

google的flutter、facebook的react native；阿里的weex；京东的Taro；ionic早期依赖AngularJS, 滴滴的卡梅隆、腾讯的hippy ……，百花齐放。当时列出表格对各技术进行了分析对比，前端技术选型是个很痛苦的过程，选择实在是太多了，另外如果不考虑团队现有技术储备的话google的Flutter也是绝佳的选择。话又说回来，没有哪一种技术是一劳永逸的，只有适合自己业务场景的才是最合适的。

前面的技术选型对比主要来源于各大平台的主流判断，还包括github上的一些信息反馈。总得来说是一些理论上的观点和其他大公司的一些实践认知。 而我们在理论的基础上，还需要去初步验证技术选型。最好的方法是从“HelloWorld”开始。属于JavaScript阵营的框架，基本离不开对Node.js的依赖，package.json是标配；基于其他语言的跨平台框架也会有类似的包管理文件。另外，关于开发环境的安装，这里就不一一赘述，既然是跨平台开发最起码就需要Android、IOS或者Web开发环境，选择不同的开发框架，可能还会要求安装额外的环境之类的。对于环境的搭建，我想说一定要有耐心，遇到问题不要灰心，基本上我们踩到的坑或多或少别人也踩过，这里建议大家勤动手多记录，一是巩固自己掌握的，二是方便后来人及时脱坑。另外，翻墙工具应该算是开发必备，虽然绝大多数依赖都有国内镜像，但是有些莫名其妙的bug在翻墙的环境下就不存在。 这里我分别安装了flutter、React Native、Weex、Taro的脚手架工具，并初始化了’helloWorld’项目。

既然是“跨平台”框架，从Helloworld的项目结构中，或多或少能看出一些端倪。像flutter、React Native、Weex都直接有名字为android、ios的文件夹或文件；而Taro编译成 原生应用是需要先编译成React Native代码的。通过展开关键开发目录，不难看出Flutter和React Native都需要开发者自动引入或配置路由，而Weex基于Vue.js,因为我初始化 项目是选用的vue-router，所以会存在路由文件；Taro脚手架初始化项目直接推荐使用了typeScript。看来学一波TypeScript势在必行啊！从HelloTaro目录结构中也能看出这个 框架初期的定位和微信小程序有着千丝万缕的关系，更适合来做兼容多端小程序。一般来说，默认的项目结构不足以支撑开发，正式开发之前我们要确定目录结构、编码规范， 甚至项目组件化、工程化等等。

“四化”

这里“四化”只得是规范化、组件化、模块化、工程化，是项目开发的必然结果，也是项目开发的必经之路，未来还会向智能化的方向发展。当然这些只是抽象的事物，需要具体的案例来阐述。按照Tencent Now直播前端工程化的实践分享，我将“四化”分为三个阶段，也是前端开发的三个层次。规范化是基础，每个开发都有自己独特的开发习惯，开发前期，我们经过讨论指定一份开发规范，包括命名规范、代码规范等等，并且在开发实践中不断完善；规范化的指定和执行抹平了开发过程中存在的各种差异；当然实际上我们做得还不够，代码review这块就没有很好的坚持执行下去。模块化、组件化其实一开始的作用不会很明显，但随着业务的拓展，模块化、组件化的优势就会凸显出来。至于工程化，我觉得是当前项目的败笔，我们项目中的工程化程度远远不足，也直接导致了“发串生成包”的“事故”,这也恰恰说明了工程化的重要性。

从0开始的话，我建议大家先要站在工程化的高度来布局整个项目架构。当然，如果有了沉淀，我们只需将过去成熟的方案制作成CLI脚手架甚至是镜像，后面开发只需拉取之前的工程化项目，直接从1开始开发。首先我们要有规范，规范怎么定？可以学习借鉴开源项目，比如Taro，官方文档中就推荐了开发规范，从工程化的角度，我们至少要引用一种代码扫码工具，如Lint，通过配置文件将我们制定的规范应用到项目中；甚至还可以通过一些配置来统一代码开发工具，如EditorConfig等；其次模块化，组件化这部分，如果我们没有自己的沉淀可以直接借助第三方开源的成熟方案，比如引用第三方UI库加以定制化，模块化、组件化具体体现在代码结构、项目目录结构。最后适当加些自动化测试、自动部署、实时监测等，使得前端项目工程化。理想化的前端工程化，是我只要安装一个脚手架，通过运行脚手架中定义的某些命令就能生成直接可用的项目，再开发的时候只需注重业务。比如携程之前开源的CRN，甚至修改了React Native底层，做了性能优化，内部再实现了丰富的命令可以在初始化项目的时候将配套的UI、测试、打包部署等工具集成进来，比如之前接触到的粤省事脚手架 weshop，包括现在那些开源的框架比如Taro、Hipy等等，基本上都或多或少实现了工程化。那接下来，我们也实现一个简单的脚手架，初始化时直接拉取某个项目代码。

一个简单的模板拉取小工具 - cliclicli

实现的功能简单到不能再简单，就是从git上拉取项目；却是前端工程化不可或缺的一环，就像前面提到的，我们有了沉淀，将成果托管在我们的git私服和npm私服上，通过拉取整个项目快速运用到新的项目中； 如果更完善的话，我们沉淀的成果随着项目的累积可以不断的优化、提炼。核心代码就是拉取项目写入本地。之前接触的粤省事就是这种开发方式，工具非常完善，一行命令就把之前积累的一些工程化成果呈现 出来，一行代码不用写就能跑起一个完整的小程序。类比一下，同样，现在我们只执行几行命令，一个clicli视频APP就出具雏形。当然，前端工程化是需要大家共同积累的，也不仅仅局限于前端。讲到现在，不知道 大家对我所讲的会不会有什么意见。是不是都以为我会讲怎么撸代码？我不知道负责web和管理端的前端同事以及其他后端同事有没有去了解过APP端的项目代码，我认为大家不要拘泥于某一个框架或者某一种语言， 其实项目工程化对我们都提出了新的挑战。就比如，前端开发也有必要了解shell、熟悉Node.js,尽管是一个个的小细节，需要我们大量的经验积累！

我在拉取模板的时候遇到了点点差错—git clone速度慢，一般来说如果是内网gitlab和npm的话是不存在这个问题的。解决方案是修改host文件，添加到git一些域名解析并刷DNS。另外还犯了个常识性的错误，开发目录不能有中文路径！通过目录结构我们可以看出这是一个简单的业务实现，component下放的是页面（也可认为是业务模块）；wdiget下面放的是组件，如果有了解过flutter，那一定对wdiget不陌生。因为页面简单，没有进行路由拆分，也没有对网络请求层做详细封装，但二次封装了播放器、Icon。

如果模板项目中工程化程度比较高的话，那我们基本可以直接得到一个最小可用的应用，包括测试、打包、发布、部署等，基本都以一行命令或者自动完成。

后记

现在回顾之前的内部分享，也不知道最后自己究竟讲了些什么，完全是无厘头的瞎比比，技术不达标可能就是这样的现状吧！

如果本文对您有启发，欢迎评论区探讨，也感谢各位在评论区多多指教！