技术分享

日迈月征，朝暮轮转。这一年里，科技开拓者们，产业同行者们用科技汇聚向上的力量步入了数智时代的 “星辰大海”。数字化是咱们发明进去的一个永恒并且充满活力的安装，数智技术正在以前所未有的速度倒退，并引发颠覆式的改革。 低提早、高通路的网络通信技术减速古代人类的“千里传音”；产业AI、泛在利用助力人类"身临其境"畅游虚拟世界；人工智能生成内容AIGC，让人工智能如同手握画笔，在一幅幅画卷上“妙笔生花”...... 京东摸索研究院联合近年来征询公司、学术界和产业界的热点钻研方向，公布了2023十大科技趋势，包含了自动化工具、产业AI、计算机通信、基础科学等畛域。 在这份报告中，咱们详细分析了十大科技趋势的要害因素，并依照其商业价值和技术栈层级，绘制了科技趋势全景图。技术的组合效应将放大并减速新的商业模式和翻新，通过颠覆现状和发明新的机会来扭转行业格局。 一、低提早、高通路的网络通信技术 低延时、高通路的网络通信技术是指可能缩小现有网络的限度及通信的提早，通过应用人工智能、边缘设施、基站上的加速器来解决运算负载，从而提供超低提早、高连贯密度和网络切片的独立网络，并促成基于互联网的生态系统的一种即时通信技术。 将来趋势： 高下轨卫星联结组网，单星与星座互补是发展趋势低延时高通路的网络通信为用户提供沉迷式娱乐、生存体验，减速XR设施在生产端的利用卫星通信与5G兼容方面的后期摸索，为6G有机交融高中低轨卫星通信与高空挪动通信倒退打下坚实基础二、下一代计算 下一代计算是以量子计算、专用集成芯片、硅基光电芯片等技术为代表的，冲破经典计算架构提供指数级算力增长的软硬件能力汇合。 将来趋势： 立法与标准化是将来五年重点科技企业更加器重量子伙伴关系的建设和坚固“量子服务”新型服务机构将会呈现神经状态计算的翻新架构办法将为倒退自主人工智能提供能源三、可信赖科技 可信赖科技旨在制订保障措施、加强隐衷计算、构建可信赖平台、治理工程危险，从而取得内外部利益相关者的信赖的零碎。 将来趋势： 新的数据分享技术无望保留隐衷的面纱，催生新的商业模式和产品数字主权将缩小网络安全/软件等畛域的信赖危险，为新的CX、EX和近程经营工作提供一个根底人工智能技术作为根底，将助力零售业，晋升供应链流程以及促成医疗行业倒退，晋升诊断效率及精度四、绿色 清洁 可继续科技 绿色、清洁、可继续科技旨在从清洁技术、人工智能和商业模式角度登程，满足对环境、可继续倒退和治理指标的需要。 将来趋势： 数字化向可继续方向变动人工智能将反对能源零碎的自动化云通信数据中心设施供应商正在减少可再生能源的耗费，并承诺实现碳中和经营。五、超自动化 超自动化是一种业务驱动的办法，用于辨认、审查和自动化尽可能多的业务流程、IT流程和算法流程等。它须要协调应用多种技术工具和平台，包含机器人流程自动化(RPA)、主动机器学习 (AutoML) 、人工智能工程化 (AI Engineering)、低代码平台等。 将来趋势： AI门槛将失去升高以及实现普及化AI工程实际一直失去欠缺，以继续的从人工智能中提取业务价值数据驱动的通用人工智能减速超自动化的实现云边一体化的协调主动优化，将扩充自动化的利用范畴六、人工智能等技术向实体畛域深度交融 随着技术能力晋升，先进科技正逐渐地利用于实体企业的设计、制作和经营工作。 将来趋势： 人-机-物共存的混合多智能体交融体系必然成为万物互联时代的新规范与实体深度交融的技术堆栈有可能扭转现有商业模式工业技术栈实体化交融、多智能体群体智能的高效扩大将促成无人驾驶、智慧城市、智慧工厂的减速落地七、指数级智能 AI大模型领有超大规模参数、巨量训练数据，通过模型的巨量化能够进步人工智能的通用属性，并升高人工智能的利用门槛。 将来趋势： 大模型倒退聚焦实现真正的多任务学习、推理与部署跨模态将海量数据积淀为海量常识，进步人工智能程度，进而进步生产力和商业价值面向决策和管制的认知智能将失去倒退，以全面实现面向视觉、语言等场景的通用感知智能八、数实融生、泛在利用 随着元宇宙（生产级体感设施、 XR设施与利用）开始衰亡，数字服务将突破虚实界线，深度交融数字经济与实体经济。 将来趋势： AR眼镜实现内容沉迷化、交互实时化与服务泛在化实时情境下的内容创作、散发、搜推能力助力售前决策、进步流量转化，重构实体零售业态设计制作、经营合作和翻新形式无望重塑，将推动实现元宇宙内容供应链九、人工智能生成内容AIGC 人工智能生成内容AIGC是继业余内容生成(PGC)和用户内容生成(UGC)后新兴的内容生产方式，具体指应用人工智能技术主动或辅助地生成或编辑文本、音频、视觉等数字内容，提供更加简略、高效、智能、业余的内容编辑、制作和发明技术与工具。 将来趋势： 多模态大模型为代表的新兴人工智能技术成为了AIGC能力降级的新引擎AIGC将不仅能够构建更加巨大的虚构数字场景，同时具备了语义了解、管制、创作能力AIGC的产品类型逐步丰盛、场景利用更多元AIGC技术不断进步将促成通用人工智能倒退十、AI for Science 基础科学减速冲破 下一代算力和人工智能的迅速倒退，使咱们可能充分利用更高维度、更多模态的数据中的信息、仿真更加简单的生、理、化过程，AI for Science就是让人工智能利用自身弱小的数据演绎和剖析能力去学习迷信法则和原理，得出模型来解决理论的科研问题，特地是辅助科学家在不同的假如条件下进行大量反复的验证和试错，从而大大减速科研摸索的过程。 将来趋势： 基础设施建设预计到2026年实现，将打造一系列工业级的2.0算法，建设与新计算状态相匹配的基础设施人工智能在基础科学畛域的广泛应用将在2030年失去实现，零碎扭转工业行业研发流程，AI for Science算法走向3.0与脑科学联合的下一代人工智能技术得以倒退，将人类迷信总结的先验常识更好地融入人工智能模型AI for Science扩大AIGC技术应用领域，加强人工智能在合成生物学、分子结构学、纳米材料畛域的预测能力2023年见证科技向善之力指引咱们一路繁花相送、过青墩。

数据是数字经济时代的基础性资源和战略性资源，也是重要的生产力。 在数字转型中，大多数企业在转型中面临的最大挑战往往都与“数据”非亲非故，比方数据的品质不高、数据孤岛重大、数据难以迁徙，原架构冗余、资源投入限度等问题，导致数据的实时性、准确性无奈失去保障，数据分析复杂度、难度较高，数据价值难以无效开掘。而 Apache Doris 作为业界最风行的实时剖析型数据库之一，自开源伊始的指标就是帮忙更多人解决数据分析的难题。截止目前已播种寰球超过 1000 家企业的认可，助力企业构建高效的数据分析平台和服务。 今天 9 点， Doris Summit 2022 正式启程！ 近 40 场精彩演讲，涵盖热门畛域、前沿技术解析！ 追随泛滥知名企业技术大咖，享受这场技术盛宴！ 还等什么？即刻扫码锁定直播间！ 残缺议程 各论坛亮点介绍： 核心技术个性全面解读！Doris Summit 2022 主论坛议程介绍商业与数据生态议题解读，Doris Summit 2022 分论坛议程介绍行业最佳实际论坛议题解读，Doris Summit 2022 分论坛议程介绍**Doris SummitDoris Summit 是 Apache Doris 社区举办的年度技术盛会，大会汇聚世界各地 Apache Doris 社区成员及实时剖析数据库畛域的专家。社区通过大会颁布最新动静及年度 Roadmap，集结国内外各大厂商分享基于 Apache Doris 的实践经验及行业将来发展趋势，更有畛域内大咖与大家在线互动交换。这是相干畛域从业者不可多得的技术盛宴，不容错过，期待您来加入！ 对于主办方SelectDB 是 Doris Summit 2022 的主办方，也是 Apache Doris 背地的商业化公司。SelectDB 致力于为 Apache Doris 社区提供一个由全职工程师、产品经理和反对工程师组成的团队，凋敝开源社区生态，打造实时剖析型数据库畛域的国内工业界规范。基于 Apache Doris 研发的新一代云原生实时数仓 SelectDB，运行于多家云上，为用户和客户提供开箱即用的能力。 ▼   点击浏览原文，获取峰会观看地址！

1、演讲题目利用RDMA减速FaaS服务 2、演讲工夫2022年11月6日上午10:30 3、演讲人李弘宇 北京邮电大学 网络与替换国家重点实验室硕士研究生 4、引言FaaS (Function as a Service)服务灵便可扩大，然而受制于隔离带来的开销。能够利用RDMA来减速FaaS服务，晋升性能，本次分享将从目前学术界的钻研（论文）登程，论述学界的最新研究进展以及能够从哪些方面进行减速。 5、内容简介云计算承载着聊天、领取、娱乐等多种需要，而FaaS 服务是云计算提供服务的新兴形式，然而FaaS服务中隔离环境的开销不容忽视，无论是启动容器的工夫，还是容器虚拟化的开销。这就导致了FaaS服务性能不佳，能够承当的业务品种受限。因而，利用新兴硬件，如RDMA，来减速FaaS服务是新的趋势，它涵盖了从启动、执行、到治理的全生命周期。 6、直播预约欢迎您预约直播，或者登陆腾讯会议观看直播： 会议号：581-8301-3525

主题：分享发表在OSDI2022的论文zIO: Accelerating IO-Intensive Applications with Transparent Zero-Copy IO 内容简介从最开始数据拷贝导致了内存和CPU的开销，限度了IO密集型利用的性能。零拷贝（zero-copy）IO是广泛谋求的长期指标，但已有的钻研次要关注缩小IO栈内拷贝次数，疏忽了利用中的内存拷贝。以Redis为例，一次SET操作经验了4（利用）+ 2（IO栈）次拷贝。zIO提供了一套用户态库，可在用户无感知且无需批改程序的状况下缩小利用中的内存拷贝次数。本次分享将介绍zIO的设计，并就开发中的内存拷贝问题做梳理和提醒。 zIO设计示意 常见利用中的内存拷贝次数 直播预约欢迎您通过微信视频号“达坦科技DatenLord”预约直播，或登陆腾讯会议观看直播：会议号：772-6477-5345https://meeting.tencent.com/d...

作为国内挪动互联网、云计算畛域的行业巨擘，阿里巴巴在大前端、云原生畛域有着丰盛的实战经验。阿里技术人从2016年开始逐渐将阿里团体外部成熟的利用中间件云化输入，并在2018年推出了挪动研发平台EMAS。 >>快来收费下载《云原生时代下的App开发》<< 现在，EMAS曾经逐步成长为横跨多端（挪动App、H5利用、小程序、Web利用等）场景的云原生利用研发平台，基于宽泛的云原生技术（Backend as a Service、Serverless、DevOps、低代码等），为企业、开发者提供一站式的利用研发治理服务，涵盖开发、测试、运维、经营等利用全生命周期。 点击收费下载《云原生时代下的App开发》 为了让大家更全面地理解EMAS产品背景、产品内容以及相应的利用案例，特此推出该电子书——《云原生时代下的App开发》走进阿里云一站式利用研发平台EMAS，心愿对宽广开发者们有所参考和帮忙。 >>精彩内容领先观看<<**EMAS产品背景： 端利用研发进入云原生时代EMAS产品全景介绍： 开发更便捷 阿里云推出一站式利用研发平台 EMAS 2.0EMAS客户案例：杭州银行：动摇投入挪动化策略，借助EMAS研发平台迈入挪动开发3.0时代 隐衷政策爱护下EMAS的产品升级： EMAS公布最新隐衷协定，为客户信息安全保驾护航EMAS旗下挪动性能测试： 云上的挪动性能测试平台EMAS旗下低代码mobi产品背景： 什么是低代码（Low-Code）？EMAS旗下serverless小程序开发： 基于小程序云Serverless开发微信小程序**

有限用户散发因群成员数量多、业务需求量大面临音讯散发量激增、音讯状态多样等多种挑战。 为了保障超级群在超大规模用户散发上的极致性能，融云超级群从设计阶段便综合思考了服务部署模型、音讯投递形式以及资源隔离等外围难题的解决方案。 本文次要分享融云超级群有限用户散发的架构设计和实施方案。 有限用户散发 面临的技术挑战 每个用户上行发送的每条音讯，都须要实时分发给所有用户。即便指标用户不在线，也须要转成推送，触达这个用户。有限用户可能过于形象，咱们以领有 1000 万用户的一个群为例，一个用户发送的每条音讯都会变成 1000 万的上行散发。在面对突发峰值，特地是群内有爆点音讯或大规模成员被带起节奏的时候，数据的存储和网络的散发压力会急剧回升。 超级群内成员可能面对海量信息。无论是客户端的性能或者用户的心力，都是有瓶颈的。成员量宏大的超级群会产生不同于一般聊天室的独特需要：用户心愿既能够在有须要的时候不脱漏信息，又能在无关的时候不要被打搅。 所以，哪些音讯、哪些场景须要推送，会话和音讯以什么频率和聚合的形式告诉到客户端，须要有一个微小的可定制空间。 也就是说，作为一个通信平台，在海量信息和实时聊天之间，须要把能力形象，并赋予 APP 弹性调整的能力。 因为超级群中的信息量太大，须要反对将群宰割为不同的频道，相似传统的 topic 或 channel。即便雷同的群和群成员，通过不同的频道，依然能将会话、音讯、未读数分门别类聚合。用户能够更关注本人感兴趣的局部，晋升用户粘性。将信息和聊天联合的场景，个别都有多端的需要。不同的平台，比方 Android、iOS、Web 等，在海量音讯的网络申请和存储方面都有不同的技术特点，甚至同平台不同厂商的推送通道个性也不同，这些都须要一一思考。当然，有限用户群，还须要为每个用户提供寰球的优质网络接入，保障客户端和服务器之间音讯不重不丢不乱序。 在这方面，融云平台每天承载亿级用户和千亿的音讯散发，曾经提供了松软的根底，毋庸特地思考。 计架构和实施方案 服务散发分层架构 融云超级群从设计阶段便综合思考了服务部署模型、音讯投递形式、以及资源隔离等外围问题。 无限的扩散模型： 主节点负责外围校验，扩散节点则负责数据读写，保障主节点高可用和扩散节点分组内高可用，确保强数据一致性 低劣的资源隔离： 反对私有云、专有云，分级的资源隔离，精准的流控策略 动静的投递模型： 依据群类型抉择音讯投递模型，多级音讯缓存构造，在线状态联动，多种音讯定向投递策略 存储和散发 对于底层存储而言，群成员无下限和有下限区别很大，有下限咱们能够依据下限进行设计。 比方，一般群的音讯，通常能够抉择写扩散，能够在实时投递中取得比拟好的速度和并发性。联合半写扩散（援用散发）的机制，能够在工夫和空间上做肯定的均衡。 然而超级群的场景，为了升高读写压力，默认采纳读扩散的形式进行优化。原则上 1 写 N 读，通过上下行节点拆散和一致性 hash 的特点，能够对读和写别离进行特定优化。针对热点数据引入内存级音讯环和二级 LRU 缓存，保障读写性能。 散发模式 面对海量音讯，用户心愿既能够在有须要的时候不脱漏信息，又能在无关的时候不要被打搅。 对这些业务状态进行剖析和实现，落到散发模型上，能够分为两大类。 一类是音讯驱动型，比方 Telegram，一个用户实时接管所有会话的音讯，会话状态、未读数、告诉揭示其实都是由音讯驱动的。 另一类是会话驱动，比方 Discord，用户有选择性地接管某些会话的音讯，关注度低的会话，仅须要接管会话状态、未读数、@ 信息等告诉就能够。和第一类联合起来，还能够做到订阅式的会话驱动。 散发机制决定了群的治理节点、会话节点、音讯散发节点都必须是独自的高可用逻辑单元。 音讯投递形式 用户不在线的状况下，超级群依然反对给用户进行推送。然而，思考到用户体验，APP 能够设置按工夫聚合，或者仅推送 @ 等关联度较高的音讯，也能够让用户自行抉择，设置全局、群组级别、频道级别的免打搅，缩小对用户的打搅。 用户在线的状况下，IM 长连贯个别有间接推送、告诉拉取、聚合告诉等形式。超级群的音讯和会话，会动静地联合这几种形式。协定层反对 QoS 并保障每条音讯都有惟一值，客户端能够通过增量工夫戳的形式，进行同步和弥补。 用户离线再上线的状况下，客户端会首先增量同步超级群会话信息，并通过会话和音讯的 merge 和音讯断档机制，同时保障音讯的疾速获取和信息的齐备性。 局部操作内化 一般群场景下，大部分的状态、未读数、正在输出等会话信息，默认交给客户端进行解决，以保障灵活性。 但在超级群场景下，因为海量的历史音讯和多端的特点，这些信息的存储和获取，须要内化在超级群的通信模型中。 针对音讯的变更，融云超级群也提供了一系列扩大和内化的能力，比方音讯发送时、发送后的扩大信息，并反对音讯的撤回、删除、批改、援用批改等操作。 而针对 APP 罕用的告诉或者管制信令的场景，融云也提供在线音讯等形式，保障在线用户的触达并升高散发量。 ...

明天，简直没人再狐疑云计算的价值和倒退空间 —— SaaS 市场空间微小，能最扼要地为客户输入商业价值，头部公司市值已破万亿；IaaS 代表了云计算的最后状态，将基础设施以“服务”的模式提供给客户，价值无可替代。 但在最近几年，最引人瞩目的其实是 PaaS 。据相干机构预测，从 2019 年到 2023 年，中国 PaaS 服务市场年复合增长率将达到 31%，PaaS 业务的支出将占整个云支出的 48.5%。 人们逐步发现，PaaS 平台的引入，是企业构建本身技术生态的要害一环。PaaS 的实质是软件模块的疾速构建和高度复用，关注定制化的平台能力，是企业实现麻利响应的基本。对于大中型企业而言，是否将业务、技术、数据合并成一个整体，并集中对生态凋谢和赋能，决定了其最终的倒退高度。 能够说，在翻新倒退达到肯定阶段，每一家企业都终将遇见 PaaS。 在明天，企业级 PaaS 平台也迎来了其新的倒退挑战和时机，大部分人只晓得与云原生、中台无关，却不甚具体。为了更好地解读当下企业级 PaaS 平台的技术倒退，咱们访问了用友，具体理解了用友 iuap 的技术演进和布局。iuap 是用友商业翻新平台 YonBIP 的 PaaS 云平台，也是 用友 BIP 松软的技术底座，为用友及平台生态提供开发、集成、监控、服务治理等 PaaS 服务。 用友 iuap 的倒退历程，也是国内企业服务软件技术改革的一个缩影。 1.iuap 倒退历程与外围架构 用友从 2006 年着手平台产品研发、积淀技术能力，倒退至今，用友 iuap 服务过上万家大型客户，研发老本投入超百亿。 2006 年，在《2006-2020 国家信息化倒退策略》的政策激励下，国内企业纷纷投入到信息化建设的大潮中，为了可能帮忙企业更疾速地建设信息化，用友基于应用软件，积淀平台能力，为 iuap 的呈现奠定了根底。 2010 年，在通过一段时间的技术积淀之后，用友 iuap 正式进入企业级 ERP 市场，满足企业定制开发、系统集成的需要。 2014 年，iuap 开始引入云原生技术，同时实现了从单体利用到分布式服务架构的降级，从单体利用中抽取出了要害的技术服务能力进行组件化封装，例如分布式缓存、分布式锁、打印、工作流等，更加灵便地服务于企业。 2015 年，随着企业一直上云，iuap 实现了云原生技术的重构，成为国内企业服务畛域首款齐全云原生的平台，并同时在平台之上搭载了 SaaS 服务，例如纯云原生的友云采、友报账等。 2018 年，企业对于云计算的认知逐步深刻，单纯的私有云服务不能满足所有需要，混合云成为了新趋势。因而，iuap 再次降级了架构，采纳混合云架构，全方位买通了云上云下用户、根底档案、认证、性能等，并推出了中台架构。 ...

