代码优化

1、引言 岁月真是个养猪场，这几年，人胖了，微信代码也翻了。 记得 14 年转岗来微信时，用自己笔记本编译微信工程才十来分钟。如今用公司配的 17 年款 27-inch iMac 编译要接近半小时；偶然间更新完代码，又莫名其妙需要全新编译。在这么低的编译效率下，开发心情受到严重影响。 于是年初我向上头请示，优化微信编译效率，上头也同意了。 学习交流： - 即时通讯/推送技术开发交流5群： 215477170 [推荐] - 移动端IM开发入门文章：《 新手入门一篇就够：从零开发移动端IM 》 （本文同步发布于： http://www.52im.net/thread-2873-1-1.html ） 2、相关文章 《 微信团队分享：微信移动端的全文检索多音字问题解决方案 》 《 微信团队分享：iOS版微信的高性能通用key-value组件技术实践 》 《 微信团队分享：iOS版微信是如何防止特殊字符导致的炸群、APP崩溃的？ 》 《 微信团队原创分享：iOS版微信的内存监控系统技术实践 》 《 iOS后台唤醒实战：微信收款到账语音提醒技术总结 》 《 微信团队分享：微信Android版小视频编码填过的那些坑 》 《 微信手机端的本地数据全文检索优化之路 》 《 微信团队披露：微信界面卡死超级bug“15。。。。”的来龙去脉 》 《 微信客户端团队负责人技术访谈

队名 八组评分了吗 组长博客链接（2分） 组员1李昕晖（组长） 过去两天完成了哪些任务 文字/口头描述 12月9号了解各个小组的进度与难以攻破的地方，晚上安排开会，安排新的冲刺任务。 重新分配小组及个人任务。 展示GitHub当日代码/文档签入记录 接下来的计划 优化软件界面 还剩下哪些任务 希望能让界面好看点 燃尽图 遇到了哪些困难 界面不太好搞 有哪些收获和疑问 学会了及时去了解大家的进度并更改任务分配，尽量让每一个人都有事可做。 要及时了解到每一个人任务的难点，并在大方向上给大家一个明确的目标。 任务分配均匀的疑问需要去请教其他的组长。 组员2王怀骋 过去两天完成了哪些任务 文字/口头描述 对java语言进行学习， 继续对微信接口进行学习，对运用方面进行学习。 接下来的计划 继续学习java语言，不断尝试， 对接口方面进一步学习，不断尝试 还剩下哪些任务 了解与其他模块的合作方法 燃尽图 遇到了哪些困难 时间紧，学习进度有点跟不上计划， 学习方面，运用还是不足，具体学习，知识还是有挺多欠缺，需要百度和查看博客来补缺补漏。 有哪些收获和疑问 学习了API调用和JAVA入门， 未来要对如何学习新语言，新知识和新技术这方面进行思考，要更快，更系统性的学习这些，同时不缺少计划性，不影响到其他的安排 组员3张伟佳（组员） 过去两天完成了哪些任务 文字/口头描述 地图功能完善

一、基本任务：代码编写 + 单元测试 1、GitHub 地址： https://github.com/Wegnery/New_WordCount 2、PSP2.1 表格 PSP2.1 PSP 阶段 预估耗时 （分钟） 实际耗时 （分钟） Planning 计划 5 5 · Estimate · 估计这个任务需要多少时间 5 10 Development 开发 260 350 · Analysis · 需求分析 ( 包括学习新技术 ) 20 25 · Design Spec · 生成设计文档 —— —— · Design Review · 设计复审 ( 和同事审核设计文档 ) —— —— · Coding Standard · 代码规范 ( 为目前的开发制定合适的规范 ) 20 30 · Design · 具体设计 30 30 · Coding · 具体编码 180 200 · Code Review · 代码复审 30 60 · Test · 测试（自我测试，修改代码，提交修改） 60 60 Reporting 报告 60 75 · Test Report · 测试报告 30 30 · Size Measurement · 计算工作量 5 5 · Postmortem & Process Improvement Plan · 事后总结 , 并提出过程改进计划 30 25 合计

