Android volley framework and androidvolley framework
The younger brother is very lazy and does not like to write these summaries, mainly because his presentation skills are limited. If you want to share volley-related information, please refer to my github.Volley
Learning and progress together
1. Add url parameters in Volley and form requests. You need to splice your own string or rewrite the getUrl method.
StringBuilder sb = new StringBuilder(); if (!url.contains("?")) { url = url + "?"; } else { if (!url.endsWith("?")) { url = url + "&"; } } Iterator<String> iterotor = paramsMap.keySet().iterator(); while (iterotor.hasNext()) { String key = (String) iterotor.next(); try { sb.append(key).append("=").append(URLEncoder.encode(paramsMap.get(key), "utf-8")).append("&"); } catch (UnsupportedEncodingException e) { e.printStackTrace(); } } if (sb.lastIndexOf("&") == sb.length() - 1) { sb.deleteCharAt(sb.length() - 1); }
Add parameters in post to override the getParams method of Requst, or customize the request
@Override protected Map<String, String> getParams() throws AuthFailureError { ParamsEngine engine = new ParamsEngine(mContext); Map<String, String> p = engine.generateRequestParams(paramsMap); return p; }
2. Volley can only process network requests and cache network requests when loading local images. However, the request and response architectures are also suitable for Asynchronously loading local and local files. All network requests are obtained by the BasicNetwork. It is the core of Volley. In the initiate mrequest method, all requests are converted to the corresponding response and handed over to the NetworkDispatcher for scheduling. We only need to judge the request url. If it starts with a slash (/) or a file, it can be processed as a local file, and the response is put back in the form of a local parsing stream. At the same time, set shouldCahce in the request to false because the local file already exists locally, the Code is as follows:
String urlString = request. getUrl (); if (urlString. trim (). toLowerCase (). startsWith ("file") {try {// if the local image is loaded, do not put the request in the disk-cache directory. setShouldCache (false); return new NetworkResponse (getFromFile (new URI (urlString ). getPath ();} catch (URISyntaxException e) {e. printStackTrace () ;}} else if (urlString. trim (). toLowerCase (). startsWith ("/") {request. setShouldCache (false); return new NetworkResponse (getFromFile (urlString ));}
The getFromFile method converts a file to a byte array. You can refer to the method for converting entity in volley.
Private byte [] getFromFile (String urlString) throws IOException {File file = new File (urlString); PoolingByteArrayOutputStream bytes = new PoolingByteArrayOutputStream (mPool, (int) file. length (); byte [] buffer = null; // obtain the input stream InputStream in = null; try {buffer = mPool. getBuf (1024); in = new FileInputStream (new File (urlString); int count; while (count = in. read (buffer ))! =-1) {bytes. write (buffer, 0, count);} return bytes. toByteArray ();} finally {if (in! = Null) {try {in. close ();} catch (IOException e) {e. printStackTrace () ;}} mPool. returnBuf (buffer); try {bytes. close ();} catch (IOException e) {e. printStackTrace ();}}}
Here ByteArrayPool is used to avoid repeated byte [] array space applications
3. DiskBasedCache initialization in Volley is very slow. In the initialize method, All cached files are traversed, And the read header information is stored in the map. When there are many cached files, the initialization implementation provided by google takes more than 10 s !!! I don't know if this is a bug. That is to say, each newRequestQueue takes 10 seconds to start processing the request. In this case, this framework cannot be used. At present, I have not found a good method. There are two optimization solutions. (1) Someone mentioned this problem in stackoverflow and then gave a solution. In initialize, set BufferedOutputStream to FileOutputStream. I tested it and the speed has increased by 10 times. The initialization time can basically be controlled within 1-3 s. (2) initialize the SDK in advance. Every newRequestQueue initialization takes such a long time. But in actual use, do we need so many new RequestQueue? As you can see from the source code, each RequestQueue actually starts five cyclic threads to schedule various requests. Four of them are used to process network requests and one is used to process cache requests. This is enough for an app. We do not need to start a RequestQueue on every page. Therefore, I set RequestQueue as a singleton and initialize it in the Application so that initialize can be called repeatedly and data can be prepared before the interface is displayed.