用户体验

<article class=“article fmt article-content”><p>用户故事在软件开发过程中被作为“形容需要”的一种表达形式，是定义用户想要什么的简略办法。通过它能够分明地解释产品。一个好的用户故事能帮忙利益相关者了解产品的性能，并且有助于向客户介绍产品是什么。用户故事都会写，但如何写出最贴近用户理论场景的用户故事？</p><h3>1 ）用户故事根本表达式</h3><p>为了标准用户故事的表白，便于沟通，用户故事通常的表白格局为：<br/><strong>作为一个<用户角色>, 我想要<实现流动>, 以便于<实现价值>。</strong><br/>一个残缺的用户故事还应该蕴含以下三个因素：</p><ul><li>角色（who）：谁要应用这个。</li><li>流动（what）：要实现什么流动。</li><li>价值（value）：为什么要这么做，这么做能带来什么价值。</li></ul><p>举个例子：“<strong>作为一名</strong>禅道项目管理软件的用户，<strong>我心愿</strong>看板抉择自适应列宽时，不会铺满全屏，<strong>这样能够</strong>节俭空间，操作便捷，在观感上更加好看简洁。”<br/><br/>除了格局标准、因素残缺外， 一个好的用户故事还要遵循INVEST准则：<br/></p><h3>2 ）好故事编写指南</h3><p>一个好的用户故事能够用简略的语言让每个人都能够了解。让技术和非技术成员都应用它作为交换的媒介。<strong>如何编写出一个好的、让人易于了解的优良故事呢？上面分享几个要点</strong>：</p><h4>从指标故事开始</h4><p>一些大型项目，通常会波及多个用户角色，这就导致咱们有时很难晓得从哪里开始辨认故事。要想辨认故事，首先要<strong>思考每个用户角色，并思考他们应用本产品的指标是什么。</strong></p><p>举个例子，比方开发某招聘网站我的项目，角色是求职者，TA的指标是找到一份工作（这是主指标）。咱们可了解为：有什么性能能够反对TA找到一份工作。而后将其拆解为几个子目标：</p><ul><li>搜寻TA感兴趣的工作（基于技能、薪资和地点等）。</li><li>主动执行搜寻，因而不用每次都手动搜寻。</li><li>让TA的简历可见，以便招聘公司能够搜寻到TA。</li></ul><p>划分之后，上述的子目标还能依据须要衍生出其余的故事。比方依据定位主动举荐相应区域的岗位，这样故事的撰写就逐步清晰了起来：<br/></p><h4>编写关闭的故事</h4><p><strong>关闭故事是指随着故事的实现实现，一个有意义的指标也随之实现</strong>，这能让用户感觉TA实现了某件事。</p><p>比方，还是招聘网站我的项目。其中一个故事为“招聘人员能够治理其公布的广告”，这就不是一个关闭故事，因为这是一项继续的流动。怎么编写能更好呢？能够这样：</p><ul><li>招聘人员能够更改招聘广告的截至工夫。</li><li>招聘人员能够删除与职位不匹配的申请等等。</li></ul><h4>故事中要包含用户角色</h4><p>如果我的项目团队曾经辨认出了用户角色，那么<strong>在编写故事时就应该应用这些具体的角色，而不是用较为抽象的角色</strong>。比方不要写成“用户能够公布本人的简历”，应该写成“求职者能够公布本人的简历”。因为“用户”蕴含了“岗位发布者”和“求职者”两种，这会减少开发对需要了解的难度。</p><p>能够用后面咱们提到的表白格局：<strong>作为一个<用户角色>, 我想要<实现流动>, 以便于<实现价值>。</strong> 这样就能帮忙辨别重要的和无价值的故事，也能更加清晰明确。</p><h4>不要适度依赖用户故事</h4><p>用户故事尽管是一种常见的需要收集和表达方式，但并不是惟一的形式。团队依据我的项目的具体情况，能够联合其余办法来收集和记录需要，以确保全面和精确地捕获我的项目的需要。这样做能够提供更残缺的视角，并满足我的项目的特定需要和要求。</p><h4>为一个用户编写故事</h4><p>只为单个用户编写故事时，故事通常更容易被了解和浏览，故事也更加具体和清晰。但并不是所有的故事都会因为用户数量的变动而产生差别。对于很多故事来说，无论是为一个用户还是多个用户编写，故事的内容并没有太大区别。然而，对于某些故事，用户数量的变动可能会对故事产生很大的差别。比方以“求职者能够从网站上删除简历”为例。它就有两种解释：</p><ul><li>一个求职者能够删除本人的简历；</li><li>一个求职者能够删除其他人的简历。</li></ul><p>如果咱们只思考一个用户的故事，那么问题就会变得清晰起来。比方能够将故事改为：求职者能够删除本人的简历。</p><h4>应用被动语态</h4><p>在编写用户故事时用被动语态，而非被动语态，尽可能让故事清晰简洁易懂。比方“简历能够被求职者公布”就能够改为“求职者能够公布简历”。</p><h4>客户编写</h4><p><strong>在现实状态下，客户应该参加编写故事。</strong> 客户有责任确定每次迭代的故事优先程序，所以客户对每个故事的理解至关重要。为了确保客户对故事有充沛的理解，能够让客户亲自参加进故事编写，同时也为了防止只由开发人员独自编写故事而导致的了解偏差或误会。</p><h4>不要遗记目标</h4><p>在编写时，记住故事的目标是为了<strong>促成对话</strong>，确保故事可能起到引发对特定性能或需要的探讨和交换的作用。为了达到这个目标，用户故事应该放弃简洁明了。</p><h3>3) 最初</h3><p>假如“求职者能够搜寻未实现的工作”这个故事太大了，不适宜一次迭代实现。你会如何拆分它？</p></article>

*昨天，一位同学在咱们社群分享了DockQuery的应用体验，失去许多搭档的共鸣。文中介绍了DQ的装置和应用步骤，具体比拟了DQ与达梦工具的异同，从普通用户的角度总结出DQ的劣势与有余，为产品后续改良提出了宝贵意见。*每位用户的应用体验对咱们而言都是举世无双的，欢送大家退出DockQuery社区，建言献策，见证产品的更新迭代，播种个人成长与提高。当初一起来看看这篇分享吧！ 以前感觉国产数据库离咱们很远，我始终应用的是 mysql、postgres这类支流数据库。自从退出了一家政务行业研发公司做零碎研发，国产数据库应用得越来越频繁，近一年来的我的项目应用的都是国产数据库。 在各个我的项目中，我陆续应用过TIDB、达梦、opengauss等数据库。TIDB采纳的是mysql连贯协定，所以有很多客户端可供选择；然而达梦数据库始终没有被支流的数据库工具(如navicat、datagrip 、DBeaver)反对，只能抉择达梦官网DM管理工具。这个工具始终以来都只是“能应用”的水平，对于开发者并不是很敌对。 近期发现一款数据库客户端叫DockQuery，声称反对达梦这类国产数据库。因为报名加入了达梦的数据库beta流动，急需一个好用的国产数据库工具，我从官方网站下载了DockQuery。 体积1GB，大小是不是有点夸大，只有百度云下载渠道（100～200K的速度），未入门就让我想放弃。 带着对国产数据库工具的好奇，我还是决定挂机下载一晚。通过一晚工夫，DockQuery工具已下载实现。居然是个绿色版（免装置客户端），不必放心又给我装置一堆其余垃圾软件，哪个工具是垃圾也能够间接删了。对于软件应用，我向来习惯上手干从来不看应用文档。关上软件后感觉界面有点在抄navicat 界面风格应用习惯，隐约里又看到eclipse的影子（应用idea久了，再看eclipse有点老掉牙）。这下释怀了，学习老本又升高了。不过在应用过程中还是显著发现界面有点糙，细节解决得不是很好。 拿数据库先试试，目前只反对三款数据库：达梦、opengauss、Vastbase(???这是个什么数据库)。至多三个里有两个是我用到过的。应用祖传的 next by next 招式，很从就实现数据库创立。达梦连贯与其余工具没有差异，不再一一阐明。 先说说比拟好的感触吧，重点与DM工具相比拟。编辑器性能做的还是比DM强一丢丢，有语法提醒、格式化、代码折叠、切换数据源。 语法提醒性能 DM工具也反对语法提醒，但默认状况是不开启这个性能，能够通过配置关上语法提醒性能。应用体验始终都得很卡，不晦涩反馈很慢。对于平时写SQL语法体验十分不好，想必这就是官网默认不开启的起因之一吧。DockQuery编辑器关键字与数据库动静提醒响应很疾速，基本上秒出，能够晦涩应用工具，体验上比DM工具好太多了。不过对于提醒的类型短少分类，不能很好的辨认表、字段还是关键字等。倡议官网思考从这个方向优化后续版本。 切换数据源性能 这个性能navicat 始终都有，我也始终在应用，是比拟不便的中央。作为开发很多时候要验证bug，须要针对多个环境数据进行查问验证，不须要针对多个数据源关上多个查问窗口进行切换验证。这一点也体现了DockQuery 作为客户端工具在投合客户端应用的需要点。 代码格式化与代码折叠 这两个性能合起来比拟有特色。代码格式化自身没有什么好阐明的，就是重点说说折叠性能，这个拆叠比拟像代码编辑器的折叠性能。能够将语句通过格式化后的关键字进行代码档次的收起与开展。 通过代码折叠，极大晋升了编辑器应用体验。集体十分喜爱这个性能带来的SQL语句浏览清晰构造、关注重点语句局部。 最初再补充些毛病问题吧。整个软件还是有一些些不成熟，很多性能在应用过程就能感触进去，还须要几个版本的迭代能力达到日常应用。毕竟还是在beta版本，有一些不稳固的问题也很失常。对于国产数据的反对，加上些特色性能，起码给咱们多一份抉择和可能性。 加油 DockQuery ，期待后续版继续改良！ 看了下面的分享，你是否对DockQuery更感兴趣了呢？欢送扫描下方二维码增加小助手，退出官网微信群，获取安装包，开启您的DockQuery之旅！

在任何业务中，用户体验的重要性显而易见，很多时候，用户体验被误认为是在大型的软件开发我的项目中才会被着重关注的中央，但实际上并不是这么回事。 企业要取得长足发展，而用户很难依据产品的性能和定价去辨别并定位不同的企业或组织。因而，客户本身的“体验”就会成为被提及的聚焦的亮点，这从另一方面揭示咱们：企业能够通过精心打造“客户体验”，凸显企业的不同凡响，从而取得商业上的回报。 用户体验，即UX，这个标签涵盖了专一于进步最终用户的易用性和满意度的钻研和设计畛域。现实状况下，良好的用户体验设计，能够让面向客户端的应用程序或者网站的实用性大幅提高，也能在应用过程中让用户产生愉悦的感觉。 通过低代码开发平台打造高效、易用、互通、易保护的企业应用能够给企业带来质的飞跃。低代码已被证实是一种可能减速数字化转型的工具。企业岂但可能通过低代码构建利用，还能够疾速、大规模地进行迭代，通过自动化优化业务流程，充分运用数据和API的力量来推动翻新。 但达成“完满用户体验”很难成为一个欲速不达的后果。体验自身就是一个十分主观的概念，针对所谓的“公众审美”提供一些所谓的页面模板尽管可行，但实际上，大量我的项目的理论状况是，客户对于“体验”的了解、判断规范、预期形式千差万别。客户并不认可对立模板和规范，更偏向于依据本身业务用户的预期，一直打磨利用的用户体验。 因而LeaRun低代码开发平台采纳组件化开发，将用户体验细化，把反复的代码提取进去合并成为一个个组件，成为一个个小的单位，形象出适宜不同利用类型的各种模块化的组件。如此，用户就能够以拖拽的形式，疾速在利用里启用这些用户体验能力。 但企业的资源毕竟无限。尽管LeaRun低代码开发平台已为客户开发了多种根底组件，然而依然无奈保障可能穷举和笼罩客户全副的业务场景。所以，LeaRun低代码开发平台采纳全源码交付的模式，用户能够依据本身的业务场景，自行开发满足本身要求的组件。通过将扩大的能力赋能给用户本人，平台就取得了近乎有限的用户体验开发能力。 另一方面，每个流程都会影响用户体验，流程优化正在推动竞争劣势。但许多企业机构仍难以解脱纸质流程和电子邮件审批工作流程，这不仅仅会拖慢工作进度，还会对员工和客户产生负面影响。更甚者，数据被困在利用孤岛中，进一步升高了客户和员工的体验。 LeaRun低代码开发平台以流程为外围，提供设计灵便、功能强大的图形化流程配置工具，反对多场景、跨零碎业务流程，反对拖拽式配置业务流程。帮忙业务人员实现低门槛的可视化流程再造与设计，打造一体化协同办公，疾速响应业务需要。 为了在不同模式和情境中发明统一的体验，LeaRun低代码开发平台装备了开箱即用型API的应用，这些API能够轻松连贯不同的零碎和数据源。依附疾速、牢靠的系统集成，开发者可能疾速连贯各外围记录零碎并满足客户残缺体验的需要。 低代码从概念到实际，从宏观趋势角度来看减速了企业数字化转型；从市场的角度来看，满足了行业节约老本的须要；从行业客户体验后果来看，低代码带来的不仅仅是惊喜更是效率。LeaRun低代码开发平台通过应用对立、可视化、引擎驱动的语言将所有这些联合在一起，为用户提供全方位的卓越体验。 体验传送门：www.learun.cn/Home/VerificationForm

在遇到网页内容有着较大调整的时候，往往需要一个导览功能去告诉用户，某某功能已经调整到另外一个位置。比较常规的办法是添加一个蒙层，高亮显示被调整的区域，然后通过文字介绍去完成引导。我们把这个功能称为“导览”，而 Smartour 则把这个导览的功能抽离出来，提供了一个开箱即用的解决方案。 项目地址：https://github.com/jrainlau/s...官方示例：https://jrainlau.github.io/sm... 安装Smartour 被构建成了 umd 模块，允许用户通过不同的方式引入。 npm install smartour/* ES Modules */import Smartour from 'smartour'/* CommandJS */const Smartour = require('smartour')/* <script> */<script src="smartour/dist/index.js"></script>const tour = new Smartour().queue([{ el: '#id', slot: ` <p>Something you want to guide to the visitors</p> `}])tour.next()配置项Smartour() 是一个构建函数，它接受一个 options 对象作为其配置项。 { // `maskStyle` 为导览蒙层的样式 // 默认值将会和配置的值叠加，配置的内容可覆盖默认值 markStyle: ` position: fixed; box-shadow: 0 0 0 9999px rgba(0, 0, 0, .5); z-index: 9998; `, // 默认值 // `slotStyle` 是导览介绍内容的样式 // 默认值将会和配置的值叠加，配置的内容可覆盖默认值 slotStyle: ` position: fixed; z-index: 9999; }` // 默认值 // `maskPadding` 设置高亮区域的内边距 maskPadding: { vertical: 5, horizontal: 5 }, // 默认值（垂直、水平） // `slotPosition` 设置导览介绍内容的位置 // 可选项为：'top', 'top-right', 'top-left', 'bottom', 'bottom-right', 'bottom-left' slotPosition: 'bottom', // 默认值 // `maskEventType` 导览蒙层事件触发的方式 // 可选项为：'click', 'mouseon', 'mouseover', 'mousedown', 'mousemove', 'mouseup', 'touchstart', 'touchmove', 'touchend' maskEventType: 'click', // 默认值 // `maskEvent` 导览蒙层事件 maskEvent: () => {} // 默认值APIqueue(TourList) ...

2019年6月28日，在中国国际软件博览会上，蚂蚁金服金融科技产品技术总监杨冰发表主题演讲，分享了蚂蚁金服在过去的十多年里，是如何通过商业创新与技术创新的双轮驱动，创造出数字时代的普惠金融“奇迹”。 十多年以前，大概很难有人能想象到如今我们习以为常的生活场景：只要带上手机就可以放心出门，从购物到餐饮，从打车到住宿，甚至理财和贷款，都只需轻点几下屏幕。 十多年以前，大概也很难有人能想象到金融业会发生如此深刻的变革：人满为患的实体网点、冗长的申请表单和繁复的审批流程都逐渐成为过去时；传统金融行业因成本和风控问题而难以触达的用户，比如小微企业和个人，也日渐成为银行的目标用户群体。 越便捷的服务，需要越强大的技术蚂蚁金服为金融业的变革做了些什么？ 在过去的十五年中，它通过技术重塑了支付服务小微贷款服务，让普惠金融服务对于每一个普通的中国人来说，都变得触手可及。 基于互联网和移动互联网，蚂蚁金服的产品为用户带来了前所未有的轻松和便捷：转账无需再去银行排队，在只需在手机上轻点几下；消费无需现金，二维码支付已经遍布中国的大街小巷；即使没有信用卡，只要开通花呗即可先付后还；余额宝可以让用户通过手机就能实现理财，而如果一名小微企业主想要贷款，只需要花3分钟在网上填写申报材料，1秒钟就能实现贷款到账，整个过程中零人工干预。 但是，用户对于快捷和便利的要求不断增长，也给金融机构带来的全新的挑战。在挑战面前，唯有技术的创新和发展才是最有力的武器。 通过智能手机，用户可以随时随地发起交易，线上交易流量远非传统银行柜台业务可比。在类似“双十一”的大促活动中，每秒的交易峰值可达数十万笔，在这样巨大的流量面前，如何保持交易系统的稳定、安全、高可用，保证数据没有任何丢失和偏差，这是互联网时代的“新型银行”必须面对的难题。 金融交易技术中，最关键的是分布式数据库能力。随着蚂蚁金服的业务量突飞猛进，依靠开源的分布式系统已经不足以解决问题。2009 年，蚂蚁金服自主研发金融级分布式关系数据库 OceanBase，这是一个专长于高可用、一致性的分布式数据库，结合蚂蚁自研的金融级分布式中间件，整个系统具备百万级每秒的伸缩支付能力，成功经受住了“双十一”交易量每年翻三倍的考验。 金融交易的另一个关键点是风控，这关系到金融业务的生命线。传统金融机构用严格的审核来控制风险，但在互联网时代，为了用户体验及时流畅，消费、信贷、保险等交易的审核都必须在尽可能短的时间内完成。 对于金融机构而言，这可谓压力山大：交易是否违规？是否虚假交易？是否合谋套现？如何在不借助担保材料的情况下来判断借款者是否可靠？如何甄别诈骗和洗钱？如何避免坏账和资金损失？这一系列复杂的问题，都要在毫秒级的时间中里找到正确答案。 传统金融机构依靠人力来审核的做法显然是行不通的，不但成本高企，时间也不允许，因此必须要有一套数据和算法构筑的庞大、复杂而精密的平台，依靠海量的计算来做出精准的决策。 这不是一件简单的事，因为每一笔交易都关系到真金白银，出错就会带来资损，金融级对于精确和稳定的要求非常高，尤其在延时性要求也非常苛刻的情况下，对技术是很大的考验。举例而言，如果要甄别一个花呗账号是否有套现嫌疑，既要做实时的特征计算，还要用图计算去查看与这个账号关联的资金情况。如果在多种计算模式之间来回切换，不仅会增加成本，还会带来延时，影响用户体验。 蚂蚁金服：不是取代者，而是支持者强大的技术支持，让蚂蚁金服实现了快、稳、准，许多本来难以享受金融服务的企业和个人，如今也可以享受到普惠金融带来的便利。在传统金融机构看来，像这样的新型科技金融机构是强有力的竞争者，发达国家的许多银行家担心，新兴科技公司的崛起将挤压他们的份额。 但在蚂蚁金服看来，这种担心是多余的：蚂蚁金服不会取代传统机构，而是扮演支持者的角色，通过技术开放帮助机构提升服务效率和质量。 自研技术的基础上，蚂蚁金服还一直在扮演着推动技术开放，为传统金融业赋能的角色。因为蚂蚁金服定义中的普惠金融，不仅是自身要服务大量的用户，让原本难以享受到便捷金融服务的用户受益；还要通过技术的开放，让更多的金融机构具备更好地服务大量用户的能力。 在金融业变革的大势之中，许多传统金融机构都走上了数字化转型的道路。转型之中，他们不约而同地遇到了相似的门槛：如何快速搭建线上业务？如何利用互联网获客、扩大业务规模和覆盖范围？如何基于互联网用户群体的特性开发新的产品？ 蚂蚁将自己沉淀下来的技术和经验开放出来，让传统金融机构在面对这类问题时，手握更具效率的工具，也少走了很多弯路。 三大PaaS产品都是蚂蚁金服技术开放的结晶：mPaaS（mobile PaaS）能够快速帮助这些机构开发移动APP；bPaaS（business PaaS）是凝结了蚂蚁金服多年来积累的分布式金融核心能力的套件，能帮助这些机构在最短三个月内快速“复制支付宝的能力”；dPaaS作为一个数据智能平台，借助强大的底层数据引擎，通过海量的计算，能帮助这些机构获得基于大数据的业务分析洞察能力和实时智能决策能力。 mPaaS自2017年下半年开始推广以来，已经帮助多家股份制银行和城市商业银行完成互联网金融升级，如广发银行，华夏银行，苏州银行等。mPaaS团队仅用了不到三个月的时间，就帮助铁路售票系统12306 App完成重构，极大提升了性能和效率。此外，mPaaS还和上海地铁深入合作，推出了“Metro大都会 App”，实现扫码进站，为日均客流量超过1100万人次的上海地铁解决了排队买票的问题。 bPaaS的面世，为传统金融机构的转型提供的现成的平台，让他们不必再从零开始摸索和开发自己的分布式业务系统，节约大量时间的同时，也极大减少了分布式技术在核心业务中的落地难度。bPaaS中整合的是蚂蚁金服十几年来在金融业务实践中经过无数次验证的技术和解决方案，在保持银行传统核心稳定的前提下，bPaaS可以根据不同银行差异化的业务场景，快速定制新业务场景。随着bPaaS的开放，金融机构在最短三个月内“复制蚂蚁金服的核心技术能力”，完全可能成为现实。 dPaaS则针对传统金融机构转型中使用数据门槛过高的痛点，主要提供“三合一”的数据智能能力：处理海量数据的工具，收集和存储数据的标准，使用数据的方法论。在风控和营销场景之中，dPaaS都有突出的表现，在dPaaS的帮助之下，传统金融机构能够更为顺畅地使用数据来提升业务，将手中的数据资产切实有效地转化为业务能力，实现数据的价值。 《经济学人》特别指出，技术对金融业的意义深远。科技创新可以孕育更灵活、便利、开放的金融系统，而智能手机和数字技术在金融业的广泛应用将成为推动社会经济发展和普惠的最佳途径之一。在运用数据和数据技术规避风险、降低成本、促进业务成长、推动普惠金融等方面，以蚂蚁金服为代表的中国金融科技公司已经走出了一条自己的道路，同时，也在不断将技术进步的趋势推广到全世界。 本文作者：华蒙阅读原文 本文为云栖社区原创内容，未经允许不得转载。

