详细讲解Android中使用LoaderManager加载数据的方法
Android的设计之中,任何耗时的操作都不能放在UI主线程之中。所以类似于网络操作等等耗时的操作都需要使用异步的实现。而在ContentProvider之中,也有可能存在耗时的操作(当查询的数据量很大的时候),这个时候我们也需要使用异步的调用来完成数据的查询。
当使用异步的query的时候,我们就需要使用LoaderManager了。使用LoaderManager就可以在不阻塞UI主线程的情况下完成数据的加载。
(1)获取loaderManger:activity.getLoaderManager()
(2)loaderManager的事件回调接口,LoaderManager.LoaderCallbacks<D>
下面是一个demo,从contentprovider中query数据添加到listview中,是异步执行的。
MySQLiteOpenHeleper.java:
packagecom.app.loadermanager; importandroid.content.Context; importandroid.database.sqlite.SQLiteDatabase; importandroid.database.sqlite.SQLiteDatabase.CursorFactory; importandroid.database.sqlite.SQLiteOpenHelper; publicclassMySQLiteOpenHelperextendsSQLiteOpenHelper{ publicstaticfinalStringdb_name="test.db3"; publicstaticfinalintversion=1; publicMySQLiteOpenHelper(Contextcontext){ super(context,db_name,null,version); } @Override publicvoidonCreate(SQLiteDatabasedb){ Stringcreate_sql="createtabletb_student(_idintegerprimarykeyautoincrement,namevarchar(20),ageinteger)"; db.execSQL(create_sql); } @Override publicvoidonUpgrade(SQLiteDatabasedb,intoldVersion,intnewVersion){ } }
MyContentProvider.java
packagecom.app.loadermanager; importandroid.content.ContentProvider; importandroid.content.ContentUris; importandroid.content.ContentValues; importandroid.content.UriMatcher; importandroid.database.Cursor; importandroid.database.sqlite.SQLiteDatabase; importandroid.net.Uri; publicclassMyContentProviderextendsContentProvider{ privateMySQLiteOpenHelperhelper=null; privatestaticfinalUriMatchermatcher=newUriMatcher( UriMatcher.NO_MATCH); privatestaticfinalintstudents=1; static{ matcher.addURI("com.app.contentprovider","tb_student",students); } @Override publicintdelete(Uriarg0,Stringarg1,String[]arg2){ return0; } @Override publicStringgetType(Uriarg0){ returnnull; } @Override publicUriinsert(Uriuri,ContentValuesvalues){ SQLiteDatabasedb=helper.getWritableDatabase(); intflag=matcher.match(uri); switch(flag){ casestudents: longid=db.insert("tb_student",null,values); returnContentUris.withAppendedId(uri,id); } returnnull; } @Override publicbooleanonCreate(){ helper=newMySQLiteOpenHelper(this.getContext()); returntrue; } @Override publicCursorquery(Uriuri,String[]projection,Stringselection, String[]selectionArgs,StringsortOrder){ SQLiteDatabasedb=helper.getWritableDatabase(); Cursorcursor=db.query("tb_student",projection,selection,selectionArgs,null,null,null); returncursor; } @Override publicintupdate(Uriuri,ContentValuesvalues,Stringselection, String[]selectionArgs){ return0; } }
MainActivity.java:
packagecom.app.loadermanager; importjava.util.ArrayList; importandroid.annotation.SuppressLint; importandroid.app.Activity; importandroid.app.LoaderManager; importandroid.content.CursorLoader; importandroid.content.Loader; importandroid.database.Cursor; importandroid.net.Uri; importandroid.os.Bundle; importandroid.widget.ArrayAdapter; importandroid.widget.ListView; @SuppressLint("NewApi") publicclassMainActivityextendsActivityimplements LoaderManager.LoaderCallbacks<Cursor>{ LoaderManagermanager=null; ListViewlistView=null; @SuppressLint("NewApi") @Override protectedvoidonCreate(BundlesavedInstanceState){ super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); listView=(ListView)this.findViewById(R.id.listview); manager=this.getLoaderManager(); manager.initLoader(1000,null,this); } @Override publicLoader<Cursor>onCreateLoader(intid,Bundlebundle){ CursorLoaderloader=newCursorLoader(this, Uri.parse("content://com.app.contentprovider"),null,null, null,null); returnloader; } @Override publicvoidonLoadFinished(Loader<Cursor>loader,Cursorcursor){ ArrayList<String>al=newArrayList<String>(); while(cursor.moveToNext()){ Stringname=cursor.getString(cursor.getColumnIndex("name")); al.add(name); } ArrayAdapteradapter=newArrayAdapter(this,android.R.layout.simple_list_item_1,al); listView.setAdapter(adapter); adapter.notifyDataSetChanged(); } @Override publicvoidonLoaderReset(Loader<Cursor>loader){ } }
LoaderManager与生命周期
Activity和Fragment都拥有getLoaderManager的方法,其实Fragment的getLoaderManager去获取的就是Activity所管理的众多LoaderManager之一。
1.Who标签
先来看一下Activity的getLoaderManager方法:
LoaderManagerImplgetLoaderManager(Stringwho,booleanstarted,booleancreate){ if(mAllLoaderManagers==null){ mAllLoaderManagers=newArrayMap<String,LoaderManagerImpl>(); } LoaderManagerImpllm=mAllLoaderManagers.get(who); if(lm==null){ if(create){ lm=newLoaderManagerImpl(who,this,started); mAllLoaderManagers.put(who,lm); } }else{ lm.updateActivity(this); } returnlm; }
mAllLoaderManagers保存着一个Activity所拥有的所有LoaderManager,其key为String类型的who变量。若从Activity调用getLoaderManager,那么所得LoaderManager的who标签为(root):
publicLoaderManagergetLoaderManager(){ if(mLoaderManager!=null){ returnmLoaderManager; } mCheckedForLoaderManager=true; mLoaderManager=getLoaderManager("(root)",mLoadersStarted,true); returnmLoaderManager; }
若从Fragment中使用getLoaderManager,则所得LoaderManager的who标签会根据Fragment的层级不同而不同,在Activity中处于最顶级的Fragment的who标签为:
android:fragment:X
X为序号。
而属于Fragment的Fragment所活的的LoaderManagerwho标签就成为了:
android:fragment:X:Y
甚至更大的深度。
2.LoaderManager状态量mLoadersStarted
在开篇分析的时候分析过LoaderManager内部保存了一个mStarted状态,很多操作会根据这个状态做不同处理。通过上边的分析也能看出,Fragment中获取LoaderManager最终是通过Activity获取的,在LoaderManager构造时,就将一个状态量mLoadersStarted传递了进去,这个状态量交给LoaderManager自行管理。
而无论是Fragment还是Activity,都有mLoadersStarted这样一个状态量,在onStart生命周期后为true,onStop后为false。所以在onStart生命周期后做initLoader操作就会使Loader一经初始化就开始运行了。
3.Fragment和Activity的生命周期
Fragment和Activity能够对LoaderManager产生影响的生命周期是一样的。
onStart
系统在onStart阶段会获取LoaderManager,如果成功获取,则调用LoaderManager的doStart(),这里需要特别说明的是,虽然所有LoaderManager都是保存在Activity中,但是在Activity的onStart生命周期其也只是会获取属于自己的(root)标签LoaderManager,而并不是将所有保存在mAllLoaderManagers里的Manager全部遍历一遍。
onStop(performStop)
处于onStop生命周期,但是系统内部是通过performStop调用的。在这里,同样会获取属于自己的LoaderManager,如果Activity是因为配置改变出发的onStop(旋转屏幕),则调用LoaderManager的doRetain()接口,如果不是,就调用LoaderManager的doStop()接口。
onDestroy(performDestroy)
调用LoaderManager的doDestroy()接口销毁LoaderManager。
4.LoaderManager的生命周期
因为LoaderManager与Fragment/Activity的生命周期紧密相连,所以想要用好LoaderManager就必须了解其自身的生命周期,这样就能把握数据的完整变化规律了。
正常的从出生到销毁:
doStart()->doReportStart()->doStop()->doDestroy()
Activity配置发生变化:
doStart()->doRetain()->finishRetain()->doReportStart()->doStart()->doStop()->doDestroy()
Fragment在onDestroyView()之后还会执行LoaderManager的doReportNextStart(),即:
doStart()->doRetain()->doReportNextStart()->finishRetain()->doReportStart()->doStart()->doStop()->doDestroy()
doStart()会将LoaderManager中保存的所有Loader都启动。最终是运行每一个Loader的onStartLoading()方法。只要是通过initLoader使用过的Loader都会记录在LoaderManager的mLoaders中,那么问题来了:
怎样在Fragment/Activity不销毁的前提下从LoaderManager中移除某个使用过的Loader呢?
答案就是使用LoaderManager的接口去除指定ID的Loader:
publicvoiddestroyLoader(intid)
这样就能在mLoaders中移除掉了,下次onStart的时候就没有这个Loader什么事了。
doReportStart()。如果Fragment上一次在销毁并重做,而且数据有效的话会在这里主动上报数据,最终走到callback的onLoadFinished中。
doStop()会停止mLoaders保存的所有Loader。最终是运行每一个Loader的onStopLoading()方法。
doDestroy()会清空所有有效和无效Loader,LoaderManager中不再存在任何Loader。
doRetain()会将LoaderManager的mRetaining状态置位true,并且保存retain时LoaderInfo的mStarted状态
finishRetain()如果之前所保存的mStarted与现在的不一样而且新的状态是停止的话,就停止掉这个Loader。否则若有数据并且不是要下次再上报(没有calldoReportNextStart)的话就上报给callback的onLoadFinished。
doReportNextStart(),根据第6条,已经能够理解了。当Fragment执行到onDestroyView生命周期时,对自己的LoaderManager发出请求:即使现在有数据也不要进行上报,等我重做再到onStart生命周期时再给我。