LCFinder 0.2.0 Beta 开发日志
2018年10月15日 · 3213 字 · 阅读
2018-11-27
微软应用商店好多 BUG,“已安装”界面里的操作按钮还是英文的、应用页面里的截图点击没有反应、点击查看评价后是空白的。
2018-11-25
UWP 应用审核需要大约三天的时间,上次的提交没有验证通过,原因是隐私政策页面链接无效,在编辑应用信息时才发现自己忘记改链接了,这次提交顺便补上了英文版的介绍内容,等几天看看能不能通过验证。
准备添加英文版的项目主页,有点纠结该如何整,像 LCUI 那样买个 lcfinder.org 域名来放英文版页面的话有点浪费钱;弄成 cn 和 en 路径的话又多了次跳转,不直接;手写 js 代码用 vue + vue-i18n 实现单页多语言切换的话会增加开发成本,挺麻烦的。最终决定只用英文版,反正就那么几行英文,大多数人也就是看看截图,点击下载链接,顺便砍掉下面的功能介绍和未来计划,懒得整翻译,等以后再加内容。
2018-11-21
在生成 LCUI 时即使手动指定了静态库,vcpkg 也还会去链接它的动态库,看上去只是 libxml2 和 zlib 有问题。要解决这个问题只能临时移除 vcpkg 集成,然而生成 LCFinder 时又要安装 vcpkg 集成,因为需要链接 leveldb、sqlite 库,搞起来比较麻烦。
vcpkg 会在生成 LCUI 时链接一堆动态库,增加了文件数和空间占用,不符合我个人偏好,而且 libxml2 里用不到的功能太多,又不能裁剪掉,所以现在的 LCUI 还是用自己手动编译的依赖库。
2018-10-24
对文件列表的渲染流程做了一些调整,采用类似于生产者消费者的工作模式,大致如下:
- 文件扫描线程在每扫描完一批文件后,将它们追加到线程安全的暂存区中
- 取消视图同步线程,改用定时器来实现文件列表渲染,每隔 200 毫秒从暂存区取出全部文件数据,然后追加到视图中
所有 UI 操作都在主线程上进行,可以避免因资源不同步而导致的内存访问越界的问题。
接下来是调整缩略图视图组件,在加载缩略图时清空内容很容易出错,需要把一些操作移动到主线程上。
2018-10-20
用 Dr.Memory 检测内存泄漏问题时,会输出一些来自 UnQLite 的错误,例如:
~~Dr.M~~ Error #4: UNINITIALIZED READ: reading register eax
~~Dr.M~~ # 0 unqlite.dll!SyRandomness [c:\users\lc\documents\github\unqlite\unqlite.c:30381]
~~Dr.M~~ # 1 unqlite.dll!unqlitePagerOpen [c:\users\lc\documents\github\unqlite\unqlite.c:57810]
~~Dr.M~~ # 2 unqlite.dll!unqliteInitDatabase [c:\users\lc\documents\github\unqlite\unqlite.c:4120]
~~Dr.M~~ # 3 unqlite.dll!unqlite_open [c:\users\lc\documents\github\unqlite\unqlite.c:4342]
~~Dr.M~~ # 4 KERNEL32.dll!BaseThreadInitThunk +0x23 (0x76928484 <KERNEL32.dll+0x18484>)
~~Dr.M~~ Note: @0:00:11.229 in thread 29492
~~Dr.M~~ Note: instruction: movzx 0x02(%eax,%ecx) -> %eax
~~Dr.M~~
~~Dr.M~~ Error #5: UNINITIALIZED READ: reading register eax
~~Dr.M~~ # 0 unqlite.dll!SyRandomness [c:\users\lc\documents\github\unqlite\unqlite.c:30381]
~~Dr.M~~ # 1 unqlite.dll!unqlitePagerOpen [c:\users\lc\documents\github\unqlite\unqlite.c:57810]
~~Dr.M~~ # 2 unqlite.dll!unqliteInitDatabase [c:\users\lc\documents\github\unqlite\unqlite.c:4120]
~~Dr.M~~ # 3 unqlite.dll!unqlite_open [c:\users\lc\documents\github\unqlite\unqlite.c:4342]
~~Dr.M~~ # 4 KERNEL32.dll!BaseThreadInitThunk +0x23 (0x76928484 <KERNEL32.dll+0x18484>)
~~Dr.M~~ Note: @0:00:11.235 in thread 29492
~~Dr.M~~ Note: instruction: mov %bl -> 0x02(%eax,%ecx)
这堆内容很碍眼,我只想关注自己程序的问题,于是就看了下它的文档,据说可以用 -suppress
参数指定一个文件,只需在这个文件里写上需要屏蔽的错误即可,内容格式可以参考它的安装目录里的 suppress-default.txt
文件。
2018-10-15
LevelDB 的数据库文件不是单个文件,获取占用空间和移除文件不能用 stat() 和 remove() 来实现。LevelDB 有提供 leveldb_approximate_sizes() 函数来获取大致的大小,但在看了他的文档和示例代码后,还是不知道这函数的参数是什么意思,start 和 limit 里的 a z 表示什么?
StartPhase("approximate_sizes");
{
int i;
int n = 20000;
char keybuf[100];
char valbuf[100];
uint64_t sizes[2];
const char* start[2] = { "a", "k00000000000000010000" };
size_t start_len[2] = { 1, 21 };
const char* limit[2] = { "k00000000000000010000", "z" };
size_t limit_len[2] = { 21, 1 };
leveldb_writeoptions_set_sync(woptions, 0);
for (i = 0; i < n; i++) {
snprintf(keybuf, sizeof(keybuf), "k%020d", i);
snprintf(valbuf, sizeof(valbuf), "v%020d", i);
leveldb_put(db, woptions, keybuf, strlen(keybuf), valbuf, strlen(valbuf),
&err);
CheckNoError(err);
}
leveldb_approximate_sizes(db, 2, start, start_len, limit, limit_len, sizes);
CheckCondition(sizes[0] > 0);
CheckCondition(sizes[1] > 0);
}
就算不用 leveldb_approximate_sizes() 也可以自己手动遍历文件累加大小,至于移除数据库,可以用 leveldb_destroy_db()。
leveldb 产生的 ldb 文件太多,大小都是 401KB,一个文件装不了多少张的缩略图,需要调整数据文件大小。他的头文件里有给出 leveldb_options_set_max_file_size(),但 vcpkg 提供的是 bitcoin-core 的 leveldb,没有这个函数,算了,懒得自己编译 google 的 leveldb,文件数太多也不算大问题。
文章版权归作者所有,未经许可不得转载。