What could make the loading slow in android 4.1.X and not on 4.2?
I am using UrlImageViewHelper in order to load pictures in an adapterview.
My adapter is:
@Override
public View getView(int position, View convertView, ViewGroup parent) {
if(convertView==null){
convertView=new SquaredImageView(getContext());
}
SquaredImageView view= (SquaredImageView) convertView;
final long time=System.currentTimeMillis();
UrlImageViewHelper.setUrlDrawable(view,getItem(position).getLook_picture(),
R.drawable.placeholder_bkp, -1,new UrlImageViewCallback() {
@Override
public void onLoaded(ImageView imageView, Bitmap loadedBitmap,
String url, boolean loadedFromCache) {
Log.d(TAG,"time : "+ (System.currentTimeMillis()-time));
}
});
return view;
}
I am downloading and displaying large pictures (620x620 jpg) in a full width list. They are slow the first time it is downloaded/displayed. This problem is not anymore occuring after an upgrade to android 4.2. on HTC one.
I tried to profile the calls and I believe that during the very long calls, it hangs reading the socket inputstream.
Has anyone a clue as to why there is such a difference in performance between the two platforms?
Logcat outputs: (timings under 100 ms are usually duplicates)
android 4.1.2 Galaxy SIII mini
mostly above 1.5 sec. user needs to scroll items one by one to see the picture
On android 4.3 nexus 4:
consistently under 500 ms, list is usable
This has nothing to do with the OS running on the phone. The probable reason and the most possible one is the amount of RAM memory that is being consumed by other applications on the device. For testing purposes try running the same code on a new device that has not many apps running on it..
(I do not expect this answer to take the bounty)
UrlImageViewHelper uses HttpURLConnection to make the http calls to the web server serving the images. We have used HttpURLConnection (and tried most of the other classes to do http gets) we found it to be the least flaky (particularly on Android 2.3) of the generally flaky classes (eg the org.apache.http stuff etc). At one point I used a protocol analyser (tcpdump or tshark) on our web-server and found that the ACKs weren't coming back in a timely fashion, I think (this was over a year ago) I found more or less the same thing on WiFi and cell data (t-mobile GSM). I concluded there were low level problems in these classes, perhaps problems with Dalvik itself. Again, I don't expect this answer to take the bounty, I have not attempted to prove my assertions, I am merely recounting how far I got in my investigation a similar problem.
上一篇: JNLP，Webstart和Maven