EROS 是什么?

如果您没听过 EROS，没关系，百度一下，看看 EROS 到底是什么：

emmm...

很遗憾，我们好像和某种神秘力量撞上了，所以你是永远搜不到我们的文档的。

不难看出，开源一个项目，名字很重要。

言归正传

很多开发者称 EROS 是框架，其实我认为不是。

EROS 是基于 WEEX SDK ，拓展了一系列工具，暴露了大量原生能力，让开发者使用 Vue 来开发两端的 APP，它更像是 WEEX 的另一套开发方案。

主项目地址：EROS

简单统计

50 + 在线 APP，涉及行业分布于区块链、资讯、医疗、招商、购物、政府、办公、直播等。
180+ issue，已关闭 170 个
拥有千人活跃开发者群（大多数 issue 胎死腹中的地方）
近 30 个开源项目（包含贡献者贡献的插件）

在上周，EROS star 刚刚破千。

在 Mybridge 发布6月 Vue 新晋开源项目中排名第 6。

Vue.js Open Source Projects of the Month (v.June 2018)(需要翻墙)

虽然和很多优秀的项目有很大的差距，但已经是一个较好的开始，下面请欣赏，那些年我们没错过的弯路。

前期：除了混乱，还是混乱。

最开始我们是这样做的开源：

内部 Git 建立开发模板项目，发布到 npm。
内部脚手架支持 EROS 相关起服务，打包功能到 npm。

当时我们加了一个 WEEX 有一个比较大的群（里面 WEEX 的大佬也在），这个群基本上可以用“惨不忍睹”来形容，每天都有人在问问题，问不同的问题，问一个问题很快就被淹没了。

然后我们就在这个“惨不忍睹”的群里发了条小广告，当天就涌进了几十位“头铁”的开发者，然后各位也能猜到，我们的群，也成了一个“惨不忍睹”的群。。。

当时比较“经典”的几个问题

开源问题：虽然名义上是开源，代码都在 node_modules 中，也就能让开发者看看，不能参与修改。
环境问题：绝大多数前端开发者完全搞不定，只有对前端熟悉的客户端开发者，有经验的开发者能运行起来 demo。
文档问题：文档不全，有太多情况没考虑到，也没说明。
兼容问题：因为团队都用 mac，脚手架根本没兼容 windows/linux，所以很多人第一步就跪了，各种暴露出来的原生能力更是有很多兼容性问题。
更新问题：对于底层的 SDK，很多命名不合理，设计不规范，每次在更新的时候都在进行断崖式更新，很多用户更新完就跑不起来了。
代码问题：由于没有很多的人力去进行前期的测试，造成的过多的 BUG，也没有一个完整的 demo 让我们进行开发完成后的快速测试。

思考

而这段时期，进群的开发者和出群基本保持持平，这时候我们才渐渐意识到几个问题：

EROS 的开源和平时我们做项目，团队贡献插件，组件等是不太一样的，项目很多，环环相扣，耦合严重，稍微一有变动都有可能造成开发者的流失。

这与我们前期没有做好开发者调研，开源经验欠缺等有直接关系，当我们不在 面向团队，而是 面向开发者 的时候，之间的增量问题 让我们差点手足无措。

我们对 EROS 没有一个明确的定义，没有对开发者的增长有一个很好的规划。

这个是很要命的，如果没有一个明确的定义，我们就像无头苍蝇，陷入永无止境的解决问题中，当时有一大段时间我们团队都在解决问题，甚至到晚上 12 点之后。

我们暴露出的原生能力，并不足以支撑起更多的业务。

举个例子，业务中需要上传图片的组件，你这里没有，绝大多数开发者肯定会扭头就走，这时候我们必须开发大量原生能力来留住开发者，事实也是，我们在这段时间积累并暴露了大量的原生能力。

行动

