DownloadManager源码

各家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）做中台统一处理做分发