一、前言挪动互联网时代，网页仍旧是内容展现的重要媒介，这离不开 WebKit 浏览内核技术的反对与倒退。在 iOS 平台下开发者们须要通过 WKWebView 框架来与 WebKit 打交道。尽管苹果官网提供了对于 WKWebView 的 API 与应用阐明，但这并不能满足开发者们的需要，各类简单场景仍旧让咱们焦头烂额，而解决方案却不易寻找。此时，优良的开发者们将眼光移向苹果开源的 WebKit 内核代码，试图从中寻找解惑之道，却发现仍旧困难重重，崎岖一直，次要问题如下： 内核源码简单难懂：动辄几个 G 的源码，且不足要害代码正文与阐明，跟踪剖析工作量大；零碎兼容分支较多，一块代码可能辨别 iOS、Mac、嵌入式等分支；历史代码或试验性能较多，导致查看源码并不容易缕清逻辑。无奈联合业务代码剖析：异样问题往往在简单场景下才会呈现，不足业务代码的联合，问题无奈复现，咱们也就无奈定位问题，最终容易走上猜想起因、更换计划尝试修复的路子。无论你是出于趣味还是以上起因，想要摸索 WebKit 源码而不得其法，本文都将帮忙你疾速入门。接下来，咱们将依照源码下载、源码编译、创立调试工程、源码实战剖析的步骤助力你深刻浏览内核摸索之路。二、源码下载编译及调试之前咱们首先须要获取一份苹果官网的 WebKit 源码。 github下载 (举荐)： https://github.com/WebKit/WebKit官网下载：https://WebKit.org/下载后的 WebKit 工程通过 Xcode（ Xcode 是苹果官网举荐的 iOS 利用开发工具）关上后目录如下图。WebKit工程目录其中gtest / MiniBrowser / MobblieMiniBrowser / TestWebKitAPI / WebKitTestRunner仓库为测试仓库。思考到编译效率的问题，通常状况下不须要编译测试仓库。因为本文前面将形容如何无效利用这些测试仓库，咱们此处抉择进行全源码编译。 三、源码编译获取到源码后，接下来咱们介绍下命令行及 Xcode 的编译形式。本文举荐先应用命令行编译一遍，再用 Xcode 编译。从实际来看，如果编译过程中出错，命令行编译形式更易追踪到具体异样信息。1) Embedded Builds下载的 WebKit 目录外面有一个Tools/Scripts 目录，这外面有各种脚本，包含应用命令行编译 WebKit 的脚本，其中一个重要的脚本就是 configure-Xcode-for-embedded-development，在 Mac 终端控制台运行如下命令:sudo Tools/Scripts/configure-Xcode-for-embedded-development之所以须要执行这个脚本，是因为 iOS 属于嵌入式平台，编译嵌入式平台的 WebKit 须要用到一些命令行工具，Xcode 正是利用该脚本构建这些命令行工具。否则，在编译诸如 JavaScriptCore 等工程的时候，就会报如下谬误：‘com.apple.product-type.tool’, but there’s no such product type for the embedded platform，找不到对应的架构。 ...

前些日子我给 Santd 的 Tree 组件减少了虚构树的性能，用于解决 Tree 组件在渲染海量数据时的性能问题。 虚构树这个货色，大家当前在前端业务中可能有机会用到，即便没有间接用到，理解一下虚构树兴许也能给大家提供一点解决问题的新思路。 Santd 是 Ant Design 的 San 实现，服务于企业级中后盾产品。0 目录1 什么是虚构树？ 2 为什么要用虚构树？ 3 怎么实现虚构树？ 4 最终成果 5 参考资料 1 什么是虚构树？可能有的读者还晓得一个概念，叫 “虚构列表”。 虚构树和虚构列表实质其实是一样的，只不过前者的原始数据的构造是树，而后者的原始数据的构造是列表，以及最初的表现形式不一样。 不论是虚构树还是虚构列表，外围原理都是只渲染可视区域内的数据，也就是说，用户看不到的数据就不渲染了，这也是之所以称之为 “虚构” 的起因。 一言以蔽之，虚构树就是只渲染可视区域的数据的树。 2 为什么要用虚构树？因为渲染耗时。 如果一棵树含有海量数据，比方上万条，那么，这棵树的渲染耗时会很长。 咱们能够通过一个理论的例子直观感触下。 上面的代码是应用 Santd 的一般树组件创立一个有 11110 个节点的树，代码的具体细节咱们不须要关注，咱们只须要晓得它创立了一个有一万多个节点的树并打印出了树的渲染工夫就能够了。 <template> <s-tree treeData="{{treeData}}" defaultExpandAll="{{true}}"></s-tree></template><script>import {Tree} from 'santd';function dig(path = '0', level = 3) { const list = []; for (let i = 0; i < 10; i += 1) { const key = `${path}-${i}`; const treeNode = { title: key, key, }; if (level > 0) { treeNode.children = dig(key, level - 1); } list.push(treeNode); } return list;}const start = Date.now();const treeData = dig();setTimeout(() => { console.log(`渲染耗时：${(Date.now() - start) / 1000} 秒`);}, 0);export default { components: { 's-tree': Tree }, initData() { return { treeData } }}</script>而后，咱们就能够看到，这个 11110 个节点的树在我的 2019 款的 MacBook Pro 的 Chrome 里渲染了 26 秒，将近半分钟。 ...

简介：本文探讨了如何让技术一号位可能从实践上、以宏观的视角看清日常工作非亲非故的事物的倒退法则，从而为适应法则办事或者创造条件突破法则提供理论依据。 往期技术一号位方法论系列文章： 「技术人生」第1篇：什么是技术一号位？「技术人生」第2篇：学会剖析事物的实质「技术人生」第3篇：解决问题的法则总结 本期文章篇幅较长，倡议珍藏浏览。 背景本期文章将接上期《「技术人生」第3篇：解决问题的法则总结》持续探讨技术、业务、组织的个别法则及应答策略。须要留神的是，以下内容为集体实际后果的总结和剖析，受限于集体能力和教训无限，在形容法则的过程中，可能会存在维度的缺失；或者以后形容的法则所波及的维度并不是某些读者认知中的重点，因为事物不同的维度在不同角色和级别的人的认知中重要水平不同，即：PD和研发对于同一件事件的侧重点不同；P6到P11对于同一件事件，很大概率看重的侧重点不同，咱们特地欢送不同档次的同学分享你眼中的法则进去指引其他人实际。 而对于明天本文接下来要探讨的内容，须要大家辩证地去对待，并且在探讨初始须要从新对齐以后事物的探讨范畴：以后对组织、业务和技术的法则的探讨，限定在“技术团队leader率领研发团队负责某个业务或负责某个业务的一部分”的状况下，“技术”一词指代研发人员应用的信息化技术；“业务”一词指代研发人员应用信息化技术解决的问题域的统称，“组织”一词指代技术团队 Leader 率领的团队（可能是跨团队的组织）。 同时依然须要留神的是： 上述范畴中提到的组织、技术、业务没有加上“规模”相干的限度，能够了解为，任何规模都合乎上面探讨的法则，即咱们探讨的是个别法则。同时，不同规模，即团队规模、业务规模、技术深度实质上都是非凡条件，非凡条件的存在可能会触发非凡的法则，然而还是那句话，非凡法则存在并不影响对个别法则的探讨。并且受限于自己以后理论的实际状况，不同规模所触发的非凡法则并没有全副都直观感触过（实际缺失），也没有看过相似的书籍（实践输出缺失），所以不在本文内进行相干非凡法则的探讨。不排除将来有了更多的实际会来欠缺，同时更欢送有实践经验的人整顿总结成法则分享进去。 上述范畴中提到的剖析问题的主体是技术 leader，所以对于其余角色类型的同学而言，探讨之后造成的论断须要辩证地去了解，可能有很大部分都是相通的（留神不是雷同，而是相通，象征能够互相借鉴），然而同时也有一部分是不实用的，是和探讨的主体自身的特殊性相干的。而这种特殊性对于其余类型的角色并非没有意义，恰恰相反，这可能是比拟宏观地、间接地理解另外一种角色的十分无效的路径。即经营一号位或产品一号位或业务一号位能够看到技术一号位所负责的事件中的个别法则和非凡法则，而个别法则大概率相通，而理解非凡法则是了解彼此差异性的在宏观层面的认知。 业务的倒退法则及应答策略业务的倒退法则业务的生命周期如下图所示：看图时，须要留神以下内容： 图中的曲线仅用于定性分析，非定量分析的准确图表，因而生命周期中各阶段的长度、和业务规模、利润规模的比例关系也都是示意型的，而非准确的比例关系。不同的业务，生命周期长短可能不同，各阶段继续的工夫也不同，业务方冀望各阶段持续时间长短也不同，须要具体问题具体分析。不同的业务，利润呈现的工夫和业务生命周期的阶段对应关系不同，利润规模和生命周期各阶段对应关系也不同，须要具体问题具体分析。 在此基础上，咱们简略用语言讲清楚业务倒退过程是怎么的： 启动期启动期能够粗略分为立项期和验证期。 立项期个别都是业务侧如PD或者经营发动，要做很多事件，例如围绕业务产生的价值是什么、指标客户是哪些、如何交付给客户、如何收取对应的费用继而维持业务运行上来，这个过程往往还须要联合大环境的要求补充更多细节，即以后事物的主要矛盾次要矛盾的剖析解决要合乎大环境的主次矛盾，即以后事物倒退法则遵循于事物所属大环境的倒退法则，因而须要联合组织策略、组织价值、业务所属大业务的战略目标等一系列大环境的要求来实现立项信息的筹备。 如果持续探讨，就会波及到这个探讨事物的实质剖析，咱们前面有精力的状况下会新开文章去剖析，本篇内容不再开展。这个阶段的次要作用就是通过正当的业务模式设计拉通各方对新业务的认知，获取组织的反对。优良的技术一号位会在这个阶段就染指进来，为业务发起者，通常是业务一号位，提供必须的技术视角的剖析和反对。验证期个别是在立项通过后。次要是通过疾速的产品原型的实现，证实业务模式是行得通的，证实业务或产品是能解决客户问题，并且指标客户群体的客户代表是违心为这种产品付费的。这个阶段个别会投入大量的研发人员来做对应的信息系统来撑持业务的运行。研发团队个别从这个阶段开始做深度染指，并且相较其余角色的团队而言，研发团队在该阶段是配角。 发展期当启动期内实现了价值证实之后，接下来的重点就是如何将单个客户验证的业务模式疾速地规模化复制到更多的客户场景中，从而可能让业务在肯定工夫内实现业务规模的暴发。研发团队在这个阶段会次要解决零碎齐备性的问题，因为波及到越多的客户，新的共性的场景就会越多，为了承接规模化的用户而须要补充对应的业务场景的撑持。这些补充的业务场景，往往是技术系统核心畛域的补充以及撑持。 同时，这个阶段的配角不再是研发团队，意味着研发团队的体现逐渐从次要口头方逐渐转变到幕后成为根底参与方，而其余团队如经营、PD、销售、客服等团队会独特入场互相协同形成以后阶段的配角。所以研发团队除了反对客户自身的业务需要外，还承当着业务上下游合作角色的需要的信息化工作，这一点往往是老手技术一号位可能会漠视的点。 平台期当业务通过规模化复制推广造成肯定规模当前，增长会逐渐受限于指标客户群体规模，规模增长达到下限，逐渐趋于平缓，同时利润曲线也应该在此阶段之前转正并且在以后阶段达到最大。这个阶段谋求的不再是规模化增长，而是开始持续谋求利润的最大化，降本提效往往变成该阶段的主旋律，而很多业务环节和参与方也往往会在“降本”提出当前，呈现较多的矛盾，呈现较多的问题，实质上是之前的几个业务阶段中留下的隐患，即：为了达到业务指标而采纳了看似过后荒诞不经然而实际上对整体无害的形式。 这个问题看似是短期利益和长期利益的抵触，然而对于技术一号位而言，须要寻找既能满足长期利益又能兼顾短期利益的计划，并且肯定是以长期利益为宗旨的，作为次要做事准则的，而不能反过来。其余的业务参与方应该放弃同样的认知，并以之作为实际行动准则。 业务进入平台期之后，随着整个业务进入成熟周期，很多流程逐步完善，组织撑持逐步形成体系，这套配套的组织和流程能让业务持续安稳地倒退上来，并且尽可能维持成熟期的长度，然而同样也会带来新的问题，即组织僵化后，业务对市场、客户的变动的感知敏感度降落；针对客户、市场变动的决策被提早或者阻滞；最终后果就是业务当初产生的价值不再可能满足目标群体的要求，如果不做任何调整和干涉的话，业务进入衰退期是必然的。这个阶段，业务和技术都不是破局的要害，而是组织自身。 衰退期业务进入衰退期没啥好说的，技术团队须要思考的一个问题就是，业务经验残缺的生命周期而做没了是自然规律，那么对应的技术是否也须要随着业务的沦亡而沦亡？如果技术和业务耦合度太高，那么业务沦亡天然会株连技术，而导致后续新的业务无奈利用起来。所以不管从哪个方面思考，都须要在技术设计和实现过程中，将技术体系进行系统性的、结构性的分层，底层的通用技术和通用的业务服务自身要做到业务无关，而业务相干的局部要构建成通用的业务畛域，确保业务变动当前，畛域依然是可用的，因为业务畛域自身是业务内核的反馈，只对业务实质相干的事件负责；而最上层的和产品展现层相干的内容都束缚到最上层的业务利用中，业务利用中对产品的展现和交互负责，对场景化的技术需要负责。 沦亡期如果业务进入沦亡期没啥好说的，及时转身止损，投入正当的资源善后即可。 各阶段的主要矛盾次要矛盾剖析在整个业务发展过程中，不同阶段的主要矛盾不同，不同的矛盾须要用不同的形式解决。咱们这里只探讨最根本的状况，为的是寻找法则。在理论业务的发展过程中，很可能业务属于某个阶段，然而在其余条件的作用下，主要矛盾产生了变动，这一点并不意味着咱们明天探讨的内容没有意义，因为矛盾的普遍性和矛盾的特殊性自身都是客观存在的，不能因为特殊性而漠视普遍性，当然也不能因为理解了普遍性，就不再关注特殊性。 • 启动期：前半段有无是主要矛盾，业务价值证实是次要矛盾；后半段业务的价值证实是主要矛盾（业务是否可行），业务规模化倒退、大规模获取收益是次要矛盾。• 发展期：业务规模化复制从而高效发明商业价值是主要矛盾，业务老本管制和价值变现效率是次要矛盾。• 平台期：业务老本和价值变现效率是主要矛盾，其余问题是次要矛盾（组织等）。• 衰退期&沦亡期：业务进入平台期，如果不可能基于过来的业务求变求新适应新的市场环境，则业务很快会衰败，则业务的可继续倒退就成了业务的主要矛盾。 各阶段的应答策略及如何突破法则3.1 从总体上看如何突破法则业务生命周期的各阶段并不是肯定必须要串行的，也不是有明确的界线的，所以对于某些业务，能够多阶段并行推开。 比方业务一号位能够从一开始就基于过来的业务教训和组织教训提供业务保障的流程和标准，在业务进入平台期之前即具备相干的组织保障能力；技术一号位能够在开始即构建良好的架构设计，关注业务特色，理解业务特色对技术架构的影响，也理解不同业务阶段对技术架构的影响，从而在起步阶段即实现整体设计，从而让架构设计具备前瞻性，同时基于理论状况逐步推进架构向终态的演进。简而言之，就是：既然晓得了前面哪些事件必须要干，那么在最开始的时候在解决主要矛盾的时候就棘手逐渐干掉，而不是非要重复地踏入业务倒逼技术架构扭转的圈子外面。 在生产力无限的状况下，能够减速某些阶段，压缩这些阶段继续的工夫，然而永远要晓得它是无奈跳过的。 作为业务一号位或者技术一号位，要晓得在不把握更高的生产力的状况下，业务每个生命周期都是不可跳过的，主观能动性不能让某个阶段凭空隐没，加人进来也不能让某个阶段凭空隐没，都只能是用资源老本来换工夫。要么就是压缩那些投入期的环节；要么就是缩短那些回报期的环节，然而无论如何不能扭转这些环节本来的生命周期。 所以当决策者发现主观能动性和砸人进去都不好使，都不能达到你想要的成果的时候，很大可能不是团队执行力不够强，而是做执行的人生产力不够高，至于为什么生产力不够高，是受到了生产关系的制约，还是自身在生产力方面的投入有余所以积攒无限，那就要具体问题具体分析了。 当然还有一种可能，就是决策者本人不晓得本人做的事件的客观规律是什么，主观认知上达不到这个高度，所以只能出于集体志愿和设想来提出不切实际、不符合规律的要求。当然，辩证地去看，即使是这种最极其的状况呈现了，也最终还是因为生产力不够先进，如果足够先进了，再夸大的要求、再不切实际的要求其实都能实现。 在生产力很先进的状况下，能够跳过某些阶段，或者连续某些阶段的持续时间，然而要关注高生产力带来的老本问题。 在生产力进步到肯定水平的时候，业务生命周期内的某些环节能够借助生产力跳过，而这种跳过并不是这个环节凭空隐没了，而是曾经被高级的生产力做掉了。例如能够利用成熟的中间件服务来解决分布式系统中的各种问题，而不须要反复从新做一遍。先进的生产力自身造成也是有其自有的生命周期和阶段的，在初步呈现阶段，先进生产力带来的各种老本必定是高的，甚至会高到无奈大规模推广，而随着先进生产力自身一直倒退，随着周围环境对先进生产力的适配，先进生产力的应用老本逐渐降落到正当的范畴内。因而在决定应用先进生产力影响业务生命周期的某些阶段的时候，须要关注投入的老本。 随着生产力的晋升，生命周期的每个阶段仍然能够持续细分为多个阶段，并且生产力越高，参加业务的各方能够管制和干涉的业务生命周期的粒度就会越细，能够管制的维度也越多。 如何了解这句话呢？首先要明确到底什么是生产力。生产力不是单纯地指技术人员把握的技术，而是以 “劳动者”——就是指人、“劳动资料”——就是指人应用的工具、“劳动对象”——就是指被人应用工具扭转的对象为因素，形成的概念。 所以生产力的晋升蕴含了人的晋升、人应用的工具（对于研发同学而言就是技术，对于PD或经营同学而言就是你们的工作方法论）的晋升。所以当人变得更强、工具变得更先进当前，能够革新的对象的粒度就越小，能够革新的对象的维度也就越多。 这是普世的个别法则，想想物理上化学上随着生产力的晋升人类能够革新的对象的维度和粒度是如何演变的。而这个法则在业务上的体现就是技术能力更强、PD经营方法论更先进更适宜业务的团队，可能感知并管制业务的更多的维度，业务的倒退周期也会拆解地更细。这一点其实是最和咱们日常工作最为非亲非故的一个法则。 咱们能够利用这个法则来针对“生产力不够先进的业务”构建构造上的劣势，例如在业务的“启动期”，生产力落后的一方在解决零碎有无问题时，而生产力先进的一方曾经同时在着手解决塑造品牌形象等问题。 这些问题看起来不是主要矛盾甚至都算不上次要矛盾的维度的事件，之所以在同样的业务倒退阶段，两种团队解决的问题齐全不一样，起因就是在于生产力的差别，即：落后的一方在以后阶段解决骨干问题时，先进的一方曾经解决了主要矛盾并实现了多轮“由主到次”的解决过程，而每一轮“由主到次”的过程，都是拓宽问题维度、拆分问题粒度的过程。这种劣势是结构性的，比工夫上发力更早而造成的后手劣势更高级，也更难被追上。同样的，这个法则也会在技术上同样起到作用，上面在探讨技术的个别法则的时候，会提到这个法则的具体体现。 3.2 从具体的倒退阶段上看整体应答策略• 启动期：尽可能利用现有积攒或与三方单干减速或跳过启动期。• 发展期：具体问题具体分析，与非凡法则无关。• 平台期：做好孵化新业务的技术筹备和业务筹备，防止业务进入衰退期当前组织随着业务沦亡而价值升高。• 沦亡期：利用转型或孵化新业务形成第二业务曲线，从而在宏观上看到以后组织的业务规模没有产生消退。 4 从整个业务倒退的法则来看，技术一号位须要具备哪些能力从业务倒退法则来看，技术一号位的能力大多数和做业务相干，同时和宏观的技术架构及落地把控能力相干，具体如下： • 剖析业务实质的能力，即能看清业务外部主要矛盾次要矛盾，能依据业务外部和外部环境的互相关联和相互影响来判断业务将来的发展趋势。• 剖析业务各参与方的外围利益诉求，可能正当利用商业模式尽可能多的均衡各方利益诉求，并从技术零碎上针对这种业务模式给与反对。• 剖析业务各参与方的外围利益诉求，可能应用指标别离体现各方的外围利益诉求，并且可能以体系化的维度将指标拆解，防止看问题的片面化；同时可能分阶段理清不同阶段的重点指标并在技术支持上予以歪斜，防止看问题动态化。• 在业务初期，可能联合业务的问题域，实现正当的业务领域建模；并且联合市场调研及业务发展趋势，正当设计零碎架构，体现出架构的前瞻性和扩展性。同时要开始做技术生产力上的长线投入，借短期业务需要落地长期技术布局。• 在业务中期，逐步完善业务撑持维度，全方位构建支撑体系。将支撑体系解决方案化，并且将业务撑持解决方案跨业务复用。同时利用业务初期投入的生产力的晋升，来推动业务倒退。• 在业务末期，可能实现技术侧的积淀，并且有能力孵化出新的技术产品。 技术的演进法则及对应的应答策略对于技术一号位而言，技术畛域是本职畛域，探讨技术畛域的法则时，要充沛联合组织、业务对技术的影响来谈。因为组织特色、业务特色独特决定了技术特色。在咱们开始谈个别法则时，先把“技术”这两个字讲清楚，不是要讲概念，而是要讲这两个字在不同语境下的侧重点，而后别离从不同的视角来探讨他们具备的法则。 咱们常见的研发过程分类来看，一种是业务研发过程，一种是技术研发过程。两者在某个层面恪守同样的个别法则，同时也因为各自受生产对象的不同而别离有“各自的个别法则”。留神，这里讲“各自个别法则”是指探讨范畴别离限定在各自的话题之内，而在更大的技术范畴上看，它们则是非凡法则。 为了能清晰地讲清楚业务研发过程中的技术和技术研发过程中的技术到底有什么个别法则，咱们先明确二者之间的辩证关系，对立大家的认知，为前面的探讨扫清阻碍。 从实质上讲，所有的研发过程都是业务研发过程，技术研发过程只是业务研发过程的一种非凡状况。业务研发过程服务的对象，是客户的业务人员，要解决的问题域集中在宽泛的客户业务畛域上；技术研发过程服务的对象，是客户的技术人员（请辩证地、狭义地了解客户，不要狭窄的了解客户二字），要解决的问题域集中在狭窄的技术畛域内。即：业务研发过程的内核是业务问题，技术研发过程的内核是技术问题，而技术问题是一种非凡的业务问题。 业务研发中的技术解决的对象是个别的客户业务需要；技术研发中的技术解决的对象是非凡的技术需要。技术研发过程中的技术的特殊性在于需要不是间接来源于客户在业务发展过程遇到的业务问题，而是来源于客户在业务发展过程中遇到的非凡畛域的、业余的技术问题。 技术研发过程中的技术的一般性在于不论需要从哪来，需要类型是什么，需要有什么特色，都属于狭义的业务需要，因而技术研发畛域中的技术也同样恪守业务开发畛域中的技术所恪守的个别法则。 业务研发过程和技术研发过程在肯定的条件下和非凡的阶段是会互相转换的：业务研发过程一直由主到次地解决问题，最终问题的畛域会聚焦在繁多技术问题上，变成技术研发过程；而技术研发过程一直由主到次地解决问题，最终会在进行对外价值传递时变成业务研发过程。所以业务研发过程的次要问题是对外传递业务价值，主要问题是技术在某些畛域的先进性；而技术研发过程恰恰相反，其次要问题是在以后技术畛域的先进性，其次才是自身价值的对外传递，因为其价值自身是基于它本身的先进性的。这就是业务研发和技术研发的对立统一的过程，互相演变的过程。 ...

