概要说明格式说明有两类主要的音频文件格式：无损格式，例如WAV，FLAC，APE，ALAC，WavPack(WV)有损格式，例如MP3，AAC，Ogg Vorbis，Opus.序号类型说明1cdaCD音频格式扩展名2wav微软公司开发，用于保存WINDOWS平台的音频信息资源。3mp3全称MPEG：MovingPictureExpertsGroupAudioLayer-3，是目前用户最多的有损压缩数字音频格式。4aif/aiff苹果计算机公司开发的一种音频文件格式。5mid经常玩音乐的人使用，最大用处是在电脑作曲领域。6wma即Windows Media Audio，来自于微软。7ra主要适用于在网络上的在线音乐欣赏。8vqf雅马哈公司的一种声音格式，可以用雅马哈的播放器播放。9ape目前流行的数字音乐无损压缩音频文件。项目应用说明在视频编辑剪辑项目中主要使用：Mp3,AAC,Ogg,Wav, FlAC, APE等，如果前端无法识别需要服务端转码处理好后给前端一个规范的编码类型。不同类型在采集频率、编码方式、压缩率等都不太一样,另外在音频处理过程中还有增强、降噪、AI语音识别，网络与传
共享文档来源 于2021年 tweb 大会宣传资料1、渲染管道优化以表格为例，对layout布局，paint 优化。尽量避免几何属性修改导致全局layout的修改.paint only 修改减少repaint.2、DOM 复用dom 复用减少渲染的dom节点数量3、升级 canvas 渲染解决复杂页面和页面滚动后，由于layout与 recalulate style 开销增长过大问题。4、解决canvas 的性能问题a) 减少渲染时触发GC。优化gc的逻辑b) Canvas API 调用的优化 strokeStyle、fillStylec) canvas 渲染复用，后面几页都是凑得内容[肖骏_腾讯文档渲染优化之路.pdf] https://docs.qq.com/pdf/DYk1QV1djbENGWnZw?
本文是读了腾讯文档前端TechLead, T12大佬曾探哥。 他经历了腾讯文档前端从0.1到现在的建设过程，和团队同学一起持续对腾讯文档前端进行架构优化，对前端架构设计有一些经验和兴趣 。 《JavaScript设计模式与开发实践》作者。这6-7万字文章中蕴含很多大型项目设计的经验和感悟，值得学习和借鉴。1、模块依赖优化a) 理清模块结构依赖，分类管理。当小团队3-5个人的时候项目架构依赖还很好管理，尤其到项目规模变大了，以及团队规模也变大了，整个架构、模块、类、函数、工具、相关的复杂的和层级变深了，整个项目的管理难度会指数级上升，到后续一定要分工明确，边界与规范也需要明确。尽量减少不必要的依赖。b) 合理抽象模块，降低耦合复杂度在开发的过程中，一定要随着系统的升级迭代、新人加入一定要做好培训讲明规则，保持好各个模块之间的功能单一性、独立性、复用性。 模块功能职责单一之后，对模块的迭代修改就会相对简单，不至于牵一发而动全身。针对业务逻辑一定要有核心人物多来思考抽象业务逻辑。让模块具有普适性。c) 代码架构分层，提升稳定性数据、逻辑、UI分层管理，梳理出核心业务层封装，对核心逻辑的质量提
背景在工作和生活中，我们经常会遇到这样的情况：某些热点事件刷屏，人们纷纷转发，众口一词，但很快又会出现反转的情况。在对一件事情或人进行评判时，我们有时会以偏概全，或是以感觉代替事实。在交流和沟通中，不辨真伪，执着偏见，或是盲从他人的看法等现象也时常发生。这些现象的根源大致可以归结为三点：将假设当作事实，将表面现象当成根本原因，将情感决定思考。胡适先生于百年前提到了“大胆猜测，小心求证”，这就体现了在创新思维和现实态度之间达到理想平衡的重要性。影响独立思考的因素：从众心理迷信权威情绪干扰以偏概全错误归因独立思考四部曲：锚定目标：1)列明目标清单2)转换角色检查目标清单3)反思优化目标清单回顾事实：5W1H法则；1)怀疑精神：为什么相信？2)分析精神：可靠吗？3)实证精神：理解什么事实、观点、立场、信仰寻找真相的方法：1)寻找第一手的原始信息2)留够时间让细节更完整，避免片面3)广泛求证，兼听则明，多渠道分析4)信息提供者 多元视野、多维度、正反两面1)长度（时间）：目光长远2)宽度（模型）：看到全貌而非局部，防止单一视角3)高度：看清本质，而非表象全局看问题—>理解问题的层次结构—
开源常见的问题和解决流程方法当业务有国内、出海规范需求的时候一般会对开源组件有明确合规的要求,如文中所示:1、开源信息整理对项目中使用的每一个开源组件名称、版本号、下载链接地址，并确认是否对开源软件做出修改，是否对开源软件进行分发。一般情况需要尽量保证提供的信息准确，开源软件使用的许可协议可能因不同版本而存在类型差异，因此开发团队需要提供准确的版本号，准确的下载链接，明确开源软件许可协议文件，以免在审核过程中出现问题。2、怎样判断是否对开源软件构成分发？以任何方式对外（譬如用户）提供开源软件，例如通过邮件、U盘、云、私有部署等使外部能够获得开源软件，即构成分发。通过SaaS等仅提供服务，而不提供开源软件的，则不构成分发。以下表格列明的场景可供开发团队参考。开源组件（源代码/二进制代码）在哪里调用不构成分发构成分发仅在服务后端√ 从第三方软件库下载至客户端电脑/手机/其他终端设备√ 提供私有部署云端产品 (即是开源软件组件须要安装于客户的服务器里) √其他人在自己服务上下载至客户端电脑/手机/其他终端设备 √提供下载 √以任何其他方式提供给客户使用 √3、对外分发开源软件应注意什么对外分
最近在优化业务在国内外合规问题，并整理了所有依赖包的开源协议，顺便讲开源协议的规则共享一份。常见两类开源开源协议上百种。常见的开源许可协议主要有 Apache、MIT、BSD、GPL、LGPL、MPL等，可以大致分为两大类：宽松型开源许可协议和传染型开源许可协议。宽松型其中宽松型开源许可协议有Apache、MIT、BSD；协议说明1、BSD（二条款版）分发软件时，必须保留原始的许可证声明。2、BSD（三条款版）分发软件时，必须保留原始的许可证声明。不得使用原始作者的名字为软件促销。3、MIT 分发软件时，必须保留原始的许可证声明，与 BSD（二条款版）基本一致。4、Apache 2 分发软件时，必须保留原始的许可证声明。凡是修改过的文件，必须向用户说明该文件修改过；没有修改过的文件，必须保持许可证不变。基本特点:1、没有使用限制。用户可以使用代码，做任何想做的事情。2、没有担保。不保证代码质量，用户自担风险。3、披露要求（notice requirement）用户必须披露原始作者。传染型传染型开源许可协议有GPL 、LGPL、MPL。协议说明1、Affero GPL (AGPL) 如果
引言时间过得很快，一晃毕业快十年了，感觉自己积累的知识，沉淀的技术都没有很好的保留下来，前些天看到左耳朵耗子，因病逝世。自己的腾讯也是经历了很多次部门调整，作为一个开发也是顺着部门的调整而调整了很多次，如果部门或者公司不需要了，那也就拍屁股走人，留下的东西全是公司的，自己好像什么也没得到，除了养活自己的那点工资。细细想来，还是想为这个世界留下点什么，有可能是信息世界里面的噪音，也有可能是新人们引以为戒的教训，有可能是大家所借鉴的经验。从上学到工作我09年上大学13年毕业，我学的是计算机软件的，做c#和asp.net的开发，初入社会的时候也做了一些PHP的后台开发。经历过了很多次的技术潮流的迭代与更新。在学校里的时候因为比较喜欢做前端开发即见即所得，所以后来也就走上了前端开发的道路。我记得最早做项目页面中大部分还是table标签，然后有div+css，最痛苦是ie6+的兼容，然后有了jquery/zpeto等js内库辅助丰富前端开发，然后到后来的做一些h5/nodejs的开发，然后到移动端兴起后，参与了多端的hybrid开发，然后又是小程序开发。也做过各种业务系统，如电商+ERP、配置系
小码哥
十年老程序员
粤ICP备2023052298号-1