如何像参与开源那样，去参与一款 IDE 插件的设计？ 作为一款 IDE 插件的使用者，我是否能决定下一个版本的功能？ 自从产品经理银时小伙和他的开发小哥们在去年12月发布 Cloud Toolkit（一款 IDE 插件）以来，已帮助数以万计的开发者们提高了业务的部署效率。期间，开发者们不仅是 Cloud Toolkit 的使用者，同时也作为设计者参与了插件的更新迭代。 本文来自开发者徐靖峰，分享了他和 Cloud Toolkit 的故事 遇见 Cloud Toolkit在与中间件小姐姐的一次聊天中，偶然间了解到这款插件，小姐姐跟我提到自己正在运营一款 IDE 开发者工具，能够使开发部署效率提高 8 倍，出于好奇心，我就上手体验了一下，看看究竟是一个什么样的产品。使用了一段时间之后，便迫不及待地向小姐姐分享了我作为开发者对插件的一些看法。 我对这款产品最直观的感受：这是一款发布工具，帮助用户在 IDE 中直接打包应用并部署到各种终端。一开始看到这款产品位于阿里云的页面中，原本以为是一款和阿里云服务强绑定的产品，但试用过后才发现，即使对于普通的云主机，也非常适用，还可以解决很多开发运维的痛点，非阿里云用户可以放心使用。 在 Cloud Toolkit 出现之前作为一个 Java 程序员，我们大多数会在 Intellij IDEA 中基于 SpringBoot 来开发 WEB 应用，所以本文中的测评将会基于以下几个架构来构建： 开发环境：IDEA项目组织方式：Maven开发框架：SpringBoot在接触 Cloud Toolkit 之前，用什么方法来部署一个 SpringBoot 应用呢？作为一个偏正经的测评人员，我不会为了凸显出 Cloud Toolkit 的强大而去翻出一些上古的部署工具来做对比，而是直接使用 Intellij IDEA 的内置功能与之对比。 第一步：配置服务器信息 在 Tools -> Deployment 中找到 IDEA 对项目部署支持的内置插件，我们可以在其中进行服务器信息的配置，包括服务器地址和权限认证，并且在 Mapping 选项卡中完成本地工程与服务器路径的映射。 第二步：配置 Maven 打包插件<build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> </plugins></build>由于是 SpringBoot 应用，配置专用的打包插件后，可以将整个工程打成一个 fatjar，示例工程非常简单： ...

首先感谢@栖冰 @祖建国 一起对FFW的预研做的投入！ 背景Google在最新的Google I/O上推出了Flutter for Web，旨在进一步解决一次代码，多端运行的问题。Flutter for Web还处于早期试验版，官方不建议在生产环境上使用。那么到底它的实际情况怎么样呢？ 我们做了一次预研。期望这次预研的结果可以帮你决定是用，还是不用FFW。 Flutter for Web原理 Flutter for Web和Flutter在上层都是Dart环境，两者不同的是，Flutter的Dart代码运行在Dart虚拟机中，界面由Flutter引擎处理，通过Skia绘图引擎经由GPU绘制到屏幕上。而Flutter for Web的Dart代码编译成JavaScript，界面上部分转换成标准的html标签，部分转换成通过Canvas绘制的自定义标签，最终构成一个dom树。这个原理上的差异非常重要，这直接可以让我们通过原理得出下面的结论： Flutter for Web的一致性和体验上存在矛盾如果Flutter for Web追求（和Flutter）完美的一致性，势必需要大量使用Canvas去绘制，而Canvas去绘制组件的性能（尤其在移动端）至少不会比html标签好。如果FFW追求性能极限而使用大量标准的html标签，这就会带来和Weex、RN等一样的一致性问题：对于Flutter所有的控件都是一套代码在绘图引擎上绘制，对Flutter for Web如果要使用大量html标签，那如何保证一致性呢？只能靠大量精细的打磨工作了。所以FFW必须要处理好这个平衡。 为啥使用canvas绘制性能不优于手写html呢，定性的从几个角度分析： FFW在canvas上绘制的组件带有很多MD特色的视觉和动画，比如阴影、Z轴变化等，这部分对性能的消耗要大于普通html标签FFW是通过Dart的DSL转成的dom树结构，转化后的dom树十分复杂，不太可能比手写的dom树更简洁使用canvas的控件，其手势事件的捕获分发都是靠FFW框架自己实现的，emmmm虽然不排除Google大力出奇迹的情况，但是不管怎样，相同素质的开发人员，相同的界面，性能上也不可能优于html+css+js另外一点，如果FFW在原理上涉及大量HTML标签的转化，那就势必会涉及到碎片化的处理中，浏览器的碎片化程度可一点都不比Android系统的碎片化小。像Flutter本身之所以被那么多人看重，就是因为其通过绘图引擎这一层，完美的避开了碎片化，保证一致性。所以最好的平衡就是，只有有限的一部分标准的html标签可以被FFW复用，其必须有几点性质： 标签本身的功能简单又直观最好不要有直接图形化的展示，或者只负责简单的图形化展示（比如画方形）那几个比较典型的标签就是<p>、<div>这种了Flutter官方就是这么做的，所以我的结论是：一致性上大体不会存在问题，性能上，FFW应该不会优于纯手写html标签界面。 官方现状&建议根据官网和Github repo上的说法，我们整理了一下： Flutter for Web和Flutter目前暂时是两个仓库，官方正在进行合并，没有给出结论。这一点在工程上非常重要，它说明了几个问题： 目前官方对FFW的成熟度没有信心，同时FFW的迭代速度也很快。目前FFW和Flutter最多保证API一样，实现原理差异可能非常大，同时不保证所有控件都已经在FFW上实现。官方不建议应用在生产环境目前插件能力十分有限，和系统交互的一些能力缺失，比如拍照等。性能无法保证，运行会慢，可能会有掉帧FFW中针对桌面的UI部分没有完成（跟我无线有什么关系？）开发中只能在Chrome中调试（又有什么关系？），release版是可以运行在任意浏览器中（除了IE，另支持的最低版本存疑）。实践对于这么新的东西，官网上的内容的确不多，而且简单来看这些问题好像也没什么，所以对于到底能不能用，我们还是需要抱着吃螃蟹的心态具体进去预研一下，为了尽快弄清，我计划找一个我们app已经做好的flutter页面，把它迁移成FFW，对整个迁移过程做个评估，再看下页面效果，基本上就能得出结论了。具体的迁移细节就不提了，官网也有迁移文档，大体上就是这么几个步骤 安装Flutter for Web的工具webdev改SDK依赖，新增Web文件夹(和之前存在的android、ios文件夹同级)，新增一些其他文件(index.html, main.dart等)。将所有flutter代码中依赖的flutter包，改成flutter_web包去掉所有不兼容的代码，比如多语言、路由、Platform.isAndroid等等编译运行实践的主要目的，有以下几个： 对整体坑的深度和广度有个认知，方便推算出填坑成本对FFW整体的性能和体验有个把握，尤其是我们自己的页面跑在FFW上是什么体验。对FFW和JS相互调用有具体的了解，如果可行，那复用集团已有能力（比如mtop）的坑就会小很多 删了一万行代码跑成功之后，最终在工程、开发体验、用户体验上得到一些结论，以下的结论中，体验部分是我在我的mix2s上的感受： 工程支持debug和release模式，后者比前者性能高（差异很明显）。 debug模式支持代码修改后自动重新编译，和其他的前端框架（我只用过Django）一致支持hotreload，暂时没有尝试支持webdev build命令编译出index.html+js，可以通过nginx做反向代理。非常重要 编译出来的代码，gzip压缩前，最简单的helloworld的main.dart.js大小约为500k左右，sample中的gallery大小约为2M，阉割版的纯展示用的订单列表大小约为1.3M。gzip对文本的压缩率一般是80%，压缩后也要动辄几百k的大小。而且main.dart.js不加载完，界面是不会展示的。开发体验非常重要flutter for web使用flutter_web库，且不支持其他许多插件，这会带来几个问题 工程上无法优雅的解决flutter和flutter_web共存的情况，最多搞个dart2的conditional import(这个特性可不在官方文档中哦)依赖flutter sdk的几个库，尤其是多语言库无法应用在flutter_web上，并且Google肯定不会再单独为flutter_web适配，而是在合并时做支持。这就意味着现阶段所有依赖flutter sdk的库不能被flutter_web使用。调试困难 错误日志可以打印到浏览器的console中，但是try catch部分的堆栈不好拿浏览器中的堆栈很复杂，但是基本上能找到出错的dart代码目前没有发现单步调试的能力Platform.isAndroid全部报错，针对Android和iOS做差异化展示目前还不知道有没有其他方法可以做到。目前没有发现控件的api不一致的地方，不过有些控件的行为十分异常，比如下拉刷新，在Android手机上经常卡死、失效。猜测重交互的一些控件都有可能存在类似的问题，但是测一遍的成本太高。图片控件NetworkImage可以直接用，但是现在来看有些糊，不确定是官方控件的问题，还是我们做的cdn url策略有问题。dart代码可以调用js，开发体验和反射类似，并且需要处理JS类型和Dart类型的转换。Dart和JS的交互速度未知。只能说哪怕FFW有很多浏览器的API不支持，也可以通过JS来扩展能力。Dart和Js语言本身的差异会带来测试和兼容成本的增加，虽然Dart可以编译成Js，但是跑在DartVM上的Dart的表现，和其编译成Js运行在浏览器中的表现并不完全相同。比如对于如下代码 Map<String, String> query = null;val b = query["abc"];在DartVM中该代码可以执行，结果是b=null；但是编译成Js以后运行时因为query为null，会报空指针。 用户体验使用了chrome、uc、小米自带浏览器分别试了一下订单列表和官方的sample-gallery界面，体验如下： 加载速度差不多，因为是局域网环境，感知不到差异。非常重要打出的唯一的main.dart.js和部分资源文件（比如MaterialIcons）没有加载出来的时候，界面不会展示。帧率或者流畅度上，chrome > uc >> 小米自带浏览器，其中chrome算是最流畅的体验，但是sample中的一些动画和页面转场也可以看到明显的卡顿。文字展示上，看flutter for web的界面，chrome对大部分文字处理的很清晰，小米自带浏览器看文字明显模糊。对比下面两张图，点开放大之后查看，FFW页面的文字模糊的很明显。 ...

国内的前端行业，是一个群星璀璨，同时又有些纷纷扰扰的圈子。很多初出茅庐的年轻人怀着改变世界的梦想，谁也不服谁。不过，有一些为前端领域做出贡献的拓荒者几乎受到所有人的尊敬，玉伯就是这些拓荒者中的一员。 如今，他已经是蚂蚁金服研究员，带领着体验技术部，打造出 Ant Design、AntV、Eggjs 等广受欢迎的开源项目，他所在的团队也成为国内前端开发者向往的地方。 在同事眼中，玉伯是一个严谨的人，同时保持着对生活的热爱，他曾以 lifesinger 为笔名写名为“岁月如歌”的博客、参与 GitHub 上的开源社区，到现在也经常在知乎上分享自己的知识和见解。 从中科院到支付宝时间转回到 2006 年，当时在中科院物理所进行硕博连读的玉伯对前途产生了迷茫，是就这样继续深造，将来投身学术界，还是出来干一番事业？ 当时，腾讯的 QQ 已经开始有所起色，在年轻人之间开始风靡，淘宝网已经成为中国最受欢迎的线上购物网站，互联网正风起云涌。这时，玉伯得知中科院软件所正在找人，一番思考之后，玉伯毅然放弃学业投身到软件行业。由于他当时年龄小，在软件所工作期间，经常闹出被误认为是学生的笑话。 中科院的生活单纯但缺乏激情，2008 年，玉伯终于离开了象牙塔，南下杭州，加入了当时正在招兵买马的淘宝 UED。虽然并非科班出身，但玉伯从 2002 年起就已经开始接触前端开发，从此与前端结下了不解之缘。 加入淘宝 UED 后，他与承玉等人一起研发了 Kissy，当时淘宝前台业务的标准前端技术栈，并将之开源，在 GitHub 上，Kissy 一度是阿里系开源项目 Star 数最多的项目。 在淘宝期间，玉伯还发起了 Sea.js，一个开源的 JavaScript 模块加载框架，它契合了前端工程化的演进趋势，也是现代大中型前端项目的基础。 2012 年，玉伯加入支付宝前端开发部，负责基础技术组。第二年，他遇到了职业生涯的另一个重大选择：阿里宣布“ALL IN 无线”，支付宝前端解体，所有人都面临选择，要么转岗去做移动端开发，要么留下来做中后台的前端开发。玉伯选择留了下来。 虽然从事后来看，无论是走的还是留的，结果都挺好的，但当时对于玉伯是一个痛苦的时刻，甚至对前端的价值产生了怀疑，他在《阿里前端的困局与突围》中写道： 一个事实：把国内大部分公司的 UX 部门解散掉，也不会太影响产品的体验。在国内，UX 主要还是起到美工的作用，虽然我不想承认。前端依旧是美工，而且仅仅是实现工。 在阿里，我们不得不承认一个事实：前端的确有价值，但放在全局来看，前端产生的价值并非核心价值。 在阿里，虽然前端的工作已经不可或缺，但对大公司而言，不可或缺的岗位多了去呢，不可或缺不代表有核心价值，我就不说了。不过好在，他很快振作起来，从中后台业务中找到了前端的价值。 “后来我们发现中后台业务也是有很多事情可以去做的，无论是业务还是技术都值得深挖，只是以前前端只关注 C 端业务，但其实 To B 的业务对前端来说是一片蓝海。”玉伯说。 玉伯发现中后台的业务量其实非常大，如果没有一套系统的规范来应对，研发效率和产品体验都将面临挑战。 在这样的背景下，前端技术部改名为体验技术部，玉伯和他的小伙伴们踏上了新的征程。 冰山之下的体验意识到中后台方面前端体验的缺失，玉伯开始带领团队做这方面的工作，他还专门招募了设计师团队，和前端工程师一起工作，开始在体验方面深挖。 设计师的加入让前端团队发生了巨大变化，也让玉伯开始思考体验的更深层含义，他在《我们是如何从前端技术进化到体验科技的》一文中表示： 前端技术再牛，都很难直接解决产品层的用户体验。对中后台产品来说，设计的价值也远远不止于让产品的颜值提升，设计的更多价值，在于深入到产品的业务逻辑里去，去帮助业务梳理产品信息架构与任务流程。用户体验是一个非常综合的事，需要各种专业人士在同一个产品上聚焦发力，一起共同努力才能真正提升产品体验。他还引用乔布斯的话说：设计不止于好看，更关乎好用。 为了让前端工程师和设计师更好的协作，玉伯说，团队曾经开展过一个活动：任何设计师的要求都是合理的，只要设计师提出的要求都尽可能的去实现，除非技术上的确实现不了。这个活动让设计师感觉到前端工程师的尊重，增进了双方的互相了解。而且前端工程师和设计师都是视觉型动物，都关注人机交互的细节，所以相处下来很融洽。 2015 年，体验技术部推出了 Ant Design，它有别于 UI 组件库，是一种全新的设计系统，随着 Ant Design 不断的证明自己，它受到了阿里内外的广泛赞誉，也在一定程度上引领了国内业界关注中后台体验的风潮。 ...

5月29日，VEA中国视频体验联盟与VideoCTO联合主办“中国视频体验CTO论坛”在成都圆满落幕。该论坛旨在邀请视频产业生态链的经理人与技术专家，共同探讨视频体验评估标准，推动内容分发产业发展。阿里云受邀出席，技术专家陈石平现场进行了《云端一体化视频服务 打造极致播放体验》主题演讲。 视频体验关键指标作为开发人员，需要关注的用户视频体验关键指标是什么？陈石平认为可以分为以下几个： 第一：视频源质量，包括清晰度、保真度、流畅度是否能满足用户需求。第二：交互体验，可以理解为用户在客户端交互的响应速度，应该关注频道切换、初始加载、快进快退等播放性能指标。第三：观看体验，是否有花屏、卡顿、马赛克等问题，需要关注信号传输的质量以及网络质量。 综上所述，用户体验指标体系可以概况为：画质、网络、播放，是从视频源经过网络传输到最终播放的全过程。画质上需要考量转码、采集的质量，网络传输要关注CDN网络分发的质量，在播放环节需要考量播放器的质量，这三个环节的质量保障最终的用户体验。 云端一体化的视频服务视频服务的整体流程是从上传、转码、存储、分发到播放。阿里云提供云端一体化视频服务，在上传端，需要提供高质量的直播推流、短视频拍摄和上传的SDK；在转码端，通过业界领先的窄带高清技术可以实现观看体验和码率的最佳平衡，同等视频质量下最高节省20%-40%的带宽。在存储和分发环节，依托于安全可靠的OSS存储服务和遍布全球的CDN网络，来保障视频的传输的流畅和稳定。在播放环节，通过对各种业务场景，如直播场景、点播长视频、短视频等场景用户体验的痛点分析，并从云端一体化的角度来解决问题。 在本次议题中，陈石平从点播多码率、直播低延时和高清、短视频以及用户体验数据系统几个场景来讲述阿里云如何实现最佳视频体验。 体验优化实践一：点播长视频多码率用户痛点一：用户在APP上观看电影的时候通常可以选择不同清晰度，如超高清、高清、普通、流畅等。在不同清晰度之间切换时经常会遇到视频跳跃和音频中断的情况。因为通常处理方式是切换时记录下此时的播放位置，停止当前的清晰度，然后再起播下一个视频，跳转到上次播放的位置，这种方式处理最简单，但是体验很差。 用户痛点二：当视频播放过程中发生网络抖动，则会导致用户当前和播放码率和网速不匹配的情况，进而导致卡顿。用户通常会自然的把清晰度调低，但是当网络情况变好了，用户没有感知所以是无法体验到当前最佳的观看效果的。 陈石平现场演示了一个真正无缝切换码率的视频效果，同时也对实现方式进行了讲解。 他说道：首先，因为人耳对声音是非常敏感的，所以要做到音频的切换不卡顿，就要做音视频分离，保持音频的持续播放。第二，要精准控制各个视频码流之间的切换，通过播放器支持hls master playlist来实现码率、甚至音轨、字幕流之间的切换。同时，在切换策略上，从低清到高清采用的是快速策略，在视频缓冲区找到最近的切换点，让用户最快看到高清的视频。从高清到低清的切换采用缓慢切换策略，找到最远切换点，确保缓冲区里的高清数据能完整被用户看完。 视频地址：https://yunqivedio.alicdn.com... 针对于第二个用户痛点，也就是网络和当前播放码率不匹配的问题，可以通过自适应码率切换来解决。根据用户网络变化来自动切换码率有两个实现难点，第一如何避免频繁切换，第二是避免切换卡顿。自适应码率有很多算法，陈石平团队采用的是最为有效的基于缓冲区buffer以及当前下载网速的方法。同时，在基于buffer的策略中，也要考虑上下切换的预留buffer水位，当buffer降低到一定量时提前切换，防止切换晚导致卡顿。另外，在网速检测上面要考虑一段时间内的最大最小下载网速，综合此时的缓冲区的变化，通过算法来做出综合的判定。 体验优化实践二：直播低延时和高清用户痛点一：直播场景非常多，其中互动直播、游戏直播、电商直播、在线课堂等场景对低延时的需要更为强烈。技术层面，直播一般采用rtmp、http flv和m3u8流形式，其中rtmp和http flv延迟通常可以做到3-5秒，m3u8要在10秒以上。这必然满足不了这些场景的需求。用户痛点二：在远程医疗、赛事直播、VR直播等场景下，对直播清晰度要求非常高。比如赛事直播下要捕捉运动员的细节画面，才能为用户带来临场感。随着用户体验的升级，高清视频播放逐渐走向常态化。 为了解决直播低延迟的问题，阿里云打造了端到端超低延迟ARTP协议，全称为Alibaba Realtime Transport protocol。从推流端、CDN到播放端实现基于UDP传输协议的改造，将直播延迟控制在1秒以内。在抗网络抖动、秒开、降低卡顿错误率等性能指标上都得到了大幅的提升。经过大量数据验证，在相同卡顿率情况下，延时可以降低75%。相同丢包率和延迟下，播放成功率和卡顿率会明显降低。同时，依托于阿里云海内外2500+CDN边缘节点优势，能够具备支持千万级并发的能力。在电商直播场景下，通过使用低延时技术，相比于以往的rtmp的直播，商品转化率得到较大提高，也就是说商家因为低延迟直播卖出了更多的商品。 “在高清直播场景上，阿里云去年推出首个互联网8K直播解决方案，并联合多家合作伙伴在云栖大会上成功展示了8k直播远程医疗案例。这次成功的演示背后也有非常巨大的技术挑战。”陈石平说。 第一就是如何保证8K超过码率的实时链路传输。为了保证和普通直播同样的低时延，阿里云首次采用了5G上传，同时也扩展了RTMP协议对H.265支持，采用了H.265的压缩方式进一步压缩码率。 第二是直播服务端需要能够支持实时的切片和录制，来实现8K的直播时移、回看，这需要通过扩展服务端对8K实时处理能力来实现。 第三需要健全的8K直播全链路监控系统，实时显示音视频帧率、码率以及波动情况，这对现有的直播服务性能和稳定性都提出了更高的要求。 第四，全自研8K播放器，能够实现120M码率、60fps直播流的实时播放，替换掉了专有的昂贵的播放硬件设备，这对8K直播整个商业化推广非常关键。在如今4K直播还未普及的情况下，阿里云已经具备了8K直播的商业化能力。 体验优化实践三：短视频场景要实现优秀的短视频的用户体验，需要端到云、云到端的完整体验闭环。通过阿里云云端融合的技术优势，实现了短视频从采集上传、转码、媒资管理和播放一体化服务体验。 在短视频拍摄环节，有业内领先的短视频SDK，异构编码和极速合成的技术保证采集端的体验优化。在上传环节，将视频上传至点播服务，通过窄带高清的转码、智能审核等技术保证高画质、高效率和内容安全。然后通过CDN分发到播放端，在播放环节，通过独创的短视频的列表预加载技术，实现端上的极速秒开。最终通过云端各个环节的整体优化，才能保证用户最终得到最佳体验。 “在所有环节中，短视频列表播放的体验非常重要。例如抖音，你会发现起播非常快，循环播放也很流畅。这是怎么做到的呢？”陈石平讲到：这就是通过列表预加载技术实现的。常规的预加载是通过多个播放器来实现的，播放当前视频的时候去预加载下一个视频，这个方案的缺点是实现逻辑非常复杂，同时也消耗更多性能。所以，阿里云独创了列表播放器，通过简单的接口调用就可以实现列表的预加载播放。它有几个特点，首先是能够做到防卡顿的缓存策略，通过对缓存的管理，可以灵活控制卡顿期间的预缓存策略，同时优化缓冲的淘汰策略。第二是对滑动的流畅性针对性优化，保证每个视频停止的耗时在16毫秒以内。第三是采用了基于内存的预加载缓存技术，循环播放和秒开直接从内存读取数据，无需额外的文件操作。第四非常关键，是提供简单的接口，可以非常快速的实现短视频播放功能。 体验优化实践四：实时掌握用户体验数据通过以上一些列优化动作，那么最终我们如何知道线上用户的体验到底如何？这就需要数据说话，通过播放数据服务来打造用户体验闭环。这其中包括卡顿率、秒开、成功率等数据，这些数据指标也为下一步优化用户体验提供了重要依据。 在演讲的最后，陈石平表示：未来的时代是体验为王的时代，用户对体验的追求是永无止境的。阿里云视频服务将持续打造云端一体化的极致视频服务体验，进而帮助平台为其用户提供更优的观看体验。 本文作者：樰篱 原文链接 本文为云栖社区原创内容，未经允许不得转载。