简介： 最近我发现一些同学的分享越来越趋于“念稿”式。我一边看着分享的同学在下面念稿，另一边看着几十号人在上面看电脑看手机，我心里就特地焦急。巴不得我本人下来讲，也巴不得没收了大家的电脑手机。但这种粗犷的办法必定是不解决问题的，外围问题还是大家不长于分享。那么到底应该怎么分享呢？ 最近我发现一些同学的分享越来越趋于“念稿”式。我一边看着分享的同学在下面念稿，另一边看着几十号人在上面看电脑看手机，我心里就特地焦急。巴不得我本人下来讲，也巴不得没收了大家的电脑手机。但这种粗犷的办法必定是不解决问题的，外围问题还是大家不长于分享。 我自认为本人过往的分享都还是中等偏上的，因而总结一下，讲讲如何做场高质量分享，心愿可能给将来要做分享的同学提供一些帮忙。 一 为什么要分享每个人在分享前都应该先问本人这么一个问题，我为什么要分享？我感觉分享就一个最纯正的起因，就是“我有一些常识，是他人不晓得的，但对别人会有所帮忙，所以我想分享给大家”。 换言之，分享的本意就是总结并流传常识，分享的外围是利他。 而现实情况呢？ 做了一些技术产品，想推广给大家，所以要分享。为了体现本人有团队奉献，想要好绩效，所以要分享。就是想show一下本人，让他人感觉我厉害，所以要分享。是不是有些变味呢？其实我也并不否定这些起因，咱们如果能分享的好，这些也都是自然而然的后果。这就类比咱们退出蚂蚁最外围还是想要疾速成长，而好绩效是疾速成长的后果。但谁不想要好绩效呢？ 但咱们不能为了这些后果而疏忽了初心。分享的初心是心愿大家互相分享常识，相互成长。我感觉也只有真的能对他人有帮忙的分享能力称之为“高质量分享”。 所以，如果你在筹备分享，请你再质问一下本人，你到底是为什么要分享？只有本人初心摆正了，在做分享的筹备的时候，才会真正的去想：怎么能力把这个分享做好，怎么能力让分享生动有趣，怎么能力让分享干货满满，怎么能力更好传播本人的常识。否则，你认为本人分享了就是获得后果了，其实你什么也没失去，还节约了他人的工夫。 二 什么是好的内容好，置信看到此处的同学都是违心利他的同学了。那新的问题又来了，我须要分享什么呢？什么样的内容能力撑持所谓的高质量分享，我了解是如下三种。 1 高度总结的常识有些常识也不是多难把握，而是把握的过程可能须要破费大量的工夫去到处收集信息。过程中可能又会衍生出很多问题，须要本人破案一样的去钻研。比方很早时我写的一篇《你的Tree-Shaking并没什么用》[1]。为了钻研 tree-shaking 为什么实在场景下优化无限，钻研了 babel、uglyfy、webpack、rollup，甚至去翻一堆 issue，最终花了我数蠢才窥见原由。 其他人如果也想理解这外面的起因，也须要破费数天的话，未免太折腾了。因而我把钻研的过程总结成了文章并发表，同时在团队内做了一次分享。一方面流传了常识，另一方面如果他人真的想再认真钻研，至多能够节约一些工夫。 相似的还有一些新技术推出时，业界文档较少，大家学习老本较高，本人系统性学习当前做一些总结并在团队内做系统性的分享。比方React16刚推出时，我师兄芃程在团队内分享了16的新个性： 2 能够借鉴的教训还有一些偏经验性的内容。可能是非技术性的教训，比方成长教训、人生感悟或集体思考。最典型如降职总结、治理教训分享等等。比方咱们部门曾邀请过的一些分享： 兼续同学的《聊一聊平台技术前端如何成长》依鹭同学的《业务中台 - 合作伙伴提效》我感觉他们的分享都十分的好。比方兼续提的“微习惯”，依鹭提的“不要用战术上的怠惰覆盖策略上的懈怠”等等都给我留下了十分深的印象。 也有可能是技术上的教训，比方某类技术产品的建设教训、推导的过程等。比方2020年前端D2大会上的： 辰啸的《前端故障演练的摸索与实际》当轩的《跨端的另一种思路》霸剑的《SSR 在双十一会场的落地实战》外围就是：把本人的长期教训做一些零碎总结，以本人的故事或技术专项作为案例撑持，摆事实讲道理，给其余有类似诉求的人一些“长者”教训。 3 艰涩难懂的技术还有一些是十分难了解的常识，这种往往是非本人业余畛域的常识、或上手老本特地高的技术点、亦或是某些浅近的源码解析之类。如果咱们的分享能把这些艰涩难懂的技术讲的十分深入浅出，易于了解与排汇，那也是十分优质的分享。比方部门邀请过的邦祝老师的《Challenges for On-device System Design and Innovative Algorithms》（连题目都看不懂了）。还记得过后邦祝老师讲卷积神经网络时，板书做的很好，挺容易让大家了解。 不过这类分享在蚂蚁我见的比拟少，也很少看见讲的十分很好的。不过网上有一些，比方：李永乐老师的很多迷信、数学相干科普视频。 那是不是咱们分享的内容属于高度总结的常识、能够借鉴的教训、艰涩难懂的技术就代表着是一场好分享呢？必定不是的。内容虽有用，也要观众听。能被观众听进去的内容，能力称之好内容。所以如何把咱们的内容给分享好才是最要害的。 我认为，想分享好内容，首先是要组织好内容，而后是要找到好的形式去展现它，最初是有肯定的技巧去表白它。 三 如何去组织内容1 结构性很多人都听过《金字塔原理》，这是一本解说写作逻辑与思维逻辑的读物。其实我也没看过，但我晓得它的最中心思想，就是“总-分-总”。总分总置信大家都晓得，一个主观点，N个子观点，每个子观点可能还有子观点。讲每个观点都是论断后行，而后解说论证，而后总结阐明。用技术人更容易了解些的话，就是整顿成一颗树，而后做深度优先遍历。 当然《金字塔原理》里还有十分多有用的常识，还是举荐大家有空去读一读，必定会有更多的收货。 咱们明天先迈出第一步，就是总分总。换言之，内容的组织须要具备结构性。如果通篇内容，没有题目、没有分段、没有中心思想。是文章的话看着累，是演讲的话听着累。而结构化表白当前，有两大益处： 对于本人：更零碎、更体系的整顿了本人筹备分享的常识，对自我常识是更好的总结跟整顿。对于别人：人类对于有序事物的忘性必定是大于无序事物。结构化表白有利于观众接管信息并回顾信息。2 故事性除了结构性表白，我集体还很喜爱故事性的表白。就是想方法让本人的内容显得更加跌宕起伏或具备延续性。 跌宕起伏指的是一直地抛出问题，再解决问题。比方在我的《保险智能经营体系2.0的前端建设之路》。我先讲1.0的现状与问题，而后讲本人的策略与解法。做完当前，通过一些数据分析又发现了新的问题，而后又出了一些解法。这样一直的发现问题 -> 解决问题，让内容具备肯定跌宕起伏的故事感，能让读者继续保有新鲜感与浏览欲望。 延续性是指一直的由一个内容衍生出新的内容，最终答复最后的问题。比方我的《国家为什么老爱管咱们》（一篇介绍金融基础知识的文章），从金融引到货币，从货币讲到银行，再讲到影子银行，再讲到具备影子银行个性的互联网产品，最初答复国家为什么老爱管咱们。就像是在一条风景优美的公路兜风，两边的风光从树林突变到草原再突变到湖泊，过程连接顺畅，风光琳琅满目。最终证实了这是一条风景优美的公路。延续性的内容能够始终牵引着观众思路，放弃观众注意力。 其实我这边文章就尽量去恪守结构性跟故事性。主题是「如何做一篇高质量分享」，前面细分成几个观点，观点再细分子观点。这些观点又具备肯定延续性。先是定义什么是好的内容，有了好内容后讲怎么去组织、去展现、去表白。最初的最初再做一个总结。四 如何去展现内容如果是以文章模式的非现场分享，那能组织好内容，内容又是高质量的，置信文章肯定也是高质量的。但本文更多的还是想探讨周会、月会等现场分享时，该如何更好的展现咱们要分享的内容。 而对于这个问题，我只有一个外围观点：少字多图。 我当初发现很多人特地喜爱把文章间接拿来做现场分享，但这种状况的分享我没见过有成果特地好的。因为根本都是在念稿子。这就是我观点的最极其背面，简直全都是字。如果一篇现场分享稿也全都是字。那请问大家是听你谈话呢？还是看你文字呢？还是听你念字呢？这还不如把文档发给大家本人看呢。 我始终激励大家还是用PPT分享，因为PPT上不容易放太多字，只能放外围信息。因而用PPT会倒逼本人把要害信息摘取进去。因为字少了，信息少了，又会倒逼本人去更活泼的传播观点。 我以我的《国家为什么老爱管咱们》为例。我写完文章当前，又筹备在团队内做个分享。但文章字数有3万多字，如果我当稿子念，预计大家梦都做两回了。所以我把文字信息给形象，配上适合的图，把文章当做演讲稿，再多加一些即兴施展。比方其中的「什么是资产证券化」一节，该节纯文本字数有867字，我转成PPT后如下： 用几张图片加摘要文字，展现资产证券化的演化过程。而后画了专门的图来介绍资产证券化自身的运行机制。最初加粗个大字表白外围的观点。 对于有些并没有太多观点的章节，我的PPT更简略。比方其中的「你是否听过影子银行」这一节，次要是讲了两个小故事，并没太多观点。因而我的PPT就放了两张图，其余靠嘴巴讲讲即可。因为这种没要害信息的内容，观众没必要一边听我讲一大段故事，一边在PPT上看一堆文字。 当然，很多技术的分享，可能要演示一些代码，或者展现一些流程图、架构图，用语雀这样的文档工具可能会更不便编写跟展现。只有管制好排版，不要堆列演讲文字，对要害信息加大加粗，这也是能够的。语雀也提供了演示模式，但心愿大家能更好的利用这个演示模式。 总结一下，其实分享模式自身并不重要，重要的是别念稿。分享文档肯定是高度形象后的信息展现，其余过程的论述尽量靠本人的嘴巴配合图片去传播。记住外围要义：少字多图。 PS：有一种PPT分享模式，叫高桥流。每一个PPT上就几个大字，其余全靠嘴。罗永浩，还有咱们前端熟知的贺师俊都应用过该模式做过分享。我也已经尝试过：《Node HTTP/2 Server Push 从理解到放弃》[3]。 ...

9 月直播课领先看CODING DevOps 9 月直播课闪亮退场！本次线上直播课由 CODING 联结业余征询与培训公司 - 青蓝征询，于 9 月 22 日 - 24 日为同学们带来 CODING DevOps 深度解析系列直播课。 本次直播课蕴含 3 节课程，由 CODING 特邀讲师 —— ICAgile 认证麻利教练林伟丹、CPHT（靖本行策有限公司）创办人，软件工程布道师卢建成、EXIN 官网认证 DOP/DOF 讲师刘宁，三位大咖主讲。课程将通过 DevOps 的各面向来探讨常见的概念误区，联合实例分析部署价值流、研发价值流、治理价值流和用户价值流，探讨 DevOps 实际在技术与管理工作中的使用；并且从数字化转型的需要角度，探讨组织与 DevOps 的关系。课程内还蕴含讲师举荐书目，心愿能为对数字化转型和 DevOps 感兴趣的同学们提供一个将扭转引入组织的钥匙和终点。 那么一起来看看课程详情及报名形式，文末还有福利流动，千万别错过—— 开课时间9 月 22 日 - 24 日，每晚 19:00 - 20:00 课程安顿第一课：《助推 DevOps 的四层价值流实战》第二课：《DevOps 误区与组织筹备》第三课：《DevOps & ITIL —— 共存还是代替？》讲师介绍第一课：林伟丹 - ICAgile 认证麻利教练、Exin DevOps 资深受权讲师、中国 DevOps 社区外围组织者之一第二课：卢建成 - CPHT（靖本行策有限公司）创办人软件工程布道师第三课：刘宁 - EXIN 官网认证 DOP/DOF 讲师、高级 ITIL 讲师扫描海报二维码立刻报名 ...

