爱上修改源码-----修改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的地方，于是在这里，把透明度处理一下就好了。问题从头到尾的解决了！

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