fresco开篇

看了一下距离上一篇15年12月15号的文章竟然已经过去了半年。

这半年博主经历了一次更换公司,于是被随之而来的找工作找房子找室友折磨的头疼,而且由于单身狗属性,还不得不为了找女票而分心。

而近一个月,公司又在赶直播项目基本是10106,真心弄得比较累。直到最近才开始闲下来。

因此算不得懒惰,只能说生活里琐碎的事情太多了。


说说技术上吧,我之前花了很多精力在react native,插件化上面。

react native,自从产出了那几篇源码文章以及写了一个非常简单的demo之后,几乎就没怎么再继续学习了。

原因:

1 或许我对于写javascript本身就有些抵触。

2 react native的坑实在太深。react+javascrip core+native,各种js线程,native线程,我不确定当性能出了问题之后我有能力进行改进。

3 就性能来说,和native还有差异。

4 更新迭代太快,不够稳定。我司基本没几个前端,如果我花业余时间去跟进react-native,时间成本实在太高。

5 weex的冲击。

不过稀土掘金的react-native板块倒是有不少干货,喜欢react-native的朋友可以继续关注。


插件化基本由于同样的原因(在我司没什么应用,我也没有继续深入学习。

不过在现在的公司,我们使用了mvp架构,有机会把mvp的一些实践分享一下。


废话不多说,下面我会开一个fresco的系列。毕竟fresco大家应该用的很多了,而且fresco实在是一个复杂和优秀极了的图片库。


一篇介绍fresco的文章。需翻墙。

https://code.facebook.com/posts/366199913563917/introducing-fresco-a-new-image-library-for-android/

对应的翻译。翻译的水平不敢恭维。

http://blog.csdn.net/bboyfeiyu/article/details/44943959


我做点总结吧。内容来自这篇文章,正确性不敢保证。

一 fresco解决图片内存的方法。

android有三种可操作的内存区java堆(大小被限制,垃圾回收时候由于要stop the world因此会带来卡顿),native堆(大小不受限,但需手动控制内存难度较高),ashmem堆(弱内存释放模式,只有系统内存不够用时才会回收这块内存)。
其中ashmem堆不能被java应用直接处理,但可以被bitmap应用。方法是设置BitmapFactory.Options.inPurgeable = true,这样可清除的Bitmap会驻留在 Ashmem 堆中。不管发生什么,垃圾回收器都不会自动回收这些 Bitmap。当Android绘制系统在渲染这些图片,Android的系统库就会把这些Bitmap从Ashmem堆中抽取出来,而当渲染结束后,这些Bitmap又会被放回到原来的位置。如果一个被抽取的图片需要再绘制一次,系统仅仅需要把它解码一次,这个操作非常迅速。然而bitmap的解码操作是运行在ui线程的,而这显然会带来ui卡顿。

fresco的设计者选择了ashmem堆来存储bitmap,那么就要解决由于“第二次”读取该图片进行解码操作带来的卡顿
它们的解决方法很简单。不让图片被允许“再绘制”,这样就不会被”解码”,自然就不会卡顿。也就是说。If we pinned the memory in advance, off the UI thread, and made sure it was never unpinned, then we could keep the images in ashmem but not suffer the UI stalls. 
即把内存锁住就好了。只调用AndroidBitmap_lockPixels,而不去调用unlock.
这也就要求程序员来负责销毁这部分在ashmem的内存。

fresco使用了facebook的智能指针来负责销毁内存。FacebookCore.addReference deleteReference。
  //截止到今天 我还没有验证这块内容的正确性。

二 fresco的数据流设计。//后面的文章重点介绍


三 fresco异步框架的设计。
java异步类一般使用的是future类。然而在表现图片的连续loading的时候表现力不够,因为future只有两个结果。
因此,fresco实现了一套DataSource,DetaSubscriber,Executor框架。 //后面的文章重点介绍

其它:

fb实现了AnimatedDrawable来更好的支持动画。
fb实现了mvc架构来实现图片显示。 //后面的文章重点介绍

ok,这就是我的这篇fresco开篇。
敬请期待后面的系列文章。






评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值