原文地址： https://medium.com/startup-pa... 翻译君：敏杰小王子上周，我站在一家市值 200 亿美元的公司的会议室里，推动了一个关于敏捷的研讨会。出席会议的小组由这家大公司的一个产品线中的每个职能部门的董事和部门经理组成。从 UX、工程和产品管理的岗位中挑选出来的十几位领导者组成了一支团队，他们代表着约 150 人的产品线。作为一个团队，他们踏上了“敏捷”的旅程。 这不是我们平时认为的企业转型。他们的高层既没有明确支持也没有明确阻挠这次转型，这家公司对敏捷的官方态度最准确的描述是“良性冷漠”。因此，这个团队基本上只能靠自己来尝试，无论最终结果是成功还是失败。 我在那里的唯一原因，是因为到目前为止敏捷旅程还不顺利，我的任务是帮助他们找出症结并解决它。好巧不巧，他们出现的问题与我在过去 5 年中遇到其他团队的原因相同。为简单起见，以下都是直言不讳的事实陈述，但也并非都适用于您的情况。 不明确的愿景如果你在办公室走廊拦住任何团队成员，问他：“同学，我们产品的长期愿景是什么？”他们能否用一两句话来回答？八成不行。他们可能对目标客户有所了解，也可以明确地知道解决方案的功能。但是，他们真的可以说出客户想要解决的痛点吗？我猜不会。 一些高级管理人员在权利更迭期间，以临别顿悟为基础传达了自己的“突发奇想”。这个“想法”被投入了预算计划角逐会议中，这位特别的高管最终赢得了影响力战，并得到了 12 个月的项目资助。紧接着这一消息的所有内容通过一个既成事实的 PPT 传递给你，功能和时间表提前计划好了，你被正式告知“请实现它”。现在你正试图完成那个不可能完成的任务，并希望敏捷能帮到你。 解决方案：花一些时间阐明产品的清晰愿景，使用业务模型或精简图片表达您的设想，邀请团队中的每个人参与，将这些设想反馈给高层管理人员（如果他们拒绝参加），并确保你的相关信息出现在同一页面上。 PS：如果他们找你麻烦，给我打个电话。 被混淆的业务指标该团队不会考虑日常的成本和收入。事实上，团队可能不知道公司要让他们赚多少钱，他们也不知道他们需要拓展多少客户，每个时间段需要支付多少钱，以便他们在这个疯狂的想法上实现收支平衡。他们基本上不太关心自己的工资来自何处。 但如果你问大多数初创公司，他们对自己整体燃烧率和销售业绩会有更好的了解，因为收入和盈利能力对于他们来说始终是最重要的。 其实这个成本在任何情况下都不难计算。直线经理（Line Manager）通常可以在几分钟内得出工程团队燃烧率的准确数字。然后当我们将这个数字（实际成本）与我们当前的销售数据（我们作为一个团队实际产生的收入）进行比较时，这就会是一个全新的业务竞赛。 译者注：直线经理（Line Manager）是指诸如财务、生产、销售等职能部门经理，每一个直线经理肩负着完成部门目标和对部门进行管理的职责。 解决方案：计算您的产品成功所需的团队收入和成本，并确保每个人都知晓。它很有可能会让人大开眼界。您应该在下一次业务规划会议上与您的团队一起尝试。 持续不断的干涉由于方向上的某些紧急变化，您最后一次中断正常工作流是什么时候？它可以是最近的客户投诉或请求，也可以是来自首席执行官措辞强烈的电子邮件——邮件涉及团队在上周产品演示中使用的配色方案。 无论如何，如果你总是打破团队的正常工作流，会给团队带来巨大的压力。这种压力转化为吞吐量降低、士气低落、人员流动率增加、航运延误、工艺粗劣、以及对团队绩效的普遍拖累。所以把这个坏习惯丢弃掉吧，您并没有因为在组织中的管理地位而拥有在事务优先级排序方案中的特权。 解决方案：每周为计划外工作分配一些容量，比如总容量的 20％，只安排 80％ 的团队时间，而不计划其余的时间。可以在发生“紧急情况”时使用此容量，而不会影响原来的正常计划。无人认领的话可以用它来偿还技术债务。您可以轮换团队成员来执行此操作。 不够专注的团队我工作过的每个大公司都有这个问题。项目中的大多数人被分配到多个其他项目当中。当我问团队中都有谁时，我得到的答案一般是某位工程师分配了 50％ 在这个项目上，而某位工程师与我们在一起的时间占 20％，超过一半的项目人员将一半以上的时间花在其他项目上。难怪项目的最终结果往往是事故，因为这种工作方式不管用。 产品开发是一项团队活动，团队成员之间需要极大的关注和大量的沟通和协调。您团队中的每个人在部分时间内被分配到其他项目，这会使交付日期常常延迟数周或数月。 关于这一点我从企业管理者那里得到了更多的案例，举一个具体的例子，你也许会问：“我们真的需要在团队中设置专门的产品体验人员吗？如果他们一半闲着怎么办？我们不是在浪费钱吗？” 让我们思考一下： 假设你有十个工程师和一个交互设计师（本来不应该是这个 1/10 的比例，但你可能会这样做，所以我们姑且先这么选着）。设计师为工程师构建了 100 个线框，现在你有 10 名工程师开始工作，设计师又回到了其他项目。工程师几乎立即向设计师提出了要求，但设计师此时被其他项目束缚，所以工程师必须等待（延迟）。也许工程师选择打开另一项任务并开始工作。当设计师重新上线时，工程师必须暂时放下第二个任务以重新打开第一个任务（延迟）。 现在，第二位工程师需要帮助，可能还有第三个工程师，他们都在等待（延迟）。设计师再次有空并开始与第一位工程师合作，而其他两位排队等候（延迟），后两者的任务未完成（延迟）。所有三位工程师都失去了他们正在研究的一些事情的背景（延迟）。 在与第一位工程师合作时，设计师发现了设计中的错误，需要更新所有 100 个线框（大延迟）。现在，每个工程师都必须停止并重新检查他们的工作以应对新设计（大延迟），已经完成的一些工作必须废弃并重新开始（更大的延迟）。 所以你是选择固执己见还是有所改变？您可以试试把上面的示例中替换成后端 API 开发人员，事情的结果会变得更糟。 解决方案：请组织小型、跨职能、专注的团队，将一小组作为一个单元一起工作，并不断获得双方关于事务进展的反馈与澄清。 分散各地的团队大型企业团队往往由一个地理位置分散的大型池的“资源”组成（原谅我用“资源”这个词）。因此，企业产品团队的成员处于不同的时区和地区，这使得沟通协调效率低下且成本昂贵，结果就会发生很多延迟等待和错误传达。远程通信的保真度绝对不如面对面沟通，视频通话确实让沟通变得更容易一些，但它与能够一起走到白板前讨论出来的东西并不相同。 解决方案：将所有团队成员放在同一个房间，或至少在同一建筑物的同一楼层。如果您必须与远程人员一起工作，请根据康威定律分解任务，按地理划分（具有明确定义的接口的模块）而不是按功能划分（设计、工程）。 太过臃肿的团队通常情况下，在企业中找到大型团队来构建产品不是那么复杂的事情。但由于各种原因，团队规模常常大得惊人，这主要与高管倾向于通过指挥大群人来建立自我的事实有关。 100 名工程师构建一个 SaaS 产品？你确定？较大的团队效率更慢，因为协调成本是巨大的。您需要更多层次的管理，更多会议和更多文档。大型团队对其速度的负面影响随着其增长而渐渐变得更强烈。 解决方案：您应该使用尽可能小的团队在企业中构建产品。如果你可以把它减少到几十个，甚至一打，那就更好。 太重的技术债务企业往往有很多旧的代码库。然而这并不是企业敏捷团队积累技术债务的真正原因。我敢打赌，您当前项目中的大部分技术债务是从您当前项目开始以来由您的团队创建的，而不是通过来自较旧的遗留系统的继承。 这是因为，尽管敏捷社区重复了 15 年： （1）结对编程技术实践的重要性 （2）测试驱动开发 （3）对代码的持续集成但非常少的企业团队真正去做这些事情。出于各种原因（主要是因为那些专注于流程而非卓越技术的大型咨询公司向高管出售的所谓“敏捷”），企业敏捷团队很少接受：核心技术实践使得敏捷出色。结果大型的工程团队开始设计和执行有缺陷的系统，然后在漫长而痛苦的发布周期中相互折磨。 ...

服务不停歇，运维不休息。 7x24 小时连轴转已成为运维工程师的常态，故而每年的 7 月 24 日被视为运维日，代表着运维全天候的保障系统稳定、维护业务正常运行、时刻准备着一线工作的召唤。 腾讯运维技术开放日是由 CODING、腾讯云、TEG 技术工程事业群共同发起，面向运维人员的技术开放日。旨在分享和交流腾讯内部在运维方面的实践经验，打造腾讯内部与外部共同交流、共同进步的运维技术生态。 此次举办的首届腾讯运维技术开放日，将邀请四位在运维及 DevOps 方面有丰富经验的演讲嘉宾，为大家分享他们对运维工作，以及在新时代下关于运维发展的独特见解，共同打造一场运维盛宴。 活动时间和地点时间：2019 年 7 月 21 日地点：腾讯滨海大厦北塔 3F 多功能厅报名方式：点击此处报名参加活动活动福利：20 日前转发本文至朋友圈，在活动当天签到时出示朋友圈转发，即可获赠 CODING 周边小洋葱猴一只 活动议程13:00 - 13:30 签到 & 自由交流 & 展区体验13:30 - 13:45 开场致辞13:45 - 14:30《DevOps 理念下运维与开发的新关系》——张海龙 CODING 创始人 14:30 - 15:15《Serverless DevOps 最佳实践》——张远哲 腾讯云中间件产品经理 15:15 - 15:30 茶歇交流15:30 - 16:15《把大象搬上云端 - 腾讯海量业务上公有云历程》——周小军 腾讯自研上云项目负责人 16:15 - 17:00《机器学习在数据中心探索实践之路》——岳上 腾讯 TEG 技术发展中心副总监 17:00 - 18:00 自由交流 & 展区体验 ...

近期给孩子学校做科普宣讲，效果不错，孩子们很喜欢。回想近些年来，自己大大小小也进行了上百次的演讲。有公司内部的分享，也有外部的技术沙龙和技术大会；有线上直播式的，也有线下互动式的；有面对十余人的，也有面对数百人的。作为IT从业者，很多人比较内向，不太善于、甚至是惧怕演讲，我也经历了从最开始的内心畏惧，到现在可以做到张弛有度。那么如何进行一场精彩的演讲，我谈谈自己的心得体会。 一、演讲益处在谈到后面内容之前，我们先聊聊演讲的益处。或者说，IT人为什么有必要具备一定的演讲技能。 1.1 深入思考技术对于一个演讲者来说，不是简单的将自己懂的技术讲出来就可以，而是需要更深入地思考已有的技术内容，也就是“知其然也知其所以然”。你需要查阅各种资料，把概念的内涵外延、解决问题思路、对应的理论基础等想清楚明白。 一个10分钟的演讲内容，可能需要花费你数倍、甚至数十倍的时间来完成上面工作。甚至需要做重新做测试，取得一手数据加以佐证。而做这些都是必要的，因为我们需要为听众负责，也避免一些可能的谬误误导大家。同时对于自身来说，也是一个非常好的锻炼。我们可以更为系统地看待这些技术，将它们由点串线、由线到面，构建自己的知识体系。下图是一个很经典的学习金字塔，我们可以看到不同学习动作对内容留存率的效果。 从上面被动式学习的听讲、阅读、视听、演示；到主动式的讨论、实践与教授。从各种方式空间，将学习内容教授给他人，是留存率最高的一个手段。也就是说，教授是最为有效的一种学习方式。 1.2 锻炼教授技能这里就谈到了所谓”空杯”心态，也就是要以空杯子的定位去对待演讲。认清“我懂了”和“我能让你懂”是两个完全不同的问题。自己弄懂，可能和自己经年累月的思考有关，也可能需要以自己之前的知识积累做背景。但是让观众懂，而且是在演讲的几十分钟之内让观众懂，就必须把自己从“假想观众”中区分开来，哪些是自己特有的思维习惯，哪些是自己特有的背景知识，哪些是自己特有的学习方式…… 这些思维习惯、背景知识、学习方式，和典型观众有多少重合？以及，观众有没有办法在这几十分钟内倾注注意力来听取你的表达？这对演讲者的教授方法，提出了很高的要求。通过不断地演讲，可以更好地锻炼演讲者从用户侧角度出发，提高自己的传授能力。 1.3 塑造个人品牌所谓个人品牌，就是一个人带给别人的印象，以及所影响的人的范围。说一个人个人品牌很好，通常是说他在某一方面有专长，有权威，另外就是他还影响和帮助了很多人。可以有很多种方式进行个人品牌的塑造，例如演讲、自媒体、图书等。其中自媒体、图书更多是个人对某问题的深入思考，更具条理性和传承性。演讲相对来说，更为常见，也简单些。但从某种程度来说，反而要求更高。 因为写作可以反复加工，直至拿出成品为止；演讲却没有反复上台的机会。写作可以不必直面观众，以文字作为中介，演讲却必须与观众做直接沟通。写作是比演讲更为自由的，空间也更大，所以写作时往往可以对某个主题做大而全的论述。但是演讲的时间有限，观众的注意力和耐心也更有限。所以设计演讲稿时务必对写作的内容做大的削删，去掉细枝末节，只留下最重要的点。1.4 有效沟通手段作为职场最为常用的技能之一，沟通是非常重要的。在很多比较正式的场合，是需要通过演讲的方式进行有效沟通的。例如，和你的领导汇报工作，争取领导批准；去跟关联部门开会，争取工作支持；对个人阶段工作进行述职的时候等等。以上这些，都是要以演讲形式体现，某种程度来讲，演讲技能对于个人在职场升级有着举足轻重的作用。 二、演讲准备要做好一场演讲，必要的准备工作必不可少。我们可以从下面几个维度做好演讲准备工作。 2.1 心态准备严肃对待首先要有一个严肃的态度去对待一场演讲。不要以一种无所谓的态度面对。每一次演讲，都是需要精心准备、反复演练以达到最优的效果。这是对演讲者个人负责，也是对台下每一位听众负责。 调整紧张我们要认识到，紧张是一种非常正常的现象。紧张说明你内心重视，甚至适当紧张的状态有助于你的发挥，当然要避免过度的紧张。可以通过充分准备材料、反复排练试讲等手段减轻，但要完全避免是不太可能的。这时更需要以一种“微笑”的心态对面对，自我调节、自我鼓励。 面对错误要认识到，演讲中的错误是不可避免的。可能是材料准备的瑕疵、可能是演讲状态的不佳、可能是问题回答的欠缺。可以说，在演讲中，错误肯定会发生，重要的是如何定位错误以及如何应对错误。面对错误，我们应该抱有坦然接受的态度，要接受不完美的演讲，而不要试图避免错误的发生。因而只有接受这点，才能放松自己，对演进者而言，越放松状态越好。此外，面对观众的态度如何？针对重大错误，可以坦然说明；对于微小错误，可以轻轻跳过，很可能听众都没有感知到。 2.2 情况收集 – 演讲六要素(4W2H)Why：演讲的目的是什么？为什么需要这场技术演讲，目的应该是明确的，这也是整个演讲的核心所在。演讲目的要鲜明，要让听众直观接收到这一信息。不要出现不知所云、稀里糊涂的情况。一个糟糕的演讲总是让我们找不到重点。常见的演讲有以下一些目的： 教育性，例如说明某项技术的使用等。说服性，例如说服领导支持某项决策，寻求资源支持等。引导性，例如说明某产品的最佳实践，引导用户用好产品等。告知性，例如说明某产品的最新技术、最新版本功能等。What：演讲的内容是什么？要围绕上面的目的，组织演讲内容来说明它，这也是考验演讲者能力的地方。尽量采用详实的、有说服力的材料来补充，做到言之有物。往往一些真实案例、踩坑经历、对比方案等，较之空洞的理论，更容易引起大家的共鸣。 Who：演讲的受众是谁？要尽量做到了解受众情况，他们的参与目的、能力水平、接受程度等，这对于演讲者组织材料、演讲手段等均有影响。可通过多种方式，提前了解到这些信息，比如问卷调查、个别走访、之前演讲反馈等。如实在搞不清受众情况，就要反思一下做这场演技的目的是什么了。 Where：演讲的地点在哪里？是公司还是外部演讲？受众的人数有多少？是开放式还是封闭是场所等。 How：如何完成演讲？这是对演讲者的核心考验，你要通过什么方式展示演讲内容，包括演讲结构、辅助工具等。这往往是需要做专门设计的。后面我们还会谈到。 How Long：演讲的时长？演讲会有多久？中间是否有休息？是否有问答环节等。 2.3 方案设计后面是针对演讲方案进行具体设计，这里包括了很多细节问题。 演讲开场开场给人的第一印象很重要，常见方式是说明公司、姓名、职位等。接下来对演讲内容做一个概括性的描述，方便台下听众了解。最重要的是，对听众可以带来什么收获。其目的是聚焦听众注意力，为后面做铺垫。一个好的开场，往往是成功的一半。 内容结构采用什么样的结构来说明，比较典型的是”抛出问题、分析问题、解决问题”的三段式，总的方式上可考虑“总-分-总”的方式。这是比较常规的一些做法，也比较安全。此外对于阶段间的衔接等，也要做好处理。 演讲收尾进入收尾阶段后，此时的要点就是针对重点内容的”反复强调”。对于听众来说，第二天还能记住演讲内容的已经少之又少，因此需要在末尾强调，加深听众记忆。有所谓的“遗忘曲线”，希望能够通过强调，减少流失。 2.4 材料准备材料内容尽量主题清晰、言简意赅。展现形式上，则按照“图>表格>文字”的优先顺序。所谓之，一图胜千言嘛。在具体内容上，建议： 使用图的目的，是将复杂问题简单化，因此要重点突出，不需要表达太多信息。表格展现形式优势在于对比，关键需收集具有说服力的数据。文字上，尽量简洁；一屏最好不要超过50个汉字，让人可以快速定位信息。2.5 演讲技巧把控节奏对于长篇演讲，把控节奏很重要，常常面临两类问题：内容多，时间不够；内容少，提前结束。这两类其实都在于对节奏的把控不够，可通过下面方式解决： 控制好语速。人在紧张是很容易语速加快。一方面可以刻意放慢语速，另一方面可以预留材料，防止”无料可讲”。计划时长。针对每页材料，有大致的评估，需要演讲的内容及时长是多少。必要时，可以把所说文字材料写到备注区。针对计划好的部分，需要反复练习，做到”心中有表”的状态。预留时长。在某些环节，可以预留部分buffer时间。例如某个案例的说明，可视情况来临时决定讲与不讲。这样灵活机动性比较好。应对预案。对于一些意外情况，例如设备故障、临时提问等，打断了原有的节奏，也要把底线留好。哪些内容是必须要讲的，哪些是可以放弃的，留到后面大家自己看的。出现问题时可随机而变。控制语速控制语速，更多的是心态问题。这一点只有通过反复练习，通过各种场合的锻炼来逐步提高对语言的控制力。 如何互动互动是需要专门设计的。其根本目的是在于将平铺直叙的演讲，引入一点意外，提高大家的注意力。这里有多种选择，有些适合使用开放式问题，发散性思维，听取大家的想法；有些适合封闭式问题，主要得到“是与否”即可；有些甚至可以用自问自答的方式，只作为一种过渡。对于互动的要求，一般是比较高的，需要演讲者有较强的控场能力。如感觉不太好控制，不采用也罢。 回答问题一般演讲的末尾，会有问答环节，这也是很多演讲者比较头疼的地方。一方面可能是问题比较刁钻，一方面可能无问题有点冷场。对于第一种情况，可以模糊化回答，只谈自己观点，不谈对与错；或者将问题转化为自己熟悉的问题，即使此时问题有所偏差，一般也不会计较。再或者干脆说明，这一点比较复杂，建议台下沟通。对于第二点，可自备一两个问题，与演进内容比较契合，也就是作为“反复阐述”的一部分，加深大家对演进的记忆。 设计段子可以在演讲中，不定期地插入段子，目的是重新抓回听众注意力。其数量不宜太多，多了就干扰正常演讲内容了，只是在较长描述部分适当点缀，来保证听众的注意力都在自己的身上。 肢体语言知名的传播理论家Albert Mehrabian教授研究出了"7/38/55法则"。他总结，你传递的信息或旁人对你的观感主要取决于三个要素： 实际言语（内容）占7%；语气（说话的语调、声音的抑扬顿挫等）占38%；肢体语言（手势、表情、仪态等）占55%。由此可见，肢体语言在整个演讲中的重要性。这个可以通过排练，把自己的语气、肢体语言形成“记忆”。这样在演讲中，就不容易因为紧张而导致变形。此外，可通过练习回放的功能，反复观察自己的肢体语言，听取他人的建议。 2.6 反复练习技术演讲其实完全不需要什么天赋，完全是个熟练工。所谓“熟练工”，就是反复练习多遍之后，动作顺理成章，不会有任何走样。建议每一遍练习，都要计时；练习完后需要复盘。不断改进，反复排练，直到达到自己比较满意的状态。 三、演讲中期对于精心准备、反复排练后的演讲，在正式演讲中，一般都不会有太大问题，要对自己有充分的信心。此时，更多的是”灵活调整”的能力。需要根据现场观众的反馈来调整自己的语速、内容等。可通过台下的表情、眼神、动作等，观察当前观众对内容的接收程度。对于不感兴趣的部分，可适当做删减、跳过处理。缺少的时间部分，可通过备选的重点内容来补充。 四、演讲结束接受不完美并不代表接受错误，我们要做的是在演讲之后及时复盘、查漏补缺。这可以帮助我们客观的了解自己讲得到底如何，演讲中出了什么差错，哪些地方没有达到自己的预期，然后找出到底是什么原导致你犯了这个错误，是否有方法可以改进，保证下次不会出现一样的失误。 作者：韩锋 首发于公众号《韩锋频道》，欢迎关注。 来源：宜信技术学院

