2014年7月19日

无题

一个同事走了。今天应该是头七。
跟他相识很早,那时他还是实习生。后来相忘于江湖,虽然还是同事,却基本没怎么打过交道。印象里始终是那个真诚的腼腆的大男孩。
这里是他最后的文字。其实每个心灵都有柔软的一面。
今天应该是头七,无以为祭。谨聆一曲『我用所有报答爱』,故人如歌。

2014年5月11日

我的又一个 fuse 客户端——upyunfs

我写 fuse 客户端可能有点上瘾,是因为我觉得对于在线存储类的服务,能够映射到本地存储,对用户来说是路径最短,学习成本最低、体验最友好的方式。而要实现类似的效果,据我所知要么用 fuse 把远端的存储挂载到本地(如 sshfs、amazon s3fs),要么写个后台服务实现本地和远端的双向同步(同步远端可以轮询或用某种 push 技术,同步本地可以用 inotify,典型案例是 dropbox)。而我之所以倾向前者,是因为 fuse 的实现成本要小很多,对于个人开发者来说性价比完胜。

有了上述前提,什么专门的 GUI 管理工具啦,专门的 shell 啦,在我看来都比较无聊——当远端的文件系统已经变成本地的一部分时,用户可以使用任意自己熟悉的文件管理工具(无论 GUI 还是 CLI),可以使用任意自己熟悉的 shell 环境(包括相应的各种工具),来完成对远端的文件管理任务。比如将 dropbox 同步到 upyun,在我看来只需要这样就可以了:
upyunfs -b lyman_foo ~/cloud/upyun # 挂载 upyunfs
rsync -avh ~/cloud/dropbox/ ~/cloud/upyun/ # 用 rsync 同步两个文件夹
所以看到 upyun 搞了开发者比赛的时候,我实在是忍不住,便写了这个 upyunfs

对实现细节不感兴趣的同学可以忽略下面的文字了,不过还是希望各位能给 upyunfs 投个票:到项目页面里找到 upyunfs-for-UPYUN,点击「投票」按钮即可。

接下来大概分析一下 upyunfs(以及类似存储系统)的实现要点。

一、技术选择

fuse 有各种语言的 binding,从执行效率角度考虑首选当然是 c/c++。但是如 upyun 这样提供 RESTful 接口的服务,用到字符串操作的地方不少,所以用脚本写起来更方便。python 的 binding 我试过一次,问题不少文档不多,所以我一直用 perl。

二、roadmap

  1. 基本功能
    这个阶段基本上只要做好 fuse 回调和 RESTful api 的映射就好了。具体一点,在线存储系统基本上必不可少的 upload/download/list 操作,大抵就可以对应到 fuse 的 read/write/getdir 上。此时如果有合手的 sdk,完成第一阶段会格外快。即使没有 sdk(这年头能直接提供 perl sdk 的公司实在是不多),用 libwww 实现一个也不复杂——像 upyun 官方的 python sdk 那样只包装了签名认证的,写一个也就个把小时。

    这一阶段的难点是 api 映射。因为 fuse 的回调基本上是标准的 unix 风格,文件需要先 open,read/write 之后再 release。了解 fuse 各个回调的语义及调用时机至关重要。如 upyun 并不支持带 offset、length  header 的 GET 操作(至少文档上没说),而 fuse read 每次被调用只读取 4k-128k 的片段,因此有必要将下载的远端内容缓存起来(阿里云的 oss 就可以无需如此)。同理,write 每次调用也是写一个片段,需要将写入远端的文件缓存起来,然后再一次性上传到远端。

    这一阶段完成后,基本的文件操作就都可以支持了。在网络条件很好的情况下也不会有太大的问题。
  2. 完善的功能
    这个阶段一是简化用户的使用,比如支持通过配置文件来读取用户名/密码/bucket;二是支持在线存储独有的功能,比如 upyun 对图片文件就可以通过配置一系列 x_gmkerl header 来改变上传行为。
  3. 优化
    这是个无底洞。根据使用场景不同,会有很多不同的策略和实现途径。

    比如在多数家庭网络条件下(adsl,下行带宽>>上行带宽),在 release 时的同步上传就会让 release block 颇久。而 gnome 3.12 在这种情况下是会死锁的。于是,对于使用 adsl 的 gnome 用户来说,release 就需要优化——比如通过线程来异步完成上传操作,而异步的引入会令数据一致性的维持变得复杂起来(目前 upyunfs 已经实现到这里)。

    再进一步,upyunfs 在第一次 read 文件的时候,就需要把整个文件从远端下载到内存中,如果用户的网络还要差,或者文件比较大,这会导致第一次 read 也 block 很久。那么是不是应该优化下载过程,把原来一句简单的 $respond = $ua->request($req) 替换成其它实现,可以不用等到整个文件下载完成才返回?

    再进一步,如果用户的内存不太够,是不是应该支持用户把读写 cache 设置成本地文件系统的一个临时目录?

    还有,对 fuse 回调实现,需要其行为多大程度上跟其 unix 同名 api 的语义一致?如 open、read 的时候是否需要参考诸如 O_TRUNC/O_NONBLOCK 这样的 flag?

    如上所述,这个阶段有太多的如果,而且每个点都不可避免的导致设计复杂或者代码激增,从而需要更多的投入。但不能否认,这些细节才是 upyunfs 是否成熟的标志。
