可视化搭建平台已经比较普及了，具体原理本文不再赘述，这里和大家聊一聊搭建平台重要的一步：c端页面的生成流程。实际上主流的方式有以下两种：

1. 动态化方案：c端维护一个统一的入口页，动态拉取所需配置项以及组件代码。这种方式的优点是发布迅速，可批量更新、修复代码，但相应的需要维护一套后端服务，用以处理配置项的存储解析，组件的版本管理，页面组件的关系映射等。
2. 静态固化方案：每次生成页面时，根据特定活动的配置数据生成一个包含组件以及配置信息的入口文件，然后走一遍完整的前端编译流程。其优点是无需后端服务，不用再担心大促活动时的高并发影响，且页面与页面之间完全隔离、更可控，同时在c端页面的体验上要优于动态化方案。

以下就静态固化方案介绍下我们在编译速度上所做的优化。

如何快速定位和解决问题，前端调试指南供大家参考。

前段时间有个好玩的需求：把人、货、场的整个流程通过一个个节点有序排列出来。一开始觉得这很简单呀，用G6一条线搞定。接着，需要把不同领域拆分开来，那也简单，按照规则拆出几份出来就好了。但在做的过程中，发现不太对，每个领域在同一个时间节点的数据没有上下对齐，每个节点下罗列的几行内容，横向看起来也有错落，看起来不直观。接着，对整个数据结构进行一个算法调整，完美实现上下对齐，图文节点清晰。过程中踩了些许的坑，很上头。

设计超越竞品不能片面的论证是否超越竞品，而是建立在助力业务目标实现的基础上，所以设计超越竞品是需要基于不同维度进行可量化的效果评估，以用户的理性选择得出设计评估的客观结果。

本文结合 58 iOS App 项目实践，分享一次奇异的 Bug 排查经历，谈谈 GitHub 上一个知名的 RSA 算法库 Objective-C-RSA 使用过程中遇到的一些暗坑。此现象并非个例，希望对读者有所启发。

近年来，面对企业内部产品的多样性和业务快速增长，插画系统不仅提升了产品的整体美观度，也让工具变得高效。组件化的插画设计增加了界面的美观性，更好地传递品牌特性的同时也提升了协同效率。

富媒体当下各种样式的控件庞乱繁杂，接口方法不统一，开发者经常使用富媒体控件开发时需要注意的细节较多，比如要事先了解多种控件的api请求方法。

另外，富媒体当下发展得很快，快速迭代滋生了媒体控件的多和杂（工程中图片和视频类控件有很多种）。

当下环境的缺口是，整个市场没有一个统一封装的富媒体动效控件，整个应用级别目前没有一个整体的富媒体资源缓存机制，也没有一个与列表类控件形成高效复用的综合富媒体控件。

转转的移动端开发体系主要是基于 Hybrid 方案，但长久以来 Webview 容器和 SDK 管理等存在标准不统一、更新不及时的问题。随着转转/找靓机/采货侠等多环境开发场景越来越多，适配不同场景极大的影响了业务迭代效率。所有我们决定重新规划 SDK 的建设。

58集团与2020年底启动了Swift共建项目，内部称为混天项目。目标是搭建Swift的基础组件、辅助工具及基础设施。制定集团Swift开发规范和代码检测工具以及Swift在各个业务线中的落地。

房产业务作为集团核心产业，深度参与了混天项目的研发及Swift的落地。下面的内容主要是Swift在房产业务线从0到1落地的过程中遇到的一些问题和探索。

目前公司项目都是OC语言开发的,在这样的一个快速迭代历史悠久的项目中，短期内是不可能将所有项目用Swift重写，所以我们前期采用的都是Swift和OC的混合开发。

众所周知，性能在提升网站留存率和转化率方面扮演着很重要的角色，尤其对于转转这种电商网站，性能会间接影响到公司的收入。

但是如果让你去描述你们网站应用的性能时，你会怎么回答。你可能会说：比市面上大部分应用要好。但是如果要你说出好在哪里又该如何描述呢？这个时候我们就会想到先对网站进行性能监控，用数据说话。但是监控哪些指标、怎么监控呢？

不管是即将进入设计师行业的新同学还是在设计行业摸爬滚打多年的设计行业老人，这份用户体验设计标准流程都适用。一张图带你了解用户体验设计标准流程，让你的工作不出错。

最近接到一个需求，公司内部的 OA 系统（后端基于 jQuery 开发），需要给所有的表单增加暂存与还原功能。具体来说就是对于系统内的任何表单，都增加一个暂存按钮，用户填写到一半，点击暂存可以保存起来。下次再打开时，点击还原，可以恢复到之前编辑的样子，继续编辑。

在目前繁盛的互联网世界中，各个企业都面临着随时准备掠食的黑灰产从业者。由于互联网的隐身匿名性、技术的普及以及互联网的跨地域性，导致线上线下的黑产互相渗透、深度融合。网络黑产从传统链条发展到现在的生态化、智能化以及精准化，从而导致黑产行为泛滥蔓延，网络生态的治理面临前所未有的风险与挑战。为此本文利用无监督社区发现算法来对黑灰产进行识别，通过实验数据表明，该方式具有识别精度高、鲁棒性强等特点，为保障58业务安全提供了切实可行的技术方案。

在上一篇文章《唤起App在转转的实践》中，我们介绍了唤端技术的实现原理和一些实践。

虽然，当前方案已经支持了基本的唤端能力，可以说是唤端技术在转转的从 0 到 1。 然而，随着时间的迁移，支持兼容的业务逻辑越来越多，项目内部结构已混乱不堪、维护艰难，并且满足不了新的业务诉求，因此，决定对其进行一次重大重构。

经过业务反馈和调研，主要问题如下：

• 集团内App尚未完全覆盖，平台兼容性尚待完善。
• 未与行业方案对齐，满足不了业务提出的更高要求。
• 周边生态有待完善，业务使用体验有待提高。

对以上问题进行了梳理、评估，最终定下了本次重构目标：

• 整体架构升级，支持唤起多App，提升唤起兼容性。
• 对标业界方案，完善现有能力。
• 唤起App周边生态完善，提升业务体验。

在强调以用户为核心的今天，产品设计都围绕着用户出发。但实际上用户并没有按我们预设的路径来使用产品，那我们可以通过设计手段去引导用户行为吗？本文以实际项目为例，为大家分享如何通过设计去影响用户感知力，唤起共情并引导用户行为，最终提升产品转化。

Backend For Frontend，即服务于前端的后端。

面对越来越复杂的多端应用的需求，后端提供的 RESTful 接口形式难以应对多变的页面需求，这时候需要一层专门的 BFF 层来弥合这部分差异。