语音聊天室孵化一起KTV、众人大合唱、语音开黑、狼人杀、剧本杀、多人配音、观影、语音电台、相亲联谊社交等，一般都是在语音聊天室中进行，那么语音聊天室产品如此火热的原因有哪些呢？ 一对一社交适用于朋友、家人之间，而更多的社交场景需要多人参与，聊天室的多人属性，正好满足此需求，用户按照自己的兴趣去交友聊天，也让社交更加多样化、娱乐化。对于有视频社交压力的用户来讲，实时展示自己的画面会是一个高压场景，压力也会明显大于文字、图片、语音等。另外，文字、图片社交不能携带太多用户的情绪和态度。语音社交不仅可以解决视频社交压力用户的痛点，也可以通过感知对方音量、音色等，感受到一个“真实”的对话者，让用户在轻松氛围中交友聊天。语音聊天室原型越来越多的产品提供语音聊天室，在语音聊天室的基础上创建多种玩法，那么一个标准的语音聊天室原型是怎样的呢？ 语音聊天室应该有如下角色：创建者、管理员、普通成员。房间创建者拥有聊天室所有权限；管理员应该具有拉黑、禁言、踢人、设置普通成员权限、设置房间属性：如设置背景音乐、背景图、房间密码等；普通成员可以加入房间，申请连麦，参与语音聊天互动等。语音聊天室的技术关键点语音聊天室需要为用户提供长时间、高频次语音连麦互动功能，在网络抖动时保证语音通话流畅、延迟小、卡顿低、音质好。因此开发语音聊天室，一些技术关键点需要关注，如： 频繁麦位切换：抢麦、跳麦、麦位排序、抱麦、上麦、下麦等是典型场景，复杂的麦位逻辑需要详细设计，否则影响会产品体验；高并发：应用高峰一般会出现在午休时刻、晚上或者周末，音视频通话发起、接听数会瞬间爆发增长，如果音视频架构不能支持海量并发，那么通话发起或者接听不成功、丢包、卡顿、延时等现象出现几率极高；卡顿：通常是由丢包引起，涉及到音视频编解码性能质量，以及端到端的传输链路设计都会对卡顿造成影响；时延：通话延时大于150ms时，就会影响通话质量通话连续性影响，当最大时延大于400ms，基本听不到对方讲话；音质：噪声、回声、听不清、无声等音质问题，特别影响用户体验，提高音质，适配机型、适配音频编解码、调优性能等工作需要重视。网易云信语音聊天室方案根据语音聊天室用户的需求，以及需要考虑的核心要点，网易云信提出两种语音聊天室方案，让客户迅速搭建语音聊天室。在介绍方案之前先介绍几个概念：房间：用户进行多人实时音视频通话的地方房主：音视频房间的创建者或者管理员连麦者：在多人通话时参与语音互动，发言的人，可以发送语音，接收其他连麦者、房主语音观众：只可以收听的人，没有发言的权限，其中连麦者和观众身份可以随时切换。 方案A，实时音视频方案方案A的连麦互动基于多人实时音视频通话架构实现，选择纯音频模式，多人连麦进行实时音频通话，观众只可以听连麦者、房主的声音，不可以发言。要强调的是方案A的优点是观众听到声音延时小，但是支持观众人数有上限。 方案B，互动直播方案方案B是基于音视频直播与实时互动开发架构实现，互动直播由连麦互动和直播两部分组成，其中连麦互动基于音频通话实现，房主、连麦者互动合并直播，普通观众拉流观看语音聊天室的直播。要强调的是方案B支持观众人数无上限，但是拉流延时相对方案A有点大。介绍完语音聊天室的架构之后，接下来重点介绍一下核心模块实现，如多人语音互动、麦位管理以及成员权限管理等。• 语音互动语言聊天室多人语音互动是基于自研的音视频通话开发框架实现，流程如图所示 多人语音互动流程• 麦位管理麦位管理是聊天室常用功能之一，麦位管理分类主要有：上麦 、下麦、跳麦、抱麦、抢麦、禁麦、解禁等，网易云信麦位管理方案基于自研的聊天室队列实现。 • 权限管理语音聊天室不同成员具有不同权限，按照不同角色进行分类： 语音聊天室权限网易云信的语音聊天室权限管理方案基于自研的IM以及聊天室自定义消息、系统消息实现。 网易语音聊天室方案特点丰富灵活的API：实现场景自由切换与角色灵活设置，连麦者、观众观战轻松掌控、群聊/私聊切换；音质清晰：音频独家48kHz超宽屏音质，支持全频带编解码，PLC丢包补偿算法，自适应音频模式提供复杂音频环境解决方案，满足音质要求的痛点；抗抖动、丢包：智能网络探测，智能Qos保障，音视频码率自适应，多种核心算法保障弱网环境音频体验，可抗800ms网络抖动，30%丢包；低延时：端到端平均延时低于200ms，实时连麦互动无压力；易集成、扩展：集成稳定IM、音视频服务，满足即时通信聊天场景，高度灵活可扩展，不仅支持多人语音连麦，还支持多人视频连麦；麦位管理方便：IM、聊天室自定义消息、聊天室队列接口，便捷实现频繁麦位管理需求，优化麦位管理逻辑；高可用：服务器使用高可用的架构部署，对于服务器宕机、网络切断，使用了相应的恢复和切换策略。 网易云信已经为诸多专注语音社交的客户提供优质音视频服务，语音聊天室方案的功能与服务也会越来越全面，满足更广泛场景需求，让用户快速搭建，抓住语音社交的风口。 想要阅读更多行业洞察和技术干货，请关注网易云信博客。

前言互联网产品的测试常常要覆盖在不同网络下的表现，例如丢包，带宽受限，时延及抖动等网络较差的情况，为了测试场景的网络情况可定义及复现，就需要有个工具对弱网进行模拟。业界一些通用的弱网模拟工具，如NEWT，fiddler，charles，atc，tc和packetstorm等软硬件弱网模拟工具。相较于硬件模拟器昂贵的价格和其他软件模拟器部署难度大，TC成本低，部署难度较低且容易和自动化结合实现自动化测试，此外TC适用任何平台的设备（包括PC、移动端等）。本文着重介绍TC的原理及应用。一、TC及Netem简介讲到tc工具不能不提iproute2工具集，iproute2工具集包括了一系列网络相关的工具，像大名鼎鼎的ip命令行工具，本文主要通过iptables创建一条linux系统的两块网卡的桥接。 netem 是 Linux 在2.6 及以上内核版本提供的一个网络模拟功能模块。该功能模块可以用来在性能良好的局域网中，模拟出复杂的互联网传输性能，如时延，丢包，抖动等场景。2.6 (或以上) 版本内核的很多发行版 Linux 都开启了该内核功能，比如Fedora、Ubuntu、Redhat、OpenSuse、CentOS、Debian等，本文以Ubuntu18为例。 tc 是 Linux 系统中的一个工具，全名为traffic control（流量控制）。tc 可以用来控制 netem 的工作模式，每一个物理网卡都会和一个qdisc关联，然后通过netem添加不同设置参数以实现对网络的控制。 二、Linux中的队列规则Linux操作系统中的流量控制器TC（Traffic Control）用于Linux内核的流量控制，它利用队列规定建立处理数据包的队列，并定义队列中的数据包被发送的方式， 从而实现对流量的控制。TC使用的队列规则分为两类，一类是无类别队列规则， 另一类是分类队列规则。 无类别队列规则相对简单，而分类队列规则则引出了分类和过滤器等概念，使其流量控制功能增强，本文中TC主要使用分类队列规则。1、无类别队列规则是对进入网络设备(网卡) 的数据流不加区分统一对待的队列规则。这类队列规则形成的队列可以对整个网络设备(网卡)的流量进行整形，但不能细分各种情况。常用的无类别队列规则主要有pfifo _fast (先进先出) 、TBF ( 令牌桶过滤器) 、SFQ(随机公平队列) 、RED (随机早期检测)等等。这类队列规则使用的整形手段主要是排序、限速和丢包。1.1 pfifo和pfifo_fastFIFO是linux网络接口的默认qdisc规则，没有整形和重排序的功能，仅对收到的包按照先入先出的顺序排出。pfifo_fast与pfifo类似，只是针对收到的流排出三个优先级。1.2 SFQ此种队列企图用一套公平的队列算法（哈希函数）来实现收包随机分配到不同FIFO序列，但是有些讨厌的软件上就无法保证折中公平性（分布在多个FIFO序列上）。1.3 TBF如名字所示，令牌桶过滤器基于令牌和桶，只有当令牌足够时，数据包才会从网口发出，否则，数据包将会被延迟发送，以此来实现流量限速。2、分类队列规则是对进入网络设备的数据包根据不同的需求以分类的方式区分对待的队列规则。数据包进入一个分类的队列后， 它就需要被送到某一个类中， 也就是说需要对数据包做分类处理。对数据包进行分类的工具是过滤器，队列规则会根据过滤器的分类结果把数据包送入相应的类进行排队。每个子类都可以使用它们的过滤器进一步分类，直到不需要进一步分类为止。如下图所示，为本文中TC用到的HTB，图中详细展示了qdisc和类以及子类的关系：三、TC的实现TC主要包括三个基本要素：队列规则（qdisc，queueing discipline）、类（class）和过滤器（filter）qdisc：队列规则，TC的核心，用于确定数据包的发送方式。如下命令实现了指定的eth0网卡上所有的包固定加了200ms延时 # tc qdisc add dev eth0 root netem delay 200msclass和filter：类和过滤器。类即是数据流量的类别，各种应用和终端的流量通过filter进行分类，进入到队列规则里排队进行发送。如下命令行所示即通过class和filter实现了对指定ip的限速，其他弱网类似： # tc class add dev eth0 parent 1:1 classid 1:2 htb rate 500kbit # tc filter add dev eth0 protocol ip parent 1:0 prio 3 u32 match 192.168.2.10 flowid 1:3其他常用到的弱网场景：延迟波动，如下命令表示延迟为时延150ms-250ms波动（由于网卡上发出的包延迟不同，所以会有一定程度的乱序发生）： # tc qdisc add dev eth0 root netem delay 200ms 50ms乱序，如下代表随机丢包30% # tc qdisc add dev eth0 root netem delay 50ms reorder 25% ...

介绍移动端Android/iOS硬解用法的文章有很多，本文将以笔者在实际开发工作中的经验为基础，抽出几个比较关键的部分来跟大家分享，旨在解决实际工作中可能遇到的花屏、（半边）绿屏、播放不完整等问题。本文将以目前广泛应用的H.264编码的视频为例来说明，主要包含：H.264码流数据结构说明、解码器的初始化、seek、前后台切换、无缝分辨率切换、播放结束时的处理以及iOS如何避免下半部分绿屏的问题。 一、H.264码流数据结构说明1. 理解码流数据结构的重要性我们讲支持硬解，提高硬解兼容性，实际上就是对码流数据的结构进行处理以符合平台硬解要求，因此对码流数据结构的理解是必不可少的。2. SPS/PPS与IDR帧SPS(Sequence Parameter Set)序列参数集、PPS(Picture Parameter Set)图像参数集，包含了图像编码的各种参数信息，是作为解码器初始化所必须的参数信息。IDR(Instantaneous Decoding Refresh)帧，也就是即时解码刷新帧，直观意思就是解码器在接收到IDR帧后会刷新参考帧缓存。IDR帧前后的视频帧不会有任何参考关系，解码器可以从任何一个IDR帧开始解码。3. H.264的NAL单元NALU结构图示： H.264标准中，视频流是由NAL(Network Abstraction Layer)单元组成的（简称NALU），每个NALU中可能是IDR图像、SPS、PPS、non-IDR图像等。上图中示意的NALU单元是以startcode方式分割的，关于NALU的分割方式将在后面说明。 另外，NALU内容中添加了防竞争字节，也就是说在一个NALU中，我们不可能再找到匹配的startcode.H.264流的NALU组成图示 从上图可以看到，一个视频帧中可能可能包含多个NALU, 此时可以称该视频帧为多slice视频帧（一个NALU中包含该视频帧的一个slice）。NAL Header的结构说明 其中nal_unit_type是我们关心的字段，该字段标识了当前NALU的类型，我们可以通过将NALU中第一个字节&0x1F的方式来得到NALU类型。NALU类型的具体定义如下图所示：NALU类型定义 其中5代表上面提到的IDR帧数据，7、8分别代表SPS/PPS数据。 AVCC与Annex-BH.264码流分为AVCC与Annex-B两种组织格式。• AVCC格式 也叫AVC1格式，MPEG-4格式，字节对齐，因此也叫Byte-Stream Format。用于mp4/flv/mkv等封装中。 • Annex-B格式 也叫MPEG-2 transport stream format格式（ts格式）, ElementaryStream格式。用于TS流中（以及使用TS作为切片的hls格式中）。这两种格式的区别有两点： （1）NALU的分割方式不同； （2）SPS/PPS的数据结构不同。• AVCC格式使用NALU长度（固定字节，字节数由extradata中的信息给定）进行分割，在封装文件或者直播流的头部包含extradata信息（非NALU），extradata中包含NALU长度的字节数以及SPS/PPS信息。• Annex-B格式使用start code进行分割，start code为0x000001或0x00000001，SPS/PPS作为一般NALU单元以start code作为分隔符的方式放在文件或者直播流的头部。AVCC格式的extradata格式定义在“ISO_IEC_14496-15"文档中，Annex-B格式的SPS/PPS定义可以在"ISO_IEC_14496-10"文档中找到。MediaCodec与VideoToolBox使用的数据格式Android的硬解码接口MediaCodec只能接收Annex-B格式的H.264数据，而iOS平台的VideoToolBox则相反，只支持AVCC格式。这就导致：• 在Android平台硬解播放flv/mp4/mkv等封装的视频时，需要将AVCC格式的extradata以及NALU数据转为Annex-B格式；• 在iOS平台播放ts或ts切片的hls视频时，需要将Annex-B格式的SPS/PPS NALU转为AVCC格式的extradata，以及将其他以size方式分割的NALU转为start code方式。 二、解码器的初始化及数据输入初始化解码器，除了配置输入视频流的的编码格式、宽高以及输出格式之外，还需要配置一些额外的信息。 对于H.264视频，需要填充的就是我们前面提到的SPS/PPS信息。1. Android平台MediaCodec的初始化我们需要将Annex-B格式的两个SPS/PPS NALU单元通过setByteBuffer方法，以"csd-0"为名称（或SPS设为"csd-0", PPS设为"csd-1"）设置到MediaFormat对象中，并调用configure接口配置到MediaCodec中去。MediaCodec设置SPS/PPS信息的示例代码MediaCodec mediaCodec = MediaCodec.createDecoderByType("video/avc");MediaFormat mediaFormat = MediaFormat.createVideoFormat("video/avc", width, height);// extradata中是Annex-B格式的SPS、PPS NALU数据mediaFormat.setByteBuffer("csd-0", extradata);// ...mediaCodec.configure(mediaFormat, surface, 0, 0);// ...如上节所述，对于mp4/flv/mkv等封装，我们得到的是AVCC格式的extradata，需要先将该extradata转换为Annex-B格式的两个NALU, 然后用startcode进行分割。 Android平台在配置解码方式时，最好使用MediaCodec直接渲染到Surface的方式，一是可以避免不同硬件平台繁杂的YUV格式兼容，二是在解码渲染高分辨率的视频时可以有非常明显的效率提升。2. iOS平台VideoToolBox接口的初始化VideoToolBox针对AVCC格式和Annex-B格式的SPS/PPS信息设置，分别提供了两个方法：• CMVideoFormatDescriptionCreate: 可以设置AVCC格式的extradata信• CMVideoFormatDescriptionCreateFromH264ParameterSets: 用来设置Annex-B格式的SPS/PPS NALU信息（需要去掉startcode）需要注意，iOS平台不支持隔行H.264视频的解码，需要在创建videoToolBox前从SPS中判断当前视频是否隔行编码。3. 数据格式的转换如前所述，Android平台只接受Annex-B格式以startcode分割的H.264 NALU；iOS平台则相反，只接受AVCC格式以size分割的NALU. 在原视频流格式不匹配时需要进行相应的转换。iOS还有以下的一些限制需要留意：（1）如果源视频流本身已经是AVCC格式，但NALU size的大小是3个字节，而非4字节时，需要转为4字节格式。具体的话，需要先更改extradata中标识NALU size的字段，然后每个视频帧中的NALU size都要改成4个字节。（2）如果一个视频帧内有多个NALU（多slice），那必须将这些NALU打包到一个CMSampleBuffer中，一次性送给解码器。 ...