ps. 给阿里云 oss 写的 ossfs 已经 outdated 了,测试用例挂了一堆,有空我会看下是不是 oss 有啥改动。

2014年5月9日

再见,delicious

曾几何时,delicious 就是在线书签的代名词。但是就在刚刚,我把自己的书签都搬到了 diigo

delicious 自 2003 年出现,2005 年被 yahoo! 收购,2010 年被 yahoo! 宣布关闭,2011 年被 avos 挽救,到今天,一直不死不活,苟延残喘,而我也一直坚持用它。

今天翻看自己的 delicious 页面,才发现丢了近一周的数据。大概是 5 月 4 日起,虽然 chrome 的插件、firefox 的插件在使用时没有抱怨什么,但新书签却再也没出现在我的 delicious 里。

理想不能当饭吃。

我对在线书签的要求也不高:能打标签,别人能订阅、支持主流浏览器足矣。在感受了 digg、pocket、google bookmark 和 diigo 之后,最终选择了 diigo(温馨提示,google bookmark 看起来很有步 google reader 后尘的感觉)。

彻底自由的做法,或许应该是通过自由的浏览器插件、手机客户端存储到本地,然后通过类似 dropbox、btsync 之类实现中央存储或者多点同步。只不过这么理想化的解决方式,在今天凡事都想被做成在线服务的大环境里,越发缺少生存的土壤。

祝 diigo 长命百岁吧。

2014年4月20日

Android 实现模糊效果的一些笔记

不知从 ios 的那个版本起有了毛玻璃效果,于是这东西就成了 Android UI 设计师们爱用的效果之一。实现这个效果,技术的核心是对图像的模糊处理。

当然,技术上需要做到什么程度,取决于要实现的效果如何。如果需要模糊的对象是固定的,而且是整个图像一起模糊掉,那么最简单的办法还是在开发阶段就计算好模糊的图片——photoshop 的滤镜能达到的效果永远比工程师重复发明轮子在用户手机上算要来的好。然后把这模糊图放在清晰图的上面,通过控制模糊图 ImageView 的透明度来实现渐变毛玻璃效果。在布局不是特别复杂的情况下,这样做的效率还可以接受(实在想优化的话就自己在 Canvas 上画吧)。

如果需要在手机端计算模糊图,那么这篇文章这篇文章是很好的补习资料,常见的 Box blur 和 Gaussian blur 的原理讲的很清楚。实际上,Gaussian blur 因为涉及的基本都是浮点计算,执行时间是 Box blur 的数倍。以 note2 为例,自行计算一张 radius=16 的 720x1280 的 Gaussian blur 图片,Java 版本需要约 1 分钟,c++ 版本最快也要约 20 秒(纯 cpu 单线程,多线程的边界情况处理器来很麻烦所以没折腾成),而 Box blur 同样的图片虽然可以在几秒内完成,但对于某类图片(比如带明显横竖条纹的)的模糊效果非常差,即使两次 Box blur 出来的效果也还是差强人意。自行实现模糊的另一个要命的问题是内存。例如 StackOverflow 的这个 FastBlur 答案(很多讲模糊文章都引用了这个答案),虽然速度上还不错,但是内存消耗的实在是有点粗放,只适合做小图片处理。

据说 API 17 以上 Android 提供了 RenderScript 来可以利用 GPU 做模糊计算。去年底的时候我参考这篇折腾过,不过没成功。一是 API 17 这个门槛实在是高(貌似通过 android-support-v8 也可以,但也非常折腾),二是 RenderScript 调试起来实在困难。总之 RenderScript 这条路我没走通。前阵子又有一篇文章带了示例代码,有兴趣的同学可以继续尝试。需要注意的是像这种高大上的解决方案,兼容性有待验证(Android 设备的又一个命门)。但是这篇文章末尾提到的先 scale down 再模糊的想法很聪明——当时我仅尝试了直接 scale down 然后拉伸显示,效果惨不忍睹,于是就没有朝这个方向做更多努力,可能 scale down 之后再模糊一遍效果会好很多——实际上,在资源受限的设备上,很多时候工程师就是在功能、效果和速度之间在玩平衡游戏。