阿里妹导读：当年打开天猫的那一刻，它为你完成了华丽的变身，成为世上独一无二的“天猫”，这就是智能推荐的力量。今天，来自阿里巴巴搜索推荐事业部的算法工程师陈启伟为你介绍天猫如何玩转首页个性化推荐，揭开搜索推荐的神秘面纱。天猫首页作为用户打开手机天猫App的第一印象，所推荐的商品极大地决定了用户接下来的行为，对用户流量的承接与分发、提升用户购物体验和呈现天猫货品的性价比、品质感及品牌力起到至关重要的作用，成为提升天猫用户体验的关键环节之一。 1、场景介绍天猫首页的场景主要包括大促会场入口和日常频道两大类，如图1所示。其中左图为大促会场入口，包括主会场入口和行业会场入口；主会场入口通过为用户推荐7个商品（3个在中间动态轮播）给大促主会场进行引流，引流 UV 达数千万以上；行业会场入口通过为用户推荐4个个性化会场和商品为数万的会场引流。右图为日常频道，包括限时抢购、天猫好物、聚划算、天猫闪降和精选频道；首页通过个性化推荐商品为各个特色的频道引流，通过各个频道来培养用户心智，让用户在天猫逛起来。 过去的首页推荐更多的是在相关性推荐的单一数据目标上进行优化，如今天猫首页的推荐系统不仅仅考虑推荐结果的相关性，还在推荐结果的发现性、多样性等方面上做了更深度的优化，"效率和体验并重"成为天猫首页新的优化目标。Graph Embedding、Transformer、深度学习、知识图谱等新的技术已先后在天猫首页的推荐系统成功落地，为场景带来了两位数的点击率提升和两位数的疲劳度下降。 2、推荐框架天猫首页的个性化推荐系统可以分为召回、排序和机制三个模块。其中，召回模块主要是从全量的商品素材中检索出用户感兴趣的 TopK 个候选商品，排序模块专注于用户对商品的 CTR 预估，机制模块负责后期的流量调控、体验优化、策略调控等和最终的商品排序。整个推荐系统采用 Graph Embedding、Transformer、深度学习、知识图谱、用户体验建模等新的技术构建起来，后面章节将介绍这个推荐系统的关键技术点。 3、召回3.1 Ranki2i Item-CF 是目前应用最广泛的召回算法，其原理是根据两个商品被同时点击的频率来计算两个商品之间的相似度 simScore，得到 i2i 表；然后通过用户的 trigger 去查询 i2i 表，扩展用户感兴趣的商品。Item-CF 的基本算法虽然简单，但是要获得更好的效果，往往需要根据实际的业务场景进行调优。清除爬虫、刷单等噪声数据，合理选择计算商品之间相似度的数据的时间窗口，引入时间衰减，只考虑同一个类目下商品对，归一化、截断、打散等策略对优化 Item-CF 的效果都有很大的帮助。 Ranki2i 是一种改进的 Item-CF 算法，其在 item-CF 得到的两个商品之间的相似度 simScore 的基础上再乘以该 trigger item 所召回的该 target item 在过去一段时间内的 ctr (注意 ctr 的计算需要进行适当的平滑)，对 i2i 的 simScore 进行修正，使得 i2i 表不仅考虑了两个商品的点击共现性，还考虑了召回商品的点击率。 我们基于全网的点击数据和天猫首页场景内的日志来计算 Ranki2i 表，并部署在检索系统 Basic Engine 上，对每个访问天猫首页的用户，从基础特征服务系统 ABFS 中获取用户的 trigger，并以此查询 Ranki2i 表来召回用户感兴趣的商品。 经典 Item-CF 类算法直接根据两个商品被同时点击的频率来计算两个商品之间的相似度，在寻找用户点击商品的相似、相关以及搭配商品上都有很大的优势，且其具有简单、性能高等特点，已成为目前应用使用最为广泛的召回算法。然而由于经典 Item-CF 类算法的召回结果的候选集限定在用户的历史行为类目中，并且算法难以结合商品的 Side Information，导致其推荐结果存在发现性弱、对长尾商品的效果差等问题，容易导致推荐系统出现“越推越窄”的问题，从而制约了推荐系统的可持续发展。为了跟精准地给用户推荐心仪的商品，同时维护推荐系统的可持续发展，解决推荐系统的发现性推荐和长尾推荐等问题，我们团队提出了 S3Graph Embeeding 算法和 MIND 算法。 ...

阿里妹导读：搜索导购产品作为搜索的流量入口，承载了为用户导购推荐、搜索流量分流的重要功能。主要产品包括：首页底纹、下拉推荐、搜索发现、导航、历史搜索等。经过几年的探索和积累，各个产品越发地成熟，机器学习算法广泛地应用于导购产品中，取得了显著的效果。在支撑好手淘搜索业务的基础上，搜索导购也积极地拓展边界，支持了集团内大量的产品线。因此对搜索导购产品线提出了更高的要求：不仅需要提升本身产品的效率，更好地支持手淘搜索业务，同时也需要有一套灵活的框架，支持更多更广的业务。 一、系统框架导购升级的优化思路从三个方向着手：1.策略升级。利用深度学习及异构网络的思想，对用户个性化进行更深的理解和建模；同时对因马太效应引起的独立query数下降等问题进行优化。 2.导购外投。在包括会场激活页、猜你喜欢等渠道进行搜索导购赋能，为用户打通搜索通路。 3.产品创新。一方面对现有的产品进行创新升级，如激活页、下拉推荐等；另一方面积极尝试新产品形态，如首页热词、搜索动态卡片等。 搜索导购核心解决对消费者关键词推荐的问题，因此虽然产品众多，形态各异，但是在底层架构上有很多共性，因此我们设计了一套通用灵活的框架进行支持。 在召回阶段，我们丰富了召回方式；并根据不同的渠道、场景以及产品形态，选择不同的召回策略得到候选query词candidates。 在排序阶段，我们不仅将深度学习引入导购算法框架中，而且创新的加入了异构网络的思想，将用户不同路径的序列信息结合lstm等模型进行有效融合，对消费者进行更深入的理解。 在业务策略阶段，我们利用 jaccard 系数、编辑距离等进行了对语义重复问题进行了优化，同时结合E&E机制对马太效应较为严重的场景进行了升级，并增加了效率轮播机制使得效率进一步的得到提升。 接下来以几个具体的产品来进行详细的介绍。 二、详细方案2.1 底纹推荐优化 在底纹推荐的算法优化中，我们创新性地提出了基于异构网络（Heterogeneous Information Network，后面简称HIN）的推荐方法，推荐框架如下图所示： user，item 和 query 是手淘中三种基本类型的节点，这三种类型节点之间又有不同的交互关系，比如，user 直接点击 item，user 通过查询 query 进入搜索，并在搜索里发生 item 的点击等。 但是，大多数传统推荐方法只关注特征工程，忽略了这些不同节点之间的关联关系。同时电商领域的大规模数据体量（一亿query，数十亿user和item）也是需要考虑的问题。因此我们设计提出了一种基于元路径embedding 表示的大规模 query 推荐方法，MetaPath-guided Embedding for Large-scale Query Recommendation（MELQR），它采用异构网络对 query推荐进行建模，并利用元路径通过聚合局部邻居信息来指导 user 和 query 的表示学习，此外，我们对异构网络中所有节点用term embedding的某种融合方法来进行表示，从而避免了网络学习中的大规模参数问题。 该模型结合扩召回、动态展示等策略，对线上底纹使用uv提升10%+，引导成交金额提升10%+。值得一提的是，该模型目前也同步使用到了导购的其它产品例如搜索发现、首页热词等，效果的提升同样非常明显。 2.2 首页热词优化 首页热词是今年搜索在手淘首页的一个创新性产品，可以帮助用户通过关键词找到感兴趣的商品，增强用户的搜索心智。 首页热词与底纹推荐共享系统框架与算法框架 2.3 下拉推荐优化 下拉推荐上一个版本的优化目标在于提升下拉引导pv在搜索pv中的占比，即下拉使用率。上个版本试图拟合的是用户对下拉所展示的 query 的偏好程度。但是在其使用的统计类特征中，使用的特征均都是下拉引导的数据。这就带来了一个比较严重的问题，在目前的产品形态下，每次用户输入，只能展示10个候选的 query。因此一开始展示相对较多的 query 会具有相对较高的统计值，而较高的统计值会促进该query 在排序中排到更靠前的位置。因此形成循环，久而久之，在某些特定的 query下，下拉推荐候选词的统计值特征会有非常大的差异。由此形成马太效应。马太效应一个最严重的问题就是会导致下拉展示的 query 会过度收敛到一个较小的集合中，导致引导的独立 query 数下降。 针对这些问题，我们对下拉推荐模型进行了系统的重构，框架如下： ...

与你同行，抬头便是星空。 本文整理自Nacos Committer 张龙的现场分享，阿里巴巴中间件受权发布。 随着 Nacos 1.0.0 稳定版的发布，越来越多的企业开始在测试/预演/生产环境中逐步部署 Nacos。目前，除了部分企业已处于转型分布式架构的过程中，会考虑直接使用 Nacos 上生产，但仍有不少企业会考虑一些比较现实的问题： 存量用户如何迁移注册中心到 Nacos？多区域注册中心之间如何同步？已有注册中心与 Nacos 如何并存使用？这里，我将通过对 Nacos Sync 的介绍，来回答这三个问题。 Nacos Sync 是什么？Nacos Sync 是一个支持多种注册中心的同步组件，基于 SpringBoot 开发框架，数据层采用 Spring Data JPA，遵循了标准的 JPA 访问规范，支持多种数据源存储，默认使用 Hibernate 实现，更加方便的支持表的自动创建更新。 下图是 Nacos Sync 系统的概念图，Nacos Sync 通过从各个注册中心拉取注册的服务实例数据同步到 Nacos，左右两边是不同的注册中心，绿色代表目前是可以进行双向同步的，蓝色代表暂时只能进行单向同步。 Nacos Sync 使用了高效的事件异步驱动模型，支持多种自定义事件，使得同步任务处理的延时控制在3s，8C16G的单机能够支持6K的同步任务。 除了单机部署，Nacos Sync 也提供了高可用的集群部署模式，作为无状态设计，支持将任务等状态数据迁移到了数据库，使得集群扩展非常方便。 系统模块架构下图是 Nacos Sync 目前的系统架构图，画的比较简单，只是把一些比较重要的模块做了描述。 Web Console: 提供给用户进行注册中心和同步任务进行相关界面操作 Processor Frame: 注册中心和任务的业务处理逻辑 Timer Manager: 定时轮询数据库获取同步任务进行处理 Event Frame: 异步事件来进行同步任务的同步以及删除 Extension: 对接各种注册中心客户端的扩展实现 整体调用流程我们来看一下 Nacos Sync 一次完整的调用流程： ...

背景闲鱼客户端的flutter页面已经服务上亿级用户，这个时候Flutter页面的用户体验尤其重要，完善Flutter性能稳定性监控体系，可以及早发现线上性能问题，也可以作为用户体验提升的衡量标准。那么Flutter的性能到底如何？是否像官方宣传的那么丝滑？Native的性能指标是否可以用来检测Flutter页面？下面给大家分享我们在实践中总结出来的Flutter的性能稳定性监控方案。 目标过度的丢帧从视觉上会出现卡顿现象，体现在用户滑动操作不流畅；页面加载耗时过长容易中断操作流程；Flutter部分exception会导致发生异常代码后面的逻辑没有走到从而造成逻辑bug甚至白屏。这些问题很容易考验用户耐心，引起用户反感。 所以我们制定以下三个指标作为线上Flutter性能稳定性标准： 页面滑动流畅度页面加载耗时（首屏时长+可交互时长）Exception率最终目标是让这些数据指标驱动Flutter用户体验升级。 页面滑动流畅度我们先大概了解下屏幕渲染流程：CPU先把UI对象转变GPU可以识别的信息存储进displaylist列表，GPU执行绘图指令来执行displaylist，取出相应的图元信息，进行栅格化渲染，显示到屏幕上，这样一个循环的过程实现屏幕刷新。 闲鱼客户端采用的Native、Flutter混合技术方案，Native页面FPS监控采用集团高可用方案，Flutter页面是否可以直接采用这套方案监控？ 普遍的FPS检测方案Android端采用的是Choreographer.FrameCallBack，IOS采用的是CADisplayLink注册的回调，原理是类似的，在每次发出Vsync信号，并且CPU开始计算的时候执行到对应的回调，这个时候表示屏幕开始一次刷新，计算固定时间内屏幕渲染次数来得到fps。(这种方式只能检测到CPU卡顿，对于GPU的卡顿是无法监控到的)。由于这两种方法都是在主线程做检测处理，而flutter的屏幕绘制是在UI TaskRunner中进行，真正的渲染操作是在GPU TaskRunner中，关于详细的Flutter线程问题可以参考闲鱼之前的文章：深入理解Flutter引擎线程模式。 这里我们得出结论：Native的FPS检测方法并不适用于Flutter。 Flutter官方给我们提供了 Performance Overlay (具体参考 Flutter performance profiling) 作为检测帧率工具，可否直接拿来用？ 上图显示了Performance Overlay模式下的帧率统计，可以看到，Flutter分开计算GPU 和UI TaskRunner。UI Task Runner被Flutter Engine用于执行Dart root isolate代码，GPU Task Runner被用于执行设备GPU的相关调用。通过对flutter engine源码分析，UI frame time是执行window.onBeginFrame所花费的总时间。GPU frame time是处理CPU命令转换为GPU命令并发送给GPU所花费的时间。 这种方式只能在debug和profile模式下开启，没有办法作为线上版本的fps统计。但是我们可以通过这种方式获得启发，通过监听Flutter页面刷新回调方法handleBeginFrame()、handleDrawFrame()来计算实际FPS。 具体实现方式：注册WidgetsFlutterBinding监听页面刷新回调handleBeginFrame()、handleDrawFrame() handleBeginFrame: Called by the engine to prepare the framework to produce a new frame.handleDrawFrame: Called by the engine to produce a new frame.通过计算handleBeginFrame和handleDrawFrame之间的时间间隔计算帧率，主要流程如下图： 效果到这里，我们完成Flutter中页面帧率的统计，这种方式统计的是UI TaskRunner中的CPU操作耗时，GPU操作在Flutter引擎内部实现，要修改引擎来监控完整的渲染耗时，我们目前大部分的场景没有复杂到gpu卡顿，问题主要还是集中在CPU，所以说可以反应出大部分问题。从线上数据来看，release模式下Flutter的流畅度还是蛮不错的，ios的主要页面均值基本维持在50fps以上，android相对ios略低。这里需要注意的是帧率的均值fps在反复滑动过程中会有一个稀释效果，导致一些卡顿问题没有暴露出来，所以除了fps均值，需要综合掉帧范围、卡顿秒数、滑动时长等数据才能反应出页面流畅度情况。 页面加载时长集团内部高可用方案统计Native页面加载时长是通过容器初始化后开启定时器在容器layout的时候检查屏幕渲染程度，计算可见组件的屏幕覆盖率，满足条件水平>60%，垂直>80%以上认为满足页面填充程度，再检查主线程心跳判断是否加载完成 再来看看weex页面加载流程和统计数据的定义 ...

4月9日，澳门当地时间下午4:00-5:30，阿里云在ICDE 2019举办了主题为“云时代的数据库”的专场分享研讨会。本次专场研讨会由阿里巴巴集团副总裁、高级研究员，阿里云智能数据库产品事业部负责人李飞飞（花名：飞刀）主持，五位学术界知名学者和教授受邀参加作为Panel Discussion的嘉宾，与现场近百位与会者进行了深入交流讨论。这五位教授分别是：Anastasia Aliamaki,Professor and ACM Fellow, EPFL;Ihab Ilyas, Professor and ACM Distinguished Scientist, Vice Chair of ACM SIGMOD, University of Waterloo;Guoliang Li, Professor, Tsinghua University;C Mohan,IBM Fellow,IEEE&ACM Fellow,IBM; Xiaofang Zhou, Professor & IEEE Fellow, University of Queensland;整场分享讨论会分为两部分。第一部分先由来自阿里巴巴集团、阿里云智能数据库产品事业部的吕漫漪、林亮、黄贵、乔红麟技术专家们分别介绍了阿里巴巴在POLARDB for MySQL, POLARDB X, AnalyticDB, 以及智能化自治数据库平台SDDP(Self-Driving Database Platform)等产品和技术的进展，以及如何依靠创新来帮助企业解决传统数据库业务场景中在数据处理方面面临的挑战，体现出阿里云智能数据库的技术领先性，以及品牌和文化，目前阿里云数据库在全球云数据市场上位列前三。第二部分由几位专家分别就云时代的数据库趋势和挑战发表了自己的见解，然后就与会学者关心的问题进行了深入探讨。其中，C Mohan博士提出，云时代下Serverless允许用户实现应用无需考虑软硬件配置，并且通过PaaS实现自动扩展，对数据库来说，自身健壮性是基础要求，另外还需要加强分布式负载的处理能力。目前面临一些挑战，例如公有云用户是一个私有环境，混合云方面还需要优秀的分布式OLTP DBMS， 内存/存储架构上还有很多工作可以做。除此之外，数据安全、数据管理方面都是需要考虑的问题。数据显示，中国84%以上的企业表示愿意接受云技术。针对目前面临的挑战，Anastasia Aliamaki 教授指出，一是数据多样性（关系型数据，非关系型数据）对于数据库处理数据是一个巨大挑战，需要构建一个智能的数据库来处理各种各样的负载，需要扩展SQL接口，code-generation提供了运行时构建相应底层数据的访问路径；二是 data cleaning是极其消耗资源的，包括数据从传统数据库迁移到云数据库的迁移工具（用户可以不关心如何迁移的细节问题）。对于用户来说，如果能让用户上述两点都能做到无感知应用，这无疑是云数据库的最大亮点。周晓方教授认为，从传统数据库迁移到云数据库是一个系统工程。为了提升用户体验的满意度，云数据库努力解决高并发、扩展等问题，用户从传统数据库迁移到云数据库不仅仅是一次迁移，也是一次自我调优的过程，可以构建生态系统，从不同的领域开展深入研究。Ihab Ilyas教授分享了在Data Cleaning and Integration to cloud领域的洞见和成果。他特别指出，迁移到云数据库问题不在云本身，用户通常选择他熟悉的产品。云数据库必须了解客户需求，解决客户问题。他说：“对于大数据工程师来说，算法的实现对他们不是噩梦，Hadoop版本却成为他们的噩梦。我们发现迁移这个事情已经在发生，但是我们需要更多关注这个过程本身，并且对过程敏感，能够带给用户无痛感的迁移。”李国良教授认为，云数据库最大的特点是不需要维护数据库，可以节约DBA成本，但是数据库是比操作系统还复杂的系统，需要迁移数据库设计的生态系统，并构建相应的APP。小公司业务应用简单容易上云，大公司因为业务太过复杂不太容易上云，云厂商需要解决大公司的应用迁移问题。最后，数据库领域的专家学者们强调可以借鉴云和大数据生态的演进发展，逐步把数据库技术带入机器学习中而不是强求打造一个“全能的”数据库。最后几位教授也对阿里巴巴在此领域的继续贡献充满期盼。本文作者：桐碧2018阅读原文本文为云栖社区原创内容，未经允许不得转载。

