LC-Finder 0.2.0 Beta 开发日志

发表于2018年10月15日

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

对文件列表的渲染流程做了一些调整,采用类似于生产者消费者的工作模式,大致如下:

  1. 文件扫描线程在每扫描完一批文件后,将它们追加到线程安全的暂存区中
  2. 取消视图同步线程,改用定时器来实现文件列表渲染,每隔 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,文件数太多也不算大问题。

对此文章有疑问?你可以点击此链接反馈你的问题