小议BBR算法 BBR全称Bottleneck Bandwidth and RTT，它是谷歌在2016年推出的全新的网络拥塞控制算法。要说明BBR算法，就不能不提TCP拥塞算法。 传统的TCP拥塞控制算法，是基于丢包反馈的协议。基于丢包反馈的协议是一种被动式的拥塞控制机制，其依据网络中的丢包事件来做网络拥塞判断。即便网络中的负载很高时，只要没有产生拥塞丢包，协议就不会主动降低自己的发送速度。 TCP在发送端维护一个拥塞窗口cwnd，通过cwnd来控制发送量。采用AIMD，就是加性递增和乘性递减的方式控制cwnd，在拥塞避免阶段加性增窗，发生丢包则乘性减窗。这个拥塞控制算法的假定是丢包都是拥塞造成的。 TCP拥塞控制协议希望最大程度的利用网络剩余带宽，提高吞吐量。然而，由于基于丢包反馈协议在网络近饱和状态下所表现出来的侵略性，一方面大大提高了网络的带宽利用率；但另一方面，对于基于丢包反馈的拥塞控制协议来说，大大提高网络利用率同时意味着下一次拥塞丢包事件为期不远了，所以这些协议在提高网络带宽利用率的同时也间接加大了网络的丢包率，造成整个网络的抖动性加剧。TCP拥塞控制算法的假定是丢包都是拥塞造成的，而事实上，丢包并不总是拥塞导致，丢包可能原因是多方面，比如：路由器策略导致的丢包，WIFI信号干扰导致的错误包，信号的信噪比（SNR）的影响等等。这些丢包并不是网络拥塞造成的，但是却会造成TCP 控制算法的大幅波动，即使在网络带宽很好的情况下，仍然会出现发送速率上不去的情况。比如长肥管道，带宽很高，RTT很大。管道中随机丢包的可能性很大，这就会造成TCP的发送速度起不来。 Google 的BBR出现很好的解决了这个问题。BBR是一种基于带宽和延迟反馈的拥塞控制算法。它是一个典型的封闭反馈系统，发送多少报文和用多快的速度发送这些报文都是每次反馈中不断调节。BBR算法的核心就是找到两个参数，最大带宽和最小延时。最大带宽和最小延时的乘积就是BDP(Bandwidth Delay Product), BDP就是网络链路中可以存放数据的最大容量。知道了BDP就可以解决应该发送多少数据的问题，而网络最大带宽可以解决用多大速度发送的问题。如果网络比作一条高速公路，把数据比作汽车，最大带宽就是每分钟允许通行的汽车数量，最小RTT就是没有拥堵情况下，汽车跑一个来回需要的时间，而BDP就是在这条路上排满汽车的数量。 BBR如何探测最大带宽和最小延时BBR是如何探测最大带宽和最小延时呢？首先有一点就是最大带宽和最小延时是无法同时得到的。 如图所示，横轴是网络链路中的数据量，纵轴分别是RTT和带宽。可以发现在RTT不变的时候，带宽一直在上升，没有达到最大，因为这个时候网络没有拥塞，而带宽停止上涨的时候RTT持续变大，一直到发生丢包。因为这个时候，网络开始拥塞，报文累积在路由器的buffer中，这样延时持续变大，而带宽不会变大。图中BDP的竖线所标识的就是理想情况下最大带宽和最小延时。很明显，要找到BDP, 很难在同一时刻找到最小的RTT和最大带宽。这样最小RTT和最大带宽必须分别探测。探测最大带宽的方法就是尽量多发数据，把网络中的buffer占满，带宽在一段时间内不会增加，这样可以得到此时的最大带宽。探测最小RTT的方法就是尽量把buffer腾空，让数据交付延时尽量低。由此，BBR就引入了基于不同探测阶段的状态机。 状态机分为4个阶段，Startup，Drain，ProbeBW， ProbeRTT。Startup类似于普通拥塞控制里的慢启动，增益系数是 2ln2，每一个来回都以这个系数增大发包速率，估测到带宽满了就进入 Drain状态，连续三个来回，测得的最大瓶颈带宽没有比上一轮增大 25%以上，就算带宽满了。进入 Drain状态，增益系数小于 1，也就降速了。一个包来回，把 Startup状态中产生的拍队排空，怎样才算队列空了？发出去还没有 ACK 的数据包量 inflight，与 BDP 进行比较，inflight < BDP 说明空了，道路不那么满了，如果 inflght > BDP 说明还不能到下一个状态，继续 Drain。ProbeBW是稳定状态，这时已经测出来一个最大瓶颈带宽，而且尽量不会产生排队现象。之后的每个来回，在 ProbeBW状态循环（除非要进入下面提到的 ProbeRTT状态），轮询下面这些增益系数，[5/4, 3/4, 1, 1, 1, 1, 1, 1]，如此，最大瓶颈带宽就会在其停止增长的地方上下徘徊。大部分时间都应该处于 ProbeBW状态。前面三种状态，都可能进入 ProbeRTT状态。超过十秒没有估测到更小的 RTT 值，这时进入 ProbeRTT状态，把发包量降低，空出道路来比较准确得测一个 RTT 值，至少 200ms 或一个包的来回之后退出这个状态。检查带宽是否是满的，进入不同的状态：如果不满，进入 Startup状态，如果满，进入 ProbeBW状态。BBR算法不会因为一次或者偶然的丢包就大幅降低吞吐量，这样就比TCP就有较强的抗丢包能力。 如图所示，cubic在丢包率上升的时候，吞吐量下降很快。而BBR在5%以上的丢包才会出现明显的吞吐量下降。BBR与基于丢包反馈的cubic和基于延时反馈的vegas算法的本质区别在于，BBR无视随机丢包，无视时延短暂波动，采用了实时采集并保留时间窗口的策略，保持对可用带宽的准确探知。事实上，丢包并不一定会造成带宽减少，延迟增加也不一定会造成带宽减少，cubic无法判断是否拥塞造成的丢包，vegas对延时增加过于敏感，会导致竞争性不足。BBR可以区分出噪声丢包和拥塞丢包，这样意味着，BBR比传统TCP拥塞控制算法具有更好的抗丢包能力。 BBR在实时音视频领域的应用实时音视频系统要求低延时，流畅性好，而实际网络状态却是复杂多变的，丢包，延时和网络带宽都在时刻变化，这就对网络拥塞控制算法提出了很高的要求。它需要一种带宽估计准确，抗丢包和抖动能力好的拥塞控制算法。目前Google的webrtc提供了GCC控制算法，它是一种发送侧基于延迟和丢包的控制算法，这个算法的原理在很多地方都有详细描述，这里不再赘述。GCC用于实音视频的主要问题还在于在带宽发生变化时，它的带宽跟踪时间比较长，这样就会造成带宽突变的时候无法及时准确探测带宽，可能造成音视频卡顿。既然BBR有良好的抗丢包能力，自然也被想到应用到实时音视频领域。但是，BBR并不是为处理实时音视频设计的，所以需要对一些问题做一些优化。第一，BBR在丢包率达到25%以上，吞吐量会断崖式下降。这是由BBR算法的pacing_gain数组[5/4, 3/4, 1, 1, 1, 1, 1, 1]的固定参数决定的。在pacing_gain数组中，其增益周期的倍数为5/4，增益也就是25%，可以简单理解为，在增益周期，BBR可以多发送25%的数据。在增益期，丢包率是否抵消了增益比25%？也就是说，x是否大于25。假设丢包率固定为25%，那么，在增益周期，25%的增益完全被25%的丢包所抵消，相当于没有收益，接下来到了排空周期，由于丢包率不变，又会减少了25%的发送数据，同时丢包率依然是25%...再接下来的6个RTT，持续保持25%的丢包率，而发送率却仅仅基于反馈，即每次递减25%，我们可以看到，在pacing_gain标识的所有8周期，数据的发送量是只减不增的，并且会一直持续下去，这样就会断崖式下跌。 怎样才能对抗丢包，这就需要在每个周期考虑丢包率，把丢包率补偿进去。比如丢包率达到25%的时候，增益系数就变成50%，这样就可以避免由于丢包带来的反馈减损，然而，你又如何判断这些丢包是噪声丢包还是拥塞丢包呢？答案在于RTT，只要时间窗口内的RTT不增加，那么丢包就不是拥塞导致的。第二，BBR的最小RTT有个10s超时时间，在10s超时后，进入ProbeRTT 状态，并持续最小200ms，此状态下，为了排空拥塞，inflight只允许有4个包，这会导致音视频数据在这段时间内堆积在发送队列中，使得时延增加。可行的解决办法是，不再保留ProbeRTT状态，采用多轮下降的方式排空拥塞，然后采样最小RTT，也就是在infight > bdp的时候，设置pacing gain为0.75，用0.75倍带宽作为发送速率，持续多轮，直到inflight < bdp, 此外，最小RTT的超时时间改成2.5s，也就是说不采用非常激进的探测方式，避免了发送速率的大幅波动，可以改善探测新的带宽过程中发送队列中产生的延时。第三，开始提到pacing gain数组上探周期为1.25倍带宽，随后是0.75倍带宽周期，这两个RTT周期之间会出现发送速率的剧烈下降，这可能会使音视频数据滞留在buffer中发不出去，引入不必要的延时。解决办法可以考虑减小上探周期和排空周期的幅度，比如使用[1.1 0.9 1 1 1 1 1 1]这种pacing gain参数，这样做的优点就是可以保证媒体流的平稳发送，发送速率不会大幅波动，缺点是，网络带宽改善的时候，上探时间会变长。第四，BBR探测新带宽收敛慢的问题原始的BBR算法的收敛性受到pacing gain周期影响，带宽突降的时候，BBR需要多个轮次才会降到实际带宽。这是由于BBR每轮只能降速一次，而pacing gain的6个RTT的保持周期大大加长了这个时间。解决的办法就是随机化pacing gain的6个保持周期，如果是0.75倍周期，就一次降速到位，这样可以极大的减少BBR的收敛时间。最后，BBR算法看似简单，但是应用到实时音视频却没有那么简单，需要大量的实验优化，谷歌也在webrtc中引入BBR，目前仍在测试中。本文提到的改进方法是网易云信在这方面的一些尝试，希望能够抛砖引玉，有更多有兴趣的人能够为BBR应用到实时音视频领域出力。 ...

序言 Duilib介绍Duilib是windows平台下的一款轻量级directUI开源库（遵循BSD协议），完全免费，可用于商业软件开发，只需在软件包里附上协议文件即可。Duilib可以简单方便地实现大多数界面需求，包括换肤、换色，透明等功能，支持多种图片格式，使用XML可以方便地定制窗口，能较好地做到UI和逻辑相分离，尽量减少在代码里创建UI控件。目前，Duilib库已经渐趋稳定，目前在国内有较为广泛的使用，网络上也有很多的使用教程。 网易云信Duilib介绍Duilib是在研发易信PC版时被引入，历经六七年的研发过程，相对于原版Duilib，网易云信Duilib修复了一些问题和不足，包括但不限于控件种类不丰富、不支持动画、不支持半透明异形窗体、对多线程支持不好等，目前，网易云信Duilib配合比较高效的引擎库Base解决多线程问题，可以做出功能更强更稳定的客户端界面。 网易云信Duilib特色多国语言支持通用样式支持DPI 缩放支持GIF 动画支持CEF 控件支持（CEF 2623 支持 XP）触控设备支持（Surface、Wacom）抽象渲染接口（为其他渲染引擎提供支持） 源码使用克隆项目到你的磁盘中git clone https://github.com/netease-im...进入 NIM_Duilib_Framework/samples 目录，使用 Visual Studio 2013 Update 5 以上版本 IDE 打开 samples.sln。 工程目录结构bin输出目录docs 文档libs 静态库samples 示例Demo程序third_party 第三方库toolkits ─ base 基础类库 ─ duilib 核心代码 ─ shared 工具类库 ─ ui_components 组件库 模块介绍Bin：输出目录，各个示例程序输出目录，包含预设的皮肤和语言文件以及 CEF 依赖。Docs：文档，duilib 接口的说明文档。Libs：静态库，静态库编译后的输出目录，包含预设的一些 CEF 组件静态库。Samples：示例Demo程序。Third_party：第三方库，目前仅有 cef_control 有依赖。Base：基础类库，提供了基本框架Messageloops，闭包，基本函数库（file、network等），基本类库（time，线程，定时器等），基本工具库（log，加解密）等。Duilib：duilib 核心代码，依赖 base 但不依赖 shared。Shared：工具共享库，对base库，第三方库做的简单的封装，如命令行解析、日志、路径处理，供其他模块使用。ui_components：组件库，基于 duilib 封装的常用组件库如 msgbox、toast、cef_control 等。 控件介绍容器容器可作为容器控件的介质，包含常用的水平布局和垂直布局等容器。在一个程序界面开始设计前首先要考虑整个界面的布局，这就要用到容器。不同的容器有不同的布局样式，以下为支持的容器类型，可根据自己需要选择进行布局。Box 自由布局容器HBox 水平布局容器VBox 垂直布局容器TabBox 多标签布局容器TileBox 格子布局容器ScrollableBox 带有滚动条的布局容器ChildBox 子布局容器列表此目录下包含一些列表容器，方便管理同类型的多份数据，以下列举了可用的列表容器。Combo 下拉列表ListBox 普通列表TreeView 属性列表VirtualListBox 虚拟列表控件控件包含了所有可用的独立控件，如按钮、文本、进度条等，提供用户输入或输出内容提供使用者查看。以下列举了所有可用的控件列表。Window 用于容纳所有控件的窗口，这里暂时放到控件分类中Control 所有控件的基类，包含了控件的基本属性和接口Button 按钮控件CheckBox 复选框Option 单选框Label 文本Progress 进度条Slider 滑动条RichEdit 富文本ScrollBar 滚动条CefControl CEF 控件盒子盒子通常用于容纳一组不同的控件但由整个盒子统一响应用户触发的事件。不同于普通的容器或普通的控件，它们具有容器的基本布局功能，也具备控件的事件响应机制。一般用于列表中显示一个子项，或者树形列表中显示一个节点，但这些子项和节点可能包含丰富的图标和文字描述并要求可以响应用户触发的事件。在这种场景下就会使用到这些盒子了，以下为支持的盒子模型：ListContainerElement 常用于列表中显示一个子项TreeNode 常用于树形列表中显示一个子节点Other 一些其他的盒子模型工具DPI Manager DPI 管理Muilt Language 多语言管理Shadow 阴影管理Window Base 窗口基础帮助类 ...

本文主要整理互动直播中各端的逻辑，重点是与前端相关的教师端IM的部分和Web/Wap学生端。希望通过这份整理，对于前端在维护时可以尽快的理解互动直播的流程，提高项目的可维护性；对于客户端和教师端来说，可以了解到前端提供的接口和消息的实现。也能提高对整个请麦过程的理解，便于联调和后期的定位问题。 相关阅读推荐《连麦互动直播方案全实践1：什么是连麦互动直播？》《连麦互动直播方案全实践2：网易云信连麦互动直播方案的演变过程》《连麦互动直播方案全实践3：网易云信连麦互动的实现方案》 概 况互动直播涉及到服务端，教师客户端，iOS/Android学生端，Web/Wap学生端。本文重点介绍的是请麦的交互流程，前端请麦模块的设计，前端互动和聊天组件的设计。对于聊天室本身的聊天功能的实现，因为接入云信IM SDK，主要是通过Api调用封装实现的，就不细说了。在设计系统之前，首先需要考虑以下几个问题：• 各端的需求定义以及功能划分，各端如何交互• 各端之间的协议• 客户端请麦与教师端接收• 客户端进入互动直播房间后互动信息的同步带着以上几个问题，我们先整理一下可以依赖的的服务，通过网易云提供的以下服务如下图所示，结合自有系统的需求设计，让我们能迅速集成IM和互动直播的功能。• 云信IM服务提供了一整套即时通讯基础能力，可以将即时通讯、实时网络能力快速集成至企业自身应用中。• 云信的互动直播功能，支持主播和观众实时连麦互动。 架 构我们的基本需求主要是以下三部分： 学生在App客户端进入聊天室，可以发起请麦；在教师端可以对学生的请麦进行同意或拒绝的处理；在教师同意某位学生的请麦后，这位学生可以进入直播间进行互动。结合需求整理出以下的基本请麦，连麦，互动的流程， 如下图，不同样式的数据流向代表不同的协议。 这里有几个概念补充介绍一下：1、客户端云信IM的SDK，客户端通过云信IM发送P2P消息到教师端2、客户端互动直播SDK，客户端接入互动直播3、教师端云信SDK，接受p2p消息4、教师端互动直播SDK，与客户端直播互动5、Web端云信IM的SDK，发送接收消息6、自定义消息，各端发送信息的数据结构 设计与实现实现这节主要介绍上一节概述中提到的教师客户端 ，Web/Wap学生端的实现。主要包括以下几部分：流程细化、教师IM模块、Web学生端模块、配置、优势、存在的问题。 流程细化 先来介绍一下教师端的实现，按照下图中的标号顺序，对其中的一些细节做补充说明。教师端主要有两部分，一部分是native，本文中称为教师端native，另一部分是Web页面，本文中称为教师IM。教师端native和教师IM通过jsbridge以及自定义消息进行通信。首先，整理一下教师端native与教师IM通信的jsbridge如下： notifyQueueChangenotifyVolumenotifyCustomMsgcheckUpdatenotifyLiveStatus结合以上的流程图，再对流程进行一下细化说明：1、客户端初始化各端通过请求服务端获取统一的聊天室地址2、教师端初始化教师IM，在初始化后，通过服务端请求（getPresenterLiveInfo），获取聊天室地址，取得聊天室单例，通知教师端native聊天室就绪，获取互动直播数据。3、请麦的过程• 客户端发送p2p消息到教师端native，教师端native通过jsbridge, 调用教师IM的notifyCustomMsg，教师IM更新自身维护的请麦请求等待队列。• 教师IM点击同意或拒绝，通过消息通知教师端native，教师端native通过P2P通知请麦的客户端• 客户端通过互动直播SDK，连麦进入直播间，通过互动直播SDK发送消息给教师端native• 教师端native调用notifyQueueChange方法，更新教师IM中各列表• 教师IM，异步请求（informServer）更新服务端上下麦队列，发送自定义消息（im-sdk），广播通知各客户端。 教师IM模块结合流程图以及上面的流程细化说明，对前端的模块进行设计和拆分，如下图。 这里的LivePcChat是Tab中的聊天组件，LiveInteractivePresenter是处理互动操作的组件，XXcache是封装对应数据层操作的组件。具体的组件实例，调用，数据请求和处理的过程，如下图所示的时序图： Web学生端模块对于Web/Wap学生端，因为Web/Wap学生端本身还未开发请麦的功能。这里以Web学生端为例介绍一下Web/Wap学生端在互动列表和聊天互动中的实现。本身聊天室部分与教师端的聊天室是复用聊天组件的，因而这里也先把模块划分一下。可以参考教师端的组件划分，对比一下教师端和学生端复用的部分组件，下图是web学生端的组件拆分。 从下表的对比可以看到，除了请麦相关的处理逻辑，教师端IM和Web学生端在IM的其他功能是可以复用的。 配置互动直播是在原来的直播基础上做的迭代，所以这里要保证互动直播在教育各产品线的可配置性。这里所说的配置与教育公共组件池其他的模块和组件接入的配置类似，也是依赖于教育通用组件cache-base，通过在直播页面或者工程单页加载时（机构后台），读取config中的配置，一键配置。 优劣分析采用这套设计的优点是1、所有的服务端请求都是通过web页面发送，减少教师端维护的成本；2、模块的可配置性，在不同的业务线，可以通过配置来决定是否接入互动直播；3、组件颗粒化，在不同的模块中，教师端可以接入聊天组件和互动组件，请麦组件，学生端可以只接入互动列表组件；4、最大程度的依赖了现有的云信sdk实现的功能，能在较短的时间实现需求。 存在的问题1、请麦的流程比较复杂，因为涉及到多端，各端调试比较浪费时间，这也是整理此文的目的。在打通对各端流程的认识后，各端在调试中都能首先定位到出问题的端，然后才能有的放矢的在某一个环节中发现问题。2、因为是在原来的迭代基础上进行的，很多组件没有封装成教育规范的组件，不过逻辑清晰的前提下，可以在后面的迭代中优化掉。3、优化前端实现的方法。 总 结通过本文整理一下互动直播中各端的逻辑，便于后期接入对互动直播流程的理解。对客户端和教师端来说，可以了解到前端提供的接口和消息的实现。如果在后续另外的工程中，需要接入互动直播模块，能够快速的接入和调试，同时可以就以上提出来的存在的问题做进一步优化。 另外，想要获取更多产品干货、技术干货，记得关注网易云信博客。

近几年，视频编解码技术在理论及应用方面都取得了重大的进展，越来越多的人想要了解编解码技术。因此，网易云信研发工程师为大家进行了归纳梳理，从理论及实践两个方面简单介绍视频编解码技术。 相关阅读推荐《视频直播关键技术：流畅、拥塞和延时追赶》《视频直播技术详解：直播的推流调度》《音视频通话：小议音频处理与压缩技术》《视频编解码的理论和实践1：基础知识介绍》 1、Ffmpeg介绍《视频编解码的理论和实践1：基础知识介绍》介绍了视频编码的基础知识，本篇文章，我们一起看看实际应用中的视频编码是如何操作的。在实际工程项目中，ffmpeg是应用最多的多媒体处理框架，它提供了音视频采集、编解码、图像处理，格式转换等功能，并且拥有很强的扩展能力，通过ffmpeg可以很容易集成第三方库（例如：x264、openh264等），通过这种能力，它可以实现更强大的功能。Ffmpeg由下面几个部分构成：Libavformat：音视频格式处理Libavcodec：音视频编解码Libavfilter：音视频滤镜Libavdevice：音视频设备采集Libswscale：图像缩放、转换Libswresample：音频重采样Ffmpeg：一个命令行的转码工具Ffplay：一个命令行播放器Ffprobe：简单的媒体格式分析工具 2、Ffmpeg视频编码视频编码是ffmpeg提供的基本功能之一，通过ffmpeg可以很容易实现视频编码操作。使用ffmpeg进行视频编码之前需要把x264、openh264等第三方编解码库集成到ffmpeg中才能使用。编码步骤如下：（1） 注册编码器（2） 根据名字或者ID查找你想使用的编码器（例如x264、x265、openh264等）（3） 创建一个编码器上下文对象（4） 在编码器上下文对象中设置编码器参数（5） 打开编码器（6） 读取一帧图像进行编码，一直重复该过程，直到处理结束（7） 关闭编码器示例代码如下：avcodec_register_all(); // 注册所有可用的编码器codec = avcodec_find_encoder_by_name(“libx264”); // 查找编码器ctx = avcodec_alloc_context3(codec); // 创建编码器上下文ctx->width = 1280; // 设置编码器参数ctx->height = 720;// ….其他的参数设置avcodec_open2(ctx, codec, NULL); // 打开编码器while(read_frame(frame)){ AVPacket pkt; // 存放编码之后的数据int got_output = 0; // 是否成功编码得到一个图像avcodec_encode_video2(ctx, &pkt, frame, &got_output); // 编码if(got_output){ // 得到编码后的数据，进行后续操作}}avcodec_free_context(&ctx); // 关闭编码器 可以看到，ffmpeg隐藏了大部分的编码细节，调用者不需要了解预测、变换、量化、熵编码等细节，这些细节都已经被ffmpeg封装好了，开发者只要把编码参数设置好，然后调用相关的接口函数，即可实现视频编码功能。当然，这知识最基本的编码功能，要想在画面质量和压缩率之间取得平衡，必须了解视频编码的细节，然后设置相应的参数。 3、Ffmpeg视频解码Ffmpeg自带了H264的视频解码器，开发者可选择直接使用ffmpeg自带的H264解码器或者第三方的解码库进行视频解码。和视频编码一样，解码操作的大部分细节都已经被ffmpeg隐藏起来了，开发者只需要设置好相关的解码参数，然后调用接口函数就可以实现解码功了。解码流程如下：（1） 注册解码器（2） 查找解码器（3） 创建解码器上下文对象（4） 设置解码参数（5） 打开解码器 （6） 读取数据进行解码，直到结束（7） 关闭解码器代码示例如下：avcodec_register_all(); //注册解码器codec = avcodec_find_decoder_by_name(“h264”); // 查找解码器ctx = avcodec_alloc_context3(codec); // 创建解码器上下文对象//…设置解码参数avcodec_open2(ctx, codec, NULL); // 打开解码器while(read_packet(pkt)){ ...