微信小程序设置 hover-class，实现点击态效果增强小程序触感，提高用户交互感知度概念及注意事项微信小程序中，可以用 hover-class 属性来指定元素的点击态效果。但是在在使用中要注意，大部分组件是不支持该属性的。目前支持 hover-class 属性的组件有三个：view、button、navigator。不支持 hover-class 属性的组件，同时也不支持 hover-stop-propagation、hover-start-time、hover-stay-time 这三个属性。当 hover-class 的值为 none 时，组件上不会有任何点击态效果。注意事项hover-class样式显示的原理是 点击时把样式加到class的样式中，冲突时，谁在后面就显示谁!当组件中没有任何指定的类时，直接使用 hover-class 就会起到相应的作用，但是当组件中已经指定了其他可能与 hover-class 冲突的类时，hover-class 无效将 hover-class 指定的类放在对应 wss 文件的最末尾，这样就不会被其他类所覆盖通常，当一个 view 组件中包含 image 等不支持 hover-class 的组件，但又需要在该组件上使用 hover-stop-propagation 属性的作用时，需要将不支持 hover-class 的组件用view、button 或 navigator 包裹起来使用场景1.列表页——详情页（点击跳转）以新闻资讯为例，大部分应该都是这样的添加如下代码//html<view hover-class=‘wsui-btn__hover_list’> …</view>//css.wsui-btn__hover_list { opacity: 0.9; background: #f7f7f7;}点击效果如下图2.展示类表格列表（不触发跳转）可设置hover-stay-time属性，突出显示触摸行或列//html<view hover-class=‘wsui-btn__hover_list’ hover-stay-time=“3000”> …</view>//css.wsui-btn__hover_list { opacity: 0.9; background: #f7f7f7;}3.提交类按钮1种样式往往不能满足，各种形状的按钮，暂提供以下2种参考.wsui-btn__hover_btn {//圆形按钮 opacity: 0.9; transform: scale(0.95, 0.95);//长矩形按钮 position: relative; top: 3rpx; left: 3rpx; box-shadow:0px 0px 8px rgba(0, 0, 0, .1) inset; }上图以长矩形按钮为例，采用scale整体缩放效果显然不佳圆形按钮显然更合适对于同页面等待请求返回的按钮，配合 disabled 属性，使用加载中按钮的方案更为合理4.有待考量的场景选择类按钮，特指点击切换某些状态，会有及时的状态切换响应的，如遮罩层、active类导航图标类，首页的图标导航我认为以上无需添加hover类特别说明以上只是抛砖引玉，针对点击态，用户体验优化的示例欢迎大家针对效果、使用场景、统一性等方面在下方留言、评论作出优化和补充本文贡献者约定用户体验是一个值得终身研究的课题，众人拾柴火焰高，这里将公布对本文作出贡献的思否开发者及其个人主页链接 ...

整个短视频的市场规模一直在增长，网络数据显示2018年已经突破100亿大关，在2019年预测将超过200亿。纵观行业，在生活资讯、美食、搞笑、游戏、美妆等领域，短视频流量巨大但竞争激烈，但是在教育、财经、军事、旅游等行业还存在较大的机会。那么在这些垂直行业里，我们如何结合短视频能力，实现业务突破？近期的云栖TechDay音视频技术专场中，阿里云视频云高级技术专家王海华现场分享了《高清极速-全面提升短视频应用体验》议题。他表示，作为短视频SDK服务提供方，视频云一直和客户同样关注如何把短视频的产品和体验做得更极致。本次分享讲从端到云再到端，探讨如何进行思考与优化，实现视频体验的全面提升。短视频的业务特征短视频可以随时随地进行拍摄、分享与浏览，所以它存在着海量的上传和播放用户在移动端消费短视频的机型和网络情况十分复杂用户对短视频体验的追求是清晰和流畅，而作为开发者，也需要考虑到流量与用户体验的平衡关于视频云全链路优化的技术实践阿里云视频云提供一站式短视频解决方案，并从整个链路上进行技术优化。在生产端，短视频SDK支持视频拍摄、导入编辑和视频上传的能力；当视频传到云端，支持媒体转码、存储、视频AI分析处理功能。在分发环节，通过全球节点、智能调度和热门视频预热资源，将视频内容更稳定极速的分发至消费端；最终在播放端，播放器SDK可以实现快速启播、播放缓存、无缝循环播放和多清晰度切换。一、视频生产端-帧率与低端机型体验优化在视频拍摄阶段，用户最关注视频的清晰度和流畅度。这其中的优化包括几个环节：1. 预览帧率的提升摄像头采集到数据直到呈现到屏幕上，采用GPU驱动渲染，保证渲染的实时性，减少延迟和丢帧的情况。同时，针对人脸特效的渲染，采集3buffer的CPU回调方案，减少buffer资源等待造成的帧率下降。2. 录制帧率的提升录制是把视频帧编码的过程。整体采用GPU直接渲染到硬编Surface的方案，同时保留了之前的buffer方案作为软编的适配，在编码的延迟和丢帧缩短到最小。3. 针对低端机型 定义最优适配移动终端机型复杂度极高，硬件能力、性能、屏幕分辨率等等指标千差万别，如果想要最大限度保证低端机上的视频质量，就要在提升清晰度和流畅度的时候，降低分辨率。那么问题又来了，在什么机型上降低？怎么降低？到底降低多少合适？阿里云短视频SDK又多往前走了一步，多做了一点点。经过大量的数据分析和适配测试完成了在不同性能手机的适配。要提升整个视频的清晰度视频编码是永远绕不开的一个话题，在阿里云除了在编码器算法的优化以外，也从更加贴近业务场景的角度进一步优化。在如此多的业务场景，一种编码技术和编码参数是解决不了所有问题，所以针对不同场景，需要完成相应的编码优化。比如以质量优先的场景，会适当牺牲转码速度或者压缩率，以保证清晰度最佳；以转码速度优先的场景，会调整质量，以适实现更高的转码速度。这样更有针对性的编码调优，就可以根据需求实现场景化的平衡。除此之外，还从更加上层的用户体验上做了很多细节的优化。王海华表示：“从相册选择资源进入编辑界面，从点击合成按钮进入发布界面，从点击发布界面回到APP的主界面等这些环节的交互流畅度也直接影响用户体验。这其中的优化点：首先是当从相册选择多个图片或者视频合成视频时，我们底层支持图片视频混编的能力从而缩短loading时间，减少等待时间；其次支持后台合成和后台上传，点击合成按钮和发布按钮的时候我们直接进入后台进行合成和上传，让APP可以更快的进入到下一个界面，从而提升用户体验。”“在视频生产端经过了以上的优化后，看起来我们可以根据对应的场景拿到自己需要的视频，所有的问题都解决了。但是面临着海量上传和播放，以及复杂的网络，我们怎么保证上传速率和上传功率？在播放环节上又怎样去保证播放流畅度？作为开发者（我们的客户）又怎么控制带宽成本呢？”接下来，王海华带我们了解了在上传、云端处理和分发以及播放几个环节中的优化点以及带来的效果。二、视频上传链路优化在视频上传链路，需要核心关注速度和上传成功率两个指标。视频云支持动态加速，选择最优路径来就近上传数据，保证极速上传。同时，采用分片、断点续传技术，针对不同地域和场景决定分片大小，确保上传成功率在99.2%以上。三、云端处理&分发当视频上传到云端，就需要对其进行转码等处理，并进行内容分发。这其中我们针对三个指标进行关注和优化：1. 视频发布速度不同的场景，需要的视频发布速度是不同的。对于聊天场景下的视频发布，直接在端上进行转码，把原视频直接访问，最大限度提升速度。对于对实时性要求并没有那么高的视频社交APP等场景往往在上传的时候会上传一个码率相对较高的高清视频，为了视频快速启播，我们推荐可以先运用低复杂度转码来加快转码速度；在未来，也会将视频端上合成、上传和云端转码并行处理，大幅度缩短处理时间。2. 转码成本 vs. 带宽成本在很多社区里面当一个视频变成热门视频的时候，这时候带宽会带来更大的成本，这个时候建议对热门视频重新转码，提升转码复杂度，将视频文件变小，降低带宽成本。3. 提升播放体验因为用户的终端和网络情况不同，所以需要进行多清晰度转码，并采用推荐视频预热方案，提升启播速度和流畅度四、视频播放优化播放端直接影响着用户体验，这里我们需要关注几个指标：打开速度的快慢影响着用户对产品的第一印象，启播环节用到协议优化、解码渲染优化、视频列表预加载等方案，实现极速启播。短视频通常比较短小，通常会采用循环播放的方式来吸引用户重复观看，避免流失。那无缝地循环播放、同时边播放边缓存就十分必要，可以节省流量。终端网络情况复杂，但播放流畅度依然是用户十分在意的指标。当用户出现网络环境的变更，需要快速切换多种清晰度的视频，保证视频播放的流畅。如何进行产品快速落地一、客户端短视频SDK将最新最流行的功能、交互集成到产品级Demo中，并开放了源码，开发者拿到以后可以直接集成到应用中，或者基于源代码进行业务的适配，快速开发出一款短视频APP。Demo提供了拍摄、编辑、播放等模块，同时提供相册管理、音乐、动图、字体等资源的下载和管理，也提供了异步上传发布功能、AppServer业务服务器的SampleCode。二、服务端在云端，短视频SDK与视频点播服务打通，提供了丰富的媒体管理和媒体处理能力，开发者通过简单的配合和API调用就可以将以下功能集成到业务当中。媒资存储：音频，视频，图片，字幕等丰富的存储能力；媒资管理：提供了分类，打标，搜索，审核能能力等；数据统计：存储，流量/带宽，播放量等数据统计；感兴趣的用户，可以扫描上方二维码体验demo，点击访问阿里云官网短视频解决方案页面，了解详情，或者点击浏览趣视频解决方案文档，更快上手本文作者：樰篱阅读原文本文为云栖社区原创内容，未经允许不得转载。

小蚂蚁说：《支付宝客户端架构解析》系列将从支付宝客户端的架构设计方案入手，细分拆解客户端在“容器化框架设计”、“网络优化”、“性能启动优化”、“自动化日志收集”、“RPC 组件设计”、“移动应用监控、诊断、定位”等具体实现，带领大家进一步了解支付宝在客户端架构上的迭代与优化历程。本节将结合禾兮在 OSChina 珠海站现场的分享《移动端分析方案在蚂蚁金服 mPaaS 中的实践》，介绍支付宝客户端自动化日志收集与分析的具体思路。内容将分成三个部分展开：支付宝客户端分析方案的探索；MAS 移动分析框架浅析；mPaaS 技术架构与助力。支付宝客户端分析方案的探索正如我们在《开篇 | 模块化与解耦式开发在蚂蚁金服 mPaaS 深度实践探讨》已经对支付宝的架构演变与开发团队规模发展做过介绍：截止目前，在研发上面，支付宝仅 Android、iOS 客户端开发人员近千人，客户端代码行数超过了数百万行，按业务划分的工程数也已近千个，每个工程都有独立的开发 owner 负责某一个具体的模块。虽然工程师团队及工程量越发庞大，支付宝依旧能够做到日发布的频率以确保业务快速迭代，同时在业务功能日益复杂的环境，保证 App 闪退率仅 0.01%。那么，在如此大体量的用户规模和研发团队下，支付宝又是如何确保用户使用过程中的用户体验呢？我们主要从以下两个维度衡量客户端用户体验：静态：指应用开发过程中，关注 App 本身的安装包大小、存储、涉及到的用户隐私权限、安全策略等，决定用户是否愿意安装并使用你的应用。动态：指应用发布上线后，用户在使用过程中，App 的启动速度，闪退、卡死卡顿等稳定性数据，网络请求，内存以及电量流量等用户实际的使用感受。启动应用是用户使用任何一款应用最必不可少的操作，从点击 App 图标到首页展示，整个启动过程的性能，严重影响着用户的体验。支付宝客户端作为一个超级 App，启动速度当然是我们关注的重要指标之一。支付宝对于应用启动过程中的优化，主要分为以下四个方面：框架治理：梳理启动流程并重构，遵守启动过程中按需加载原则。引用 Pipeline 机制，根据业务优先级规定业务初始化时机。制定统一的开发规范，尽量降低业务方流程对启动性能的影响。业务治理：按需加载，延时执行。线程治理：统一管理已有线程，并调整线程优先级。I/O 治理：关注主线程 I/O，优化合并频繁读写的 I/O 操作，尽量使用统一存储。技术突破：防止启动过程中的 UI 重刷操作。虚拟机优化，包括 JIT 关闭，降低 GC 次数。基础模块调优，分析主线程耗时操作并优化。另外，用户使用过程中 App 的内存、存储、电量及流量等消耗，也是重要的衡量指标。具体的优化点如下：内存：内存分析：memtrace hprof 线下内存分析，遍历对象，根据生命周期标记内存泄露，同时根据 object 创建引用确定业务归属。Native 内存：图像库切换到 native 层，4.x bitmap 像素数据放到 ashme 共享内存，降低 GC。内存优化：对象池复用，减小 bitmap 对内存占用，使用更小的图，尤其注意三方 H5 页面。存储：存储分析：查看应用存储大小。存储优化：使用共享库，业务定向优化，压缩存储等。流量：耗流量原因：分析各种网络请求。流量异常捕获：hook 所有网络请求，根据host聚合流量，超过阈值确定异常。流量优化：PC 底层协议优化，资源增量按需下载，同时通过切面信息调用方。电量：耗电原因：监控 CPU 使用率，各种 sensor、gps、weaklock、网络连接等耗电操作。耗电异常捕获：遍历线程，获取所有线程运行时间，与主线程比较确定异常。耗电优化：高性能 dump 线程栈优化，通过线程映射调用方，评估调用逻辑进行优化。针对以上每个优化点，支付宝都投入了大量精力进行研究和实践，有关启动性能优化的详细内容可以查阅文档《支付宝客户端架构解析：iOS 客户端启动性能优化初探》和《支付宝客户端架构解析：Android 客户端启动速度优化之「垃圾回收」》，其他优化点请持续关注“客户端架构解析”系列文章。基于这些对用户体验优化的内容，支付宝构建了一套完整的超级 App 线上运维体系，实时监控线上 App 发生的异常问题，针对这些问题，以最快的时间定位问题原因并找到对应的解决方案，最后通过动态热修复的技术及时修复线上问题，最终形成一个线上质量保障的闭环，保障应用运行的稳定性。MAS移动分析框架浅析接下来，详细介绍超级 App 运维体系中的移动监控框架具体是如何实现的。移动分析 MAS（Mobile Analysis Service）通过对移动客户端、H5、小程序、PC等多端埋点数据的采集与分析，实现产品核心指标监控，提供页面、设备、留存、性能等基础分析，并支持自定义事件分析、漏斗分析等高阶分析，帮助企业更好地完成业务监控、用户洞察与行为分析，指导产品迭代，精细化产品运营，辅助营销决策，加速业务商业化。主要分为以下四个阶段：整个移动分析的完整链路从左往右看，就是客户端通过调用埋点 SDK 的接口进行数据埋点，埋点 SDK 对日志进行格式化后，先写入客户端本地文件，满足日志上报触发条件后，将本地日志上报到日志服务器并清理本地日志文件以减少存储大小；日志服务器接收到客户端上报的日志后同步到计算平台，经过离线计算和实时计算后，将结果进行展示，用来监控、分析、搜索、推荐等。接下来我们将从移动分析框架的四个阶段，详细介绍数据分析的整个链路逻辑。数据采集根据采集数据时机、应用场景，最终用途的不同，我们把客户端采集的数据分为了以下几类。其中结合 mPaaS 模块化开发框架，报活埋点、押后台埋点、页面自动化埋点、性能埋点及 H5 埋点，由客户端 SDK 自动采集，无需开发者手动调用接口实现，开发者只需要关注自己的业务逻辑，在需要监控的逻辑除埋点统计。为了降低频繁上报日志对应用性能的影响，客户端采集到数据后，会预先保存在应用本地，通过以下三种方式同步到日志服务器：自动上报：满足一定条件后客户端埋点 SDK 自动上报，包括程序每次冷启动都会触发检查日志上报的逻辑。程序进入后台会立即触发上报。写日志时，某种类型的日志默认到达 40 条就触发上报。实时监控：对于比较重要的客户端日志，如异常、应用闪退日志等，可实时上报，产生一条上报一条，便于后台实时监控。动态控制：在自动上报的基础上，通过服务端下发的开关值，修改客户端日志写入和日志上报触发的条件。如在大流量并发的情况下，为减少日志服务器的压力，控制客户端只写入并上报异常或闪退日志，忽略行为日志的统计。数据计算上报到日志服务器的日志，会同步到计算平台进行计算，后台主要包含以下几个系统：mdap：日志采集网关，负责收集客户端埋点日志，收到日志后，直接传输至 JStorm 集群进行计算。JStorm：实时计算引擎，根据处理规则对日志进行实时解析并将需要的数据存储入库。SSDB： kv 数据存储层，底层使用 leveldb，支持单表十亿级记录。ZooKeeper：集群管理、组件间服务发现。数据应用计算平台计算出来的结果，可以为用户提供用户分析、事件分析、行为、性能等数据分析服务。基础分析：关注于 App 的通用分析，包括每日登录用户、新增用户、使用时长、用户留存、页面分析、访问路径等基础分析。高阶分析：用于 App 专注业务的特定分析需求，提供一种灵活的多维分析能力；提供热修复报告，帮助您了解 RPC、修复、回滚相关信息等。性能分析：提供闪退、卡死、卡顿的统计功能。当客户端发生性能问题后，移动分析服务提供实时查看性能分析的统计数据。日志管理：支持按关键字实时搜索查询日志，或通过服务端开关实时控制客户端日志上报逻辑。数据决策在上一步数据应用的基础上，可以与大数据、营销平台及推送平台结合，根据移动分析得到的埋点数据，通过大数据平台进行打标、圈人、用户画像及建模后，可以在营销平台上发起一次营销活动，指定活动的类型，活动算法，参与人群及活动奖品，通过消息推送、数据同步，动态发布等形式，触达到客户端，实现客户端拉新促活、活动推广及操作引导的目的。同时结合运营活动的场景需求，形成了一套完整的数字化运营体系，监控一次运营活动的参与人数、活动发放率、核销率等，观察活动的有效性。mPaaS 技术架构与助力上面介绍的支付宝内移动端分析方案的技术积累和架构实践，已经通过 mPaaS 移动开发平台作为蚂蚁金服金融科技的一部分对外开放。mPaaS(Mobile Platform As A Service)，源于支付宝 App 的移动开发平台，为移动开发、测试、运营及运维提供云到端的一站式解决方案，能有效降低技术门槛、减少研发成本、提升开发效率，协助企业快速搭建稳定高质量的移动 App。在 mPaaS 移动开放平台上，我们将移动分析框架中的本地日志、埋点、自动化埋点、性能监控、Crash报告、诊断日志等模块，作为一个个独立的组件来进行输出。任何一个 App 都可以通过 mPaaS 插件，添加对应的组件，在当前应用中集成这些功能，只需要这样简单的操作，就可以让你的应用具有和支付宝一样强大的移动端分析监控能力。客户端集成了这些移动分析相关的组件后，用户在使用APP过程中会产生相应的日志，经过数据采集、数据上报、数据计算等处理后，计算的结果会同步到 mPaaS 移动分析的大盘上展示，包括应用的基础应用概况、性能稳定数据、流量走向等等，方便开发者实时监控 APP 的概况大盘和稳定性等，实时发现线上问题并修复。目前，mPaaS 移动开发平台已经服务了众多企业，包括蚂蚁金服内部的香港支付宝、网商银行、口碑商家等，同时还有大量的外部蚂蚁生态合作伙伴，包括12306、上海地铁、广州地铁、广发银行等。秉承着「给世界带来小而美的变化」的理念，我们通过 mPaaS 帮助 12306 这样的国民级 App 重构了客户端，使得大家可以用上一个好的体验的 App 进行出行购票，用 mPaaS 这样成熟的底层框架搭建一个 12306 仅需要 2-3 个月的时间。除了 12306 还有支付宝香港版，广发银行手机银行和发现精彩多个客户端，同样在短短几个月的时间内便完成了业务重构。蚂蚁金服ATEC城市峰会·上海2019年1月4日，一场金融科技的前沿探索之旅——蚂蚁金服ATEC科技大会即将起航，你准备好了吗？小蚂蚁为大家准备了满满了攻略福利，等你来拿！了解蚂蚁金服ATEC科技大会更多信息，记得持续关注小蚂蚁（官微：蚂蚁金服科技）蚂蚁金服金融科技官网：https://tech.antfin.com/artic…ATEC科技大会：蚂蚁金服ATEC（Ant Technology Exploration Conference）科技大会是蚂蚁金服在中国举办的最大的技术盛会，旨在向遍布全球的合作伙伴与技术专业人群分享新技术的发展趋势与落地实践，通过对先进的前沿技术探索与讨论，为世界带来平等的机会。ATEC大会一直在路上。过去一年，蚂蚁金服ATEC科技大会走过杭州、硅谷、新加坡、伦敦等全球金融科技中心城市，之后将会造访国内各个金融科技中心城市，与当地受众分享蚂蚁金服对金融科技最前沿的洞察。ATEC科技大会报名方式 & 福利：本次大会门票采用审核制。嘉宾填写个人信息进行报名，报名后3天之内收到报名审核成功的短信，即为报名成功。大会报名截止日期为2018年12月31日24时，额满即止。前50位报名嘉宾将会优先审核通过，先到先得哦~小蚂蚁还为大家准备了本账号读者的专属福利邀请码： SF2B3A 还等什么，赶紧点击下方报名链接，小蚂蚁期待你的到来ATEC报名链接：https://alipaytech.mikecrm.co… 本文作者：平生栗子阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...

