前言
年元旦放假第一天，本文来自美团
rank的授权分享。正文从这开始～
最近工作变化较大，除了管理一个独立的产品业务外，还负责了美团Web/iOS/Android平台业务研发。
就在大约4个月前，我接手了美团大平台的大前端工作。包括美团客户端App，Web端的平台业务，还包含美团各端的基础设施研发工作。也正式开始了Web/iOS/Android的大前端路。也许很多垂直业务团队和小型创业公司现在已经是这种大前端模式了，但平台+基础设施是比较大的团队（小一百人规模）还比较少见。所以现在这模式也算是一种探索吧。
在这篇文章里，我分享一下管大前端后的一些技术及管理心得。
一.先泼ReactNative冷水
我此前虽从事过Windows和后端开发，但专业领域还是在Web前端最久，所以我首先想分享给Web前端同学的是，虽然现有ReactNative（RN）类似的跨端技术方案，「似乎」RN有一统天下的意思，但实际各公司生产环境里还都在试水，各端仍相对是独立研发的状态。
简单列几个主要问题：
RN质量问题，某些异常和Crash无法解决。要解决就必须吃透RN底层，对于研发团队来说技术质量不可控，这是个致命的问题。
两周一个迭代，维护升级成本高。问题根源还是源于「质量」，所以才会如此快地迭代。要在生产环境下用，意味着需要投入大量时间在追新版本；或在某个版本进行持续维护。这需要拿出额外的研发人力每两周合版保证RN质量。于是就有一定的拆衷方案，就是在交互复杂或表现细致的地方不做那么「细腻」。还有一种方案也就是Weex的办法，不能控制RN，宁可自己造一个RN。
无杀手级应用背书。据我所知至今还没有一个「知名」「用户端」「商业」App完全用RN开发并超过半年以上。facebook的showcase里收集了使用RN的案例，除FB外都是部分功能使用RN。
这三个问题决定了成熟的商业产品不会轻易用它开发，只用于用户端少数几个刚需高频更新功能。到目前为止，线上我们实验结果已经将它逐渐下线转而采取了其他方案；RN也目前还在偏企业侧的App应用里，但仍有些Crash解决起来很费劲。
我之前也在「微博」上提到了：
就目前RN的情况，最好不要大面积在C端产品上用。—这是几千万日活App在此实验的经验。
从最早桌面时代到移动时代，跨端开发技术都有场景受限的历史（参看Qt），要实现跨端理想还有很远的路要走，这决定了在不同端上专业差异还比较大。
二.客户端的不同
客户端相比Web端不同，是客户端可以近一步拿到更底层的控制权。
1.控制请求与资源管理
站在Web开发的角度，能控制「请求」一直是件梦寐以求的事。在HTTP2之前，请求是Web性能的第一杀手。在客户端，可以劫持所有请求都通过长链接来解决请求并发性能下降的问题。这不仅仅是简单的性能提升，还可以解决DNS被劫持的问题（对于国内环境域名被劫持实在是太常见了）。长链从根本上解决HTTP连接成功率的问题，这类技术在BAT也很成熟并广泛应用。
2.浏览器增强
由于W3C标准严重滞后于时代，加之各浏览器厂商的标准与实现不一，导致各公司桥、容器满天飞。同时这也是Web开发者熟悉的领域。说一个不好解决的问题吧，如果一个公司共用一个桥，如何定义什么是基础桥容器下沉，太灵活，业务方就相当于fork一份出去，未来不能再收拢，如果都由桥容器所在的平台组来做，响应能力是个问题。什么时候由业务方来做，这是个难点。
3.跨端全局视角
单纯在Web端立场，希望Web思想一统天下把同构做到客户端去；站在所有端立场去看问题时，却大不一样。也可以说是屁股决定脑袋。
我还是拿大家较熟悉的RN来举例（并不限于此）。用传统的MVC分层（Model，View，Controller）来理解RN是一种解决跨端组件化、快速发版、高性能的垂直纵切「切洋葱皮」MVC的方案。
那有没有其他解决思路呢？
对大型的App里模块化，有成熟的包管理与二进制集成的方案集成，开发单独方面复用与协作效率能得有效解决；随着移动设备性能提升及4G普及，大多对及时性与试错项目可通过Web与Hybrid来解决；还有一类就是既对体验有极致要求，还有界面高频变换的场景，可以横向「剥洋葱皮」来解决界面（View）层多变问题。
通过开发一个内置Native的DSL模板语言，用RN的子项目css-layout做渲染，也能很方便地做到界面灵活可变的业务场景（甚至有人改造WebCore渲染View从而实现跨端布局）。
就RN解决的领域问题，用全端研发视角，客户端模块化+WebHybrid离线化+客户端视图层模板化也是办法之一。但需要几个端一起推进协作，所以这也可以算作是前端背景的Leader管理大前端的优势之一。
三.客户端的不足
1.不能实时更新
相对Web端，客户端的缺陷是什么呢？首要问题就是由于手机操作系统的限制而不能实现快速实时更新。不能实时更新就意味着在测试周期往往比Web要长，但现在业务竞争这么激烈，就会有高速的App发版周期。App涉及业务与团队越多，项目的协调与控制成本就很高。现在的App开发周期一般是3周发版（也有滚动双周发版的），这样一来业务上的开发时间就很短了（1周多），所以业务框架如何实现多人快速开发就成了一个热门的议题，于是各种MVVM与模块化的框架就出现了。
由于不能快速更新，衍生的问题之一就是客户端版本分布较为碎片化，与传统的桌面端软件存在同样的问题。一般需要维护6个左右的客户端版本。客户端的碎片就意味着服务端数据接口也有版本的概念。给后端带来的困扰是有时一不小心后端改动一个数据结构，客户端就因为接收数据的代码防御没做好造成异常或Crash了。
不能实时更新，使得客户端与Web端的质量benchmark标准也就不同了。
2.质量控制标准
客户端质量里最重要的技术指标之一就是Crash率，通常计算方式为：Crash数量/DAU（日活）。一般C端大型（千万级）AppCrash率iOS在1‰以下，0.5-0.8‰；Android1‰左右。
要保证质量，在测试时除了传统QA的黑白盒测试外，还需要用到云测、众测等手段解决机型碎片和测试团队可能无法覆盖到的边界问题。也衍生一些枚举测试点击的自动化测试工具（Monkey等）和流程测试工具。
线上总有漏网之鱼的Crash和异常，所以线上要及时bugfix，客户端又由于操作系统的限制不允许动态下发可执行代码，所以bugfix也成为近两年研究的热门技术之一，熟称Hotpatch（热补丁）。我认为就光这个领域都可以写本书出来。
Android体系开放，很多人利用系统Hack实现了Hotpatch，但系统兼容性不太好，一旦升级封死了，这口子也就没了。我们做了Robust项目，利用InstantRun技术，在运行时字节码里加入Hook，实现Java在运行时的AOP的Hotpatch（美团博客已发布）。
iOS当前最流行的就是JSPatch了，JSPatch作者在自己博客上非常清晰地讲述了实现的思路，这里不赘述。
可以这么说，现在都是利用现有语言或系统特性，甚至Hack来实现Hotpatch，并非系统自带，或多或少还有坑，这就没有Web那么完美了。反过来说，这也是Web架构的优势所在。
3.持续集成的重要性
持续集成（CI）对Web端没有严格要求，而客户端是必须用持续集成解决很多效率问题。
iOS与Android不同的是，需要用到Apple专用机器—「垃圾桶」MacPro。（就是像圆桶一样，没显示器还很贵的主机），iOS开发团队通常是拿来做持续集成和Dailybuild编译的容器。
利用CI做什么呢？静态扫描，发现些代码防御问题，还可以检测包大小，滥用Lib库问题。还可以集成之后Dailybuild做Monkey与固定case的流程自动化测试。自动出持续集成测试的报告，能在人工介入前就发现问题，提高研发效率。如果App很多，还需要排队编译。所以如何编译效率与动态扩容又是个问题。
四.Web端的位置
现今不少人认为「Web前端」在移动设备时代只是配角，特别是做了很久Web前端的老江湖（注意：纯Web前端，不包含后端的Node.js）。这个「配角」观点是基于移动端增长强势弱化了PC端地位；其次很多用户侧的移动页面都导流到客户端了；再就是产品主要功能是用客户端技术来开发。
基于全面移动化的角度，我对以上观点是持赞同态度的。所以我一早就提出了Web前端的发展需要更全面T型人才，也认为是从事Web前端多年之后的必经之路。
T型如何理解？一类是某个端专业，也懂其他端，是跨端人才；另一类是Web前端不错，做full-stack（全栈）开发。
在跨端开发上，Web前端在「用户体验」与「界面布局」方面有优势。一方面是客户端的同学通常是毕业生或转型而来，较Web前端少了「Web重构」这个年代，而Web重构是较为白癫风区别北京治疗白癜风最好的医院是哪家