安卓不知道, 你说的拦截, 要用 chrome 点开吗, 可以了解下 chrome 的 cdp 那套协议(说白了就是 remote debug by devtools), 拦截流量, 控制浏览器什么的都可以做到, 会点 http 和 WebSocket 的知识就能打通了, 实现过相关的库, 但是不优雅就不推荐给你了

或者直接无脑走 MITMproxy 那套, 不但能拦, 还能改呢(cdp 也可以...)

和 js 没关系, 就头几篇有问题... 真想把自己的帖子全删了

GET https://cn.engadget.com/lib/metro/g/myy/rapidworker_1_2_0.0.31.js 404
C @ rapid-3.53.2.js:1
w @ rapid-3.53.2.js:1
sendRapidNoDelay @ rapid-3.53.2.js:1
(anonymous) @ rapid-3.53.2.js:1
YAHOO.i13n.Rapid @ rapid-3.53.2.js:1
(anonymous) @ (index):49
(anonymous) @ (index):55

不知道有没有关系, 反正这种情况要么新程序员提了错代码, 要么迁移导致兼容性有问题, 要么就是 cdn 之类的打不通了(类似当年的 BootCDN )

<a href="" class="C(engadgetFontBlack) Fw(400) Td(n) Bdbw(1px):h Bdbc(lightgrey):h Bdbs(s):h Fz(30px) Lh(35px) Fz(22px)--sm Lh(25px)--sm">三星 Galaxy S11 可能会采用 108MP 相机</a>

太多了 999... 用 adb 通过 包名和 biz 拼凑 uri 调起 Profile 页面, 流量里可以直接拿到最新一篇的时间, 不需要二次请求, 然后对超过半年的调起取关按钮

简单的操作 tasker 就可以实现, 包名什么的网上随便一搜一大把也不用逆

频率一高就会封号的, 已经封过好几次, 解封还要干净并且半年没解封别人的辅助解封. 再也不敢用自己微信折腾了, 这也是我现在弃用微信的一大原因吧...

@sylvos #21
可以看看 Benchmarker 那个项目, hug 从 falcon 包装来的, C 加成已经飞起来了, falcon 的性能接近 golang, fastapi 基于 starlette, 后者和 golang 差距还不小, 不过 fastapi 的几个设计思想挺有意思可以借鉴, 自带 swagger, 类型面向对象的类型检查是卖点, 不过这些都可以用插件代替
后面三个东西... 看看有没有官方 asyncio 支持吧, 如果没有就丢进 executor 问题不大的, 通过多线程包出来的协程, 不是特别高并发的话开销可以忽略, 毕竟很早期(忘了是不是 aiomysql 了) 挺多轮子这么包的

轮子什么的, 之前看的时候只是记个大概, 脑子里根据需求建个索引就没继续搞了, encode 和 aiolibs 是比较有名气的协程库组织, Django 当年提了 asgi 以后 uvicorn 火了一把

我不是什么大神前辈, 就是个刷题找工作的可怜虫...

@qixiangyangrm #77 微服务多了, 什么类型的数据都得爬... 一开始 http 被我给 D 了, 两三个大佬找上来吓死我了, 后来还是接 kafka 原生消息才不走轮询, 说多了都是泪

@sylvos #17
mysql client 支持协程的现在都烂大街了吧, 已经不是早年间给同步库套个线程做成协程就拿来用的时候了, 如果你非要, 看看 run_in_executor 的文档一看就懂了, 就是让一个跑在 concurrent.futures 的 ThreadPoolExecutor 里面的 Future 转成一个可以 await 的玩意. 我平时更喜欢用 asyncio 的 Future 去 await 一些协程玩意

换个现成的轮子算了

aio-libs/aiomysql
encode/databases

我平时用的前者, 但是更喜欢后者(很像 R 神那个 record), 这俩组织出的 aio 库太多太好使了, 至于速度... 没做过 Benchmark 不知道谁快, 看源码谁用 C 谁快吧

httpx 没有 C 加成提速, 暂时只能用 aiohttp 代替 Requests, 但 starlette 是真的好使

@DeweyLiu0 #17 北京的时候经常掉, 山东联通现在除了图片等 assets 域名, 基本裸连没问题

偷偷提醒下: 有些"不存在的" app 和 website 可以看到一些面试者和员工的爆料.

因为不存在, 所以我也没用过

我现在直连, 也不改 host, 依然很快, 四五百 KB/s

没啥好办法... 少数时候连接失败得开飞机

上次有人提到个 Github 的镜像站, 不知道背景没敢登录

就喜欢看这些骚操作哈哈

以前用 python 也干过类似的事情, 确实方便, 一个 route 让我接了几十个 utils..... 而且也方便一句 /doc 当场看文档, 至于安全问题, 做了限权和 slots, 问题不太大

不过后来就不这么折腾了, 看 doc 也用 swagger

因为... 通用框架太简单, 功能复杂的话那些公司也有足够的开发团队刷 KPI, 不需要买?

随手搜了下, flask 有个 issue 也提到改成 python -m xxx.pyd 可以避免

原来 2 3 楼你们说的是这个...

@qixiangyangrm #3 线程的好处是, 任何同步函数都能给你整异步来搞, 有些 C 库默认就是同步模型走不了协程, 也就没办法通过协程来提速, 但是线程套上依然可以搞 (以前遇到的问题就是 gevent 会被那种库 block 住)

协程就像你说的, 在特别高并发场景下, 切换开销比线程低的多, 然而在当前大环境里面, 如果你整个业务系统都是在协程的主线程事件循环里跑的 (就像 uvicorn 托管个 asgi), 肯定有阻塞的函数都尽量用协程来实现, 无法实现的把它丢到多线程那个 executor 里造个类似 Future 的协程就兼容起来了, 开销影响也不会太大

我试过在 Windows 上跑协程和多线程对比差距不大, 协程在 uvloop 尤其是 epoll 环境下面效率会不错, 可以对比 Benchmarker 项目里的一些结果, 然而真正提速的反而是依赖 C 的加成, 目前来说还是不用太纠结性能问题, 都用上 python 了, pure py 项目再优化天花板也有限的很

就目前环境来说, 养成全局协程的习惯还是比较好的. 场景来说, Django 3.0 都正式把 asgi 搞起来了(比前个版本 channels 好像优化了不少), 多线程已经基本可以当做一个子集来用了

你成功用一个破标题闪了 100 层楼里人的腰

可协程的都协程, 不可协程的丢到 executor 里做假协程

就酱

简单识别可以用 PIL / pillow 那边的, 带容错率的也有, 可以查查相关的, 以前用过基于它的以图找坐标的自动化库

代码里不是全英文吧, 带上 # coding 那段 shebang