阿里妹导读：在阿里，音视频会议已经成为跨地区沟通、开会以及招聘的首选方式。据悉，目前阿里巴巴的办公网络与音视频会议已经覆盖全球33个国家和地区，其中，音视频会议在过去3个月平均每天召开超过2000余场。在使用如此频繁、覆盖面如此之广的音视频场景中，如何满足全球各地使用者的不同需求，保障交流的顺畅？下面，我们一起来探讨、研究。音视频行业的发展音视频行业发展迅速，经历了1970年代的黑白时代、1980年代的数字化时代、1990年代的数字标清时代、2006-2015年代的高清时代，2016年逐步开始以融合通信为主的行业趋势，高质量（4K，高清，高帧率，HDR）、多场景（点播，直播，实时通讯）、云化（硬件软件化，平台云化）和行业化已经成为当下音视频行业的发展趋势。音视频行业未来的发展趋势，在我看来就是云+端+服务。云：平台云化，从PaaS到SaaS，从私有公有云，一切都是基于云的服务。端：兼容各种终端，PSTN和VOIP，会议室设备，手机，PC，Web，Android终端等。服务：包括短信，语音，IM，音视频，呼叫中心，云客服和附加AI服务等多种服务。目前，音视频已广泛应用于包括B2B（企业与企业间、企业内部间）、C2C（用户与用户间），以及B2C（企业和用户间）。根据著名Cisco的VNI（Virtual Network Index）预测，到2021年，地球上将有46亿互联网用户，271亿联网设备，82%互联网的流量是视频。每一秒钟将会有一百万分钟的视频内容被创建，其中4K高清的内容会增加30%，相当于每个月生成71亿部DVD影片，直播的需求也会大幅增长15倍。从视频本身发展的趋势看也是一路狂奔向高清、CIP、4CIP、720P、1080P、UHD4K和8K；加上高帧率FPS 120-160FPS、HDR（High Dynamic Range）、宽色域（Wide Color Gamut），一切发展变化都是为了给人一种身临其境的Immersive体验。当然还有VR、AR、360视频，这所有的一切都意味着更多的视频数据流将被生成和消费。网络环境让我们需不断完善音视频服务如果网络带宽是无限且畅通无阻的，那世界将是多么美好。但网络并不是一马平川的。有时像十一长假堵车，有时像乡间泥泞小道，而且还有可能布满大坑。根据Silver-Peak跨美国和欧洲的网络健康报告发现，网络传输的延时、抖动和丢包是普遍存在现象。有时网络状况就像天气一样令人难以捉摸。虽然网络的平均丢包率只有0.34%，但个别情况下可以达到2.2%；而且丢包从来都不是均匀的，是突发性的Burst，网络延迟可能会超过平均值300多倍。这些极端的网络情况对音视频的传输和用户体验来说，都是极大挑战。网络和音视频流量的供求矛盾，网络传输的不确定和不完善的残酷现实，倒逼着我们不断完善和监控音视频服务。音视频内容从生产到消费的过程会经历不同环节，且链路较长，其中涉及的技术也较多，下面将主要对其中的视频编码，网络构架进行解析。视频编码视频编码标准的选择视频编码标准作为视频技术的核心，在过去几个世纪出现过很多不同标准，但最终被市场采纳主要为以下两套体系：一套是标准化体系的H264、H265 和正在制定中的VVC；另一套是开源无版税的VP8、VP9和AOM(Alliance for Open Meida)的AV1。阿里巴巴是AOM的成员也同时积极参与VVC的制定，对于视频编码的核心不能被掐住发展的咽喉。针对不同场景的不同编码需求视频不同的应用场景（如：点播、直播、实时通讯），决定了在每一个应用场景底下对编码的不同需求。对点播而言最重要的是编码效率，如何有效节约带宽。直播对延时有要求，但是是在秒级的，对编码的速度和稳定性的需求也比点播高。实时通讯对“点对点”的延时要求最高，同时它对稳定性和容错性的要求也很高，这需要通过平衡编码效率来实现。如何配对编码率与分辨率视频编码以前简单地采用固定压缩参数，固定码率和固定分辨率，对于HLS和MPEG-DASH的ABR(Adaptive Bitrate)，也用固定编码率和分辨率来配对。这就无法满足不同视频对码率的不同需求。1M的720P动画片看起来可能已经不错了，但是1M的720P动作片看起来就会很糊。但对于ABR，编码率和分辨率也是一个动态平衡的过程。在低码率的情况下用低分辨率以减少块状效果（blocking effects），当码率的提高到一定程度时提升分辨率，包围不同分辨率RD曲线的就是凸包（Convex Hall）。曲线中的交叉点就是理性的编码率和分辨率配对。如何确定视频质量的衡量指标但怎么确定曲线中的交叉点呢？这需要有衡量视频质量的指标。通常的视频指标包括主观的MOS分和客观指标比如PSNR，SSIM和VMAF。阿里巴巴的视频质量指标，不但结合了通用的客观指标，也同时考虑了影响播放质量的的卡顿和网络状况。如何进行自适应编码自适应编码（Content Adaptive Encoding）是视频编码的一大趋势。从One-size-fit-all的单一编码参数、码率和分辨率配对，到根据视频内容的复杂度进行定制化的编码参数适配。自适应编码可以针对单个视频、场景、GOP，甚至是Frame用不同的压缩参数进行动态调整，这样最大限度优化视频质量、节约带宽。这种自适应优化最重要的就是视频质量的衡量指标。一旦定义好可用的指标，就可以围绕它进行不同层次的优化。对于自适应编码，机器学习可以大有用处。比如利用机器学习针对不同的视频特征，找到对应优化的编码参数。人脑占人身体的比例不大，但是消耗人体大约1/3的能量，人的基因特性决定了大脑只会关注画面中重要区域，忽略不重要的区域。利用这种ROI（Region of Interest）进行编码，就可以在保持视频主观质量的情况下减少编码率。比如人脸和文字是经验意义下的ROI的例子。音视频服务器网络架构实时音视频服务器的网络架构，除了MESH外，还有MCU（Multi-point Control Unit）和SFU(Selectiveforward Unit)两种。MCU是集中的媒体处理服务，优势在于可以对媒体和信令进行控制和转换，如对媒体进行转码、转流、混屏、分流，对信令进行转换，对媒体包进行路由优化等等。MCU可以减低Client端的CPU和对网络带宽的需求，但是MCU的缺点也较明显，那就是服务器CPU的开销以及带来的延迟。相对MCU来说，目前更流行的架构是SFU，它主要的好处是简单、低时延、高吞吐，缺点是对client端的带宽要求比较高，client上传一路或者多路流同时下载多路流。SFU的客户端可以发单流、多流（Simulcast）和SVC。根据运用场景的不同，客户端发流策略也不同。在阿里巴巴的音视频会议系统中，采用的是一种SFU+MCU的混合模式，以保证最大的兼容性。这种SFU和MCU级联的策略保证对各类客户端的最大灵活性。此外媒体服务器在不同区域可以进行级联，客户端就近入会、就近补包，减低第一公里和最后一公里对音视频质量的影响。网络带宽评估网络带宽评估是实时通话的关键技术。阿里巴巴在这方面进行了很多针对会议室场景的优化。并且通过评估算法可以在服务器端快速发布，不用等待更新客户端软件。在弱网不可避免的情况下，通过合理的带宽分配，确保音频优先传输，同时及时把弱网信息传达给用户，同样可以得到用户理解，提升用户体验。后记音视频提供的是服务，不是单点的QoS，用户的最终体验不是简单的抗丢包率、卡顿率的指标，而是端到端的体验。所以不仅需要我们在事先创造一个良好的音视频环境，更需要我们对整体链路进行质量监控。除了能及时发现问题，快速响应外，还能帮助我们不断发现与创造更多新业务场景。通过把业务数据化，再根据数据来指导业务，这样才能让音视频的服务体验达到极致。本文作者：致凡阅读原文本文来自云栖社区合作伙伴“ 阿里技术”，如需转载请联系原作者。

阿里妹导读：不同岗位、不同职责的技术人对工程师思维的深度要求是不一样的，但从多维度去思考却应是每个技术人都应该具备的素养。本文整理自阿里巴巴高级技术专家至简在团队内部的个人分享，希望通过对工程师思维的分析和解读，让大家能正确对待那些在现实工作中看上去与本职岗位无关，却对团队效能影响极大的一些点和一些事。作者简介：至简，阿里巴巴高级技术专家，是集团Service Mesh方向的重要参与者和推动者。曾出版《专业嵌入式软件开发——全面走向高质高效编程》一书，坚信和倡导软件设计是软件质量之根本，并对软件开发的复杂性本质有着深刻的认识，对如何高质高效实施软件开发有着自己独到的见解和方法。在社会分工的背景下，软件行业的工程师群体被划分成了开发、测试、产品等诸多岗位，以协作的方式共同完成价值创造。高度依赖软件的互联网行业正以全新的方式改善着人们的生活，同时在改善的道路上对价值创造的效能提出了更高的要求，而背后是对个体与团队的协作效能有着更高的诉求。专人专岗的协作模式在进一步改善团队的协作效能时所面临的最大挑战在于“岗位墙”，即岗位间衔接不可避免会出现一些模糊地带，而这些模糊地带又很容易相互忽视，导致失去关注而很大程度地拉低了团队效能。比如，开发工程师会认为保证质量是测试工程师单方面的职责；开发工程师不关注用户体验而只需关注实现需求，等等。此外，这种协作模式也会固化个体的思维和心智模式，将个体的思维和心智框定在所处岗位之内，以致对于岗位之外的内容不能很好地理解，使得个体在整个协作活动中会缺乏同理心、系统性，从而影响工作幸福感。相信这些现实工作场景读者并不陌生：开发工程师对产品工程师所提出的用户体验方面的需求会认为过于吹毛求疵；产品工程师因不理解技术的实现原理而提出天马行空、不接地气的需求（我们在此不讨论创新这一特例）；测试工程师因为不理解工程效率的内涵而将自己的工作变成了体力活；开发工程师不清楚自己对于软件质量的责任，而将那些本因自己做好的琐碎工作心安理得地交给测试工程师去做；辛辛苦苦所开发出来的功能，用户抱怨难用。这些问题发生的最终结果，一定是团队协作效能的低下。那么在没有找到比专人专岗更好的协作模式的情形下，我们该如何发挥个体的力量去改善团队的协作效能呢？改善的起点在于全面地梳理工程师思维，帮助工程师个体在职场和职业发展中建立起更为全面的思维和视野，以促使每个工程师在协作过程中能最大程度地发挥个体能力去推动团队协作效能的提升。我将工程师思维分解为产品、技术和工程三大思维。每个维度主要关注的内容通过几个关键字去表达，如下图所示。下面针对每种思维需要关注的每个词以图中从上至下的顺序去解释。由于解释是基于关键词去展开的，所以段落之间的衔接可能会显得生硬，还请读者见谅。产品思维产品思维的起源是用户（或客户）价值。用户价值是通过技术手段以产品或服务的形态去解决用户的痛点，或带去爽点。毫无疑问，工程师在日常工作中应时刻关注并理清自己的工作与用户（或客户）价值的联系，并且应该通过聚焦于用户价值去安排工作的优先级和分配自己的精力。当用户价值足够时，产品能否在市场中立足并真正收获收益，首先考验的是产品的用户体验。良好的用户体验一定是站在用户的角度，基于用户心智来塑造概念，由于概念存在理解和解释成本，所以塑造的概念应足够轻、少且易掌握。概念一旦塑造出来则概念间的关系也随之确定，这些关系基本上决定了产品与用户的交互流程。好的产品体现于“易用”二字，其极致在于迎合用户的本能反应并符合各种生活或专业常识。所有产品都存在演进的过程，所创造的用户价值也在被不断地挖掘与探索，那时不同的细化价值需要通过产品特性去区分和表达。特性也是产品差异化的一种体现，特性也间接地确定了软件实现层面的功能模块边界。作为开发工程师，也需要对产品特性有非常透彻的理解，并能将其很好地抽象并转化为软件实现层面的功能模块。特性需要考虑通过售卖license等形式进行开启或关闭去实现售卖，这一点对于2B的产品甚是必要。为了产品更好地演进，需要通过数据闭环的形式去检验创造用户价值的效果，让产品的开发、运营、营销工作做到有的放矢。在产品价值创造的道路上，最害怕的事莫过于只顾低头干做加法，做得多却无人关心收效。而我们通过数据化闭环的形式，不仅能让整个产品大团队聚焦于核心价值，还能帮助团队在探索用户价值的道路上理性地做减法。大多情形下，做减法远难于做加法。技术思维技术思维的源头是需求。需求可以分成市场需求、系统需求、特性需求等不同层次，回答的是技术层面“做什么”的问题。显然，清晰表达的需求以及对需求的精确理解才能确保将事做对。毋容置疑，需求一旦出现偏差所导致的浪费是非常严重的，也正因如此工程师对于需求的质量相当重视。需求一旦确立，会基于模块化的思想拆分成多个功能模块去降低实现的局部复杂度，最终将所有功能模块“拼接”在一起去实现整体需求。每个功能模块会安排给一个人或一个团队负责，由于功能模块是需求分解后的产物，容易导致工程师在实现的过程中只看到“树木”而忘记了“森林”。性能是工程师在实现一个功能模块时不得不关注的，特别是当功能模块被运用于高频、时效性敏感、算力有限的场合时性能将尤其被关注。在现实中有时会存在工程师乐于追求性能的极致去体现自己的技术实力，甚至出现过早追求性能而滑入过度设计的误区。毫无疑问，一个正规的团队，对于功能模块的开发工作多会以项目制、多个迭代的方式去完成交付。不少工程师这里会有一个误区，忘记了敏捷思想所倡导的“项目计划的目的是为了适应变化”，而是将“按时交付”当作是天职，各种赶工爬到终点时却毫不意外地看到了“一地鸡毛”的景象。在迈向第四次工业革命的道路上，人工智能、大数据、机器学习，Kubernetes、Istio、Knative、Go、Dart、Flutter等新技术不断冲击着工程师已掌握的技能。快速跟上技术的迭代步伐是每个有追求的工程师不断提升自己专业素养的表现之一。工程师的内心一定不缺乏对新技术的追求，憧憬自己所掌握的技术具有一定的先进性。工程思维工程思维的起点是流程。流程的背后是科学，以既定的步骤、阶段性的输入/输出去完成价值创造，通过过程控制确保最终结果让人满意。由于流程涉及每一个工程师的工作质量与效率，其含义不只在于定义、工具化、检查等内容，而是应基于工程师的日常工作习惯，将流程与工程师的工作环境无缝整合。“无缝”体现于流程中的概念与工程师群体已建立的专业常识相一致、没有增加毫无价值的负担，根本仍是确保易用性。机制的含义是通过对所需解决问题的分析，以一种模式去解决同类问题。机制应体现一定的系统性，而非“头痛治头，脚痛治脚”。系统性不是一开始就能被洞察到，可能在演进的过程中逐步发现和完善的，因而需要工程师在工作的过程中不时回顾并付诸实践去落实。对于工程师来说，机制是通过系统性的软件设计去达成的。可以说产品质量直接决定了工程师的工作和生活幸福感。一个质量不可靠的产品一定会给用户和工程师自己带去麻烦，甚至造成无法挽回的经济损失并造成负面的社会影响。对于工程师来说，那势必打乱个体的工作与生活节奏。为了让产品的质量做到可靠，单元测试、静态分析、动态分析等确保工程质量的手段应成为工程师的基本工作内容，通过将这些手段与CI（Continuous Integration）流程进行整合去持续构建起对软件产品的质量信心。在互联网行业，除了软件产品的质量得可靠外，风险可控是另一个不能忽视的内容。而风险可控是建立于系统性机制和质量可靠之上的。对于服务端软件来说愈是如此。风险往往出现于资源使用的极端场景，当从外部涌入的过多事务远超软件产品的处理能力时，需要有一定的机制让整个产品能相对平滑地应对，或是扩充资源、或是限制涌入事务的流量。软件所需的机器成本是比较容易忽视的话题，软件成本不只与软件性能相关，还与软件之间的依赖、技术方案等因素相连。当一个软件需要从公司的内部对外输出时，平时忽视对成本的关注就会暴露出成本问题。比如，为了运行某个软件需要数量庞大的计算资源，所导致的资金开销对于客户来讲很可能是无法接受的。至此，大致介绍完了自己所理解的工程师思维。延伸了解工程师思维的价值在于，工程师个体需要在工作中逐步建立起产品、技术和工程三大思维，以便用更为全面的视角去看待日常工作中所面临的困境和困惑。当站在单一的思维去看待所面临的问题时可能觉得不合理，但从三大思维层面去审视时所得到结论可能完全相反。从团队协作的角度，只有团队中有更多的个体从多维度去进行思考，才容易发现岗位间衔接的那些无人问津的灰色地带，进而通过补位、助攻去更大程度地发挥团队的效能。显然，不同岗位、不同职责的工程师对于这三大思维的深度要求是不一样的，但从多维度去思考却应是每个工程师都应该具备的素养。最后，我也给读者留下一些问题，同样期待您在留言区分享自己的思考。本文作者：至简阅读原文本文来自云栖社区合作伙伴“阿里技术”，如需转载请联系原作者。

摘要： 构筑敏捷能力中心，打造下一代数字银行“操作系统”！小蚂蚁说：近年来，越来越多国内外领先银行全力投入数字化转型。数字化转型是技术与商业模式的深度融合，最终结果是商业模式的变革。银行数字化转型是一个逐步递进的旅程，敏捷能力中心的打造如同建设下一代数字银行“操作系统”，在银行数字化之旅中具有里程碑意义。银行业已进入全面数字化时代，数字化转型将从改善客户连接的1.0时代，进入到以敏捷能力为核心的数字化2.0时代。蚂蚁金服认为，打破过去独立分散的系统架构，铸造以分布式平台为支撑的金融敏捷能力中心，将成为银行机构全面数字化转型、提升客户服务能力的重要引擎。2018年11月29至30日，由《当代金融家》全媒体集团、鸿儒金融教育基金、蚂蚁金服主办的2018年（第七届）中国中小银行发展高峰论坛在广州举办，论坛围绕新时代中小银行金融科技与风险防控展开，来自监管层、股份制银行、国内城商行、农商行代表及相关机构领约300位专业人士出席峰会。在演讲中指出，银行数字化转型是一个逐步递进的旅程，敏捷能力中心的打造如同建设下一代数字银行“操作系统”，在银行数字化之旅中具有里程碑意义。他解释道，“敏捷能力中心从根本上解决企业的管理效率，以及服务终端、前台创新的问题，可助力银行不断快速响应、探索、挖掘、引领用户的需求，提升用户体验，降低服务成本，在全面数字化时代领先行业。”曾经，金融行业由于对可靠性和风险管理的要求高于一般行业，而后台修改的成本和风险较⾼，所以驱使他们会尽量选择保持后台系统稳定性的IT建设模式，把大量的业务逻辑（业务能力）直接部署在前台系统中，形成厚重的前台系统。这样便形成业务联系彼此割裂的状态，并未能很好地支撑前台快速创新响应用户的需求，降低了用户体验。随着IT技术的不断发展，曾经微服务、DevOps等技术也给出了技术上实现敏捷能力的“银弹”。但局部的方案未能从根本上解决全行级敏捷问题，银行的业务部门、研发中心、数据运维中心各自都是拿着拼图的一部分寻找方向。峰会上，蚂蚁金服结合自己的实践，从自身的实践总结出覆盖技术、数据、业务多个维度的敏捷能力中心，与广大银行业伙伴共享，以助力各家银行机构打造自身的“数字化操作系统”。据介绍，数字化时代敏捷能力中心包括以下几个方面：敏捷技术中心：把分布式架构体系涉及到的研发、测试、治理、运维、风险形成完整的支持全行应用的技术平台。除此之外还有三地五中心的灾备架构、免疫架构、防御资金安全和不断地、主动地发现故障等。这些技术能力体现蚂蚁技术敏捷中心不断追求的在分布式架构下的敏捷与自愈能力，将“不确定性变为确定性”。敏捷智能中心：把数据智能计算、数据研发、数据资产有机组合形成全行统一数据平台和金融智能应用，例如针对全行风险八大领域，构建全行级风险平台，实现风险管理统一化、风险技术平台化、风险数据规划化。敏捷业务中心：沉淀分布式架构下组件化、服务化的业务核心能力，向上提供平台化领域服务、开放式的编程接口来帮助快速构建存贷汇、互金等各类业务产品；同时封装了金融级分布式架构中的技术复杂性，降低分布式转型的学习曲线，提升分布式转型速度。纵观银行数字化发展历程，数字化1.0从移动端开始，着力于改善客户连接，提升业务触达能力。而刘伟光分析道，到数字化2.0时代，银行等企业机构重点在于通过分布式架构，获得数字化原生企业的标准技术栈能力，来建立与数字化原生企业相对标的三大核心竞争力：技术敏捷能力、数据智能驱动能力、业务敏捷能力，打造面向下一代数字化转型的数字银行“操作系统”。基于这些能力，银行可在未来的数字化3.0时代，建设多方位的生态合作新型银行模式：对内进行业务场景接入，对外通过API Bank向企业开放、建设基于API的应用生态市场模式，构建基于金融组件化操作系统的开放生态银行。本文作者：平生栗子阅读原文本文为云栖社区原创内容，未经允许不得转载。

