Developing for Android, IV: The Rules: Networking

推荐整理分享Developing for Android, IV: The Rules: Networking，希望有所帮助，仅作参考，欢迎阅读内容。

文章相关热门搜索词:,内容如对您有帮助，希望把文章链接给更多的朋友！

This section covers practices around network behavior of applications.

Sending data to and from the cloud is one of the largest consumers of battery. The problem is not that any particular network transaction kills the device, but rather the sheer number of background applications and services making these requests and the side effect on the inability of the device to sleep (or for the radio to enter low power mode) for any reasonable length of time causes a significant drain on the battery in general. If you don’t need the data immediately, don’t get it. If you need the data sometime in the future, batch it up with other system requests with JobScheduler or GCM Network Manager.

Here are some general tips for avoiding over-syncing:

When a server request fails, use exponential back-off techniques to avoid hammering the server with constant, repeated requests. Also, never synchronize against wall-clock time to avoid problems with the server being hit by large loads at these absolute times.

When making network calls, be sure to call NetworkInfo.isConnected() to ensure connectivity.

Also, it is not possible to know when or if a network request will actually succeed, which is yet another good reason to not make network requests on the UI thread or in other places requiring fast or synchronous behavior.

The Develop for the Low End rule in the Performance chapter is as true for network performance as it is for raw device hardware performance. If your application is dependent upon network performance for content (such as a video or music application), then you should develop on a device that has a slower network connection, just to understand the implications in markets that do not have easy access to fast network speeds. If your application can get much of the content across with text (such as messaging or social apps), it is important to be able to make that work without being dependent on slower network times for associated media components. 2G networks, in particular, are important to test against since this is a slow network speed that is very prevalent in some markets.

There is a tendency in back-end applications to provide a general purpose API for all of their clients. Although this is a reasonable strategy for back-end systems, it is not good for the client because the application ends up transferring and processing a lot of data on a small device while some calculations could be made on the server.

For example, if your application displays a feed of mixed content, make sure the client can fetch that information in a single request and that the returned data is suitable for caching in pieces. You generally want your client to be able to identify entities so that it can persist them and also avoid duplicates of the same objects in memory.

While doing this, many APIs return hierarchical data where all relations are denormalized. Although this approach is preferred for most web clients, it is not good for mobile clients where persisting data and serving it from disk is important.

The more information the client has about the data it is displaying, the more efficient it can be. The application can make a careful selection of what to cache, what to prune, and how to invalidate layout when new data arrives. Treating the client application like a simple HTML renderer will miss out on all of these advantages.

Developing for Android, III: The Rules: Performance OnAndroid,performanceandmemoryarecloselyintertwined,sincethememoryfootprintoftheoverallsystemcanaffecttheperformanceofalloftheprocesses,andsincethegarbagecollectorcanhaveasignificantimpactonruntimeper

AsyncTask 转载自

android中解析doc、docx、xls、xlsx格式文件 解析doc，要tm-extractors-0.4.jar这个包解析xls，要jxl.jar这个包下载jxl.jarpublicstaticStringreadDOC(Stringpath){//创建输入流读取doc文件FileInputStreamin;Stringtext=null;//Envir