近几年，视频编解码技术在理论及应用方面都取得了重大的进展，越来越多的人想要了解编解码技术。因此，网易云信研发工程师为大家进行了归纳梳理，从理论及实践两个方面简单介绍视频编解码技术。 相关阅读推荐《视频直播关键技术：流畅、拥塞和延时追赶》《视频直播技术详解：直播的推流调度》《音视频通话：小议音频处理与压缩技术》 1、视频介绍视频的本质是图像序列，根据视觉暂留的原理，每秒播放20~25张图像，就会形成连续平滑的视觉效果，人眼将无法区分其中单幅的图像，就这样连续的画面叫做视频。每秒播放的图像数量叫作帧率。图像是由像素构成的，在彩色图像中，每个像素由R、G、B三个分量构成，每个分量用一个字节存储。分辨率用于描述图像的尺寸，例如分辨率1280x720就表示图像宽度是1280个像素、高度是720个像素。 2、压缩视频的原因为什么要对视频进行压缩？假如有一段时长为60秒视频，它的分辨率是1280x720，帧率是25，那么这段视频的大小等于：60 x 25 x 1280 x 720 x 3 = 4147200000字节，大约是3955MB，如此庞大的数据，如果不进行压缩，那么磁盘空间将会很快被占满。多媒体数据占了互联网数据量的80%以上，其中大部分都是图像视频数据，未压缩之前的视频非常庞大，不利于存储和传输，因此很有必要对视频进行压缩，视频压缩也叫作视频编码，它利用视频中存在的空间冗余和时间冗余，剔除人眼不敏感的信息，达到数据压缩的目的。3、视频压缩的依据视频能够进行压缩的根本原因是信息冗余，视频中存在两种冗余信息：（1） 空间冗余。对于视频的每一帧图像，在一定尺度范围内，像素的变化是非常平缓的，像素之间非常相似，这就是空间冗余。（2） 时间冗余。视频是由连续变化的图像构成的，在一个很短的时间内，相邻图像之间的变化很小，因此相邻图像很相似，这就是时间冗余。 4、视频编码的原理和细节由于视频中存在大量的信息冗余，想要对视频进行压缩，就必须找到去除冗余信息的方法，标准的视频编码过程包含下面几个步骤：（1） 预测编码。所谓预测就是利用前面像素值来推算当前的像素值。根据前面的知识我们知道，在空间或者时间上相邻的像素是很相似，因此只要预测方法合适，预测值和实际值会很接近，假设当前像素的实际值是X，预测值是P，那么X和P之间的残差A=X-P。如果我们只对残差数据进行编码，那么将会大大压缩数据量。这就是预测编码的原理。预测编码可以分为空间预测（帧内预测）和时间预测（帧间预测）两种。预测编码可以分为下面几个步骤：i. 利用前面已经编码并重构像素块预测当前像素块的值ii. 求当前像素和预测像素的差值iii. 对像素差值进行编码iv. 把编码后的数据传输到解码端，在解码端按照同样的方法对像素值进行预测，再加上残差，就可以重构得到原始图像了。为了得到最佳的预测值，编码器通常需要使用不同预测方法进行预测，然后根据某个评判标准（一般是SAD、STAD、RDO等）得到最优的预测值（注意不是预测值越接近实际值就越优，所谓最优是计算复杂度、失真和码率之间的综合考量），特别对于帧间预测来说，在预测的时候要在参考帧中找到当前块的匹配块，需要大量的计算，因此预测模块一般是编码器中计算量最大的模块，而预测方法的好坏也直接决定了视频的压缩率。（2） 变换编码。变化编码本身不会对数据进行压缩，变换的目的是把空域信息转换为频域信息，去除了信息之间的相关性，在接下来的编码操作中可以得到更高的压缩比，变化编码是为下一步的量化编码做准备的。在视频编码中常见的变换方法是DCT变换和哈达玛变换。（3） 量化编码。量化是视频产生失真的根本原因。经过预测编码、变换编码之后得到的数据被称为变换系数，虽然变换系数相对于原始数据数来说已经很小了，但是系数值的变化范围仍然很大，利用量化把变换系数的连续取值转换成有限的离散值，这样可大大提高压缩率。假设有这样一组数据[16,96,100,600,50]，量化参数是25，那么量化之后数据是round([16 / 25, 96 / 25, 100 / 24, 600 / 25, 50 / 25]) = [0,4,4,24,2]，可以看到，量化之前的数据范围是16~600，需要大量的比特数才能表示，量化之后的数据范围是0~24，只需要少量比特数就可以表示，实现了压缩数据的目的。编码是一个不可逆的操作，它是失真产生的根本原因。（4） 环路滤波。环路滤波和压缩没有很大关系，却和视频的画面质量有很大关系。视频编码是以块为单位进行的，在经过量化模块时，可能每个块选择的量化系数不同，导致每个块产生的失真不一样，造成像素块的边界不连续，因此人眼观看视频的时会有方块效应（也就是有很多马赛克现象）。为了提高视频质量，有必要对方块效应进行消除，这就是环路滤波模块的功能。经过量化操作之后的数据块，再经过反量化、反变换，然后进行重构，接着进入去方块滤波进行去方块操作，得到的像素块就可以作为参考像素块给预测模块使用。环路滤波是一个可选模块。（5） 熵编码。熵编码的目的是去除统计冗余，实现数据的进一步压缩。这么说可能有点抽象，举个例子，假设有这样一组数据[0,4,4,24,2]，如果使用定长编码来进行编码，这段数据可以表示为[00000,00100,00100,11000,00010]，每个数据需要5 bit来表示，这段数据的总长度是5 bit x 5=25 bit；如果我们使用哈夫曼来编码，这个数组中每个元素概率值分别如下：数值0的概率是20%，数值4的概率是40%，数值24的概率是20%，数值2的概率是20%，即[20%,40%,20%,20%]，根据每个元素的概率构造哈夫曼树（节点中括号内的是数组元素值），如下图所示，因此这段数据可以表示为[0,10,110,111]，数据的总长度是11 bit。 由此可见使用哈夫曼编码可以去除统计冗余，实现数据压缩的目的，哈夫曼编码就是一种熵编码方法，但是由于哈夫曼编码对错误非常敏感，不适合实际应用，因此实际应用中通常使用变长编码（CAVLC）和算术编码（CABAC）作为熵编码算法。算术编码利用一个0到1之间的浮点数来描述一个信号序列，然后用这个浮点数来表示这个信号序列，极大的压缩了数据。算术编码可以使用一个简单的例子说明，假设有一个二进制串“10101110”，符号0和1的概率值都是50%，算术编码的过程如下：（1） 设置定一个区间，通常这个区间我们设定为[0,1)，然后使用low指向区间的下界，用high指向区间的上界，现在low指向0，rhigh指向1.（2） 输入每一个符号，按照符号的不同对low和high进行调整，调整方法如下面公式所示，最后把low指向的浮点数作为这个符号串的码字，表示这个二进制串，可以看到算术编码的压缩效率比哈夫曼编码高很多，在x264中使用CABAC（上下文自适应的二进制算数编码）作为熵编码算法。 以上就是编解码技术的基础知识介绍，该系列第二篇文章将会介绍视频编解码技术的实践。更多即时通讯、音视频技术的干货文章，请关注网易云信博客。

4月23日，由腾讯云与msup联合主办的以“揭秘智慧出行核心技术与创新实践”为主题的的闭门交流活动在北京3w咖啡顺利举办，本次活动出行行业的技术大咖们齐聚一堂。 我们特邀请到腾讯云高级解决方案架构师罗勇、摩拜单车大数据高级技术专家陈尚安、腾讯云安全部资深产品经理马中一、Grab北京研发中心总经理郑少麟，与现场学员共同探讨当下在云计算架构、出行安全、大数据地图等方面的技术与创新实践，为大家带来了一场技术盛宴。 在本次活动中，首先由罗勇先生带来了主题为《智慧出行新趋势与挑战》的演讲。他主要从智慧出行生态趋势与挑战、腾讯云智慧出行解决方案两个方面进行了阐述。 ![图片上传中...]回顾2018年出行行业，可以明显看出整个行业的趋势变化还是相当显著的。罗勇先生就趋势变化做出了三点总结：一、行业进入下半场，深挖用户需求，回归价值；二、出行安全，上升为“生死存亡”核心问题；三、出行业务出海，技术红利覆盖更多受众。 目前国内出行行业主流已经演化到移动互联时代，部分业务已经步入大数据，人工智能时代 ；网约车的平台演进也由1.0阶段逐步演进到3.0阶段。接下来，罗先生重点为大家阐述了腾讯智慧出行的战略。他将其分为三大场景（自主出行、共享出行、公共出行）和四横二纵一中台（四横：腾讯车联TAI 、腾讯自动驾驶TAD 、腾讯位置服务TLBS 、腾讯乘车码TRC ； 二纵：海量内容平台、安全保障体系 ；一中台：腾讯云腾讯AI）。 此外，罗勇先生也为我们分享了智慧出行的核心需求，即优质网络与弹性资源、全方位安全防护、高质量且丰富的LBS服务；最后，罗先生就智慧出行解决方案及腾讯云的解决方案为我们详细的进行了讲述，并提出腾讯智慧出行的愿景。 随后，来自摩拜单车大数据高级技术专家陈尚安发表了《大数据&算法改变单车运营效率》的演讲。陈尚安先生主要为大家介绍了贵公司的业务背景、以及在此背景下存在的问题及解决方案。陈尚安先生为我们简单介绍了摩拜的发展史及业务背景。摩拜单车，是全球首创通过智能锁实现无桩借还车，2019年1月并入美团，成为LBS平台单车事业部。接着陈尚安先生对业务背景，提出了5个关键词，即无桩、数百个城市、数百万辆单车、每日数千万次骑行、复杂状态的重资产运营。在这样的业务背景下，会产生诸多问题，例如：如何让坏车尽早地进入维修流程，提升用户体验？如何让用户在想骑车的时候更方便的找到车？ 就这些问题，陈尚安先生通过几个案例总结出了解决方案。即实时处理车辆的相关数据，尤其是位置的数据，通过算法和上面提到的这些场景，对用户、车辆、围栏做画像，然后通过算法抽象各种静态、动态的一些标签。最后当把这个数据同步到线上后，准确度提升了10%+，找车成功率提升率10%+，找车时长下降了5%+。 接下来，腾讯云安全部资深产品经理马中一分享了《AI&大数据风控能力为出行服务互联网化护航》的话题。马中一先生分别从2018年共享出行乘客风险控制、司机分享控制、出行支付&金融风险控制三个部分为我们重点进行了讲解。 首先，他为我们讲述了大数据风控的相关知识。随后他介绍了出行行业同互联网化的创新服务趋势，（1、发展迅速、共享出行超过40家、共享出行用户超过4.5亿人；2、出行平台地域化、垂直化、传统国企与车企入局加速竞争 ；3、后付费、免押金、汽车租赁的收费模式会成为流行；4、业务安全——成为出行平台的核心话题。）接着从乘客、司机、支付方面分析了新市场下的新业务挑战，此外，腾讯生态握手出行产业链，从流量平台、技术平台、金融平台方面推动了企业信息平台互联网化。 最后马中一先生重点阐述了大数据风控能力是如何从共享出行乘客风险控制、司机风险控制以及出行支付和金融风险控制方面为互联网服务行业保驾护航的。 最后一位分享嘉宾是Grab北京研发中心总经理郑少麟，他为参会者带来了《出行大数据构建更精准的地理信息服务》主题演讲，他首先为大家介绍了Grab。Grab北京研发中心成立于2015年，最开始起家是打车软件，现在有打车、送餐、物流、移动支付和地图，在东南亚300多个城市运营，其愿景是成为东南亚的超级APP。接下来，郑少麟先生介绍了地理信息服务平台。就Grab场景来说，派单、计价、ETA、反作弊安全对于打车平台都是很重要的，地理信息是反作弊安全中的一个非常核心的组件。 接下来，他从基础路网建设、上下车点体验、路径规划及ETA问题、反作弊与安全四方面详细的进行了阐述。演讲结束后，大家意犹未尽的和众位老师进行了切磋交流。最后，为大家奉上一张现场学员做的笔记，从密密麻麻的文字中，我们看到了诸位学员的认真和虚心，想必本次闭门交流会定为参会者带来了一定的收获！期待和大家再次相聚！

