爱上修改源码-----修改libgd源码有感

        最近做的PDF阅读器被boss骂了一顿,说是“架构失败!”。不过也是,能够把更多的逻辑放到NDK里面就应该放嘛~

        于是乎,开始忙着移植GD库。首选的是libgd,因为这个库很轻很适合在嵌入式设备上跑。但是今天忙了一天,才把一个png图片显示在android模拟器上,不是因为这个库很难懂,也不是因为libgd需要和libpng才能显示png图片,而是因为透明度的问题。

        Java里面bitmap的格式支持ARGB8888,意思就是一个整数表示一个像素,每个像素由ARGB四个byte组成,分别表示透明度,R值,G值,B值。同样,或者说凑巧,libgd默认的像素格式也是ARGB8888,于是乎我就直接把libgd的数据返回给java,然后填充到bitmap里面去,可是,一直看不到图片。。。。。

        一开始以为是字节顺序问题,比较inter的字节顺序是小端顺序,java虚拟机是大端顺序。其实,想想就知道了,在NDK返回的整数,在java里面拿到的是意义上一样的整数,所以,虚拟机已经考虑了字节顺序问题了。

        那问题在哪里呢?

        问题出现在透明度上!libgd的透明度0表示不透明,255表示透明,这个跟java的ARGB8888格式刚好相反!

        原因找到了,问题就很好解决了。在拷贝数据的时候把每个像素的透明度用255减一下?

        如果是昨天的我,我会以为这样很方便啊,两重for循环就把问题解决了。可是,效率呢???

        终于,硬着头皮想办法找更高效更合理的办法。修改源码!每次,我直接找到了加载png图片的时候的代码,并找到了一个函数:gdTrueColorAlpha,这个函数是组装ARGB的地方,于是在这里,把透明度处理一下就好了。问题从头到尾的解决了!

        在使用源码的时候,由于我们贪图便宜,贪图方便,不愿意去仔细看看源码,更不用说修改源码,总想着在上层能够把问题解决就解决算了,可是,效率何在呢?开源库的设计者在设计和开发的时候,并没有考虑到所有的使用环境,也就是说不能保证所有情况下都有好的效率,所以,在自己使用的特定环境下,应该尽量优化开源代码,直接研究源码,修改源码,这样才能够深入学习源码,才能够在学习源码的过程中体会库的设计和架构!

你可能感兴趣的:(android/NDK)