进程池加协程爬取优美图库
刚学协程之后就想着把之前的代码重构一下，现在终于算是改造完成了。
以下为调试程序过程中的碎碎念。
原本用的xpath匹配的，然后增加了url后发现通用性较低，所以将使用xpath的部分全部修改为bs4，虽说吃一堑长一智，但修改真的好烦人啊。
这里说一下自己的体会，就是什么时候用bs4，什么时候用xpath。像这个程序，后边我添加的url比较多，几乎把这个网站那啥的url都放进来了，这个时候一些页面的细节可能就有不一样的地方了，用xpath的话，可能一个很小的变动，就会导致找不到内容而报错。比如有的页面在页数前边加了“标签”，xpath就会由/html/body/div[2]/div[11]/a变为/html/body/div[2]/div[12]/a，div会发生变化。所以我个人觉得xpath还是比较适合单个页面，或者能够确定一系列url的内容格式一样的时候用；如果url比较多，不确定页面细节的话，还是用bs4容错率比较高一些。
页码所在位置的xpath：/html/body/div[2]/div[11]/a此时页码所在位置的xpath：/html/body/div[2]/div[12]/a
写完这个程序后，我发现后边运行的速度有点慢，我甚至一度怀疑是程序出了问题，是不是程序阻塞了，协程没有发挥作用，然后用之前写的线程池下载了一遍，刚开始下载的特别快，我以为线程池要比协程快一些，然后到了后边也是慢的一批。。。再然后就用了进程池加协程的方法，就发现，也是一开始下载的特别猛，后边也是有点乏力，运行程序之前就想着用秒表计时来着，也没有计，现在也不知道到底哪种方法快一些，就感觉上是进程池加协程比较快，可能是个别图片加载速度有问题吧，这实实在在的等待时间确实无法避免。
程序一共行，不过实际上有效代码可能只有行左右吧，有挺多是之前写的，调试后注释掉了，一个是舍不得删，另一个是留下来看一下当时的思路。
经过各种测试，结论来了！进程池加协程是真的快啊，我还是没忍住，就把urls里的链接全放出来跑了一遍，速度是真的快啊，搜个报错的功夫，就全部下载完了，带宽都差不多跑满了。看来任务量越大，进程池加协程的速度优势越明显。
报的错：aio
