hotfix

消息 HOOK 原理： 1. 用户输入消息，消息被放到系统消息队列。 2. 程序发生了某些需要获取输入的事件，就从系统消息队列拿出消息放到程序消息队列中。 3. 应用程序检测到有新的消息进入到程序消息队列中后，调用相应的事件去处理该消息。 所以在系统消息队列与程序消息队列的中间安装 hook，即可获取消息队列中的信息。 安装： SetWindowsHookEx（键盘消息（WH_xxx），Hook函数（处理键盘输入的函数），句柄（hook函数所在的DLL的句柄），线程ID（要hook的线程ID，0为所有线程）） API在简单高效的同时也有一个弊端，就是它只能监视较少的消息，如：击键消息、鼠标移动消息、窗口消息。 SEH(调试) HOOK 原理：与调试器工作方式类似，让进程发生异常，然后自己捕获到异常，对于除于被调试状态下的级进行操作。 1. 正常情况下，进程未被其他进程调试时，当进程发生异常事件，系统将捕获该事件，并进行事件处理。 2. 当进程被其他进程调试时，处理该进程的异常事件的工作则交给了调试进程。（调试进程未处理或不关心的调试事件由系统处理） 3. 调试 HOOK的核心思路就是将API的第一个字节修改为0xCC（INT 3，留给调试工具的中断，调试工具运行完后，会将下一条指令手动替换回原先的代码），当API被调用时，由于触发了异常，控制权就被转交给调试器（调试进程）。

3 月，跳不动了？>>> 关于分支 分支种类 master 主分支 master主分支始终保持稳定的可发布版本 只有项目组主程才拥有master主分支的管理权限（例如其他分支合并到master必须由主程操作） dev 开发分支 dev开发分支为不稳定版本，可能存在功能缺失，但已有的功能必须是完整的 原则上不允许直接在dev分支上进行功能开发，必须新建feature分支进行开发 hotfix-[问题名称 | bug编号] 紧急热修复分支 从master分支创建，横线后面跟上问题名称或者对应的bug编号，仅仅适用于 生产线问题紧急修复 ！！！！ 修复完成，测试通过，合并到master和dev分支上，然后将此分支删除 feature-[功能名称] 功能开发分支 从dev分支创建，横线后跟功能名称，用于新功能开发，每天下班前push提交到远程 开发完成以后，在远程发起向dev分支的合并请求，由指定的CodeReview人员审查通过以后进行合并，并删除该分支 bugfix-[bug编号] 问题修复分支 从dev分支创建，用于修改测试提出的bug，横线后跟bug编号 修复以后，在远程发起向dev分支的合并请求，并指定提交者自身（或其他人）作为CodeReview，合并以后删除该分支 refactor-[重构名称] 重构分支 从dev分支创建，用于代码的 重大规模重构

3 月，跳不动了？>>> ET5.0支持服务器热更，可以在服务器运行时更新代码。 目前服务器运行时，VS2017重新生成Hotfix项目的解决方案由于文件占用无法生成Hotfix.dll，导致无法热更 解决： 1.保证服务器已经生成解决方案 2.在Unity端运行服务器，然后修改服务器端Hotfix模块的代码 3.在VS2017打开 生成->配置管理器，修改如下 4.然后选择在VS2017的解决方案资源管理器，选择重新生成hotfix 5.此时应该只会生成Hotfix.dll 6. 然后就能在Unity发送热更消息，服务器就能热更了 来源： oschina 链接： https://my.oschina.net/u/4454895/blog/3198346

3 月，跳不动了？>>> 前些日子，监控显示线上偶尔发生请求两秒超时的情况。解决这个问题前前后后花了不少时间，也走了一些弯路。这里记录下来备忘。 前期分析 首先需要了解一下我们的服务： 我们的服务是一组无状态的前端服务器加上有状态的后端存储层。 这些服务都部署在腾讯云黑石服务器上面。 第一件事是要定位问题出现在前端还是后端。通过日志，我们发现在出错时间段里，每个前端服务器都有报错，并且出错请求都是发往同一后端服务器的。由此可见，问题出现在后端服务上。 接下来，需要分析出错的特征。通过日志发现错误都是因为前端两秒超时导致，而后端在前端超时之后事实上是完成了请求。因为是存储服务，我们自然在第一时间就查看了磁盘的情况。果然，在出错时，磁盘的 io.util 非常高( sar -dp 的输出，从第4列开始分别是 tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util )： 需要注意的是： io.util非常高，且只持续了2~3秒 几乎所有盘的io.util都高 io的tps和吞吐并不高 另外，还发现了另外一个规律：单台机器，大概每12小时左右会出现io.util高，并伴随着超时出错： 问题排查 快速排查 我们做了一些快速排查，试图以比较小的代价找到问题的根源： 查看系统的定时任务 查看系统日志 查看存储服务代码中的定时任务 可惜

