archko的专栏

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

阅读器完善的差不多.发现mupdf还有一些工具,放到移动端中也是可以用的.只是没有mutool这么强.今天主要涉及加密,解密,修改字体等功能。

前面的文章主要在应用端.本文主要是针对文本重排,从mupdf的导出文本到应用端对这个文本再重排.尽量保持原文的格式方面作些说明.文本重排,对于扫描版,目前不考虑,因为图片的ocr准确度不好,而且要ocr,当前的主流机型一页消耗时间太长.所以只考虑非扫描版,可以用mupdf直接导出文本的.

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

现在基于谷歌购买的pdf解析库的更多一些. 著名的就是 AndroidPdfViewer. 因为之前分析过AndroidPdfViewer的源码,java部分,要去修改它比较困难,尤其offset的计算.所以现在有了这个库,按page去分页的.设计上要好一些.如果要省体积,可以使用系统的pdfrender,但是解码部分需要大改,现在的解码它先缓存page,可是系统api不允许,当前页面未关闭,就去加载下一页就崩溃.做完完整的app后,想做一个lib,像pdfium这样的,外部可以直接集成的库。

剩下绘制这些代码不变.key简化了,因为涂鸦在一个图片上可能会产生很多点,尤其不是画直线,是画曲线,点的数量比较可观,尽量减少整个点的存储量.画一笔可能几十个点.原作者是保存在图片上,我想在pdf上画,我不想保存在图片上面,所以我保存在json的串里面,可以随时恢复.因为我不想编辑pdf,pdf是一个成品,不建议编辑.要站在牛人的肩膀上,这是做人做事的非常重要的法则.只要合适,合道德,我们应该参考别人的代码.程序员是这世上最善良的人群,写好文档,就怕别人看不懂.这里增加了个方法,点也增加了两个.

解析大tiff,png并显示

在浏览目录时,长按菜单,出现相册功能.按时间倒序排列查看.与pdf一样,所有的照片默认是同一个宽.不像barteksc它们都是保留原始宽,这样滑动后,可能容易内容滑出去了.这不是一个阅读器的好的体验方式.因为中间有一张特别宽的图片,会导致内容经常滑出去.这段代码,处理了超长图片,比如全景图片,进行缩放,因为在实际使用过程,如果不处理,会出现3000*500这样的图片,或者更大,导致内存溢出崩溃,draw时会有异常出现.所以针对 1080宽高作了一次缩放.图片太大,滚动起来也很慢,主要还是draw的问题.

mupdf不支持直接的多线程.multithread.c我也没看明白,android直接调用多线程就会莫名其妙的事,要么崩溃,要么渲染出的页面不对.pdfium倒是可以直接多线程.但是解码速度要慢不少.

需要string作缓存key,能读取,且能根据容量把最早未访问的清除出缓存队列.

图片的切边操作有时是比较有用的.看着舒服多了,页面间的空白如果比较大的图片在显示上,需要缩放,缩放后通常滚动会有偏移.这里先说算法思路.

前文介绍如何使用图片生成pdf,这里介绍如何使用文本生成pdf。

前面的文章都是如何展示pdf,这篇关于如何生成pdf文件.

barteksc/PdfiumAndroid 这个源码被,引用的次数是比较高的,flutter的几个pdf库也是引用它.它使用福昕的开源sdk.福昕阅读器我早期的时候用,交互一般,渲染也不如mupdf,有些pdf中文显示不了,体积小点.checkLinkTapped处理的是页面点击.点击是调用了sdk的mapRectToDevice,这个操作是在jni处理的,外部传入点击的位置,返回的是LinkTapEvent,同样包含uri或目标页。

继续分析源码。

上文基于recyclerview修改,没有自定义layoutmanager,其实并不是一个好的阅读器,缩放功能有限,放大了容易内存溢出.本文,从修改vudroid源码来完成一个阅读器.它是基于view系统的相对完整的功能代码没有那么抽象,简洁容易修改功能没有完善,有修改空间可以容易做一个sdk对外提供原作者ebookdroid更好,基于opengl实现的,修改更麻烦,代码非常抽象.已经是一个完整的项目,各项功能都完善了,也没有修改的必要.

recyclerview的滑动并不是像ios那样,有很好的惯性,针对此,从ebookdroid中拿了flinger,因为recyclerview不能直接修改scroller,所以只有修改源码了,换了包名,避免冲突.先找到点击的view,然后得到它与屏幕偏移量,找到偏移量,可以得到它在页面上的偏移量,通过缩放因子,得到最后在页面上的点击区域.点击区域确定后,去查看页面上有没有对应区域的链接,链接目前支持url与目标页码两种。点击上半页,向下滚动,点击下半页,向上滚动.点击中间区域,显示当前的页码.

之前的文章,分享了几个开源的库,如果要作一个完善的pdf库,需要的工作比较多,除了阅读功能,还有文件浏览器,历史记录,标注等一系列的事.有些场景则不需要这些,比如很多app会嵌入一个pdf阅读器,常见的是股票软件,它的财报是pdf的,这时只要展示出来,能滚动,缩放就足够,甚至可以不需要大纲导航,跳转到某一页.当然也不需要曝光,背景,切割这些功能.pdfiumandroid相关的库因为谷歌收购的原因,变的人尽皆知,原开始阅读器的作者不维护,可能因为工作关系,时间关系.但从它的派生出来的库非常多

然后运行:./gradlew publishMupdfPublicationToMavenLocal 就可以发布了.发完在自己工程最外的build.gradle加入mavenLocal()仓库,就可以引用到了,加两处.其它文件如gradle.properties,gradle目录,gradlew从别的工程弄过来就可以了.建一个mupdf_c目录,名字自己取,在里面git下载mupdf源码,把目录修改为libmupdf。因为mupdf编译的体积不小,之前也发过编译的文章,现在更新一下.

pdf已经使用很普遍了,android上的好用的pdf工具也有不少,个人更经常是用于阅读,很少标记,所以有一个适合的阅读器对我来说非常重要了.自己写一个阅读器是不是太闲了,市面上有静读天下,ebookdroid都是非常优秀的阅读器,只不过对于来说,需求没匹配上,因为我读了几百上千本书,还有很多没有读的,需要一个好的文件浏览器,ebookdroid本来是很好的,但滚动上有问题,横竖切换有bug一直没有更新了.静读天下是基于pdfmaster,有些pdf的中文显示不了.