区块链技术是世界上最重要和最具颠覆性的技术之一。多个行业正在采用区块链技术来创新其运作方式。希望采用区块链的行业之一是医疗保健行业。在本指南中，我们将熟悉区块链，特别是有助于打破这个行业原有桎梏的功能。此外，我们将研究医疗行业的未来将会是什么样子。医疗行业和创新中的区块链无论我们说什么，我们都不夸大医疗保健行业的重要性。话虽如此，这很容易成为整个领域中发展最慢的行业之一。当然我们也意识到这是一个非常有争议的说法，但是，证据就在于反应迟钝。与二十年前相比，整体而言，医院的功能基本相同。正如Richie Etwaru所说，其原因在于缺乏创新。当你考虑到这个领域，特别是整个世界里有一些最聪明，受过良好教育的人时，这实际上是非常令人惊讶的。当然，说在医疗领域没有做任何创新是一个非常错误的说法。看看由于药物，平均预期寿命增加了多少。因此，我们需要更深入地了解Etwaru所说的“缺乏创新”是什么意思。如果你深入研究一下，那么你会发现这个领域充满了垂直创新，然而，在横向创新方面，它总是落后的。那么垂直和横向创新是什么意思呢？垂直创新与横向创新垂直创新是在特定领域内专门完成的创新，而横向创新是每个人都可以采用的。让我们举一个例子来说明这一点：青霉素，脊髓灰质炎疫苗和复杂的操作方法都是垂直创新的例子，因为它们仅针对特定领域。另一方面，电力，互联网和云计算是横向创新，已被多个领域和行业采用，以提高其功能效率。大多数医院仍然使用纸张和文件来记录这一事实，这表明它们在涉及到时已经远远落后横向创新。区块链：下一个横向创新我们之前在这个网站上已经多次讨论过区块链基础知识。所以，给你一个非常简短的描述。用最简单的术语来说，区块链是一组带时间戳的系列不可变记录数据，由不属于任何单个实体的计算机集群管理。这些数据块（即区块）中的每一个都使用加密原则（即链）来保护并彼此相互绑定。区块链之所以获得如此关注的原因是：它不是由单个实体拥有，因此它是去中心化的。数据以加密方式存储在内部。区块链是不可变的，因此没有人可以篡改区块链内的数据。区块链是透明的，因此可以根据需要跟踪数据。区块链和去中心化为了理解为什么去中心化和运行无信任系统的概念很重要，你需要了解我们人类从一开始就拥有的信任关系。早期的穴居人了解到相互信任的重要性。这实际上是一个生死攸关的问题。一个穴居人独自生存的机会为0。想想自然界中可能杀死它们的所有元素，从野兽到天气的变化。一个人必须学会如何与他们可以信任的人一起生活在社区中，只为了生存。随着时间的推移，你可以看到这种信任以许多有趣的方式发展。首先，我们有易货系统，其中人们相互信任，为他们提供有价值的产品与他们交换以进行交易。然而，随着时间的推移，我们的交易系统变得无比复杂。由于医疗保健在很大程度上得到了改善，我们的人口激增，我们的业务变得更加复杂。结果，我们从信任个人，到信任集中的研究所，如银行。然而，随着时间的推移，这些银行变得越来越强大。由于这些银行所大量处理而带来的责任，它们必然会带来可能非常糟糕的问题和局面，人们将不得不寻找另一种金融体系。这一点出现在2008年的金融崩盘中。许多银行，尤其是雷曼兄弟（Lehman Brothers），都承认过度承担风险，使整个地球陷入自20世纪30年代大萧条以来最严重的经济衰退期。在中央银行体系中，一位名叫Satoshi Nakamoto的匿名人士提出了比特币的想法。比特币是世界上第一个由区块链技术驱动的去中心化加密货币。那么，区块链是如何去中心化的呢？这真的是一个非常简单的概念。存储在区块链中的所有记录不会保存在一个集中存储单元中。网络中运行的多台计算机拥有区块链中所有数据的副本。这就是为什么无论何时在区块链中更新任何内容，网络中的所有节点都会立即得到通知。这就是去中心化的意思。没有单一来源可以管理所有数据。好吧，这听起来很酷，但是，这对医疗保健行业有何帮助呢？医疗保健和互操作性互操作性是医疗保健行业的一个大问题。事实上，改善医疗保健互操作性已经成为供应商，政策制定者和患者的首要任务。那么，在无效的互操作性方面，两个主要领域是什么？识别患者方面的困难信息共享限制识别患者方面的困难我们在研究本指南时学到的最令人惊讶的事情之一。显然，仍然没有普遍认可的患者标识符。尽管像CHIME和HIMSS这样的组织近二十年来一直在推动其发展。当你考虑到一个独特的患者标识符能够轻松解决患者EHR（电子健康记录）不匹配的问题时，这确实令人震惊，这些问题过去曾导致患者护理中的多个错误并增加了患者受伤的可能性。生物医学信息中心（CBMI）主任肖恩格兰尼斯已经很好地表达了这个问题。“将正确的个人与他或她的健康数据相匹配对他们的医疗保健至关重要，”他说。“统计数据显示，即使在同一医疗保健系统内，也有多达五分之一的患者记录无法准确匹配。在医疗保健系统之间传输数据时，多达一半的患者记录不匹配。“那么，区块链怎么可能解决这个问题呢？好吧，让我们稍微调查一下。在我们这样做之前，让我们看看我们在这里遇到的第二个问题。信息共享限制尽管被视为非法行为，但信息拦截一直是医疗保健行业的一个问题。信息共享限制是什么意思？在医疗保健行业，信息共享限制被描述为“对患者数据或电子健康信息交换施加了不合理的限制。”根据美国卫生信息技术协调员办公室的说法，有三个标识用于识别信息共享限制：不合理干扰有意识拦截没有理由的无法访问数据。不言而喻，涉及不合理干扰和有意识的信息拦截，在实践对于有效的医疗保健实践是一个巨大的损害。由于阻止信息共享的策略以及非常不切实际的共享实践，可能会发生阻塞。原因很简单。医院不希望失去患者，并不希望他们搬到另一家医院。在这个数字时代，这应该是一种严峻的做法，但各种调查和研究都说这么说。在对60名HIE领导人进行调查后，发现信息拦截极为普遍，而采取的各种措施仍然非常无效。据报道，50％受Adler-Milstein研究的受访者通过参与信息拦截与健康IT公司合作。这些受访者中有四分之一也表示，医院和卫生系统都是这种做法的罪魁祸首。根据研究人员的说法，可以通过以下方法之一来抑制信息阻塞：通过提高透明度，可以考虑参与者采取的每一项行动。应该有强大的经济激励，以便参与者希望彼此分享信息。健康IT公司，医院和HIE之间的协作关系可以进一步抑制信息阻塞。好吧，现在我们已经熟悉了从内部消耗医疗保健行业的互操作性问题。现在让我们看看区块链将如何帮助解决这个问题。公共和私有区块链有两种特定类型的区块链：公共区块链私有区块链由于两者都是区块链，它们提供了一个点对点网络，提供了一个去中心化，不可变的生态系统，通过共识协议进行同步。但是，他们也就这点儿相似之处。公共链公共区块链是我们最熟悉的区块链。比特币，以太坊等都是公共区块链，因此它们之所以被这么称呼是非常不言自明的原因。它们是完全开放的生态系统，任何人都可以参与生态系统。该网络还有一个内置的激励机制，奖励参与者更好地参与系统。那么，这是非常棒的权利，然而，医疗保健行业是否会受益于公共区块链？嗯……不是那么多。首先，正如已经非常详细记录的那样，比特币和以太坊中的区块存在存储问题。比特币每块有超过1mb的空间，这根本不足以运行这种交易并存储医疗机构所需的数据类型。然后我们遇到了吞吐量问题，这些问题也得到了很好的记录。比特币每秒几乎无法管理7-8笔交易。区块确认时间为10分钟，这只会增加延迟。大型医疗保健机构需要每天处理大量交易，延迟接近0。事实上，任何类型的延迟都可能危及生命。公共区块链，尤其是遵循像比特币这样的工作量证明协议的区块链，需要大量的计算能力来解决难题。因此，这些机构在共识机制上花费这么多钱实在是不切实际的。最后，公共区块链是开放链，这本身就是另一个不利因素。想一想，为什么医疗机构应该尝试在任何人都可以进入并成为其中一部分的网络中相互交流。医疗机构处理高度机密和敏感的数据，他们为什么要让圈子外的任何人与之互动呢？因此，公共链对于这些目的是不切实际的。然而，医疗机构还有一种实用的区块链，它们被称为私有区块链。私有链私有链当然是……私有的。与公共区块链不同，这些并非对所有人开放。因此，想要加入私有链的人必须获得成为该网络一部分的许可。这就是私有链也被称为“许可区块链”的原因。因此，对实际参与共识的人有限制。可以通过以下方式获得新参与者：参与生态系统的现有参与者。受监管的权威。一个财团。一旦实体加入生态系统，它们就可以在网络维护中发挥作用。Linux Foundation的Hyperledger Fabric是许可的区块链框架实现和Linux基金会托管的Hyperledger项目之一的示例。它经过精心设计，以满足这些企业的要求。这些私有区块链专为满足企业需求而设计，并提供许多功能，例如：快速交易隐私保护安全性高好的，所以我们有一个方程式，即私有链。然而，在我们围绕医疗行业如何处理区块链之前，我们必须了解还有一个难题。密码哈希函数hash意味着获取任意长度的输入字符串并给出固定长度的输出。在像比特币这样的加密货币的情况下，交易被视为输入并通过哈希算法（比特币使用SHA-256）运行，该算法给出固定长度的输出。让我们看看hash过程是如何工作的。我们将输入一些内容。在本练习中，我们将使用SHA-256（安全哈希算法256）。有很多属性使哈希函数非常有用。我们之前已经介绍过这些内容，但是现在让我们关注其中的一些。属性1：确定性这意味着无论你通过哈希函数解析特定输入的次数，你都将获得相同的结果。这很关键，因为如果每次都得到不同的哈希值，就无法跟踪输入。属性2：无法预测无法预测状态是说给定H(A)确定A是不可行的，其中A是输入而H(A)是输出hash。我们来举个例子吧。这是一个哈希：559AEAD08264D5795D3909718CDD05ABD49572E84FE55590EEF31A88A08FDFFD你能确定生成这个精确哈希的输入是什么吗？你很难确定它。这不是不可能的，只是非常刺激和耗时。属性3：雪球效应此属性指出即使你对输入进行了少量更改，将在哈希中反映的更改也会很大。让我们用SHA-256测试它：你看到了吗？即使你刚刚更改了输入的第一个字母的大小写，请查看影响输出哈希的程度。现在让我们将它们整合在一起，看看许可的区块链如何帮助解决医疗保健行业的互操作性问题。医疗许可区块链想象一下医疗机构的网络，他们没有患者的个人数据。数据都属于区块链。通过其哈希ID识别患者，该哈希ID将是其唯一标识符。hash允许ID是唯一的并且保护用户的隐私（参见上面的属性#2）。区块链还可以帮助创建患者信息共享市场。这样，就可以实际激励不同机构之间的信息共享，以防止任何类型的信息阻塞。但是，如果我们仍然有一些恶意行为者试图阻止或篡改信息呢？在这种情况下，区块链的两个最重要的功能将加强并处理这种情况：首先，区块链是一种透明的。作为网络一部分的任何人都可以查看区块链，查看每笔交易是如何进行的，以及是否所有相关信息都已通过。其次，我们有反篡改。如果有人试图阻止数据然后通过滚雪球效果，它将彻底改变hash。现在，请记住，区块链中的块通过哈希指针相互链接。区块链中的每个块都存储存储在前一个区块中的数据的哈希值。如果任何一个区块内的数据发生变化，它会产生链式反应，这可能会冻结整个区块链。由于这是理论上的不可能性，因此无法篡改区块链内的任何数据。医疗保健区块链的其他优点那么，既然我们知道如何解决互操作性，那么区块链还能为医疗保健机构带来哪些其他惊人的优势呢？由于区块链是不可变和可追踪的，因此患者可以轻松地将记录发送给任何人，而不必担心数据损坏或篡改。同样，已生成并添加到区块链的医疗记录将是完全安全的。患者可以控制他们的医疗数据如何被研究所使用和共享。任何想要获取患者医疗数据的方都可以查看区块链以获得必要的许可。还可以通过奖励机制激励患者获得良好的行为。例如，他们可以获得代币以遵守护理计划或保持健康。此外，可以通过代币奖励他们为临床试验和研究提供数据。制药公司需要拥有一个非常安全的供应链，因为它们带有各种产品。药品一直从供应链中被盗，被非法销售给各种消费者。此外，假冒药物本身也使这些公司付出了代价，每年近2000亿美元。透明的区块链将帮助这些公司实现药物的密切跟踪，从而有助于消除伪造的药物。图片来源：普华永道世界各地的各种医疗机构对各种新药和药物进行自己的研究和临床试验。区块链将有助于创建单个全局数据库来收集所有这些数据并将它们放在一个地方。保险欺诈是影响医疗保健行业的主要问题。当不诚实的提供者和患者提交虚假声明/信息以获得应付福利时，就会发生这种情况。为了解这个问题有多严重并请试着解决这个问题：根据Boyd Insurance的说法，仅在美国的医疗保险欺诈每年就要花费大约680亿美元。事实上，根据图表，前两种医疗保健欺诈与医疗相关。 ALLIVE的首席执行官Jack Liu是一个基于区块链技术的智能医疗生态系统，他认为区块链将有助于解决这个问题。据他介绍，“当供应商和患者必须输入他们的信息和数据进行验证，记录和存储，并且健康保险公司必须能够访问这些数据时，区块链环境可以消除大部分欺诈行为。”由于所有数据都不会存储在集中式基础架构中，因此无法破解系统并掌握所有数据。这使系统无泄漏，并有助于保护患者的隐私。批评者显然，并非所有人都认为将医疗行业建立在区块链技术的基础上。其中一位批评者恰好是哈佛大学教学医院波士顿Beth Israel Deaconess医疗中心的首席信息官John Halamka。他已经开始研究几种生产区块链应用程序，因此他非常熟悉它的工作原理和潜在的用例。据他介绍，“区块链不适用于存储大型数据集。区块链不是分析平台。区块链的交易性能非常慢。但是，作为防篡改的公共分类帐，区块链是工作证明的理想选择。区块链具有很强的弹性“。医疗保健行业区块链结论你必须拥有它。我们已经列出了区块链可能赋予医疗保健行业的各种优势。显然，在我们看到这种伙伴关系的正确实施之前，这都是传闻。我们可以说明的事实是，其他各种研究所和领域已经开始尝试和使用区块链技术。这个领域不缺钱。实际上，请考虑以下统计信息：数字健康创业公司的资金在2018年第一季度创下历史新高。2015年全球年度医疗支出超过7万亿美元。到2020年，全球年度医疗支出预计将超过8.734万亿美元。因此，他们应该没有财务限制来研究新的和令人兴奋的技术。所有迹象都指向区块链医疗的未来。让我们看看为什么。根据BIS研究报告，到2025年，医疗保健行业到2025年每年可以节省高达1000亿美元的数据泄露相关成本，IT成本，运营成本，支持功能和人员成本，假冒相关欺诈和保险欺诈。如果他们采用区块链技术。该报告还指出：“预计医疗保健市场的全球区块链将从2018年到2025年以63.85％的复合年增长率增长，到2025年达到56.1亿美元的价值。区块链在医疗保健数据交换中的使用将在整个预测期内贡献最大的市场份额到2025年，由于使用区块链来解决与互操作性和非标准化相关的医疗保健信息系统中最普遍的问题，导致该行业产生数据孤岛，到2025年达到18.9亿美元。”根据报告和区块链被各个部门采用的方式，看起来医疗保健行业的未来确实是去中心化的。让我们希望区块链技术为这个迫切需要的行业提供横向创新。======================================================================分享一些以太坊、EOS、比特币等区块链相关的交互式在线编程实战教程：java以太坊开发教程，主要是针对java和android程序员进行区块链以太坊开发的web3j详解。python以太坊，主要是针对python工程师使用web3.py进行区块链以太坊开发的详解。php以太坊，主要是介绍使用php进行智能合约开发交互，进行账号创建、交易、转账、代币开发以及过滤器和交易等内容。以太坊入门教程，主要介绍智能合约与dapp应用开发，适合入门。以太坊开发进阶教程，主要是介绍使用node.js、mongodb、区块链、ipfs实现去中心化电商DApp实战，适合进阶。C#以太坊，主要讲解如何使用C#开发基于.Net的以太坊应用，包括账户管理、状态与交易、智能合约开发与交互、过滤器和交易等。EOS教程，本课程帮助你快速入门EOS区块链去中心化应用的开发，内容涵盖EOS工具链、账户与钱包、发行代币、智能合约开发与部署、使用代码与智能合约交互等核心知识点，最后综合运用各知识点完成一个便签DApp的开发。java比特币开发教程，本课程面向初学者，内容即涵盖比特币的核心概念，例如区块链存储、去中心化共识机制、密钥与脚本、交易与UTXO等，同时也详细讲解如何在Java代码中集成比特币支持功能，例如创建地址、管理钱包、构造裸交易等，是Java工程师不可多得的比特币开发学习课程。php比特币开发教程，本课程面向初学者，内容即涵盖比特币的核心概念，例如区块链存储、去中心化共识机制、密钥与脚本、交易与UTXO等，同时也详细讲解如何在Php代码中集成比特币支持功能，例如创建地址、管理钱包、构造裸交易等，是Php工程师不可多得的比特币开发学习课程。tendermint区块链开发详解，本课程适合希望使用tendermint进行区块链开发的工程师，课程内容即包括tendermint应用开发模型中的核心概念，例如ABCI接口、默克尔树、多版本状态库等，也包括代币发行等丰富的实操代码，是go语言工程师快速入门区块链开发的最佳选择。汇智网原创翻译，转载请标明出处。这里是原文医疗保健行业中的区块链

今天看到勾三股四的文章我对技术会议的一些看法,有些感想, 也想把自己感受到的写出来, 大致顺着勾股的文章做感想吧.秋天的时候整理的吊牌… 这些年压下来已经挺多的了.这些年参加的回忆都是国内的, 之前是同城的聚会, 然后有一些其他城市的活动,最远的一次跟着勾股去了台湾那边参加 ModernWeb, 体验也更特殊一些.会议的意义我觉得网络发达了真的对技术会议有不小的改变, 特别是视频的传播,国内的开发者应该也感觉得到, Google Apple 那些大会我们都没机会去,但是会议结束之后, 那些视频往往会被整理出来, 全世界的开发者都有机会看,视频的好处, 可以暂停, 可以快进, 可以选择, 纯粹出于学技术的目的, 完全足够.所以我会觉得更多是交流的意义, 面对面那种投入感, 信任感, 能进行更深入的交流.当然, 分享也是挺重要的. 不做分享, 陌生人交流会尴尬, 不好进入话题.熟人之间当然是很容易进入到相互熟悉的话题的, 因为铺垫比较充足,但是陌生人之间要沟通, 首先要有一定的了解, 然后有一些共通的知识基础.我当然也相信有些人口才好, 陌生也能聊起来, 但是我想, 更多人还是需要先相互有所了解.我幸运的地方是, 我因为 React 认识了不少人, 所以在大会上能有熟人交流了,但我最初去 D2 那样的会, 跟着五花肉问, 放眼望去总共就认不到几个人,那种情况下交流的障碍带来的隔阂我也是能体会到.但是她当时说的蛮有道理, 先要有些认识的人, 然后才能认识更多的人,至少做些准备吧, 匆匆忙忙的机会本来也就不是那么多, 总不能不说话就结束了.审稿我觉得审稿有一定的必要, 之前有机会旁听过贺老给人审 review Qcon 试讲,对于演讲质量和演讲技巧来说, 有不小帮助的, 主要是对演讲经验少的帮助更多一些,程序员很多都在埋头做技术, 锻炼演讲技能的机会不是那么多,我的经历, 如果不是 Teambition 当年有内部的分享, 我最开始的演讲底子就很欠缺.这两年工作节奏忙这方面做的不够, 所以我能感觉到审稿和试讲会有不少帮助.而且稿子的内容, 长短, 深度, 是否跟其他嘉宾有重叠, 我觉得也是主办方需要考虑的,倒不是说要主办方控制讲师讲的是什么, 而是说根据观众群体水平调整一下侧重,有时候大会上嘉宾内容之间深度会有明显的反差, 这时候事先通气总是能调整一些的.会前预热参会是交流的好机会, 但是很多次, 会发现等到认识了, 会议已经散场了,如果说接下来晚饭或者第二天有活动, 大家还能一起继续交流交流,不然的话, 各自就回到自己城市去了, 下一次碰面不知道什么时候.所以我觉得, 会议开始之前进行预热, 很多时候能带来好处.深圳 JSConf 那年, 就是提前有建群, 然后大家出车站机场就有在指路或者约饭的,小圈子里当然建群还更早一些, 熟人可能更早约见面了.我个人比较期待的话, 如果可以带着自己代码的 Demo 去交流, 效果会更好,其实很多说的事情, 你在网上说, 或者看新闻说, 是相似的,或者见面的时间那么短, 能说的事情反而可能不如在网上能展开的细节来得多,但是 Demo 的话, 现场演示和交流还是比录视频去演示要好的,随时能跟着对方的想法去调整, 去解释, 会更有效果. 也明白哪里更重要.而且可能提早一段时间去讲师的微博 Twitter 上熟悉一下相关领域还更好一些,会场要上去聊天的话, 对方近期做的一些事情当然了解一下是更好,特别是相互之间做的事情有没有交集, 有没有项目方面搭上的机会…我站到讲师的角度, 我也希望有人到我面前说事情之前, 微博上是打过招呼的.交流工具目前为止我看到的, 大陆的会议, 如果交流, 都是用的微信,台湾那次比较邪乎, 他们用的 Gitter, 结果人真的少, 听不到什么八卦,有微信其实蛮不错的, 主办方能很快收到反馈, 有什么问题, 都很快.微信麻烦的就是刷屏了, 话题也很容易带偏, 几个人聊着很容易被大部队冲散了,所以我一直有点期望能有个两个维度的聊天工具, 论坛帖子那样的,聊着聊着能很容易走近小圈子, 这样有些技术问题能在时间线当中延续.还有一个就是陌生人的话, 你很难把他微信跟他在技术社区的身份很快关联起来,网上的话, 看看这人 GitHub 或者中文版 StackOverflow, 或者博客, 能看到水平,技术会议上看着别人主页晒美食晒行程总觉得哪里不大对….本地聚会和全国会议参加大会, 有一个问题是, 一些新人去了, 其实很难找到机会跟有名气点的人聊天,如果害羞, 话都没机会说, 如果没有知识储备, 聊两句就聊不下去了,也不能指望对方一定是耐心的人, 毕竟一天时间另一个人还想找别人聊天呢,对于新手来说, 更需要的是本地小规模的聚会, 甚至多接触经验相近的人.相比各种大会, 我觉得地区性的小型聚会需要更多的人去组织,我在上海, 参与过很多次朋友办的 Linux 用户组的分析, Elixir 社区的分享,也有参与过比较少的 Ruby 社区的活动, 或者 FreeCodecamp 的活动,上海这些活动应该说比较好, 相对其他城市加班少一些, 人口数量大.但是小型的活动挺难延续的, 找场地, 找话题, 都要免费, 比较难凑起来.之前同城的 Ruby 聚会, Elixir 聚会, 给我的感觉更好一些,人少, 相互都能认识, 交流的时间也稳定一些, 也不像大会那么拘谨,这种氛围对于经验少一些的人更合适一些了, 而且也不用去愁很贵的门票.而大会的话, 听说是门票钱很多耗在了外国讲师的行程上面(没去确认过),我也当过讲师, 能感觉到机票食宿方面如果折腾起来, 都挺耗钱的…这对很多新人来说是吃亏的地方, 因为大老远请来了嘉宾, 你一句话都搭不上,而且在会场认识的人多了, 能做的事情也就更多, 这是有点两极分化的.英语广州这次终于壮着胆子跟国外讲师套近乎了, 我口语也不够流利,听 Sean 聊天给我的感觉, 他在国外各种分享认识了好多人,所以他接触过很多的想法, 不同的技术氛围, 我们在国内很难碰到,我是在讲师聚餐时候听到讲的, 所以听了总比平时碰到能听到的多,当然相应的, 需要的知识储备, 不同的方面的东西, 也要求会多一些…然后问题就是, 国内的话, 越是年纪大的人当中, 英语好的人越少, 这么一趟下来我更觉得英语重要了, 或者说对英语好的人是个机会, 万一突然红了呢!说不定哪天开会的时候就要征志愿者给他们配翻译呢, 谁知道呢…我觉得外国讲师应该也是会觉得国内生态有什么有意思的, 也想听听八卦,就算不听八卦, 满街的中文饭馆还有路标总是需要人帮衬的.圈子外的人我有在参会的时候遇到过圈子外的人来听技术分享的情况, 当然这种少一些,我是说, 换个角度可以想想, 除了新手, 还是有一些人需要我们给与一些帮助的,那些人可能是对某项内容感兴趣的创业者, 可能冲着朋友或者讲师过来的,技术会议内容晦涩, 如果能提供一些帮助, 我们可能包容多一些人参与进来.而且某些情况, 等这一茬的程序员长大结婚了, 带着配偶带着小孩参会也是可能发生的事情,这种, 说不定同城聚会不那么正式的场合会多一些,这样其实还是要有心理准备要跟圈外的人甚至还没入行的人作交流.我印象当中新人畏惧社交会多一些, 还没有进入圈子的人, 他们也需要多一些机会.结尾勾股说得对!最后我想鼓励大家多学习英文，多出去走走。 ...