我们已经从SVN 切换到Git很多年了，现在几乎所有的项目都在使用Github管理, 本篇文章讲一下为什么使用Git, 以及如何在团队中正确使用。 Git的优点 Git的优点很多，但是这里只列出我认为非常突出的几点。 由于是分布式，所有本地库包含了远程库的所有内容。 优秀的分支模型，打分支以及合并分支，机器方便。 快速，在这个时间就是金钱的时代，Git由于代码都在本地，打分支和合并分支机器快速，使用个SVN的能深刻体会到这种优势。 感兴趣的，可以去看一下Git本身的设计，内在的架构体现了很多的优势，不愧是出资天才程序员Linus (Linux之父) 之手 版本管理的挑战 虽然有这么优秀的版本管理工具，但是我们面对版本管理的时候，依然有非常大得挑战，我们都知道大家工作在同一个仓库上，那么彼此的代码协作必然带来很多问题和挑战，如下： 如何开始一个Feature的开发，而不影响别的Feature？ 由于很容易创建新分支，分支多了如何管理，时间久了，如何知道每个分支是干什么的？ 哪些分支已经合并回了主干？ 如何进行Release的管理？开始一个Release的时候如何冻结Feature, 如何在Prepare Release的时候，开发人员可以继续开发新的功能？ 线上代码出Bug了，如何快速修复？而且修复的代码要包含到开发人员的分支以及下一个Release?

本人使用的是VS2019和Unity2019.3.0f6版本.net3.1，导入ET5.0项目后，我们来实现如何服务器代码热更. 申明：因为ET5.0原版本使用热更无法正常使用，所以修改了部分源码，至于以后ET作者是否会修复完整，导致现在修改的项目是否冲突暂不可知. 打开服务器工程 方案一（改动大） ： 1.在入口类Program的Main函数中为Game.Scene添加MailBoxComponent组件 Game.Scene.AddComponent<MailBoxComponent>(); 2.找到C2M_ReloadHandler类，改为 [MessageHandler] public class C2M_ReloadHandler : AMRpcHandler<C2M_Reload, M2C_Reload> { protected override async ETTask Run(Session session, C2M_Reload request, M2C_Reload response, Action reply) { if (!(request.Account == "XXX" && request.Password == "XXX")) { Log.Error($"error reload account and password: {MongoHelper

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 转至： https://mp.weixin.qq.com/s/0LVj1IcWMWAuUeY6U7r4hg 阿里妹导读：技术主管，又叫「技术经理」，英文一般是 Tech Leader ，简称 TL。随着工作经验的不断积累，能力的不断提升，每个人都有机会成为Team Leader。然而在机会到来前，我们必须提前做好准备，对TL的工作职责有一定了解。当然，这也会为当下更好地配合TL工作打下基础。 今天，阿里巴巴高级技术专家云狄将结合自己多年的经验，从开发规范、开发流程、技术规划与管理三个角度出发，分享对技术TL这一角色的理解与思考，欢迎一起探讨交流。 「技术主管」是开发团队中的某位程序员需要对一起创建系统的整个开发团队负责时所承担的角色。通常他既要对最终交付的软件系统负责，另外也会像一个程序员一样去开发实现系统。 一个技术主管的 60% ～ 70% 的时间可能花在了开发任务分解分配、开发实践、技术架构评审、代码审核和风险识别上，而余下的 30% ～ 40% 的时间则花在为了保障系统按时交付所需的各种计划、协作、沟通、管理上。和团队管理者不同的是，技术主管的大部分管理工作都是针对具体研发任务和技术事务的。 接下来基于我在技术TL这个角色上，在开发规范、开发流程、技术管理与规划等方面我的一些心路历程，和大家共勉。