我们首先把所有项目源码搬到了国内的码云上，在搬的过程中，顺道解决了上面的问题
脚手架兼容所有平台文档补全，同时开设问答板块来纪录常见问题
客户端全力投入 fix 兼容性群里搜集开发者需求，客户端排优先级来实现
每次更新的时候都会出一篇迁移指南，通知开发者群（因为我们知道除了群外基本不会有人来用）
编写一个较为简单的 demo，方便测试
组内定期讨论，总结流程上的不足，记录下来，定期优化
每次开发者要崩溃的时候，都进行语言安慰，并尽可能的解答群里回答的问题，无论大小。。。

第一款 APP

终于，搬到 码云 后的第一个月，我们终于有开发者做出了第一款双端的 APP 连云港点点通 ，虽然功能很简单，但对于我们整个团队是莫大的鼓舞，真的是有开发者一次次陪我们更新，陪我们试错的，很感动。

这期间我们有哪些用户群体

小公司
外包公司
独立开发者

由于我们存在上面说的那些问题，导致稍微有些规模的公司是肯定不敢使用的，他们宁愿使用 RN，或者咬咬牙使用 WEEX。

中期：与开发者一起成长

我们在码云待到了11月份左右，这期间看似比较稳定：

已知上线 APP 和开发中 APP 近 10 个左右
客户端稳定拓展功能现有 BUG 解决的差不多了
文档也进行了补全和优化，让开发者更易懂
开发者群人数也在一点点增长

不成熟的稳定 = 面临无果

这种不成熟的稳定，给我们敲响了警钟：

我们需要把代码发布到更大的平台
我们需要把项目进行更多解耦我们需要进行项目体积的优化
我们需要更多有经验的，有规模的团队一起参与其中我们需要让开发过程更加迅速，开发体验更加友好
我们需要知道此时的开发者需要什么

随后我们做了这几件事：

所有项目全部迁移至 Github
独立出来各个项目如 eros-cli,eros-publish 等
我们用 docsify 重构了文档，并补全了更多的机制介绍，让开发者更加易懂。
我们优化了开发流程，增加了模拟器/真机同时单个或多个 热刷新
我们不在局限与 JS Bundle。仅仅用作页面的思想，针对类 MPA 项目的不足，拓展出了寄宿 Bundle 和中介者 Bundle，减少了包体积 60%+。
客户端重新优化了一版底层 SDK，前端重构了一版 Widget，并优化了 api 的使用方式等。
我们给群里开发者发送了问卷调查，搜集目前开发者需求
做好新的大版本的迁移文档

问卷调查部分截图:

这番折腾过后

开发效率上升一个层次。
我们积累了更多原生能力。
项目之间耦合更低，更加稳定。
越来越多的团队加入到了 EROS。的行列中，不泛有规模的团队，也渐渐有项目从 WEEX 迁移至 EROS。
我们也 EROS 也有了一定的规划。

在后续的交流中中，明显能感觉到开发效率有质的提升，这里晒出前面调查问卷的开发周期，我们不难看出，WEEX 在一定业务复杂度范围内的开发效率真的是非常高。

近期：赋予开发者更多的能力

二次稳定

完成上面的优化之后，我们又一次进入一次看似稳定时间，这段时间每周基本都会有 APP 上线，开发者也越来越多，但又暴露出来一个严重的问题：

目前虽然拓展了很多原生功能，但还是远远不能满足用户的需求，同时我们又有自己的业务要开发，很难有大量时间和经历去帮助开发者进行快速拓展。

所以我们决定推出插件化方案，让更多开发者成为贡献者。

说到插件化，很多人会问，这不是一开始就应该去考虑的吗？这也就是开头说到的问题，我们一开始并未给 EROS 一个很好的定位和规划，我们一开始想做一个大而全的“坦克”，但我们一边面对大量的业务，一边一组负责近 5 个左右的仓库，还要在帮助开发者回答问题，修复 bug，已经是非常吃力了。

形成小型社区

今年上旬我们客户端投入到了插件化方案，从设计到最终落地稳定将近 3 个月的时间，由于 WEEX 插件市场已处于基本没人维护的状态，我们并未沿用 WEEX 自身的插件方案。

同时插件化中我们也把自身 SDK 抽离成插件，把项目进行进一步解耦，用户现在只需修改依赖版本号进行升级即可，解决了用户更新困难的问题。