摘要： 数字金融时代！小蚂蚁说：我国"十三五"信息化规划明确提出，全球信息化将进入全面渗透、跨界融合、加速创新、引领发展的新阶段。未来，以云计算、大数据、区块链、人工智能为代表的新兴技术将改变金融行业的形态、支撑设施和运行机制。越来越多的银行开始拥抱科技公司以加速数字化转型。今天我们以“移动化”为主题，向大家呈现一些零售业务、小微金融业务领域的典型合作故事，与大家探讨金融数字化转型。为什么银行纷纷走向开放？未来移动金融、数字化银行将需要怎样的能力和运营？数字金融时代，金融科技创新的领先机构，各自都有哪些实践经验？近期，广发、西安等领先的股份制银行、城商行，以及更多的农商行都相继发布新一代手机银行服务平台。移动优先战略成为金融机构数字化转型的重要实践之一。基于每家机构的业务战略差异，各家的数字化战略也会有各自的差异化。而如西安银行王欣副行长在《多维深耕打造数字化银行》一文中指出，今天所有业务都推向手机端，未来银行将打造APP统一入口，通过场景化联接方方面面，移动化是数字化转型战略的核心。值得一提的是，从各家银行对新一代手机银行的App的升级和塑造来看，于金融机构而言，手机App不再仅是一个渠道，而是经营新一代银行的移动终端工具，因此无论从技术架构还是业务的发展，转型路径规划中呈现出前、中、后台完整的建设体系的趋势。这样银行可通过“统一银行超级App”来实现端到端客户旅程的数字化改造、建立“全渠道、全业务、全智能”的服务能力，拓宽、深化服务半径，打造卓越的随人、随地、随需、随时的服务和客户体验。今天我们以“移动化”为主题，向大家呈现一些零售业务、小微金融业务领域的典型合作故事，与大家探讨金融数字化转型。“小微金融专家”台州银行如何利用科技创新提升服务台州银行的服务一直极具特色。针对小微企业主白天工作时间长、生意经营繁忙的情况，以及小微企业融资“金额小、需求频、周期短、要求快”的特点，从创立初期开始，就调整、延长了服务时间，并于1989年在浙江金融界最早推出“夜市银行”。台州银行推行“简单、方便、快捷”的服务理念，每一项业务都有限时服务规定，将柜面业务办理时间精确到秒，使贷款业务达到“新客户3天内回复，老客户立等可取”的效率。此外，台州银行还练就了一套标准化的风控技术。在90年代，凭两张身份证，就能贷到两三万元钱，个体户的融资难题也迎刃而解。如今台州一些产值几亿元的规模企业曾经就是他们客户，从这里获得第一笔2万元、3万元的小额度贷款开始的。随着数字化时代的到来，台州银行更是把这些优秀的服务理念推向新的高度。为了更高效、便捷地服务客户，台州银行引入蚂蚁金服移动开发技术，以及在线生物识别和智能风控技术Zoloz，发展移动金融业务，一方面将服务效率和体验持续优化，同时拓宽服务半径，推动普惠金融的发展实践。突破疆界“发现精彩”，广发银行的移动金融创新2018年9月，将是广发银行成立三十周年。近年来，该行通过金融科技的主动创新，在为客户提供金融服务的同时，也在提高自身风险控制能力，不断实现自我升级。在移动金融中心的建设方面，广发银行引入蚂蚁金服移动开发平台mPaaS构建新一代信用卡“发现精彩”App和手机银行两大App，解决App用户体验差、数字化运营能力弱等问题。通过蚂蚁移动开发平台mPaaS，广发大幅提升了APP开发和运营性能，其中 “发现精彩”的启动时间就降低近70%，同时具备了强大的实时稳定监控能力，保证线上金融服务稳定流畅。作为一家历来“以客户为中心”，高度重视用户体验的金融机构，广发银行除了通过技术升级改善用户体验上全面落实，还在产品设计上大胆创新。举个例子，不久前，广发信用卡推出了多种给利信用卡产品，其基于大数据实时营销平台，率先做到消费后实时返现，在服务用户中践行普惠金融理念。日前，广发银行闪亮发布了手机银行4.0新版。广发手机银行4.0重构重建,针对目标客群特点，重新设计手机银行界面、交互和流程，形成广发银行特有体验风格，并融入银保协同、人工智能、生物识别等新元素，打造差异化。据介绍，手机银行是广发银行重点打造的综合性金融生态平台，是最主要的移动网点。广发银行2018年9月介绍，值该行成立30周年之际，广发手机银行客户数已突破3000万，年复合增长率超90%，稳居同业前列，手机银行已成为该行客户服务最主要的渠道。据介绍，未来广发银行全面实施 “数字广发”战略，积极推动金融科技发展，推进实现服务智能、业务协同智能、数据动能，以及风控效能和平台的聚能，以“平台互联、数据互通、能力开放、场景聚合”为目标，将手机银行打造成开放的平台，将产品服务进行整合和场景嵌入，为客户提供综合金融服务，创造更多业务价值。常熟银行的移动金融创新从第一家银行“网点”落成起，网点数量成为银行业务发展规模的衡量指标之一。但数字化时代，这些常规都将被打破。常熟银行以“农村金融领跑者”为企业愿景，并不只是意味着更多的网点增加。作为区域性农商行，该行高度重视科技创效与互联网金融业务发展，以及零售转型创新。一方面，依托公司条线、零售条线客户经理走村入户提供三农金融服务的模式，常熟银行采取错位竞争策略，发力零售银行业务，持续下沉服务，拓展小微金融服务范围。在此实践下，助推融资便利化、精准化，扶持了一大批小微客户成长与发展，并帮助银行进一步迭代到依托公司、零售、金融市场业务“三驾马车”，资产规模稳步增长，资产质量稳中提升。另一方面，在科技和组织的创新上，常熟银行加大转型创新力度，组建财富管理中心，打造私人银行团队，积极推进客户精准服务。同时，大力发展线上业务、手机银行，推进大数据平台建设，进一步提高科技自主研发水平。据介绍，在新一代信息系统建设中，常熟银行把移动互联网和移动终端作为金融科技的关键技术，并且“移动化”能力作为该行未来业务发展中的第一阶段关键能力。为统一移动端平台的开发与运营管理，加快移动金融产品迭代速度，常熟银行引进蚂蚁金融科技mPaas作为全行统一的移动平台架构。同时，引进分布式数据库OceanBase搭建基础分布式架构能力，助力搭建数字银行大中台，为实现未来的移动银行目标打好基础，全面适应互联网时代的发展。西安银行APP的智慧城市建设与场景金融连接背靠千年文化古都、旅游名城，以及在智慧城市升级的时代变化下，西安银行旨在通过科技创新，布局未来数字金融发展，提升银行对经济和人们生活的服务。因此，西安银行需要通过以建设新一代移动金融中心为抓手，进行数字化转型升级。在经历了电子银行、网络银行、移动银行后，银行业已经全面进入数字化时代，金融科技创新正加速重构银行经营发展模式和市场竞争格局。这样的环境下，西安银行提出以下数字化转型战略目标，以实现“体验和单产提升，风险和成本双降”：利用互联网技术打造创新的产品体系、创新的获客渠道、创新的风险管理机制乃至创新的金融生态。将“数字化”注入全渠道业务的全流程闭环操作，全面提升客户体验，形成新的交互体验。建立全方位对接互联网机构的业务和科技能力，形成场景共享，生态共建，着力打造具有高效流程、大数据模型和高并发支撑能力的平台。探索“集中+分布”的开放融合架构，推进云平台集中管理模式的应用，实现信息科技支撑的安全高效、开放融合、集中管理和弹性扩展。移动化、平台化、场景化，统一移动服务门户，以开放、标准的框架无缝打通手机银行业务生态，并以平台化的方式，对内聚合产品与服务，对外链接合作伙伴与客户，广泛连接各类金融生态场景。数据化，通过大数据应用和挖掘，全面客观地刻画客户标签，设计针对性的产品和营销方案，提高“识客、达客、获客、活客”能力。西安银行通过引入蚂蚁金服移动开发平台mPaaS，对手机银行进行架构升级，实现手机银行由传统移动渠道向移动金融开放平台的转变。在这个平台上，从基本银行业务功能，到生活、出行、购物消费，银行能从全生命周期了解用户，推动个性化的产品设计和服务能力，精准触达用户，将金融服务渗透到用户的生活当中，推进普惠金融实践。在合作过程中，通过mPaaS模块化组件，西安银行手机银行从建立标准化开发框架，到应用模块组合，逐步完成新一代手机银行数字化、智能化、平台化升级。性能优化基于mPaaS经历过支付宝高并发、大流量检验的组件，以及分布式底层框架，西安银行新一代手机银行能够支撑复杂的客户端情况，接口响应速度从平均500ms提升到平均200ms左右，提升手机银行平台化高频、多维运营能力。场景化金融生态圈建设基于mPaaS的小程序App开发技术，构建手机银行App生态，简单快捷地将支付宝小程序迁移到自己的App中，拓宽数字化服务的广度和深度。智能营销基于mPaaS的用户行为分析、数据同步等黑科技组件，更好地了解用户，了解需求，通过数据化实现数据驱动业务运营智能化。敏捷开发基于mPaaS模块化开发框架，西安银行可实现手机银行App模块化多人协作开发，从研发上提升App功能应用的开发迭代效率。……总结2018年9月21日云栖ATEC大会上，结合与合作伙伴的广泛探索，以及自身的经验，蚂蚁金服自主研发并开放了未来数字金融或数字经济社会所需的5个基础科技。海量金融交易技术、金融智能技术、区块链技术、金融安全技术、新一代交互技术，在蚂蚁金服技术解决方案中的多条重要技术主线上，无数的金融场景都能被一一对应，蚂蚁金服也由此不断在技术前沿展开探索。此外，蚂蚁金服还发布了基于实践总结的数字化转型构建框架，基于该框架，以及蚂蚁金服实践中总结的五大解决方案，金融机构可定义标准、量化评估自身数字化阶段和缺口，与蚂蚁金服共同寻找数字化转型最佳抓手。未来的数字化银行也会逐渐形成差异化、快速创新、细分市场的商业格局，只有结合自身银行特点、选择适当的数字化转型，并快速实践获得“银行数字力”才能成为未来的赢家。未来，我们将继续深度分享更多合作故事，通过更多的技术创新与实践，蚂蚁希望帮助银行机构在推进数字化转型中有经验可循，有技术可用，有方案可落，有效果可预期。本文作者：平生栗子阅读原文本文为云栖社区原创内容，未经允许不得转载。

这可能是个别人写过很多次的话题，但貌似由于兼容性的原因？图标的显示还是用着 Iconfont 或者 CSS Sprite 的形式？希望通过自己新瓶装旧酒的方式能重新引导一下问题。SVG vs Image比方说现在要做下图这样的视觉效果：分析：可能需要三张图片鼠标移入时的背景图渐变色前景图鼠标移入时白色前景图独立图像现在对比一下背景图使用图片与使用 SVG 格式的体积大小（做图的时候拿错颜色了，其他都一样，能说明道理就行，见谅见谅）可以看出，在肉眼感觉差异不大的情况下，WebP 格式体积最小，其次是 SVG，而 PNG 的体积过大。 这个 SVG 是在 Sketch 设计稿中导出来的，源码包含了很多冗余无效的代码，实际上是可以优化的，如下。内部源码优化后优化后大约可以减去 1K 个字符。当然这个需要内联使用（Inline SVG）CSS Sprite使用 CSS Sprite 的方式可以减少 HTTP 请求，貌似还可以减少总体图片体积。这里用前景图来对比一下，实际上背景图和前景图都可以合成一张 sprite。可以看出，CSS Sprite 的体积比 Inline SVG + CSS 的方式大很多。SVG vs Image 结论绿色部分表示 SVG 比 Image 略胜一筹的地方，黄色部分表示有所欠缺的地方，灰绿色表示差不多。1、如今已接近 2019 年了，对于 IE9 (2011年) 这种古老的浏览器都支持 SVG，所以再过多强调更低的兼容性也没有什么意思。2、Inline SVG 在浏览器应该是被渲染成 DOM 节点，所以关于 DOM 节点的性能优化都有必要注意；一个 SVG 图像可能就会有很多路径，即 DOM 节点，太多的 DOM 节点必然会影响浏览器的渲染性能及内存占用，而纯位图的渲染方式应该是没有这方面的顾虑。（DOM 数量影响参考：Google WEB 开发者文档）综上结论：除开复杂图像，选择 Inline SVG 或者 <img/> 标签的方式引入 SVG，会比使用 独立图像 或 组合图像 (CSS sprite) 的方式更好。SVG vs Iconfont书写对比首先看下 Iconfont 与 SVG 图标的使用方式，来源 阿里 Iconfont 平台很明显 SVG Sprite 使用起来没有 Iconfont 方便，需要写 3 行代码， 而后者只需要写 1 行。当然上面的不是重点，重点是下面的换色与多色支持换色与多色支持换色1、Iconfont 通过 CSS color 可以轻松更换图标颜色。2、而 SVG Sprite 比较麻烦，SVG Sprite 的代码原理如下。// 定义 symbol<svg> <symbol id=“icon-arrow-left” viewBox=“0 0 1024 1024”> <path d=“M694 … 44.576-45.952”></path> </symbol> <symbol id=“icon-arrow-right” viewBox=“0 0 1024 1024”> <path d=“M693 … 0-0.48-46.4”></path> </symbol></svg>// 使用<svg><use xlink:href="#icon-arrow-left"/></svg><svg><use xlink:href="#icon-arrow-right"/></svg>渲染出来的 DOM 结构是这样的：渲染在了 Shadow DOM 中（关于 Shadow DOM 的知识可以阅读下这篇文章或这篇），这样的 DOM 元素样式就具有了作用域，外面的 CSS 对 shadow-root 内的元素不会生效，如果想要更换元素的颜色，需要使用 /deep/ 来穿透添加样式，如下。svg /deep/ path { fill: red;}当然，实际上在只需要在父级元素上添加 fill: red 这样的 CSS 也能起到同样的效果，里面的元素会继承父级的样式。PS: /deep/ 是 shadow DOM v0 的写法，v1 已经把这样的写法抛弃了，实际上支持 v1 的 shadow DOM, 父级的样式可以直接作用在 shadow-root 里面的元素。多色支持1、Iconfont 是不支持多色图标的。2、而 SVG Sprite 可以利用 CSS 变量或 shadow DOM 的方式支持多色图标，shadow DOM 的方式上面已经说明，下面借用他人的文章解释 CSS 变量实现多色，如下。不过使用 CSS 变量或 shadow DOM 的方式兼容性都不好，CSS 变量：Edge15+shadow DOM：更差。兼容性列表3、Inline SVG 可以良好地支持多色及多色变化。渐变色支持Iconfont 与 SVG Sprite 不支持渐变色。Inline SVG 支持渐变色，并且兼容性良好。渲染无抖动使用 Iconfont，因为字体文件是异步加载的，所以在字体文件还没有加载完毕之前，图标位会留空，加载完毕后才会显示出来，这个过程就会出现向下图（来自 GitHub blog）这样的抖动，而 SVG Sprite 或 Inline SVG 内联加载则不会出现这样的抖动。当然，Iconfont 也可以内联加载，不过需要转换成 base64 同样式表一起加载，转换后的文件体积则会变为原来的 1.3 倍左右这是由 base64 编码决定的（编码知识链接）。字体转换成 base64 的一个在线工具：https://transfonter.org/体积较大这个是 SVG 对比于 Iconfont 的一个不足之处，如下图。Inline SVG 与 SVG Sprite 体积差不多。开发成本三者的开发成本都差不多，不过 SVG 的两种方式都需要前期做些配置，后期开发就会顺手很多（单页应用）。以 vue + vue cli 为例说明 Inline SVG 便捷使用。1、 配置 Webpack loader:{ // 排除需要转换成 Inline SVG 的目录 exclude: [resolve(‘src/svgicons’)], test: /.(png|jpe?g|gif|svg)(?.*)?$/, loader: ‘url-loader’, options: { limit: 1, name: utils.assetsPath(‘img/[name].[hash:7].[ext]’) }},{ // 指定特定的目录用于 Inline SVG include: [resolve(‘src/svgicons’)], test: /.svg$/, use: [ // 读取 SVG 源代码 { loader: ‘raw-loader’ }, // 精简优化 SVG 源代码 { loader: ‘svgo-loader’, options: { plugins: [ { removeTitle: true }, { removeViewBox: false }, { removeDimensions: true }, // …其他参数 ] } } ]}2、 创建 SvgIcon.vue 组件:<template> <div class=“svg-icon”> <div class=“svg-icon-wrapper” v-html=“icon”></div> </div></template><script>export default { name: ‘SvgIcon’, props: { name: { type: String, required: true, }, }, data () { return { icon: this.getIcon(), } }, watch: { name () { this.icon = this.getIcon() }, }, methods: { getIcon () { return require(@/svgicons/${this.name}.svg) }, },}</script><style lang=“stylus” scoped>.svg-icon { overflow hidden display inline-block width 1em height 1em &-wrapper { display flex align-items center >>> svg { width 100% height 100% fill currentColor } }}</style>3、使用：<SvgIcon name=“arrow-right” />SVG vs Iconfont 结论应该是 Inline SVG vs SVG Sprite vs Iconfont 的结论，如下图。综上结论选择 Inline SVG 或许是一个不错地选择去替代 Iconfont 的使用方式。扩展阅读GitHub 网站很早之前已经将图标的展示方式由 Iconfont 转成了 Inline SVG, 这一篇文章是他们的描述：https://blog.github.com/2016-…很早的一篇文章关于两者的对比：https://css-tricks.com/icon-f…最后欢迎各抒己见谈论一下对 SVG 和 Iconfont 的看法，优缺点，欢迎留言。然后，本文同步发表于【凹凸实验室博客】或微信公众号，欢迎关注我们，么么哒。 ...

