各家APP都有自己的下载工具,都不用系统的,然而貌似系统的下载各方面都要好一些,看一下,为自己写下载组件做准备。
方法
- 下载肯定会有IPC,也肯定会有日志系统。DownloadManager使用的是ContentProvider的形式。业务调用的都是DownloadManager对于ContentProvider的封装
- ContentProvider事实上是个非常厉害的存在,可以做任何简单的IPC调用,只要所有数据都是Uri和ContentValue能够描述即可。DownloadProvider中的insert就做了数据库、启动下载一系列操作
- 对于不能判断完整性的输入,与其用的地方再判空,不如统一在输入的地方做合理性判断、使用默认值替换不合理或者空值
- Android四大组件中,三个能做出单例的效果来(singleTask的Activity、Service和ContentProvider)都有内存和生命周期回调,合理使用比单例会更好
- Download中Service只是充当了更方便调用的ContentProvider的作用,感觉上是可以被干掉的
- 对于生命周期与组件不一定同步的功能,本例中的下载与Service,一定要有日志和恢复系统,并且先进行可重复的工作(对于某段数据的下载)再更新日志,保证使用日志能够恢复现场
- 日志与真正工作只要有一个性能级差异就行了(文件与sqlite,sqlite与网络),不需要搞得特别复杂
技巧
- import static,仅仅import对应类中的static方法/常量,能少打几行字
- 监听ContentProvider中数据变化:ContentObserver
- Handler.Callback看上去和继承Handler的功能是一样的。可能是做Command Chain用的吧,多层次的Handler
- Future很多异常在get的时候才会抛,执行完要get一下,看看有没有异常
- 使用Handler时,尽量用Message代替Runnable,提高性能
- 后台长时间任务应该使用WakeLock,注意合适类型的选择。一定要在finally中释放锁
- 靠Exception做统一处理的分支,除了不好阅读,非常好用
- 使用Os类对文件进行各种操作,是直接调用系统的底层函数,看样子是要快一些,参考源码
- 解决多线程问题的好方法是,使用一个单线程(Handler)做中台统一处理做分发
时间: 2024-10-12 12:04:16