我们并没有做插件市场，而是大量鼓励的原生开发者来拓展插件，并上传到他们的 github 上，通过群内引导 star 和 issue 来帮助提升插件稳定性和开发者积极性。

当我们拥有了一个非常活跃的千人开发者资源，里面的开发者才会有动力开发更好的插件，而他们得到的反馈也会更快更多，如 github star。

随着插件化的稳定，群里已经不再是原来几千条信息的模样了，大部分开发者都在讨论实现，思路，同时有经验的开发者均能帮助我们解决群里绝大多数的问题，让我们轻松了很多，有更多的时间去思考，优化和拓展，而越来越多优秀的开发者贡献他们的插件，解决方案，文章等，也让我们学到很多。

大帅：教程：EROS集成到现有iOS应用 weex eros框架源码解析 - 掘金

反思当下才能无问西东

最近我们又从头反思了一遍，列出几点（不是全部）目前存在的问题：

操作体验需要优化
开发模板不够灵活
热更新服务不够灵活
复杂场景下的性能问题
需要支撑起更多类型的应用等
现有项目集成方案的规划与整理
插件生态的品控
文档的易懂与国际化等

很幸运，其中有几个问题已经有开发者为我们贡献了他们的方案，让我们有了更好的借鉴，而且不在孤单。

为什么未来会要先反思当前存在的问题呢？

没有问题，可能意味着这个项目就没有未来，从前面几个不同时期来看，如果我们不在一定的阶段，站在一个比现在更高的角度反思自己，那基本不会有现在的 EROS。

对于 WEEX

很多地方都有关于 WEEX 不好的言论，这里不做任何洗白的代表 EROS 开发者说几点：

上手有门槛，开发有门槛，很多场景下没有原生支持是很难的。
毋庸置疑是个好项目，Vue + WEEX 的开发体验真的很好，效率也很高。
但文档不全，资料不多，和官方沟通较难等都是显而易见的问题，好比隔着一个人传话，WEEX 更应该站出来拥抱开发者，多花些时间在开发者身上，去真正体会一下开发中的痛点，去拥抱更多的场景，需求。
开发项目链路很长，断崖式更新问题有时候真的避免不了，但如果发生了断崖式更新，也一定要在给予开发者更新指南，抽空也更新下官方的 DEMO，尽快发布一个稳定版本。
对于用户经常询问的常见问题给予更详细的说明和记录。
应该解决更多的极端性能问题，如 iconfont 字体使用导致内存吃紧等问题。
暴露出更多通用的原生能力。

不过据说 WEEX 今年会有较大的更新，我们有理由相信，上面的问题会被或多或少有所改善。

同时 EROS 期望做一个子集生态，通过受众开发者的不同，能反向输出的到 WEEX，为 WEEX 的发展近一点微薄之力。

为什么要做开源？

开源的优点很多，网上说的基本都有，这里说下我们的体会，不代表其他人：

对于发展中公司来说，如过遇到大量/爆发式的业务增长，往往技术都会要不断迭代，甚至是推翻重来，开源即是一个需求前置的过程，随着功能的积累能覆盖更多的场景，同时也是一个提升技术底层稳定性的过程。
团队相关，一个良好的开源项目可以提高整个团队的稳定性，凝聚力，在开源过程中会对每个人都有更多更全面的成长（沟通，协调，自我学习，自我驱动等）。
提升信心，尤其是小公司来做开源，起步是非常难的，开始时很少会有开发者会看好一个没有大公司背景的开源方案。

我们还在弯路上走着，或许前方就根本就没有直路，但我们还是走着。

EROS 链接

部分产品截图

感谢

starlife(新加坡)大前端团队
、车国大前端团队、钱保姆前端团队、shawn唐团队、凉城殇，何姐等独立开发者等插件贡献，方案输出，问题解答。
感谢这一年中陪我们趟坑的开发者，虽然以后可能还得继续。
感谢那些开源 EROS，WEEX 插件的开发者。
也感谢所有给出过 EROS 发展意见的开发者。
最后，感谢 WEEX。