archko的专栏

桌面端不打算用kmp实现了,虽然已经完成了90%的工作,但运行效率是真不行.先是内存占用太大.其次是线程数太多,在mac上启动后53个线程,app本身就两三个,剩下的是jvm等的.最重要的是cpu居高不下,只要动一动就是立刻大涨,回落很慢.相比同类的比如fbreader,pdf expert这些,内存占用小,cpu使用率低,目前只有rust写的可以与之相比,所以打算用rust+slint写了.完成了50%了.android端还是进一步优化.

前面都介绍过解码,布局等现在介绍手势.桌面端。

到这里,主要的流程,控件,核心点都结束了.不太难,但是过程是艰辛的,遇到的问题不少.比如page分块遇到了分割线的问题,主要是图片,会在合并时有时比较明显.比如切边的解码问题,动态切边就是每加载一个page切一次,然后重新计算page的高宽.会导致页面变形,于是采用了后台切边所有的页面的方式.比如缩放手势与流畅性的问题,缩放如何保证page能正确绘制.手势结束后的惯性问题,也耗费不少精力与时间.

mupdf也可以解析tiff,它是整张图片全部载入,这必然受限于内存,最大测试过700m的,再大的就会取消解码,这是它代码限制的.我现在加入了tiff的解码器,目前测试过最大的tiff是3.9gb的,清明上河图是2.3gb的几个都测试过,lzw压缩的解码较慢,因为递归.其它都是非常快的,缩略图更是100多毫秒就出来了.下一篇来说明view的布局,手势,page的展示等相关内容.整个阅读器不算复杂,功能简练.使用中,性能比原来的,是差不多的.优点就是ui方面,基于新的框架,更适合现在的设计.

multiplatform中,旧的库不可用了.需要新的库,新的库,目前不算多,比起其它多平台略少了.这里介绍一些常用的.这两个网站搜索相应的库.

有so的aar,目前没有找到直接使用的方式,所以要么打一个jar不包含so,然后加一个dylib的引用,要么分开引用不同的包.目前我使用方式二,一个引用aar,一个引用jar,aar可以用mupdf官方的,手机端用.jar就只有自己弄了.对于java/kt程序员,要写一个高质量的桌面端应用,是个不错的选择.虽然我觉得性能与那些比要差一些,实际还好,compose以后性能还会提升的.相比swing,这个太旧,学习成本是比较大,而android程序员的话,成本比较低.有兴趣的人可以在github提pr.

compose multiplatform写一个简单的pdf阅读器,使用mupdf解析pdf.

多平台的框架不少,flutter,rust,每一个都是优点明显,缺点也明显.flutter的桌面端控件少,质量不一.dart语言丑陋又慢.我不喜欢它.rust,桌面gui不成熟,成熟一些的slint还是授权和qt一样,同一个团队部分成员做的.移动端更不用说了.难有大企业在支持tarui,主要是桌面,可是也基于webview,试用了一下体验不好.lua,支持多端,koreader是比较有名的,剩下估计用的不是太多,移动端的体验我觉得一般.本身也没有一个团队去推动多平台这事.