摘要： 支付宝从最开始的工具型应用，逐渐发展成平台型应用，一直到现在，已经成为了一个超级 App。本文将带领大家进一步了解支付宝在动态化方案的探索以及 Nebula 框架。小蚂蚁说：此前分享的《模块化与解耦式开发在蚂蚁金服mPaaS深度实践探讨》（想要了解更多相关内容，欢迎关注公众号：mPaaS )已经对支付宝在移动端开发架构的设计思路有了初步了解。本文将结合在 iWeb 武汉站的分享，带领大家进一步了解 mPaaS 在移动端动态化方案设计。分享内容将分为以下三个方面：支付宝动态化方案的探索；Nebula 框架浅析；mPaaS 科技赋能支付宝动态化方案的探索任何一种技术方案都是在业务的发展和架构的演化中逐渐探索出来的，因此我们来看一下支付宝架构的演进： 支付宝从最开始的工具型应用，逐渐发展成平台型应用，一直到现在，已经成为了一个超级 App，它拥有多应用的生态，更加开放和动态化，并且保持着高可用，高性能，高灵敏的强大特性。随着 App 的逐渐庞大，整个应用的架构也在进行不断的调整，来适应各种特性。现在的支付宝客户端的架构如图所示： 整体架构分为五层：容器层、组件层、框架层、服务层、应用层。客户端整体采用统一的框架开发，模块化的开发模式，完全插件式的容器，支持模块独立发布，方便大规模团队的并行开发。在这样的框架结构中，同样包括了我们的动态化方案。支付宝中的动态化方案主要有两种框架：Nebula 和小程序。这两种方案不仅解决了需求迭代速度和发版周期之间的矛盾、跨平台开发、实时发布等一些普适问题，而且有效地保证了发布质量，对线上问题进行紧急止血，同时也有助于建立良好的开放生态。Nebula 是支付宝移动端 Hybrid 解决方案，它提供了良好的外部扩展功能，拥有功能插件化、事件机制、JSApi 定制和 H5App 推送更新管理能力。主要功能包括：接入 H5App 后台，方便管理离线或者在线 H5App，实现 H5 应用的推送、更新。加载 H5 页面，并按照 Session 的概念进行管理各个页面。Android 使用 UCWebView，拥有解决系统级 Webview Crash 的能力，内存管理更合理，网络加载提升更快，兼容性更好。彻底告别了在Android下兼容不同 Webview 的问题。支持自定义网络库，自定义网络通道；支持自定义键盘，自定义 Native View替换 H5 标签。提供丰富的内置 JSAPI，实现譬如页面 push、pop，标题设置等功能；支持用户自定义 JSAPI 和插件功能，扩展业务需求。自带埋点功能，接入 H5 监控平台，能够实时看到页面加载的性能、错误报警和监控。还有一种动态化方案就是支付宝小程序：支付宝小程序是一种全新的开发模式，融合了 H5 的易开发性、跨平台性、Native 性能，让开发者可以快速开发高性能的页面，提供优异的用户体验。通过使用支付宝小程序，开发者为支付宝开发了大量优质的小程序，丰富了支付宝生态能力。小程序开放给开发者更多的 JSAPI 和 OpenAPI 能力，通过小程序可以为用户提供多样化便捷服务。Nebula框架浅析Nebula 的架构如图所示，从上至下依次为 H5 应用层、服务层、原生框架层：H5 应用层：基于 HTML 和 JavaScript 技术开发，在 H5 容器上运行的手机应用，它拥有跨平台的特性，配合离线包的使用可以完成实时热修复的功能。 服务层：为开发者提供了高阶语言的 API 来使用手机系统资源，包括：视窗系统，开发者可以使用它来创造应用 UI，包括文字，图片，按键及定制 View资源管理，通过它开发者可以方便的访问如多语言文字，图片和布局等非代码资源应用生命周期管理，它决定应用在手机系统里的开始，结束以及强制关闭的时机H5 容器原生框架层：是手机系统的基础层，它提供了标准 API 来让高阶语言（比如 Java 和 Object-C）使用底层的硬件，并包含了许多为硬件访问的专有软件库。当上层调用某个框架 API 来访问硬件时，手机系统将加载相应的软件库。整个 Nebula 框架的核心部分就是 H5 容器，下面看一下 H5 容器的结构：H5Service，H5Session 和 H5Page都是从 H5CoreNode 类扩展而来，以 H5Service 为根节点，它与其他类一同形成了树状结构构成了页面流程和导航。在一般情况下，H5Pages 是 H5Session 的子节点，而 H5Sessions 是 H5Service 的子节点，在任何情况下只有一个 H5Service 根节点存在。H5Service：是 Nebula 里维护 H5 应用全局状态的基础类， 在 H5 应用的生命周期内只有一个 H5Service 的单例全局实例，H5Service 可以进行的操作包括：创建且打开一个新的 Web activity创建且开启一个新的 Web page从共享空间存储和读取数据注册插件和 Provider监听应用的生命周期H5Session：一个 H5Session 是由一叠 H5Pages 组成的完整业务流程。例如一个收银台的流程包括：一个购物车的小结页面，一个结账方式的选择页面，和最后一个结账确认页面。所有的页面都可以独立存在运作， H5Session 在其中的作用是把这些页面组织起立，按照业务逻辑把它们按序排列来完成业务。当你使用 H5Service 创建且开启一个新的 Web page 时，如果当前没有 H5Session 的话，一个新的 H5Session 实例将被创建，并为后续创建的 Web page 共享。你可以从 H5Session 中移除页面直到页面叠为空，也可以使用 H5Session 所提供的方法来获取首页，以及监听该 H5Session 的生命周期。 H5Page：是用户看得见，摸得着的页面，也是应用生命周期中最重要的一部分。你可以通过 URL 来加载内容，用 H5Param 来定制页面的外观和行为，甚至可以通过获取 H5Page 的视图层次，把 H5Page 视图和其他原生 UI 部件一起内嵌到同一个布局中。下面是 H5 容器的几个重要组成部分：API 管理器主要管理 JS API：Nebula 中已经提供许多内置的 JS API 供开发者使用，比如操控 UI，显示对话框和 Toast，以及使用网络 RCP 服务等。插件管理器主要管理 Plugin：如果现有的 JS API 无法满足你的业务需求，你也可以选择创造一个新的插件。你只需把原生代码打包在插件中，在管理器里注册该插件，便可在 Javascript 层使用新的 JS API 了JS Bridge 是连接原生层和 Javascript 的沟通桥梁：它将 Javascript 代码转译成能在系统框架运行的字节码，同时也把原生层的数据结构转成 Javascript 对象使其能在 Javascript 层处理。这里 Nebula 针对JS Bridge 做了一些优化：在 Android 里，js 调用 native 的通讯是通过 console.log 的方式，这个和其他容器实现不一样，其他容器一般通过 prompt 的方式来实现的，但是使用 prompt 的方式，有两个弊端：使用 prompt 会阻断整个浏览器的进程，如果 native 处理时间一长，会导致页面假死。prompt 是在 UI 层面上会弹出一个模态窗口，在 native 没有对其进行捕获处理的话，会造成一个问题。一旦这个页面放在非此容器的环境下，就会出现一个很诡异的 prompt 弹窗。在支付宝内，曾经出现过这个问题，天猫页面在支付宝 app 里的时候，由于容器机制不同，页面中 bridge 脚本没有判断环境，导致页面中 js 调用 API 的时候，在页面上出现了 prompt 的模态对话框，严重影响了用户体验，但是如果使用 console.log 的话，就不会出现这个问题。console 的方式避免了不兼容环境的体验问题和同时也避免了页面的假死。jsbridge 注入的时机，由于业务逻辑要依赖 bridge，所以业务的所有逻辑都会在 bridge ready 之后才会触发，而 bridge js 本身运行是要一定的时间的，因此注入的时机对于性能的影响显得非常的重要。但由于 H5 页面的生命周期和容器的生命周期是相互独立的，因此在 H5 生命周期的哪个阶段注入这段 bridgejs，对于性能的影响就显得异常重要。现在在支付宝内使用的方式为监听 H5 生活周期的事件，比如说当 Webview 设置 title 结束之后，Android 会放出一个 onReceivedTitle、shouldInterceptRequest 等事件，iOS 会尝试在 webViewDidStartLoad 事件，在监听到这些事件之后，立即注入 bridgejs，让其在 H5 生命周期尽早运行。通过这种方式的注入，经过测试，最早能在页面加载开始后， 50ms 以内就能成功注入 bridgejs。Event 机制：Nebula 提供了一套事件机制来管理事件在 H5Page，H5Session 和 H5Service 之间的流通顺序。一个 H5Event 可以在 H5Page, H5Session 或 H5Service 任何一层发生，事件派遣分为两步完成事件拦截。这个步骤中事件派遣的顺序为 H5Service -> H5Session or H5Page。事件可以在任何节点被拦截 （如果 interceptEvent() 返回 true ），也可以在任何节点被处理 （如果 handleEvent() 返回 true ）：如果事件在派遣过程中被拦截或处理，该事件将被视为已被消费且不再继续流通。如果在派遣过程后事件依旧没有被拦截或处理，会有错误抛给呼叫方处理。仅仅使用传统的 H5 技术展示在线页面，很容易受到网络环境影响，因而降低 H5 页面的性能。在 Neblua 中我们使用离线包技术来解决这个问题。离线包是将包括 HTML、Javascript、CSS 等页面内静态资源打包到一个压缩包内，它的目录结构如图所示：使用离线包可以使容器内的 H5 应用具有接近 Native 的体验，主要优势如下：减少网络环境对 H5 应用的影响：通过下载离线包到本地，然后在客户端打开，把打开H5页面的操作从网络 IO，变成磁盘 IO。直接从本地加载离线包，不仅最大程度地摆脱网络环境对 H5 页面的影响，而且增强了用户体验。提升用户打开 H5 应用的体验：通过离线包的方式把页面内静态资源嵌入到应用中并发布，当用户第一次开启应用的时候，就无需依赖网络环境下载该资源，而是马上开始使用该应用。实现动态更新：在推出新版本或是紧急发布的时候，您可以把修改的资源放入离线包，通过更新配置让应用自动下载更新。因此，您无需通过应用商店审核，就能让用户及早接收更新。下面介绍一下离线包的渲染过程当 H5 容器发出资源请求时，其访问本地资源或线上资源所使用的 URL 是一致的。H5 容器会先截获该请求，截获请求后，发生如下情况：如果本地有资源可以满足该请求的话，H5 容器会使用本地资源。如果没有可以满足请求的本地资源，H5 容器会使用线上资源。因此，无论资源是在本地或者是线上，WebView 都是无感知的。离线包的下载依赖用户当前的网络。一般情况下，只有在连接 WIFI 的情况下才会在后台下载离线包。如果用户处于移动网络下，不会在后台下载离线包。如果当前用户点击 APP，离线包没有下载好，用户就要等待离线包下载好才能用。为了解决离线包不可用的场景，fallback 技术应运而生。每个离线包发布的时候，都会同步在 CDN 发布一个对应的线上版本，目录结构和离线包结构一致。fallback 地址会随离线包信息下发到本地。在离线包没有下载好的场景下，客户端会拦截页面请求，转向对应的 CDN 地址， 实现在线页面和离线页面随时切换。那么本地资源如何寻址呢，我们设计了独特的虚拟域名机制，仅对离线应用有效。当页面保存在客户端之后，WebView 如果要访问的话，是通过 file schema 来从本地加载访问的。然而，用户就能在地址栏里直接看到 file 的路径，这就会导致以下问题：用户体验问题：当用户看到了 file 地址，会对暴露的地址产生不安全感和不自在。安全性问题：由于 file 协议上直接带上了本地路径，任何用户都可以看到这个文件所在的文件路径，会存在一定的安全隐患。基于如上问题的考虑，采用虚拟域名的机制而不直接使用 file 路径来访问。虚拟域名是一个符合 URL Scheme 规范的 HTTPS 域名地址，例如 https://xxxxxxx.h5app.example…Nebula 里面的 H5 容器和离线包，在传统的 Hybrid 框架的基础上进行了极致的优化，使整个 H5 应用具有如下特点：对网络链路强依赖的弱化增强对设备能力的支持增强的用户体验在性能方面，Nebula 在支付宝中经过了亿级用户的考验，crash 和 anr 以及其他稳定性指标有保障。Android 平台基于 UCWebview 深度定制，crash 率和 anr 量远低于系统webview，拥有解决系统 Webview 问题的能力。图中展示的就是在 Android 端，UCWebview 和系统 Webview 之间崩溃率和 ANR 率的对比，稳定性的优势显而易见。最后看一下小程序与 Nebula支付宝小程序复用 Nebula 容器技术栈，重构了开发方式，对外暴露有限个 jsapi 接口，让 app 开发更简单，更加便捷利用支付宝的能力，进而发布、推广、运营。小程序本质上是也是一个 H5 App 离线包，但是有一些自己的特点。小程序是为第三方 App 服务的，运行在独立进程，它的稳定和闪退不会影响到主 App，也支持二方 App 运行在主进程。小程序是支持保活的，极大的提升二次打开的体验。mPaaS技术架构与助力Nebula 有这么大优势，现在不仅在蚂蚁金服内部使用，也能够提供给外部来使用。首先什么是 mPaaS 呢，mPaaS 全称是 Mobile Platform as a Service 。是蚂蚁金服独创的移动研发平台，它源于支付宝 App 近 10 年的移动技术实践和思考，为移动开发、测试、运营及运维提供云到端的一站式解决方案，能有效降低技术门槛、减少研发成本、提升开发效率，协助生态伙伴快速搭建稳定高质量的移动 App。在 mPaaS 中，我们将 Nebula 的 H5 容器、jsapi 、离线包、小程序这些模块作为一个单独的组件来进行输出，在客户端中进行配置。任何一个 App 通过 mPaaS 插件，添加对应的模块，集成这些功能，只需要这样简单的操作，就可以让你的应用具有和支付宝一样强大的动态化能力。 同时 mPaaS 提供的小程序模块，允许用户把运行在支付宝上的小程序，无缝的迁移到自己的 App 中，做到【跨平台跨应用】开发，提高代码的复用能力Nebula 组件化输出，配合 mPaaS 提供的 MDS （移动发布服务） 来实现动态更新。mPaaS 提供的 MDS 服务，能够让每次发布更新就像发邮件一样简单。MDS 具有智能灰度发布的能力，可以通过内部灰度，外部灰度多重验证，保证在正式发布之前，发布的产品质量有充分的保证，同时提供多种升级策略，包括指定人群地域、机型，系统版本，网络环境等多种规则。对于离线包来说，更新离线包的下载对网络环境要求较高，包的大小越大，更新的成功率越低，在 mPaaS 中，我们采用增量差分的更新能力，减少数据冗余及设备带宽，在移动网络条件下优势明显。同时保证更新功能的高可用性，升级接口可用率达 99.99%，在线分钟级触达。下面是 Nebula 的生态基础，首先在集团内部，我们已经支持了不少产品，同时通过 mPaaS ，我们也与外部客户合作，将我们的技术能力输出给他们，典型的几个案例，包括 12306 客户端，广发发现精彩客户端，上海地铁，苏州银行等。尤其是 12306，使用 mPaaS 改版之后，客户端整体的体验更加优越。12306 整个客户端绝大部分都是使用的 H5 技术，他们就是使用 Nebula H5 容器 配合离线包来实现，无论是页面打开速度，还是UI事件响应，体验几乎接近 native。在更新发布方面，12306 的 app 包很少更新，以 AppStore 上的发布记录来看，今年只提交了两个版本，基本上都是通过动态化的方式完成业务的迭代发布。总结下来，蚂蚁金服 mPaaS 中就是通过「Nebula H5容器 + 离线包 + 小程序 + MDS」这样的方式来实现移动端的动态化方案。本文作者：平生栗子阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...

在新零售成为大趋势的今天，餐饮行业也加入到这一浪潮之中。智能餐饮系统将帮助餐饮行业从多个维度提升自己的运营能力和收益，而打造智能餐饮系统SaaS化能力也成为了目前的一个热点。本文中果仁软件联合创始人&研发副总赵亚南就为大家带来了关于使用阿里云POLARDB构建客到智能餐饮系统实践分享。本次分享中，首先介绍了“客到云餐饮”这款SaaS化产品，其次介绍随着业务发展所需要面对的挑战，以及“客到”为什么要选择POLARDB。第三将讲述使用POLARDB的解决方案以及迁移的整个过程所做的实践，最后将分享将数据库架构升级到POLARDB之后的效果。果仁软件与“客到云餐饮”背景介绍果仁软件早在2008年就是淘宝服务平台的第一批软件开发商，当时做了“麦多多”产品，也正是因为这款产品，果仁软件成为了阿里云的第一批客户。在使用阿里云的过程中也逐渐更多地了解了这些云产品，目前整体的技术架构都是基于阿里云的。使用阿里云产品为果仁软件带来的好处就是节省了大量运维成本，能够使技术团队更加专注于自身产品和业务的开发上。四年前，基于使用阿里云的经验和对于软件的理解，果仁软件参与到了餐饮行业的SaaS化软件“客到云餐饮”开发中。客到主要实现了SaaS化餐饮解决方案，包括了点餐、收银、财务以及后厨管理和营销、员工绩效考核等。“客到”通过智能化、数字化的餐饮服务软件，可以帮助餐厅更好地提升经营效率和服务质量，让客户真正地享受到餐饮行业所带来的服务。智能化点餐以及收银能够帮助餐厅很好地降低了人力成本和时间成本，智能化餐饮系统能够让餐厅的工作人员直接在报表中看到所有的流水信息，使得对账工作更加轻松简单。餐厅的厨师本身就非常忙碌，那么借助智能化后厨管理就能帮助厨师有序地制作菜品，进而提升后厨效率。会员营销是SaaS化中常用的功能，但是对于餐饮行业，传统会员营销方式并不能有效地吸引顾客，而借助智能系统，餐厅可以开展店内店外的智能营销，使得活动更加高效，为餐厅带来更多的资金流。很多餐饮企业越来越注意实时化的信息，对于报表的实时性要求更高。因此，餐饮行业的SaaS化就可以从这样的切入点开展。此外，“客到”在用户体验上也做了精细化设置，比较简洁、实用。而通过软件与智能硬件的配合，就能够更好地赋能餐饮行业。“客到”借助阿里云的SaaS化发展之路餐饮行业的特点就是业务峰值比较高，特别是午餐和晚餐时段这一点就体现的更为明显。通过阿里云后台的云监控可以看到在这两个时间段，几乎在瞬间系统压力就会大幅度提升，这就需要系统能够很好地应对峰值情况。此外，周末的晚上会比平时出现更大的峰值，能够达到平时的2到3倍。而且餐厅的订单数据量也是非常大的，正常的一家中餐厅每餐大概会销售200到250单，一些快餐厅甚至会达到1000到2000单。这样如果服务1万家餐厅，订单量就能达到每天100万，每年订单量就会达到7、8亿。结合菜单的明细数据，这样的数据量是非常大的。而且由于涉及到订单、会员以及促销等信息，因此表结构也会比较大，而且在高峰的时候这些业务都会出现高并发。此外，由于餐厅的特点，因此对于系统的稳定性要求非常高，基本上可以说是“365*24”小时的可用性要求。因为很多餐厅不仅提供中餐和晚餐，还会提供夜宵和早餐。之前用户量小时，就可以等待用户没有的时候进行发布新版本，而当用户量增大之后发现，这样的空闲时段已经不存在了。在最初设计餐饮软件的时候，认为只要餐厅有网络就完全可以实现SaaS化。但是后来发现在业务高峰的时候，即使带宽足够，但是在访问云端数据的时候还是非常差，甚至中断而影响业务。基于这样的情况，客到实现了本地的架构调整，能够实现即使断网也不影响业务流程的继续运行，用户对于网络情况可以实现无感知，这一点在友商内能够做到的也并不多，因此也收获了较好的口碑。随着业务发展量越来越大，用户量也越来越多，需求不断增加，业务的逻辑也越来越复杂。随着多种点餐方式以及多种下单场景的增加，对于业务调整的及时性要求越来越高。此外，产品线也越来越丰富，从3个产品飞速扩展得到8个产品。而随着业务量的增长，历史数据也飞速增长，有时候会因为云端的“慢SQL”出现卡顿，暴露出一些隐藏的问题。通过阿里云监控，及时地感知到高峰时期的CPU、内存等的报警信息，进而增加服务器或者服务器组的处理。针对于上述出现的问题，经常会做一些相应的分析。从页面的加载、前端再到后台数据库都会进行排查。在系统优化方面，会每天排查出慢SQL进行优化，包括RDS也会存在慢查询的统计，虽然慢查询并不会影响业务的正常运转，但是总会带来一些不好的用户体验。针对于以上的情况，需要增加一些索引机制以及缓存层等，对于一些历史数据进行归档，对于一些业务进行拆分，减少单表的压力，同时使得业务架构更加清晰。虽然以上的技术问题并不会影响业务的正常运转，但是有限的研发精力总是被这些技术问题所牵绊，就会影响技术团队开发新的需求和功能的速度和效率。特别是对于创业公司而言，研发效率和用户需求是最为注重的关键点。因此更加希望将技术精力集中在产品业务的开发中，做好产品，服务好客户。如果能够通过更好的技术方式和产品减少非主线研发的工作量也是各个公司以及架构师所需要考虑的。也就是说除了需要解决当前问题，还需要能够支撑起两年之内的业务扩展，虽然中间也会经历架构演变，但是对于架构师而言，需要做到心里有底。此外，好的产品一定能够提供好的性能，同时在费用上需要做到可控和可预算。为大家简单分享一下“客到”基于阿里云的架构设计。首先，从用户开始访问开始，阿里云提供了域名解析服务和CDN加速以及网络安全方面的Web应用防火墙。经过域名解析之后就到了前端的服务器，而通过负载均衡器将会将前置服务器和后置服务器再次分离，进而解决应用层面的并发请求量。应用服务器为了解决Session共享问题可以应用Redis解决，实现单机出现宕机不影响用户使用，从而实现高可用。同时Redis缓存可以有效缓解数据库层面的压力，但是在使用的时候也需要注意其自身的特点，比如带宽限制以及逻辑上需要和存储层保持一致。存储层之前使用RDS，现在换用了POLARDB，之前通过一台主RDS和几个RDS只读节点就基本上解决了关系型存储，可以对于订单的历史数据完成异步的备份。对于文件和图片等的存储可以放在阿里云OSS之上，这样比放在磁盘上更加节省成本。在安全方面，使用最多的就是云监控产品，这样就可以实现问题的提前监控预警。在设计架构的时候，架构师需要不断地梳理架构，这样在进行架构演进的时候就可以容易地分析和判断架构是否可以迁移。“客到”数据库架构向POLARDB迁移实践在进行架构迁移的可行性分析的时候，首先要把现在架构的情况，涉及到的业务以及运行的主机、ECS以及OSS都需要进行风险评估。所以在实际进行系统迁移的时候需要首先进行评估。之后为了打消研发和产品对于采用新技术和产品的顾虑，就需要做充分的准备和测试，比如对于应用POLARDB而言，需要对于性能进行充分测试，比如100%兼容MySQL，还需要对于业务进行全流程测试，在测试完成之后需要第一时间进行测试反馈。在迁移之后需要进行效果评估，“客到”在迁移到POLARDB之后发现页面响应速度得到了80%的提升，复杂SQL处理性能得到了200%的提升，而费用则降低了20%。而且整个迁移过程只使用了1个多小时，生产环境目前平稳运行，并且业务代码没有做任何修改，只做了配置文件的简单替换。最后为大家分享在数据库架构迁移过程中需要注意的两个关键点，第一点就是VPC的迁移，POLARDB使用的是VPC网络连接，那么在迁移的时候就需要做好网络规划，需要把握好时间点。此外，需要注意白名单的变化，因为在整个网络架构发生变化的时候，外网IP的变动有可能影响到第三方接口调用。本文作者：桐碧2018阅读原文本文为云栖社区原创内容，未经允许不得转载。

