电子商务网站建设规划方案,wordpress知更鸟 破解,保定网站建设价格,中国手工活加工网官网背景 beeshell 是一个 React Native 应用的基础组件库#xff0c;基于 0.53.3 版本#xff0c;提供一整套开箱即用的高质量组件#xff0c;包含 JavaScript#xff08;以下简称 JS#xff09;组件和复合组件#xff08;包含 Native 代码#xff09;#xff0c;涉及前端… 背景 beeshell 是一个 React Native 应用的基础组件库基于 0.53.3 版本提供一整套开箱即用的高质量组件包含 JavaScript以下简称 JS组件和复合组件包含 Native 代码涉及前端FE、iOS、Android 三端技术兼顾通用性和定制化支持自定义主题用于开发和服务企业级移动应用。现在已经在 GitHub 上开源地址https://github.com/meituan/beeshell 。 截止目前beeshell 中的组件已经在美团外卖移动端应用蜜蜂 App 中广泛应用而且已经持续了一年多时间通过了各种业务场景、操作系统、机型的实战考验具备很好的稳定性、安全性和易用性所以我们将其开源以期发挥出更大的应用价值。 特性 UI 样式的一致性和定制化。通用性。主要使用 JS 来实现保证跨平台通用性。定制化。我们在比较细的粒度上对组件进行拆分通过继承的方式层层依赖功能渐进式增强为在任意层级上的继承扩展、个性化定制提供了可能。原生功能支持。组件库中的复合组件包含 Native 代码支持图片选择、定位等原生功能。功能丰富。不仅仅提供组件还提供了基础工具、动画以及 UI 规范。完善的文档和使用示例。对比 在开源之前我们对业界已经开源的组件库进行了调研这里主要对比了 beeshell 与其他组件库的优势与劣势为大家选择组件库提供参考意见。目前业界开源的组件库比较多我们在这里仅选取 Github Star 数 5000 以上的组件库并从组件数量、通用性、定制化、是否包含原生功能、文档完善程度五个维度来进行对比分析 组件库组件数量通用性定制化是否包含原生功能文档完善程度react-native-elements16强提供一套风格一致的 UI 控件弱若要定制化可能需要重写否高NativeBase28强提供一套风格一致的 UI 控件中支持主题变量是高ant-design-mobile41强提供一套风格一致的 UI 控件中部分可以支持定制化需求是低beeshell25强提供一套风格一致的 UI 控件强不仅支持主题变量还支持使用继承的方式进行定制化扩展是高通过对比可以看出beeshell 只在组件数量上稍有劣势在其他方面都一致或者优于其他项目。因为 beeshell 具备了良好的系统架构所以丰富组件数量只时间问题而且我们团队也已经有了详细的规划来完善数量上的不足。 系统设计 系统设计是将一个实际问题转换成相应解决方案的主动过程是解决办法的描述。在通用的软件工程模型中需求分析完成后的第一步就是系统设计。一个项目最终的稳定性、易用性在很大程度上也取决于系统设计这一步。 beeshell 组件库是为了更加快速的搭建移动端应用为业务开发提供基础技术支持大幅提升开发人效。然而面对不同的业务方、不同的功能需求、不同的 UI 规范与交互方式如何有效的兼顾所有的需求这对系统设计提出了更高的要求下面以抽象层次逐层降低的方式来详细介绍 beeshell 的系统设计。 框架设计 这些年React Native 的出现为移动端开发提供了一种新的选择。React Native 相比原生开发有着更高的开发效率同时比 HTML5、Hybrid 的性能更好所以能够脱颖而出这也使得越来越多的开发者开始学习和使用 React Native。 beeshell 组件库基于 React Native向下通过 React Native 与 iOS、Android 平台进行系统层面的交互向上提供开发者友好的统一接口抹平平台差异为用户开发业务功能提供服务支持。beeshell 扮演了一个中间者的角色从而保证了移动端应用基础功能的稳定性、易用性。 框架设计确定了 beeshell 的系统边界指明了包含的功能与不包含的功能之间的界限。明确了系统边界我们才能继续进行下面的分析、设计等工作。 设计原则 在进行组件库的详细设计之前我们提出了几个设计原则 JS 实现优先。使用 JS 来实现功能有几个好处跨平台通用性、更高的开发效率、更低的学习和使用成本。继承与组合灵活运用。继承和组合都是实现功能复用、代码复用的有效的设计技巧都是设计模式中的基础结构。继承允许子类覆盖重写父类的实现细节父类的实现对于子类是可见的一般称之为“白盒复用”这对组件的定制化扩展很有效beeshell 强大的定制化扩展的能力就是基于继承实现组合是 React 推荐的方式React 组件具有强大的组合模型整体类和部分类之间不会去关心各自的实现细节它们之间的实现细节是不可见的一般称之为“黑盒复用”。beeshell 也广泛使用了组合基于通用型的组件组合出更加丰富、强大、个性化的功能在一定程度上提高了 beeshell 的定制化的能力。低耦合、高内聚。一个 beeshell 组件本质上就是一个 React 组件React 组件之间主要通过 Props 通信这属于数据耦合相比于内容耦合、控制耦合等其他耦合方式数据耦合是耦合程度最低的一种受益于 React 的实现beeshell 组件低耦合是自然而然的而要做的高内聚则对组件的编码实现方式有一定的要求我们推行内聚方式中内聚程度比较高的交互内聚和顺序内聚。使用单一数据源使各个元素操作相同的数据结构实现交互内聚。使用不可变数据更新的方式上一个环节的输出是下一个环节的输入像流水线一样处理逻辑这便是顺序内聚。方案设计 整体上使用 JS 作为统一入口多层封装隐藏实现细节抹平 JS 与 Native、iOS 平台与 Android 平台的差异开箱即用降低了用户的学习和使用成本。局部上基于 React Native 的技术特点分成 JS 组件部分和复合组件部分两部分推行“松耦合”的开发模式使得 Native 部分拥有替换变更的能力提升组件库的灵活性。 复合组件部分可以直接暴露 JS 接口如果有需要也可以在 JS 组件部分进行定制化封装。我们尽量保证 Native 部分功能的原子性、简洁性有任何定制化需求都使用 JS 来统一实现遵循 JS 实现优先的设计原则保证跨平台通用的特性。下面分别介绍 JS 组件部分和复合组件部分的设计。 JS 组件部分设计 一个软件的设计分为三个设计层次体系结构、代码设计和可执行设计。我们使用自上而下的方法从体系结构开始进行 JS 组件部分的设计。 软件的体系结构的风格通常有 7 种管道和过滤器面向对象隐式请求层次化知识库解释程序和过程控制。 JS 组件部分使用了层次化的体系结构风格整体分成三层基础工具、通用组件、扩展组件从上到下通用性逐渐减弱、定制化逐渐增强功能渐进式增强通过分层设计各层各司其职兼顾通用性和定制化。 基础工具common最基础的、通用的部分包含 JS Utils、动画定义、UI 规范等。通用组件components把功能相似的组件进行归类整理成一个个系列每个系列内部使用继承的方式实现层层依赖功能渐进式增强该部分专注通用性不考虑定制化需求保证代码的简洁性。同时在比较细的粒度对组件进行拆分提供了良好的可扩展性。扩展组件modules是对通用组件的继承扩展、组合应用该部分专注定制化在最大程度上满足业务上的需求通用性较低。我们扩展组件部分会提供大量的定制化组件如果仍然不能满足需求用户就可以借鉴扩展组件的实现根据自己业务需求在某一继承层级上继承通用组件自行进行定制化扩展这点充分体现了 beeshell 定制化的能力。 复合组件部分设计 既然是 React Native 组件库当然少不了 Native 部分复合组件包含 Native 的功能。beeshell 组件库已经完成了 Native 部分的集成方案与规范有良好的开发与使用体验可以不断的集成原生功能。 复合组件部分通过 JS 封装接口保证了跨平台。Native 部分主要分成 Native Bridge 和纯 Native 两大部分Bridge 是针对 React Native 的封装必须在组件库中实现而纯 Native 部分则可以通过 Pods/Gradle 依赖三方实现有效的吸收利用原生开发的技术积累。 组件库实现 跨平台通用性保障 React Native 提供了一些内置组件我们能使用 JS 来实现功能都是基于这些内置组件这些内置的组件一些是跨平台通用的组件如View、Text、TextInput而另一些是两个平台分别实现的如 DatePickerIOS 和 DatePickerAndroid、AlertIOS 和 ToastAndroid。跨平台组件当然没有什么问题我们可以专注业务功能的开发问题是这些非跨平台的组件给我们的业务功能开发带来极大困扰下面举例说明。 iOS 平台的 DatePickerIOS 组件 Android 平台的 DatePickerAndroid 组件 不仅功能交互完全不同而且类名、调用方式各异这不仅满足不了业务需求而且也有很高的学习和使用成本。这样类似的组件还有很多如何抹平平台的差异实现跨平台我们提出的方案是优先使用 JS 来实现功能这也是我们组件库的设计原则。 针对上面的问题我们开发了基于 ScrollView 的 Datepicker 组件统一类名与调用方式保证了跨平台通用性。 iOS 平台的 Datepicker 组件 Android 平台的 Datepicker 组件 Datepicker 是使用 JS 完全实现了一个完整功能但是有的情况不需要实现完整的功能我们可以通过 React Native 提供的 Platform 来进行局部的跨平台处理例如 TextInput 组件。 iOS 平台的 TextInput 组件 Android 平台的 TextInput 组件 我们可以看到在 Andriod 平台并没有清空图标为了抹平平台的差异提供更好的通用性我们开发了 Input 组件对 TextInput 进行封装与优化利用 Platform 定位 Android 平台提供清空功能 Input 组件在 Android 平台的效果 总之beeshell 对跨平台通用性做了进一步的优化遵循 JS 实现优先的原则配合 Platform 平台定位 API 为组件的易用性、通用性提供了更好的保障。 定制化支持 随着移动互联网的快速发展各类移动端产品涌现并且不断发展这也让软件知识不断被普及业务方对产品功能的定位逐渐从厂商主导转变为用户主导。产品功能更加精准个性化、细化、深化是必然趋势通过定制化服务来满足产品发展的要求也应运而生。不同行业、不同类型的产品功能、特点各不相同用某一种既定的软件产品来满足不同类型的需求其适用性可想而知。定制化有良好的技术架构和技术优势可定制、可扩展、可集成、跨平台在个性化需求的处理方面有着很好的优势所以我们需要定制化。 综上所述beeshell 把定制化作为核心特性力求满足不同产品的定制化需求下文将从组件的样式定制化和功能定制化两方面来进行阐述。 样式定制化 beeshell 的设计规范支持一定程度的样式定制以满足业务和品牌上多样化的视觉需求包括但不限于品牌色、圆角、边框等的视觉定制。 在组件库设计之初就已经统一好了 UI 规范。我们根据 UI 规范统一定义样式变量并放置在基础工具层中即 beeshell/common/styles/varibles.js 文件中在 React Native 应用中样式变量其实就是普通的 JS 变量可以很方便的进行复用与重写操作。React Native 提供了 StyleSheet 通过创建一个样式表使用 ID 来引用样式减少频繁创建新的样式对象在组件库的样式变量应用中灵活使用 StyleSheet.create 和 StyleSheet.flatten 来获取样式 ID 和样式对象。 在每个组的实现中会事先引入基础工具层中的样式变量使用统一的变量对象而不是在组件中自行定义这样就保证了 UI 样式的一致性。同时beeshell 提供了重置样式变量的 API可以实现一键换肤。我们推荐 beeshell 的用户在开发移动应用时事先定义好样式变量。一方面使用自己的样式变量重置 beeshell 的样式变量另一方面在业务功能开发时使用自己定义好的样式变量从而保证整体 UI 的一致性。 功能定制化 样式定制化可以从宏观和整体的角度来实现而功能的定制化则需要具体问题具体分析从微观和局部的角度来分析和实现。下文将以 Modal 系列的实现为例来详细介绍功能定制化。 在移动端的弹窗交互与 PC 端相比一般会比较简单我们把模态框、下拉菜单、信息提示等交互类似的组件统一归类为 Modal 系列使用继承的方式实现。有人可能会问为什么使用继承而不用使用组合前文已经讲过组合的主要目的是代码复用而继承的主要目的是扩展。考虑到弹窗交互有很多定制化的可能性为了满足更好的扩展性我们选择了继承。 首先我们看下几个组件的实现效果图对 Modal 系列先有一个直观的认识。 Modal 组件 提供了遮罩、弹出容器以及淡入淡出Fade动画效果弹出内容部分完全由用户自定义。这个组件通用性极强没有任何定制化的功能。这里需要说明下动画部分独立实现提供了 FadeAnimated 和 SlideAnimated 两个子类使用了策略模式与 Modal 系列集成Modal 组件默认集成 FadeAnimated。 ConfirmModal 组件 继承 Modal 组件对弹出内容做了一定程度的定制化扩展支持标题、确认按钮、取消按钮以及自定义 body 部分的功能通用性减弱定制化增强。 SlideModal 组件 继承 Modal 组件对动画、弹出容器做了重写在初始化时实例化 SlideAnimated 类型对象完成上拉、下拉动画同时支持了自定义弹出位置的功能。 PageModal 组件 继承 SlideModal 组件对弹出内容做了定制化扩展支持标题、确认按钮、取消按钮以及自定义 body 功能通用性减弱定制化增强。 CheckboxModal 组件 CheckboxModal 组件由 PageModal 和 Checkbox 两个组件使用组合的方式实现基于通用型组件组合出了更加强大功能遵循继承与组合灵活运用的设计原则。 通过以上部分我们已经对 Modal 系列已经有了直观的认识然后我们来看下 Modal 系列的类图以及分层 动画部分在基础工具common中实现在通用组件components中 Modal 组件聚合 FadeAnimated 动画同时因为 SlideModal、ConfirmModal 比较通用也在该部分实现CheckboxModal 则定制化比较强归类到扩展组件modules中。通过这种方式的分层三层各司其职使得组件库的层次结构更加清晰不仅实现了定制化还保证了通用部分的简洁性和可维护性。 复杂 Case 处理 相互递归处理异步渲染 React Native 应用的 JS 线程和 UI 线程是两个线程与浏览器中共用一个线程的实现不同所以我们可以看到 React Native 提供的操作 UI 元素的 API都是通过回调函数的方式进行调用。 受益于 React我们一般不需要直接操作 UI 元素但是有的组件确实需要复杂的 UI 操作例如完全由 JS 实现的 Scrollerpicker 组件 我们需要精确的计算容器以及每一项元素的高度才能正确得到当前选中的项在数据模型数组中的索引。现在面临的问题是在组件渲染完成后的生命周期 componentDidMount 并不能拿到正确容器的高度为而使用 setTimeout 也会有延迟时长设置为多少的问题。我们选择使用递归来解决一次 setTimeout 不行就执行多次。 这里使用了交互递归反复执行直到得到有效的元素尺寸。 UI 尺寸容错机制 React Native 为用户提供了 style 属性来控制元素的样式我们可以手动设置相关 UI 元素的尺寸。但是在一些 Android 机器上我们设置的元素尺寸与 measure 方法获取的尺寸信息不一致经过大量 Android 机器的实际的测试我们得到的结论是有零点几像素的误差。 我们把通过 measure 方法得到尺寸信息进行向上与向下取整得到一个阈值范围手动设置的尺寸信息只要在这个阈值范围内就认为是有效尺寸这种容错机制有效的兼容了极端情况提高了组件的稳定性。 精细化布局控制 在使用 Form 组件时最常见的需求就是校验功能通常组件库的 Form 组件都会内置校验功能。然而因为校验方式有同步与异步两种校验结果展示的样式、位置五花八门这就导致了校验功能的复杂度变得很高。 绝对定位 Static 定位 自定义位置 如何有效的兼顾不同的需求我们提出了校验独立实现的方式在使用 Form 组件的父组件中使用 CVD 来定义、配置校验规则校验结果输出到统一的数据结构单一数据源基于这个数据结构我们就能在任意时机、任意位置、使用任意样式来展示校验信息。 下面我们先介绍下 CVD CVD 是一个针对复杂表单录入场景的分层解决方案轻量级、跨平台、易扩展内置在 beeshell 组件库中可以直接使用。 CVD 把表单某个控件的录入的流程分成三层 Connector 连接器把用户输入的信息转化成所需的数据格式。Validator 校验器对格式化的数据进行校验。Dependency 依赖处理器处理当前控件与其他控件的依赖关系。每一层都对单一数据源 Store 进行不可变数据更新符合交互内聚和顺序内聚内聚程度高。 每一层使用函数式组合的方式定义 key表单控件的唯一标志与 key 对应的回调函数避免了批量 if else可以有效降低程序的圆环复杂度。 下面以 Input 组件录入姓名为例来具体说明代码如下 在 onChange 中获取用户输入调用 cvd.flow 然后就可以通过 cvd.getStore 获取到结果 通过校验功能独立实现把校验信息输出到 Store 中在需要的时候从 Store 中获取校验信息可以更加精细化的控制元素的样式、位置与布局兼容各种定制化需求。很多时候只有我们想不到没有做不到。 测试 代码的终极目标有两个第一个是实现需求第二个是提高代码质量和可维护性。测试是为了提高代码质量和可维护性是实现代码的第二个目标的一种方法。 单元测试 单元测试Unit Testing是指对软件中的最小可测试单元进行检查和验证。在结构化编程的时代单元测试中单元指的就是函数。beeshell 组件库全面使用单元测试由组件的开发者完成。研究成果表明无论什么时候作出修改都需要进行完整的回归测试对于提供基础功能的组件来说更是如此在生命周期中尽早地对软件产品进行测试将使效率和质量都得到最好的保证。Bug 发现的越晚修改它所需的成本就越高单元测试是一个在早期抓住 Bug 的机会。 单元测试的优点有以下几点 是一种验证行为。程序的每一项功能是测试来验证正确性为后期的增加功能、代码重构提供了保障。是一种设计行为。单元测试使得我们从调用者的角度观察、思考迫使开发者把程序设计成易于调用和可测试的在一定程度上降低耦合性。是一种编写文档的行为。是展示函数、类使用的最佳文档。beeshell 组件库使用 Jest 做为单元测试的工具自带断言、测试覆盖率工具实现开箱即用。 测试用例设计 测试用例的核心是输入数据我们会选择具有代表性的数据作为输入数据主要有三种正常输入边界输入非法输入下面以组件库中提供的 isLeapYear 工具函数来举例说明代码如下 Jest 使用 test 函数来描述一个测试用例其中的 toBe 边是一句断言。 函数使用了外部数据正常输入肯定会有这里的 2000 和 2000 都是正常输入边界输入和非法输入并不是所有的函数都有这里为了说明使用了有这两种输入的例子边界输入是有效输入的极限值这里 0 和 Infinity 是边界输入非法输入是正常取值范围以外的数据 xx 和 false 则是非法输入。一般情况下考虑以上三种输入可以找出函数的基本功能点单元测试与代码编写是“一体两面”的关系编码时对上述三种输入都是应该考虑的否则代码的健壮性就会出现问题。 上文所说的测试是针对程序的功能来设计的就是所谓的“黑盒测试”。单元测试还需要从另一个角度来设计测试数据即针对程序的逻辑结构来设计测试用例就是所谓的“白盒测试”。 还是以 isLeapYear 函数来进行说明其代码如下 这里有一个 if else 语句如果我们只提供一个 2000 的输入只会测试到 if 语句而不会测试 else 语句。虽然在黑盒测试足够充分的情况下白盒测试没有必要可惜“足够充分”只是一种理想状态难于衡量测试的完整性是黑盒测试的主要缺陷。而白盒测试恰恰具有易于衡量测试完整性的优点两者之间具有极好的互补性例如完成功能测试后统计语句覆盖率如果语句覆盖未完成很可能是未覆盖的语句所对应的功能点未测试。 白盒测试也是比较常见的需求Jest 内置了测试覆盖率工具可以直接在命令中添加 --coverage 参数便可以输出单元测试覆盖率的报告结果如下 可以看到代码的每一行都覆盖到了 Coverage 为 100%在很大程度上保证了功能的稳定性。 UI 自动化测试 想要确保组件库的 UI 不会意外被更改快照测试Snapshot Testing是非常有用的工具。一个典型的移动 App 快照测试案例过程是先渲染 UI 组件然后截图最后和独立于测试存储的参考图像进行比较。使用 Jest 进行在快照测试在 beeshell 中第一次对某个组件进行测试时会在测试目录下创建一个 snapshots 文件夹并将快照结果存放在该文件夹中。快照结果文件以 组件名.js.snap 命名其内容为某个状态下的 UI 组件树。 下面以 Button 组件快照测试为例来说明 运行命令后得到快照结果 静态分析 经常与单元测试联系起来的开发活动还有静态分析Static analysis。静态分析就是对软件的源代码进行研读查找错误或收集一些度量数据并不需要对代码进行编译和执行。 静态分析效果较好而且快速可以发现 30%~70% 的代码问题可以在几分钟内检查一遍成本低、收益高。beeshell 使用 SonarQube 进行静态代码检查。 SonarQube 是一个开源的代码质量管理系统支持 25 种语言可以通过使用插件机制与 Eclipse、VSCode 等工具集成实现对代码的质量的全面自动化分析和管理。 SonarQube 通过对 Reliability可靠性、Security安全性、Maintainability可维护性、Coverage测试覆盖率、Duplications重复几个维度对代码进行全方位的分析通过设置 Quality Gates 保证代码质量。 beeshell 组件库的分析结果概况如图 可靠性达到 A 级别是最高等级表示无 Bug 安全性达到 A 级别是最高等级表示无漏洞 测试覆盖率平均达到 70% 以上 开发与使用一致性 beeshell 组件库使用 npm 包的形式下载使用下载成功后会放置在项目根目录的 node_modules 目录然后在项目中通过引入模块的方式引入 beeshell 的组件来使用。 那我们如何开发组件库如何保证组件库的开发与使用的体验一致性 首先我们需要一个 demo 项目这个项目是 beeshell 组件库的开发环境是一个 React Native 应用。然后我们把 beeshell 做为 demo 项目的依赖在 demo 项目中下载安装。 现在我们的问题就变成了 node_modules 目录中的 beeshell 如何和本地的 beeshell 源码进行同步。 npm link 我们知道可以使用 npm link 来开发 npm 包原理如下 本质是就是使用 Symbol link但是我们建立好软链接后运行打包命令却报错了错误信息为 Expected path /xxx/xxx/index.js to be relative to one of project roots 我们前端开发通常会用 Webpack 做为打包工具而 React Native 应用使用的是 Metro我们需要分析 Metro 来定位问题。 Webpack vs Metro 经过 Metro 的源码分析我们发现 Metro 的打包方案与 Webpack 有较大差异Webpack 是根据入口文件即配置中的 entry 属性递归解析依赖构建依赖关系图而 Metro 是爬取特定路径下的所有文件来构建依赖关系图。 分析发现 Metro 的特定路径默认是运行打包命里的路径以及 node_modules 下第一层目录这样我们就定位到了问题的所在 Metro 在爬取文件的时候通过软链接找到了全局的 beeshell 但是并没有继续判断全局的 beeshell 是否有软链接所以无法爬取 beeshell 源码部分。 直接使用软链接 通过 ln -s 命令直接建立 demo 项目 node_modules 下 beeshell 包 与 beeshell 源码的软链接 这种方式同时支持 Native 部分 iOS、Android 的源码开发注意 Android 部分的需要在 setting.gradle 中调用 getCanonicalPath 方法获取建立软链接后的路径。 通过试验、发现问题、分析源码、定位问题、解决问题、方案完善这几个步骤完整的实现了 beeshell 组件库的开发与使用的体验一致性同时提升了组件库的开发效率。 未来展望 我们的目标是把 beeshell 建设成为一个大而全的组件库不仅会不断丰富 JS 组件而且会不断加强复合组件去支持更多的底层功能。因为我们支持全部引入和按需引入两种方式用户不需要担心会引入过多无用组件而使得包体积过大影响开发和使用效率。 beeshell 目前提供了 20 组件以及基础工具基于良好的架构设计、开发体验为我们不断地丰富组件库提供了良好的基础。同时在开发 React Native 应用的几年时间中我们已经积累了 50 基础以及业务组件我们后续会把积累的组件进行梳理与调整全部迁移到 beeshell 中。因为我们的组件主要来源于我们的业务需求但是业务场景有限可能会使得 beeshell 的发展受到限制所以我们将其开源。希望借助社区的力量不断丰富组件库的功能尽最大努力覆盖到移动应用方方面面的功能欢迎大家献计献策多多支持。 我们为组件库发展规划了三个阶段 第一阶段即我们现在所处的阶段开源 20 组件主要提供基础功能。第二阶段对我们在开发 React Native 应用几年时间积累的组件进行整理开源 50 组件。第三阶段调研移动端 App 常用的功能分析与整理然后在 beeshell 中实现开源 100 组件。开源相关 Git 地址 beeshell 核心贡献者 前端小龙孟谦Native渊博杨超