2014年4月8日

Android 应用卸载监控的实现方法

不再主业折腾 Android 了,这段时间会陆续把之前折腾过的东西记录一下,免得日后忘记。

对于产品经理和运营来说,知道哪个用户,什么时候,为什么会卸载你的 app 可能是很重要的事。虽然我觉得挺扯蛋——看看国内那些应用在卸载时弹出的页面,可选原因 12345,列的比用户想的都全面周到——这分明就是在说,我也知道自己干了很多坏事让你们不爽,可我干的坏事是如此之多以至于我实在弄不清你们的底线在哪里。

好吧,在我朝可以有理想,但是不能太理想主义。所以本文只从技术角度讨论一些实现细节。

首先来看这篇文章,基本勾勒出了实现卸载监控所需的技术框架。这篇文章有以下几个关键字:

  • JNI
    Android 应用被卸载之前,其运行实例就会被停止掉。因此必须要有代码能够脱离应用的生命周期管理。这个入口就是 JNI。进入 c 的世界,想象空间完全不是 Android API 可以比拟。
  • fork
    对于卸载监控这个需求来说,JNI 是入口,为的就是进入 fork 这一环。fork 本身是比 Java 更为历史悠久的系统调用,在这里负责生成监控进程,是整个逻辑中非常关键的一环。至少要把 fork 示例的执行逻辑搞懂(系统补习的话当然是建议读 APUE 相关章节,后面 exec 也会用到)。
  • inotify
    Linux 特有的文件监控 api,IBM 这篇介绍的很好。
  • UserSerial
    这个是 Android 4.2+ 引入的安全机制,原文说的很清楚,这里不再赘述。
但是这篇文章的实现方案两个明显不足:
  • fork 出来的进程仍旧是一个带着 dalvik 的庞大进程(内存 20MiB+)
  • 通过进程父子关系较容易找到卸载监控进程
所以,针对上述不足,可以继续改良实现方案:
  • exec
    将 inotify 部分的逻辑抽离到独立的可执行文件中,fork 出来的监控进程,可以通过 exec 这个独立的可执行文件来将自己变成一个非常轻量级的监控进程(内存占用只有 KiB 级别),同时也可以通过参数将伪装自己的进程名字。其实 fork + exec 的组合在传统的 unix 多进程编程中非常常见。
  • 两次 fork
    为了断绝父子进程关系,可以通过两次 fork 的技巧。主进程 A 通过 JNI 调用,进行第一次 fork,其父进程 A 继续运行,子进程 B 调用 exec 成为监控进程。监控进程 B 再进行一次 fork,父进程 B 直接退出,子进程 C 执行 inotify 逻辑监控 app 目录。由于进程 C 的父进程 B 直接退出,进程 C 将直接成为 init 的子进程,进程 C 和原始进程 A 之间看不到明显的关联关系。
上述技术环节打通之后,剩下的就是细节的打磨了。下面这些问题都比较简单,或是影响较小。考虑到我厂在黑科技上的投入,恕不巨细无遗了。

  • inotify 是面向 inode 的。当可执行文件在运行中被删除,inode 还在不在?会触发哪些 inotify 事件?文件夹呢?所以监控哪个目录,选择哪个 inotify 事件其实还是挺有讲究的事情。这些问题追到底其实很考较对 Linux 文件子系统的理解。
  • 如何将运行时参数(比如用户 id)传递给监控进程?监控进程既然已经跟主进程没有任何关系,那么在监控进程孤悬海外期间,主进程的用户 id 变化了怎么办?
  • 覆盖安装、升级时候的误判怎么办?360 某应用的方案竟然是在反馈页面中直接加了个『我在升级/重装』的选项,挺有意思。
  • 应该在主进程的哪个时间点启动监控进程?在 thread 中执行了 fork 会怎么样?fork 过的进程中线程还都在吗?fork 执行时父进程是个 Android 进程,而 Android 进程都是从 zygote 进程 fork 出来的。这样的进程直接 fork 会有问题吗?zygote 都做了些什么事让 fork 可能存在风险?
  • 如何避免多个监控进程同时存在?
  • 默认 ndk-build 编译出来的可执行文件 stdin/stdout/stderr 都被重定向到了 /dev/null,非常不利于调试,怎么办?