Fair-Online 是面向Flutter 开发者，提供从Flutter 在线开发，到实时编译预览，打包发布、动态下发端侧更新，实现Flutter 线上动态化的一体化云开发平台。开发者无需配置Flutter 开发环境，在线开发调试代码，即时编译预览，所见即所得，结合58开源团队打造的Flutter 动态化框架 Fair 及热更新平台 FairPushy ，实现Flutter 线上动态化。 目前Fair 云开发平台已在Github 开源： Fair-Online Github 在线体验地址： fair-online.58.com
58营销平台从58主战网站或其他来源收集到的联系过58的企业，可能联系58的服务付费的企业用户，对于这样的企业信息在营销平台中称为商机。一个商机通过一系列过滤补充及数仓计算后入到营销的数仓中。其中商机包含很多对应属性，类似于：商机名称、企业所在行业、企业规模、企业地址、商机最后联系时间、商机近7天/30天/60天/90天联系次数。 平台相关运营依据自定义配置规则，条件组合选出所需商机，对所选出的商机完成所需操作。类似于：商机打标签(商机增加标签标识，销售人员依据标签选出商机做对应跟进)、商机入沉寂(业务系统中数据状态转为沉寂，减少跟进)、商机回流(将沉寂库商机转入公共库使销售人员持续跟进)......等等类似操作。 针对以上需求及场景，开发数据应用平台基于数仓的商机表输出的es索引，配置自定义数据圈选规则，并对圈选出的指定商机创建数据应用任务。数据应用任务根据场景配置调用时间窗口等规则定时调用，处理后的数据应用至各个业务场景。
目前我所维护的项目是58到家工作端,定位是一款ToB的工具型应用,目的是帮助家政从业人员更方便的进行上户工作,随着业务的逐渐迭代,发现部分用户在日常的使用中存在作弊的现象,此现象的存在会导致未作弊阿姨可能接到的订单量减少,甚至在活动期间薅羊毛,影响派单的公平性以及增大公司的活动资金投入,因此需要我们对应用的安全性进行一定的提升以保证整体系统的安全性以及公平性. 现阶段接入了梆梆加固,在接入过程中需要确定相关加固策略,因此需要对应用加固有系统的了解,本文主要是对此次安全升级的总结及以及在58到家工作端中的落地实践.
在用户体验越发重要的今天，关注页面性能、提升页面展现速度及交互体验对前端开发越来越重要。 为了监测页面性能，chrome 开发团队就提出过监测网页性能的一些指标，比如 FP、FCP等，还有我们公司自己的北斗网站的秒开率、快开比等。但是这些指标具体怎样获取呢，今天我们就来仔细了解下这个性能监控有关的 API：PerformanceObserver。
在开发或使用低代码产品时，我们总会想到一个功能，就是预览，用来确认编辑的内容是否符合预期。 市面上的编辑器在预览方面有多种实现方式： 打开一个新的窗口，进行预览 直接在编辑区所见即所得 如果是用户，当然是选择第2种，最直观，最符合预期。 如果是开发者就会知道，之所以有这样多的可能性，是因为所见即所得非常依赖实际生产的运行环境，第1种单独打开窗口的实现成本比较低。 而有的编辑器虽然声称是所见即所得，但实际操作上，只是有相似度的所见即所得，因为实际运行环境和生产有较大的差距，仍然比较容易产生预期外的问题。 在我们团队的珊瑚海项目中，就实现了一个可以做到完全所见即所得的低代码编辑器，如果想了解该项目概况，可以访问下我们过往的两篇基本介绍文章。 《设计无侵入性的低代码编辑器》 《珊瑚海跨端解决方案及在移动端的布局动态化实践》 下面我就来介绍下，我们是如何实现的所见即所得低代码编辑画布。
Fair是58TC委员会推出的动态化开源项目。项目开源至今受到了行业内的广泛关注，也有很多小伙伴加入到了Fair项目中来，为我们提供了很大的帮助。 Fair在接下来会更加关注用户体验，持续降低接入和使用成本，打造出更好用的Flutter动态化方案。 转载文章是来自于“火花思维”小伙伴们从Flutter动态化立项到开发到上线的全链路分享，内容非常详实，非常感谢小伙伴们的认可，也为贵公司项目选择Fair落地Flutter动态化能力而感到荣幸。 以下为Fair调研-接入流程记录，欢迎在留言区评论交流。
在日常进行业务需求的开发时，经常会遇到需要绘制图表的场景，其中我们使用频率最高的图表库是 ECharts[1]。ECharts 作为市面上最成熟的图表库之一，主要面向 Web 端使用，官方对小程序端也提供了解决方案，而在 RN 的开发场景中却没有比较好的实现方法，面对这种情况以前我们的解决方案有： 1.放弃 ECharts，使用针对RN原生开发的图表库，如 react-native-charts-wrapper、victory-native 等 2.通过 Webview 来使用 web 端的 ECahrts，如 react-native-echarts-pro[2]、native-echarts 等 方案1，RN 现有图表库的样式与交互与 ECahrts 相比有较大差距，图表的丰富性也不足，尤其是有多端需求的场景下，需要为 RN 单独进行UI交互设计，设计与实现成本高。 方案2，通过 Webview 的方式，当页面上有多个图表或者图表元素过多时，会遇到性能方面的瓶颈，比如安卓端的大数据量面积图、单轴散点图等会有白屏现象，而且正常渲染过程中也会有比较明显的卡顿、掉帧的情况。 所以，
2022年8月，58同城TEG-AI Lab语音技术团队完成了WeNet端到端语音识别的大规模落地，替换了此前基于Kaldi的系统，并针对业务需求对识别效果和推理速度展开优化，取得了优异的效果，当前录音文件识别引擎处理语音时长达1000万小时/年，流式语音识别引擎支持语音对话量超过5000万次/年，详细工作可以参考《58同城：WeNet端到端语音识别大规模落地方案[1]》。 在优化工作中，我们复现了Efficient Conformer[2]模型，在实际场景数据上，与Kaldi最优模型相比，识别效果上CER绝对降低3%，解码性能提升61%。与Conformer相比，识别效果上CER从10.01%降低至9.30%，解码性能提升10%，结合int8量化，解码性能可提升60%。我们也在AISHELL-1公开数据集上进行了评测，CER为4.56%（No LM）。模型代码已开源至WeNet[3]。 本文主要介绍我们对Efficient Conformer的复现工作，包含：模型介绍、模型实现、流式推理支持以及相关实验结果。