用户体验（User Experience，简称UX 或是UE），它指用户在使用一个产品、系统或者服务时建立起来的纯主观感受。初衷写这篇文章的初衷呢是因为前段时间的项目重构，作为前端工程师（本人专业前端划水）发现原项目以前不是很注重产品的用户体验，UI设计比较糟糕、交互及交互反馈也没有考虑，响应速度也有待提高。总之，就是就是能用，好不好用用户知道。第二个原因是自己也没有涉猎这块的书籍或文章，直到看到网易UEDC的网站网易UEDC，里面有很多关于UI设计、交互设计及用户体验的文章，走马观花式的看了十来篇，有些文章还是说的很好的（剩下的个人觉得不算干货，也可能是自己菜看不懂，其实干货的文章也有所保留，有些精华人家当然不会分享了，点到为止），再加上平时生活中用的网易的产品或游戏从产品文案到UI到交互到性能都是非常棒的~（码字的时候正在使用网易云音乐，多一句嘴，网易云音乐最好的地方就是产品内容，喜欢那些推荐的歌单）所以希望自己做的东西也能像别人家的那样，于是就想写这样一篇文章，写文章的过程会不断的查阅相关书籍和网络资源来提升自己，文章完成也能分享给大家，希望读者能从这微不足道的言语中获得一些东西。但是这类文章容易写着写着写成假大空，也没有所以我文字尽量精简，多举证。推荐书籍《破茧成蝶：用户体验设计师的成长之路》《写给大家看的设计书》重要说明：本人职业是前端划水，本文只是一些学习心得或者个人经验，可适用于一些UX不是很好的网站获得一些建议，不能拔高，并非专业一、用户体验核心是用户1. 用户心理学首先，用户体验是围绕用户来说的，如果对用户一无所知，谈何做出用户喜欢的产品。比如我要做一款针对小学生的产品，我自己对00后的小学生可以说是一无所知了，那我第一步不是去做产品，而是去研究00后，研究他们的行为习惯、心理特征、消费心理等等。【用户习惯】习惯在用户体验中是必须考虑的因素，因为，习惯几乎是每个人都会有的，比如浏览网页（个人偏向PC端，这里以PC端网页为例）的习惯，著名的F型浏览模式：图一（图片来源百度）首先：通过点击链接或地址栏输入网址打开一个网页，从空白页到DOM元素渲染完成（一般情况都是同时渲染完成，这里不考虑极端情况），页面印入眼帘，习惯性的目光聚焦在第一行，这是为什么？因为一般人的阅读习惯都是自上而下，这种习惯具体追溯到哪，我也不知道，就我或者说大多数人而言，上学的时候书本内容是自上而下、自左而右的。另外，很多网站都有导航栏，而且一般都在网页顶部，这种设计也是迎合用户阅读习惯的，久而久之，导航栏在顶部也成了约定成俗的设计。后来者的设计也会参考前者的习惯，假如世界上首个网页导航栏在右侧，久而久之，导航栏在右侧才是现在的主流设计。图二（图片来源：为什么喜欢运用F型浏览模式来设计网站界面）从图二看，① 跟 ③被阅读到的可能性大于2、4，而1又大于3，一般情况下，1的位置放什么内容，logo，答对啦，你真聪明。比较成功的logo设计很容易让人一眼就铭记于心的，就像迪丽热巴的脸，过目不忘。这个例子就不说了，某东、某宝大部分网站都是这样的。然后1->3的位置出现菜单的也相对算多，尤其是那种管理类网站，这种布局不要太经典，经典到好用，没有审美疲劳…说是F，第二横的话一般指一些具体内容,如图一。正文内容的话，出现网格排布的list也是很多的，比如百度图片、某东、宝具体商品，以图片流式布局或网格线排布。但整个网页无导航无菜单的纯流式或网格排布的网站平常见的相对较少。这里只是说习惯性的设计，倒不是说非习惯性设计就是失败的作品。人是有惰性的，你要驱使他改变，你就要付出代价。威逼利诱这个词，emmmmmm，比如说你家儿子（嗯，祝你生个儿子然后给他买房，而我选择生女儿）习惯用铅笔写字，后来升学了得用钢笔写，他写不习惯不想写，你可以给他糖或者揍他让他学着用钢笔。用户也是一样的，什么？看完这篇文章答对几个问题就能拿奖金？虽然内容是自下而上的，自右而左的，但是老夫看的心甘情愿啊。或者高考试卷倒过来看？没问题啊，我看还不行吗…所以说，创新设计一定要做好权衡利弊然后判断设计是否得当，甚至可以搜集用户感受以便改变这里废话有点多，担待…内容参考及推荐阅读：什么是F型浏览模式？从F型网页浏览看用户对网页的浏览习惯比如：无法想象体验者的心情…但是，创新的东西有时候会需要打破习惯，如果打破这种习惯仍然能正常使用该产品，权衡之后，利大于弊则可以算是过关的创新，具体效果当然得看具体设计。比如：跟普通热水壶整体相差不大，握把设计略有差别，一般情况下使用区别不大，如果烧水位置比较高需要手举放上去，会不如普通握把方便，一般也没谁烧个水会放在比自己个子还高的地方。然后形象比较活泼可爱像大象，出水口够高没有生活常识的人装满烧水都不容易喷溅【用户目标】小时候都知道写作文要突出中心思想，这个快节奏年代，直入主题很重要，尤其是功能性网站（展示类另说），没人跟你墨迹，精简才是王道。（精简之上可以辅助美化细节）举个反例：前段时间看世界杯大家没少看广告，有一款黄轩代言的马某窝，全程就几句台词循环，关键是最后也没说一些产品重点，原词大概是这样的：A：旅游之前B: 为什么要上马某窝A：旅游之前B: 为什么要上马某窝A：旅游之前B: 为什么要上马某窝A：旅游之前B: 嗷嗷嗷我真的，无力吐槽，只能感叹你们真是钱多的没地方花，有本事来拿钱羞辱我啊（滑稽）。旅游相关的产品不要太多，你倒是说你的优点、特性什么的啊，嗷个jer…，到底还是有钱了再举个正面例子：记忆力有限，平时看到广告偶尔会思考下，还是看到过很多设计非常棒的广告的，奈何没有用小本本记下来，记忆力也不好。就记得彩虹糖有一款鹿吃彩虹拉彩虹糖的，记忆犹新。广告词叫：遇上彩虹，吃定彩虹（大概）还有我女神桂纶镁和男神彭于晏一起演的益达口香糖。（暴露年龄了）广告词：饭后嚼两粒（大概），故事性很强，比较有意思同时直入主题，饭后吃益达口香糖有益健康。还有一种，循环三遍，也是一句话X3的，但是人家目的明确，虽不美观，但也达到目的了，洗脑式植入，有时候莫名就记住了。【产品目标用户信息收集】说实话，之前做项目都是顺带考虑UX的，最多的就是换位思考，站在用户的角度考虑问题，揣摩用户的心思。总体来说就是没有一个严格又标准的流程，比较业余。书里(破茧成蝶)说道，揣摩用户的心思远远不够，你不可能完整的想到别人在想什么，所以还需要去体验用户的生活。当然，这个用户是我们产品的目标用户，不然你的产品是给学生用的，你去体验老大爷喝茶下象棋的生活（舒服啊老公）收集信息比较常见的方式就是问卷了，以前是纸质问卷，现在网页问卷不要太方便。很多产品用户第一次使用的时候会有一个是否加入用户体验优化计划的，勾选的用户会在一些产品阶段收到UX问卷调查（机制的我从来不勾-懒）其他方式我就不介绍了，请自行思考…然后把收集到的信息分析整合到需求中，错误的分析得到错误的结果后果很严重啊，直接影响产品质量…（比如我，一般问卷我是懒得填的，有时候需要应付就随便写写，你认真分析的对象都是假的，慎重…）【关于用户的一些事要权衡好利弊】（字数好像有点多，后面精简精简我不是写书我是写文章，阿弥陀佛）关于一个交互，A说单击好B说单击不好，C说了一些鸡毛蒜皮或者不相关的小事，D提了一条天马行空的建议，EFG…其实可能有些比较靠谱的建议，也不要一下就肯定，还需要考虑一些开发周期开发成本等问题，付出全组程序员三个月全部精力改善了产品某出体验，产品质量提升千分之一（比方里的数据都是随意捏造，为了表达意思可能夸张，真实数据我会说明，下同）所以说需要权衡2. 人接收信息的方式既然研究好了目标用户，那么我们需要了解下如何把我们的表达传递给用户。谷歌了下人接收信息的途径及使用占比，数据都是别人调研的，具体多少权威我不敢说，配合我们自己的生活工作体验该数据仅供参考，如图：最主要的就是视觉了，83的占比可以说是绝对地位了，我又要打比方了，比如两个小说网站，A的界面比较杂乱，字体、字体大小、字体颜色、模块背景颜色都很乱，不方便获得信息，B网站主题色，各级字体及大小都设计的赏心悦目，UX很直观的不在一个档次了。所以，从我上小学的时候看到的接近0css的网页到现在所想即所得的网页效果，网页的‘脸’也是越来越好看了。然后听觉也占了一定比例，给我印象最多的就是web或H5的背景音乐，还有交互时候的声音，还有音乐网站、视频网站类的。从声音能想到跟UX有关的就是是否需要声音、声音大小、声音是否应景（一个可爱风格的运营活动H5 你放一首DJ，霓虹风格的运营活动界面你放山歌，合适吗对吧）等关于嗅觉、触觉、味觉，目前跟网页好像没啥关系，相信在以后会应用到，比如餐厅的订餐系统网页，不仅提供菜肴的图片还能闻到菜肴的香味（真香警告）二、从UI提升UX从第一章我们可以了解到，人接收信息有百分之83是通过视觉来获得的，那么你的网页就有83%左右的信息是通过视觉传递给用户的（这里不要咬文嚼字啊，83只是一个网络调研数值，还是广义上的，意义在于视觉是一个绝对地位需要高度重视的点，如果你要具体到你的产品，啊，我们的产品网站是做音乐的，80%信息都是通过听觉传递给用户，你这瞎说不靠谱。我只想说，你怕是在刁难我小猪佩奇）根据从业经验及相关书籍我从以下几个方面简单说明下：1. 产品文案我不确定把产品文案划分到UI类中会不会有点不妥，我理解的是产品文案是直观、直接的形式把信息分享给用户，而其他几个方面都是间接的传递，比如背景高亮，用户能观察到这个元素跟其他不一样，自然会提高关注度或者说用户可以很快知道自己当前选中的元素等等。我这里说的文案指文字内容，不是指字体表现形式，字体属于单独一个模块。产品文案不仅是网站中很常见的元素之一，而且是生活中随处可见的，没错，就是广告了，上面我也举例说了文案相关的。我想说的几点有篇文章已经概括的很好了，而且举证很多，比较有说服力UI设计师对广告文案的思考：我们，真的不需要懂文案吗？2. 颜色颜色也是构成网站重要的元素之一。颜色有独立的象征、寓意我们常见的网站比如思否、京东、网易等等有一个共同点，就是有主题色，包括我自己在做的，也有主题色。多次的使用同一种颜色符合【重复】的设计原则（Bootstrap、element-ui等一些UI库也有）(图片来自《写给大家看的设计书》截图)首先这种颜色一定是要让人觉得舒适，因为会频繁使用，比如黄色这种，太艳、刺眼，当主题色很容易让人不舒服（当然，如果你的网站定位就是很燥的前卫的也可以，但是会筛选掉一批用户，这批用户大多数都不是你们的目标用户），然后主题色基本就定格了你的网站的风格，比如你是一家低调奢华的XX公司，主题色选了个粉色，效果就不言而喻了。而主题色选的好的，很容易形成特点让人记住主题色配上辅色，会让网站更有层次感，主题色的内容会更突出。然后颜色不要太多，如果你的网站用了七八上十重颜色，用户一眼看去肯定不会觉得：哇，彩虹哎 ， 而是觉得： 卧槽、好乱~ 颜色分深色浅色，经常会见到浅色搭配深色类似这种的。效果还不错。而且还有很多字体颜色的深浅可以体现出想表达的权重，浅灰色的字体常常用作辅助文字（用书里的话说叫亮色暗色）亮色暗色3. 字体这块我是盲的，有点高深。推荐两篇网易uedc说字体的文章，我只能懂一点点。字体图形化设计小谈、字体的性格更多的请阅读《写给大家看的设计书》字体篇，写的很详细。4. 布局常见的布局什么的，其实都是上中下左中右的搭配，比如XXX管理系统：（图片来自百度图片）比较符合习惯性的阅读方式也就是F型浏览模式，也有叫F型布局的，这一看就能看到个F，也是比较符合大众’审美’的布局（习惯）。不过这种XXX系统的网站基本都是相关人员在操作的，保持页面逻辑清晰就好了，一般做这种系统的项目他们也不会太care UX。然后还有一些诸如：对称布局、几何图形布局、网格线布局等等这是整体上的布局，没什么好说的，看UI组的能力了，再往细看，就具体到模块的【对齐】：模块内布局左对齐这一块没啥好说的，基本上的网站都能遵循到这一原则，如果一个内容较多的网站连一处对齐都没有，这个网站简直没法看。就连CMS建站工具都能做到。【亲密性】：红线标记的是一块内容，一篇文章的一些属性：标签、标题、配图、内容、点赞、作者、发布时间等信息好了，让我这个小恶魔来搞点事情这样看，你知道这个点赞这个标签是哪篇文章的吗？这就是违反亲密性原则的反例。反例是强有力的证明手段，我喜欢举反例。违反亲密性原则的网站会让用户感到迷惑，从而降低用户体验，不能匹配去找对应元素的相关信息。上面的列表例子，模块内间距等于甚至大于模块间间距的时候，这就很容易让用户对应错信息，之前的视频列表我有考虑到此原则。【重复】：说颜色的时候说到了，主题色符合重复性的设计原则，重申一次（图片来自《写给大家看的设计书》）形状（圆角）的重复使用，刚毕业那年第一次来到SF社区就觉得，啊这个主题色我喜欢，这个UI风格我喜欢，于是就定居于SF了，偶尔写写东西看看别人的分享。后来SF的app端UI风格大改，很难看，原来的好看多了。后来app就用的少了。这个的反例不是很容易想到，大家有推荐的可以评论区说出来 我补上…感谢~【对比】：加了一段css后* { font-size: 15px!important; color: #666 !important; font-family: ‘微软雅黑’!important; background: #fff !important; font-weight: normal !important;}对比前面一张图片来看，去掉了字体大小种类颜色粗细的对比、改变了背景色对比，显然，这样的网站一眼望去，抓不到重点，而且样式太单调，让人审美疲劳，想找个需要的内容都不能很快找到，这里涉及到一个速度问题，速度分两类，一是视觉反馈速度（比如页面渲染、用户操作后的事件处理及反馈）这个会在后面单独一个章节说到、二是用户获取信息速度（用户是带着目的或者潜意识都带着目的来的，通过他们的感官获取需要的感兴趣的信息，这个读取信息的过程的快慢）这是设计类的书籍（《写给大家看的设计书》），关于用户获取信息的速度而影响到主观感受是我做的延伸。对比可以让UI具有一定丰富性，防止页面太多相同处、主观感受略压抑，可以突出重点方便用户获取所需信息，从而降低消耗时间长带来的负面情绪。关于UI这块强烈推荐《写给大家看的设计书》，通俗易懂很实用。就算你要设计一些很酷有创意的东西，应用到这本书上的东西肯定会更出色的。三、关于速度1. 首次渲染速度人们的生活节奏是越来越快了，小时候感觉日子很长可以无忧无虑的玩，后来上了大学后，日子呲溜一下就跑过去了。小时候上网是件新鲜事，能看就不错了，现在上网几乎跟呼吸一样正常，因为快节奏的生活和频繁的上网，导致用户对网页的要求越来越高，不管是好看层面的还是时间层面的，大家都希望愉快又节省时间的在网站上搞定自己的需求。首页或者说首屏是打开网页的第一印象，如果这个首屏姗姗而来，让你等半天，再美的网页也没那么美了吧。关于性能优化这些都是向BAT和类BAT看齐，因为大多数网站都不会有这类公司需求高。他们一个网站信息量这么大，依然可以做到首页秒开。网上关于他们的首页或首屏加载方案有很多，大家可以自行搜索查阅，我就不再赘述了，再多写字我都发现我在写书了，手动滑稽。2. 动画速度还记得小时候只有HTML没有css的网页吗，基本上只有一些线条和间距围绕内容的网页，慢慢的，技术在发展，到如今各种炫酷的网站。css3、canvas、three.js等等这类已经很常见了。但是，关于动画，我想说，不管你是做什么动画，都要考虑时间问题（展示类网站除外），这是用户的成本，效果固然重要，但绝不能以消耗过多成本为代价。另外一点，人的肉眼有视觉停留，只能观察到0.1s及以上的动画，如果你的动画时间低于0.1s，可以说是多余的了。做过的动画有很多，经常会在各个时间值之间切换尝试，寻找一个视觉上过渡的最佳时间同时节约用户时间成本。当然，我选的也并不一定就是最佳的。只能说我尽量往这个无标准的最佳靠近。举个例子，比如我点击SF的右上角的创建>写文章，他给我来个3、5秒的酷炫动画，然后我才能开始码字，你说我气不气，嗯，可以说是很气了。尤其是频繁的操作，如果夹杂很长的动画，应该会让人抓狂吧。所以，动画的时间需要花时间斟酌好，既能表现你想表现的效果同时兼顾用户的时间成本。为什么精简的设计风格在任何设计领域始终占有一席之地，首先，精简风格有它的美，另外，节约时间绝对是它吸引人的优点之一，可能很多人自己都没意识到这一点，喜欢简单直接，这可以是潜意识的也可以是有意识的。tips：当你页面信息量很大时，一定要注重好UI设计尤其是布局。对于非专业的设计，我们前端只是辅助设计将网页更好的呈现，如果部分公司没有设计需要自己动手的话，看一些设计类的书籍加上模仿的话应该也能应付的过去。区分一下抄袭和模仿，把别人的框架布局拿来然后往里面填充自己的内容叫抄袭，学习别人的设计优点之处、融合到自己的设计，融合的得当，符合自己的内容及风格可以算是模仿。（个人理解）3. 用户操作的视觉反馈及响应速度当用户进行一些页面上的操作，需要我们给出视觉反馈。比如：鼠标悬停的时候对应按钮下会出现背景色且鼠标指针变成小手（截图截不到这个代替下见谅哈），反馈给用户的信息就是：你当前处在首页按钮上，点击会跳转到首页而不是问答页。而且背景色块和小手给人一种心理暗示：这是一个按钮，可以点击的。如果没有这些视觉反馈，当用户移动到首页跟问答按钮中间的时候（如上图红色方框），他以为（没有像素眼的用户）点击可以去到首页，结果事与愿违去到了问答页，这可能是属于用户操作失误类的，但是你没有利用代码或者其他手段尽量去帮助用户更好的操作。希望你正确的去做视觉反馈而不是这样：悬浮前：悬浮后：说实话，很尴尬。如果说hover的效果把颜色改掉应该好很多。这样去掉样式不知道什么样的脑瓜子想出来的。有一些操作可能确实没有任何需要反馈的，可以考虑是否需要一些tips去提升他的操作是成功还是失败的状态。然后还有，比如，点击某个按钮切换展示不同的模块，JS要处理逻辑、页面要局部重新渲染，或者有什么需要去后台请求才能拿到的东西。这个响应分两类：发请求和不发请求不发请求的情况下：理想的响应时间是100ms内，这个在《高性能JavaScript》书中快速响应的用户界面章节有说到，如果懒得找书可以参考我之前的文章高性能JavaScript整理总结发请求的情况下：遵循2、5、10原则，相关文章请自行搜索。四、用户体验地图当我了解到有用户体验地图这一块的时候，我才发现UX这类看似没有衡量标准的东西，在专业的人手里是有标准有规范有流程的，后来才知道有专业的UX书籍，比如《破茧成蝶》，所以觉得UX这个东西我不能只停留在主观上去想一些办法优化而没有具体手段具体流程，当然，写这篇文章我也只是阅读并参考部分内容。暂时没精力去了解太多。交互设计知识点——用户体验地图我觉得这篇文章把用户体验地图说的很好了，可以看下。（图片来自上文）五、前端er可以用到的一些方法（建议）可能对于上面那些叽叽歪歪的废话而言，这章应该是目的性很强的读者比较愿意一看的内容了，所以我也尽量整理好分享给大家： 1. 一个有辨识度设计得当的标签页icon，如果是经常访问的用户这样容易培养感情容易记住，好感度+1 2. 一个目录直观清晰、层次分明的导航条可以带领用户更好的玩转你的网站，好感度+1 3. 一个高亮的背景色块让用户自己自己处于什么位置，好感度+1 4. 鼠标悬停时高亮当前元素背景色，颜色浅于已选中背景色色值，有助于区分，好感度+1 5. 图片不要忘记设置alt属性，当资源丢失时，可以进行这张图片的文字说明，好感度+1 6. 能用css或者图标字体实现的效果就避免使用图片，性能+1，速度+1，流量+1，好感度+1 7. 用心推敲你的产品文案，表达清晰、通俗易懂不晦涩、贴近环境风格、幽默，好感度+1 8. 避免使用过多的颜色，同样避免颜色单一单调，好感度+1 9. 颜色的亮色暗色搭配使用，对比突出亮色，容易抓住重点，好感度+1 10. 布局得当，方便阅读，千万不要做些反人类的设计，好感度+1 11. 巧妙、合理的使用对齐原则，不要乱用，网页内需要相同也需要不同，好感度+1 12. 遵循亲密性原则，逻辑单元内亲近，单元之间保持距离以示区分，好感度+1 13. 重复使用一些字体以增加条理性和统一性，用非重复字体突出特殊文字的特殊性。方便抓住重点。好感度+1 14. 把握好每个动画的时间，效果得当且节约用户时间成本，好感度+1 15. 使用的图片像素大小准确，避免图片模糊效果不佳或者浪费带宽浪费时间浪费性能，好感度+1 16. 一个表意清晰、大小、空间得当的logo（如果需要的话），跟标签页icon类似，好感度+1 17. 在需要的地方设置title属性，尤其是使用了css的三个点属性的地方（正文除外），进行友好提示，好感度+1 18. 同样可以使用字号大小的对比来实现已选中状态，避免当色块对比过多的情况，好感度+1 19. 当一些图片或内容可能有些晦涩难懂时，在旁边注上小小的浅色的文字说明，好感度+1 20. 检查代码逻辑，优化复杂逻辑代码，减少js执行时间，减少用户等待时间，好感度+1 21. 针对比较慢的请求，建议后端人员进行SQL优化，减少等待时间，好感度+1 22. 简化复杂的操作流程，不要把用户想的太聪明，简单的操作更适合用户，好感度+1 23. 处理浏览器兼容性问题，避免用户遇到异常情况，好感度+1 24. 不要忽视颜色的默认寓意，比如绿色常常代表成功，黄色警告，红色错误等等，切记不要用混，好感度+1 25. 适当的替用户做主，减少用户操作，好感度+1六、一些设计、交互细节值得借鉴的网站推荐个网站：一些不错的网站汇总永远保持学习的心态，别人做的好的地方去观摩去学习去借鉴。总结：UX看起来好像跟代码关系不是很多，但是想做好是需要花时间花心思的，当然也离不开代码技术的支持。但是，很多公司很多项目都只追求数量，不停的需求迭代，开发新功能，开发时间有限。所以开发计划里面没有排UX的时间，他们的时间只够你开发功能的。这个时候希望大家在开发功能的时候可以顺手做一些能做到的UX优化的事，至于更多的，时间不允许的话，我们也只能just so so了，尽力就好。【注】：内容有不当或者错误处请指正转载请注明出处谢谢合作！ ...