最近想写一个轻巧的日志库。在google搜索有关高性能日志的实现原理。 大多认为用mmap技术可以避免由内核到用户态的页交换。而且当进程崩溃时,内核保证mmap的内存最终都能写入磁盘（但具体啥时候程序已经不可控）。 有人认为日志库的一大特性就是顺序写，读/写缺页依然要中断，mmap与fwrite在这方面性能相差无几。 以下是我在v2ex提的帖子，反对使用mmap的理由较多 mmap相比于fwrite写日志，是否有性能优势 原文: https://lizijie.github.io/2021/07/31/mmap-%E7%9B%B8%E6%AF%94%E4%BA%8E-fwrite-%E5%86%99%E6%97%A5%E5%BF%97-%E6%98%AF%E5%90%A...

需求 答题系统,允许角色每天最多答对N道题目。 如果当天题库数量大于N，则要求当天答对的题目不能再出现。 糟糕的代码 以下是生成题目ID的实现大致如下，主要问题是作者没有想到很好的去重办法， 侥幸以为只要尽可能多的循环次数（2倍题库数量），来降低题目再次出现的概率，然而重复的题目还是出现了，这段糟糕的代码才“有幸”见于诸位。 lua代码 -- tQuestSave 记录当天答对题目 -- iQuestListSize 题库的数量 function GenQuestId(tQuestSave, iQuestListSize) local iTargetQuestId = -1 for i = 1, iQuestListSize * 2, 1 do i...

本文并非介绍框架设计。只是想通过这个案例，单地表述解决本文问题思路。 基于上一篇《生成赛事对阵图-排序》，得到小区归总有序的前16名信息 [TOC] 问题 让前4名有机会同时出现在冠军赛和季军赛 其它情况随机分组 已知 保证集合有序,且长度>=16 解决 借鉴Knuth-Durstenfeld Shuffle的算法思路，本算法特别之处在于保打乱局部范围的元素，最终令相邻的元素在一个分组。决定打乱哪些元素由外层指定，如打乱奇数位的元素，则传入{1,3,5,7,9,11,13,15} 1. 满足需求1和2 1.1 第2名交换到索引9的位置，即第5组 1.2 第3名交换到索引5的位置，即第3组 1.3 第4名交换到索引13的位置，即第7...

本文并非介绍框架设计。只是想通过这个案例，单地表述解决本文问题思路。 [TOC] 问题 有一个大区（跨服）玩法，各小区积分归总后的前16名可以参加后续的淘汰赛。 #已知 各个小区榜均已排序 归总后的数据长度>=16 解决 借鉴选择排序的思路，但由于各个集合本身有序，所以无需遍历各个集合求最大值。另外只需要归总后最高的16名，所以不需要对所有集合排序。 每次从N个有序集中，选出一个最大值 由于是有序集，后面的元素不可能比之前的大，所以已被选取的索引，之后不需要再被遍历，tOffsetMap记录各个集合最后的索引位置 Lua代码 math.randomseed(os.time()) local function sortset(s, n) ...

[TOC] 新人容易忘记要先设计GameView分辨率大小再开发界面。 从技术层面，我想一个解决办法是，分辨率默在配置表中定义，当首次打开Unity工程时，GameView默认使用这个分辨率。 翻了UnityEditor源码，发现其并不开放设置GameView窗口的接口。于是写了以下代码，尝试通过修改其配置文件GameView.asset,window下文件大概在C:/Users/YOUR_USER_NAME/AppData/Roaming/Unity/Editor-5.x/Preferences。同时Unity也不开放其内部YAML的序列化接口，于使用了AssetStore的第三库YamlDotNet。但YamlDotNet的输出内容，Unity原生的YAML格式，有一下差...

[TOC] 思考问题要从问题的原点出发，套用某个方案是解决问题的错误思路。我写这个主题，是因为大多数人（包括我也是），在解决问题时，常常不经过具体的分析/验证，就贸然使用那些被“吹得牛B哄哄”的解决方案，如程序滥用插件和第三方库，策划抄需求。 按《金字塔原理 》书中的理论，解决目标问题Root，其实是自上而下解决N个子问题（树的深度）的决策树，其特点是重权越大的子问题越在高位，即被优先考虑/解决。 对比套用方案的思路，无疑是一个逆过程，即自下而上，重要的子问题没被优先考虑。最终可能导致目标Root妥协，迎合不是最优的解决方案，令目标Root偏离最初的原意。 不做分析的原因可能有以下几种： 项目进度紧张，没时间做。 对复杂问题。可能是知识/技能不足以分析/解决子问题（...

[TOC] 吐槽别人代码乱，在程序里多见不怪。细心就会发现这些吐槽行为并不是单向，被吐槽者往往也能收集到足够的“证据”/“建议”吐槽别人的代码很烂。 吐槽经常是发生在接手（离职/休假）代码时，这不是（离职/休假）时情绪亢奋写的代码龙飞凤舞。我认为烂代码是演变而来的，非一蹴而就（后面说明）。如果问题是普遍存在的，那么问题就不是个意外或特例。至于不将烂代码说出来无非是”有技术涵养”和“彼此理解”。而说出来则是可能因为经历太少人少轻狂、或是甩锅或是恶意攻击…. 问题规模小，可能需要少量或不根本不需要程序设计，大家一看代码就轻松明白，这种代码很难被定义为烂代码。然而需求的增加和叠加各种非技术问题，好代码就会大概率演变为烂代码。 常说“下层解决上层建筑“”。烂框架就会生出烂代码。好的...