在用户体验越发重要的今天，关注页面性能、提升页面展现速度及交互体验对前端开发越来越重要。 为了监测页面性能，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的复现工作，包含：模型介绍、模型实现、流式推理支持以及相关实验结果。
深度学习推理平台在架构上属于WPAI的子平台，旨在将算法人员使用深度学习框架训练出来的模型部署到生产环境，提供高性能、高可用的在线推理服务。总体架构如下图所示，底层依托于Kubernetes和Docker，实现了对GPU/CPU等资源的统一调度和管理，网关侧搭配Istio实现了推理服务发现和流量治理功能；算法层集成了TensorFlow、PyTorch和PaddlePaddle等优秀的深度学习框架，同时也支持用户自定义服务；应用层从模型管理、部署、推理加速和服务高可用保障等方向都提供了一系列功能。支撑了58同城在图像、NLP、语音、搜索、推荐、广告、风控领域内的各类AI应用，目前已上线模型数1000+，峰值节点数4000+，日均流量30亿。本文主要介绍深度学习推理平台推理架构的演进过程，以及新架构下在流量治理建设和可观测性建设方面的设计细节。
北斗前端监控系统是 58 内部的一个线上质量监控排查解决方案，用于帮助用户大幅提升定位问题和优化项目的效率。系统共分为数据收集（SDK）、数据处理（Java）、数据存储（Druid、……）、数据分析（Node.js）、数据展示(React) 5 层模型。Node.js 作为系统中的数据分析层，提供各种数据分析和应用的方式。 在一期之后，系统的基础功能已经完备。平台可以收集 5 种类型、30 多种指标的数据，已经具备了很强的数据收集能力，数据应用的方式却很匮乏。 所以在二期开发时，我们计划在 Node 端加入多种数据应用的方式。实时告警，就是其中之一。 简单分析需求，服务端需要以一定的频次（例如每分钟）监测不同项目中用户配置关注的指标数值。当数值出现异常时，给用户发送邮件、短信等告警信息用于警示。 而其中的重点，就是如何在 Node.js 中设计并实现定时任务系统？
WLock为⽤户提供了秘钥作为集群分配、锁操作、隔离、权限控制的租户单位。为了保证数据的强一致性与服务吞吐能力，每个节点采用多Paxos分组并行向所有副本同步锁状态数据。业务接入前，首先会创建秘钥，并为秘钥分配可用的服务集群（通常包含5个节点）。在生产环境，如果为每个接入的业务独立部署集群，随着接入量的增多，存在管理不便以及资源浪费的问题。所以WLock采用的是多租户共用一个集群的部署方式，但这种方式必须要解决多个秘钥的租户因调用量参差不同而相互影响的问题。