webpack打包的体积越小，对于部署应用的网站来说，性能越好，加载速度越快。 1. 分析打包文件 1. 生成统计信息文件 首先需要通过webpack命令生成统计信息的文件。在package.json的脚本中添加命令 "scripts": { "stats": "webpack --config webpack.prod.js --profile --json > stats.json", //... } 上面的命令会在根目录下生成一个stats.json的打包统计信息文件。 2. 可视化分析 使用插件可视化分析插件：webpack-bundle-analyzer npm install --save-dev webpack-bundle-analyzer 配置插件的使用信息； const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin; module.export = { //... plugins: [ new BundleAnalyzerPlugin({ analyzerMode: 'disabled', // 关闭默认启动的展示信息的http服务器 generateStatsFile: true // 打包的时候生成stats.json文件； }), }

我们的项目随着组件的加入，首次加载的js文件越来越大，用户等待时间越来越长；之前想着使用webpack的splitCoding来解决，看了webpack的官方文档可以配置 optimization的 moduleIds这个属性来将node_modules中的公用的库的代码提取出来，如果代码没有变化，那么就不会改变文件的hash值，但是我用的是vue的nuxt框架，设置这个属性后每次build还是会生成新的hash值，每次用户都还是会下载新的文件，而我们的项目又会经常部署，显然这个方案不行； 最后我只能加一些比较大的库像threejs，phaser，videojs等直接加载.min.js文件，加载完后在执行相关的代码， 还有一些则是采用js的动态加载方案 ，最后将项目的代码的首次加载时间控制在1-2秒左右，体验效果好了很多！！ 来源： https://www.cnblogs.com/wlinglinux/p/12022460.html

队名 八组评分了吗 组长博客链接（2分） 组员1李昕晖（组长） 过去两天完成了哪些任务 文字/口头描述 了解各个小组的进度与难以攻破的地方，晚上安排开会，安排新的冲刺任务。 重新分配小组及个人任务。 展示GitHub当日代码/文档签入记录 接下来的计划 优化软件界面 还剩下哪些任务 希望能让界面好看点 燃尽图 遇到了哪些困难 界面不太好搞 有哪些收获和疑问 学会了及时去了解大家的进度并更改任务分配，尽量让每一个人都有事可做。 要及时了解到每一个人任务的难点，并在大方向上给大家一个明确的目标。 任务分配均匀的疑问需要去请教其他的组长。 组员2王怀骋 过去两天完成了哪些任务 文字/口头描述 对java语言进行学习， 继续对微信接口进行学习，对运用方面进行学习。 接下来的计划 继续学习java语言，不断尝试， 对接口方面进一步学习，不断尝试 还剩下哪些任务 了解与其他模块的合作方法 燃尽图 遇到了哪些困难 时间紧，学习进度有点跟不上计划， 学习方面，运用还是不足，具体学习，知识还是有挺多欠缺，需要百度和查看博客来补缺补漏。 有哪些收获和疑问 学习了API调用和JAVA入门， 未来要对如何学习新语言，新知识和新技术这方面进行思考，要更快，更系统性的学习这些，同时不缺少计划性，不影响到其他的安排 组员3张伟佳（组员） 过去两天完成了哪些任务 文字/口头描述 地图功能完善

字节跳动这家公司，应该是所有秋招的公司中，对算法最重视的一个了，每次面试基本都会让你手撕算法，今天这篇文章就记录下当时被问到的几个算法题，并且每个算法题我都 详细 着给出了 最优解 ，下面再现当时的面试场景。看完一定让你有所收获 一、小牛试刀：有效括号 大部分情况下，面试官都会问一个不怎么难的问题，不过你千万别太开心，因为这道题往往可以拓展出更多有难度的问题，或者一道题看起来很简单，但是给出最优解，确实很不容易的。这道题是这样的 给定一个只包括 '('，')'的字符串，判断字符串是否有效。注：空字符串属于有效字符串 示例 1: 输入: "(())" 输出: true 实例 2： 输入: "())(" 输出: false 复制代码 第一眼看到这道题，我去，这么简单，稳了（因为一面的时候，刚刚被面试官怼过 勇者斗恶龙 的DP题，在 leetcdoe 属于 hard 级别）。 其实这道题的 leetcode 第 20 题的 简化版 ，属于 easy 级别 于是我也不假思索直接用 栈 来解决了，相信 99% 都会用栈解决吧？这里我稍微说以下过程吧，步骤如下： 1、在遍历字符串的过程中，遇到 "(" 就让它入栈，遇到 ")" 就判断下栈里面有没有 "(" ： （1）、如果有，则把处于栈顶的 "(" 弹出，相当于和 ")" 进行匹配，然后继续往后遍历字符串 （2）、如果没有，则匹配失败

1. 代码相关 遇到性能问题，首先应该做的是检查否与业务代码相关——不是通过阅读代码解决问题，而是通过日志或代码，排除掉一些与业务代码相关的低级错误。 性能优化的最佳位置，是应用内部。 譬如，查看业务日志，检查日志内容里是否有大量的报错产生，应用层、框架层的一些性能问题，大多数都能从日志里找到端倪（日志级别设置不合理，导致线上疯狂打日志）；再者，检查代码的主要逻辑，如 for 循环的不合理使用、NPE、正则表达式、数学计算等常见的一些问题，都可以通过简单地修改代码修复问题。 **别动辄就把性能优化和缓存、异步化、JVM 调优等名词挂钩，复杂问题可能会有简单解，「二八原则」在性能优化的领域里里依然有效。**当然了，了解一些基本的「代码常用踩坑点」，可以加速我们问题分析思路的过程，从 CPU、内存、JVM 等分析到的一些瓶颈点优化思路，也有可能在代码这里体现出来。 下面是一些高频的，容易造成性能问题的编码要点。 1）正则表达式非常消耗 CPU（如贪婪模式可能会引起回溯），慎用字符串的 split()、replaceAll() 等方法；正则表达式表达式一定预编译。 2）String.intern() 在低版本（Java 1.6 以及之前）的 JDK 上使用，可能会造成方法区（永久代）内存溢出。在高版本 JDK 中，如果 string pool 设置太小而缓存的字符串过多

volatile是一个类型修饰符（type specifier），就像我们熟悉的const一样，它是被设计用来修饰被不同线程访问和修改的变量；volatile的作用是作为指令关键字，确保本条指令不会因编译器的优化而省略，且要求每次直接读值。 volatile的变量是说这变量可能会被意想不到地改变，这样，编译器就不会去假设这个变量的值了。 作用 编辑 简单地说就是防止编译器对代码进行优化。比如如下程序： 1XBYTE[2]=0x55; 2XBYTE[2]=0x56; 3XBYTE[2]=0x57; 4XBYTE[2]=0x58; 对外部硬件而言，上述四条语句分别表示不同的操作，会产生四种不同的动作，但是编译器却会对上述四条语句进行优化，认为只有XBYTE[2]=0x58（即忽略前三条语句，只产生一条机器代码）。如果键入volatile，则编译器会逐一地进行编译并产生相应的机器代码（产生四条代码）。 例子 编辑 精确地说就是，优化器在用到这个变量时必须每次都小心地重新读取这个变量的值，而不是使用保存在寄存器里的备份。下面是volatile变量的几个例子： 1）并行设备的硬件寄存器（如：状态寄存器） 2）一个中断服务子程序中会访问到的非自动变量（Non-automatic variables) 3）多线程应用中被几个任务共享的变量 这是区分C程序员和嵌入式系统程序员的最基本的问题

feat： 新增feature fix: 修复bug docs: 仅仅修改了文档，比如README, CHANGELOG, CONTRIBUTE等等 style: 仅仅修改了空格、格式缩进、都好等等，不改变代码逻辑 refactor: 代码重构，没有加新功能或者修复bug perf: 优化相关，比如提升性能、体验 test: 测试用例，包括单元测试、集成测试等 chore: 改变构建流程、或者增加依赖库、工具等 revert: 回滚到上一个版本 来源： CSDN 作者： coding_crazy 链接： https://blog.csdn.net/coding_crazy/article/details/103523153