Fresco的内存机制
Fresco是Facebook出品的高性能图片加载库，采用了Ashmem匿名共享内存机制, 来解决图片加载中的OOM问题。这里不对Fresco做深入分析，只关注Fresco在Android Bitmap的管理上采用了哪些黑科技。
Android的内存区域
Java Heap（Dalvik Heap），这部分的内存区域是由Dalvik虚拟机管理，通过Java中 new 关键字来申请一块新内存。这块区域的内存是由GC直接管理，能够自动回收内存。这块内存的大小会受到系统限制，当内存超过APP最大可用内存时会OOM
Native Heap，这部分内存区域是在C++中申请的，它不受限于APP的最大可用内存限制，而只是受限于设备的物理可用内存限制。它的缺点在于没有自动回收机制，只能通过C++语法来释放申请的内存
Ashmem（Android匿名共享内存），这部分内存类似于Native内存区，但是它是受Android系统底层管理的，当Android系统内存不足时，会回收Ashmem区域中状态是 unpin 的对象内存块，如果不希望对象被回收，可以通过 pin 来保护一个对象
Purgeable Bitmap
Ashmem一般在应用层中是无法直接访问的，除了几个特例之外。其中之一就是 decode bitmap ，我们可以通过设置 BitmapFactory.Optinons.inPurgeable = true 来创建一个 Purgeable Bitmap ，这样decode出来的bitmap是在Ashmem内存中，GC无法自动回收它。当该Bitmap在被使用时会被 pin 住，使用完之后就 unpin ，这样系统就可以在将来某一时间释放这部分内存。
如果一个 unpinned 的bitmap在之后又要被使用，系统会运行时又将它重新decode，但是这个decode操作是发生在UI线程中的有可能会造成掉帧现象，因此改做法已经被Google废弃掉，转为鼓励使用 inBitmap 来告知bitmap解码器去尝试使用已经存在的内存区域，新解码的bitmap会尝试去使用之前那张bitmap在heap中所占据的pixel data内存区域，而不是去问内存重新申请一块区域来存放bitmap。利用这种特性，即使是上千张的图片，也只会仅仅只需要占用屏幕所能够显示的图片数量的内存大小。
但是使用 inBitmap 需要注意几个限制条件：
在SDK 11 -> 18之间，重用的bitmap大小必须是一致的，例如给inBitmap赋值的图片大小为100-100，那么新申请的bitmap必须也为100-100才能够被重用。从SDK 19开始，新申请的bitmap大小必须小于或者等于已经赋值过的bitmap大小。 新申请的bitmap与旧的bitmap必须有相同的解码格式，例如大家都是8888的，如果前面的bitmap是8888，那么就不能支持4444与565格式的bitmap了。 我们可以创建一个包含多种典型可重用bitmap的对象池，这样后续的bitmap创建都能够找到合适的“模板”去进行重用。
Pin Bitmap
为了让inPurgeable的bitmap不被自动 unpinned ，可以通过使用jni函数 AndroidBitmap_lockPixels() 函数来强制 pin bitmap ，这样我们就可以在bitmap被使用时不会被系统自动 unpinned ，从而也就避免了 unpinned 的bitmap在重新被使用时又会被重新decode而引起的掉帧问题。同样的，Android也提供了 AndroidBitmap_unlockPixels() 来让bitmap重新变为 unpinned 状态，这样系统在内存不足时就可自动回收这部分内存
参考文献
Facebook tricks for image handling in Android
Introducing Fresco: A new image library for Android
------------------------------------------分割线-----------------------------------------------------------------
Fresco (Facebook图片加载器)
Fresco是Facebook开源的一个图片加载和管理库, 同类型的开源库市面有非常多,比如Picasso, Universal Image Loader, Glide, Volley.
而Fresco的最大特点在于,图片不在Java Heap上分配内存! 对,你没看错,困扰许多开发很久的爆Java Heap抛出OutOfMemoryError的无解难题看到了曙光!
那到底Fresco都把图片存到内存的那一片区域了呢?
答案是:Ashmem,匿名共享内存. 关于Ashmem的介绍,推荐看Android大牛罗升阳的这3篇技术Blog.
1. Android系统匿名共享内存Ashmem（Anonymous Shared Memory）简要介绍和学习计划
2. Android系统匿名共享内存Ashmem（Anonymous Shared Memory）驱动程序源代码分析
3. Android系统匿名共享内存Ashmem（Anonymous Shared Memory）在进程间共享的原理分析
Ashmem:
在Android系统里面,Ashmem这个区域的内存并不属于Java Heap,也不属于Native Heap.而Ashmem的使用,又有一点像Java的垃圾回收.
当Ashmem中的某个内存空间想要被释放的时候,会通过系统调用unpin来告知, 但实际上这块内存空间的数据并没有被真正的擦除;
当Android系统发现内存吃紧时,就会把unpin的内存空间利用起来去存储所需的数据;
而被unpin的内存空间,是可以被重新pin的,如果此时的该内存空间还没有被其他人使用的话,就节省了重新往Ashmem重新写入数据的过程了.
所以,Ashmem这个工作原理是一种延迟释放.
Bitmap在Ashmem中的使用
Ashmem内存区域是不能被Java应用直接使用的,但这其中有一些例外,而Bitmap是其中一个.
BitmapFactory.Options = new BitmapFactory.Options(); options.inPurgeable = true; Bitmap bitmap = BitmapFactory.decodeByteArray(jpeg, 0, jpeg.length, options);
Purgeable被设置成true以后,这个Bigmap就是保存在Ashmem内存区域中的,Java的垃圾回收是不能回收这篇区域的内存的.
当Android系统需要渲染这个Bitmap的时候,会调用pin,渲染完成后会调用unpin.而unpin后的内存空间表示能被其他人所使用.
如果被unpin的Bitmap需要重新渲染,系统会再次Decode这个Bitmap.而这个Decode的过程是在UI线程上完成的.所以Google后来废弃了这个pureable的参数.
后来Google提供了另外一个Flag,叫inBitmap.很遗憾的是,知道Android4.4后,这个新的Flag才得到完善.而Fresco致力于实现一个包括Android2.3以及以上的Android系统都能完美工作的图片加载管理开源库,因此Fresco放弃了使用inBitmap的解决方案.
Fresco是如何利用Ashmem去给Bitmap分配和管理内存?
上面说到的pin和unpin两个操作,对应的NDK调用是AndroidBitmap_lockPixels和unlockPixels.按照我们一惯认知,为了避免内存泄漏,这两者必须成对出现.而Fresco为了避免Bitmap再次渲染而导致的在UI线程Decode的过程,偏偏不在渲染完成后调用unlockPixels.
这做后,Fresco需要自己去管理这块内存区域,保证当这个Bitmap不再使用时,Ashmem的内存空间能被unpin.
而Fresco选择在Bitmap离开屏幕可视范围时候(onDetachWindow等时候),去做unpin.
Fresco还提供了哪些实用功能?
1. 加载和展示GIF,WebP;
2. 分别控制4个角的不同圆角;
3. 把图片切成圆形;
4. focusCrop,从指定的focus位置做类似centerCrop的scaleType;
5. 图片加载进度条,类似我们看新浪微博客户端GIF图片加载过程的那种进度,可自定义样式;
6. 点击加载失败的图片,可重新加载;
具体更多的能力提供,参考Fresco官方网页.
对比Fresco和Picasso
package com.example.garena.myapplication;
import android.content.Context;
import android.net.Uri;
import android.os.Bundle;
import android.support.v7.app.ActionBarActivity;
import android.view.LayoutInflater;
import android.view.Menu;
import android.view.MenuItem;
import android.view.View;
import android.view.ViewGroup;
import android.view.Window;
import android.widget.BaseAdapter;
import android.widget.ImageView;
import android.widget.ListView;
import android.widget.TextView;
import com.facebook.drawee.drawable.ScalingUtils;
import com.facebook.drawee.view.SimpleDraweeView;
import com.squareup.picasso.Picasso;
import java.util.ArrayList;
public class MainActivity extends ActionBarActivity {
private static final ArrayList<String> URL_LIST = new ArrayList<>();
static {
URL_LIST.add("http://upload.wikimedia.org/wikipedia/en/thumb/7/7a/Manchester_United_FC_crest.svg/1010px-Manchester_United_FC_crest.svg.png");
URL_LIST.add("http://www.newstylesports.com/wp-content/uploads/2014/09/Manchester-United-Salary-2014.jpg");
URL_LIST.add("http://www.businessofsoccer.com/wp-content/uploads/2013/06/Manchester-United-Logo-Full-HD-Wallpaper.jpg");
URL_LIST.add("http://createapk.com/project/2014/07/lightkretek/manchester-united-wallpapers/image/104267-manchester-united-wallpapers.jpg");
URL_LIST.add("http://i2.manchestereveningnews.co.uk/incoming/article339323.ece/alternates/s2197/Manchester-United.jpg");
URL_LIST.add("http://www.thedrum.com/uploads/drum_basic_article/156824/main_images/ManchesterUnitedLogo_0.png");
URL_LIST.add("http://www.manutd.com/~/media/7317FC0A0B9B4A8ABD47E29E8E47D5EA.ashx?w=2560&h=1600");
URL_LIST.add("http://niaje.com/wp-content/uploads/2015/02/manu.jpg");
URL_LIST.add("http://teamspictures.com/wp-content/uploads/2015/03/Manchester-united-Football-Club-Wallpaper.jpg");
URL_LIST.add("http://g.foolcdn.com/editorial/images/146745/manchester-united-stock_large.PNG");
URL_LIST.add("http://i2.mirror.co.uk/incoming/article4918329.ece/ALTERNATES/s1227b/Yeovil-v-Manchester-United.jpg");
URL_LIST.add("http://worldsoccertalk.com/wp-content/uploads/2014/01/manchester-united.jpg");
URL_LIST.add("http://i.dailymail.co.uk/i/pix/2014/09/03/1409773352229_wps_66_Cristiano_Ronaldo_of_Manc.jpg");
URL_LIST.add("http://i.guim.co.uk/static/w-620/h--/q-95/sys-images/Football/Pix/pictures/2014/10/5/1412513201728/Radamel-Falcao-celebrates-010.jpg");
URL_LIST.add("http://i.dailymail.co.uk/i/pix/2014/09/13/1410639943046_wps_18_MANCHESTER_ENGLAND_SEPTEM.jpg");
URL_LIST.add("http://www.manutd.com/sitecore/shell/~/media/CCE3892A29474CB7A126398691568B19.ashx?w=480&h=270&rgn=0,130,800,581");
URL_LIST.add("http://img.skysports.com/14/07/660x350/manchester-united-team-los-angeles-galaxy-la_3177246.jpg");
URL_LIST.add("http://i.dailymail.co.uk/i/pix/2014/08/02/1407019617274_wps_31_Manchester_United_defende.jpg");
URL_LIST.add("http://static.guim.co.uk/sys-images/Guardian/Pix/pictures/2013/11/27/1385582053011/Bayer-Leverkusen-v-Manche-002.jpg");
URL_LIST.add("http://www.simbasports.co.uk/wp-content/uploads/2013/08/Manchester-United.jpg");
URL_LIST.add("http://www.footballwood.com/wp-content/uploads/2014/07/Manchester-United-2014-pre-season-schedule-fixtures.jpg");
URL_LIST.add("https://lh5.googleusercontent.com/-HM991djPFX4/UTbiLMwiuNI/AAAAAAAAAFs/GFlG8v56TT0/w800-h800/Manchester%2BUnited%2Bin%2BNaruto%2BWallpaper.jpg");
}
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
getSupportActionBar().hide();
ListView listView = (ListView) findViewById(R.id.fresco_list_view);
Adapter adapter = new Adapter(this, URL_LIST);
listView.setAdapter(adapter);
adapter.notifyDataSetChanged();
}private static class Adapter extends BaseAdapter {
private final ArrayList<String> mUrlList;
private final LayoutInflater mInflater;
private final Context mContext;
public Adapter(Context context, ArrayList<String> urlList) {
mUrlList = urlList;
mInflater = (LayoutInflater) context.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
mContext = context;
}
@Override
public int getCount() {
return mUrlList.size();
}
@Override
public String getItem(int position) {
return mUrlList.get(position);
}
@Override
public long getItemId(int position) {
return 0;
}
@Override
public View getView(int position, View convertView, ViewGroup parent) {
ViewHolder viewHolder;
if (convertView == null) {
convertView = mInflater.inflate(R.layout.fresco_item, parent, false);
viewHolder = new ViewHolder(convertView);
convertView.setTag(viewHolder);
} else {
viewHolder = (ViewHolder) convertView.getTag();
}
Uri uri = Uri.parse(getItem(position));
// viewHolder.draweeView.setImageURI(uri);
// viewHolder.normalImageView.setVisibility(View.GONE);
Picasso.with(mContext).load(uri).into(viewHolder.normalImageView);
viewHolder.draweeView.setVisibility(View.GONE);
return convertView;
}
private static class ViewHolder {
private final SimpleDraweeView draweeView;
private final ImageView normalImageView;
public ViewHolder(View view) {
draweeView = (SimpleDraweeView) view.findViewById(R.id.fresco_image_view);
normalImageView = (ImageView) view.findViewById(R.id.normal_image_view);
}
}
}
}
上面是一个非常简单的Activity,一个ListView展示一个列表的网络图片.
Android2.3.7,Fresco:
Android2.3.7,Picasso:
Android4.4.4,Fresco:
Android4.4.4,Picasso:
Android5.1,Fresco:
Android5.1,Picasso:
从上面的对比中发现:
1. Android2.3.7,Fresco反而内存占用比Picasso高.
2. Android4.4.4,Fresco完胜Picasso,无论怎么滚动ListView展示图片,内存都是静止的一条直线.
3. Android5.1,Fresco和Picasso不相伯仲.这是因为Fresco没有使用Ashmem.
Fresco至于我的疑虑
最后,Fresco让我疑虑的一点是,粗略查看了Fresco提供的能力,貌似木有发现有类似Picasso.pauseTag和resumeTag的API.
这两个API对于scrolling的操作非常重要.当scrolling的时候,应该暂停图片的加载的线程,当滚动停止时才恢复图片加载的线程运行.