@Cavolo
我差不多是在 Adblock plus 还是叫 Adblock 的时候就有在用，知道这段历史。

adblock (for chrome) 是在 Chrome 有了 webextension API 之后才出现的，这是 2009 年的事情。
这个扩展程序的开发者是 Michael Gundlach ，它的创新之处在于，它从一开始就是为 Chrome 设计的，虽然性能 /内存占用比 Adblock plus/ublock 差。

Adblock plus 的历史可以追溯到 2004 年或更早，那个时候 Chrome 连影子都没有。
https://adblockplus.org/zh_CN/faq_project
Adblock plus 来自于当时 Firefox 上的扩展程序 Adblock

在 AMO 上能找到的最早的 Adblock plus 是 0.6 ，于 2006 年发布
https://addons.mozilla.org/en-US/firefox/addon/adblock-plus/versions/?page=9
adblock 在 AMO 上已经找不到了。

Adblock plus 是在 adblock (for chrome)出现以后才移植到 Chrome 的


--------以下都是之后的故事了--------

ublock origin 的作者是 gorhill
他先是开发了 HTTP switchboard(好像是这个名字，相当于一个复杂版本但不包括 XSS 防护的 Noscript)
后来从中衍生出了新项目 ublock:
https://github.com/gorhill/uBlock


之后 gorhill 不想开发了，就把 ublock 交给了 chrisaljoudi:
https://github.com/chrisaljoudi/uBlock/
https://ublock.org/这个域名是 chrisaljoudi 的，不是 gorhill 的

后来 gorhill 又反悔了，便用 uBlock origin 的名义继续开发 uBlock
https://github.com/gorhill/uBlock

uBlock 的创新之处在于：
1 ，它(在使用 WebExtention 的扩展里)性能最好，最节省内存， gorhill 目前在活跃地开发它，并积极添加新功能。
2 ，它是比较早自称是内容(content)拦截器，而不(仅)是广告拦截器的扩展程序

@Cavolo
错了

@waiaan 使用 caf chromium
比较好的一个实现是 mokee 的羽浏览器

今日头条的质量之低还是很明确的

@belin520 ubo 应该是目前通过 webextension API 实现的内容拦截器里效率最高性能最好的的。

safari 的拦截器是原生的，性能应该会更好

然而 MBP 的电池比充电宝大得多，就算是 2016 版为了轻薄缩水了不少，依然还是相当大的（有 bar 的是 49wh ，没 bar 的是 55wh ）。

一个 20000 毫安时的电池（说的就是楼上那个紫米的 PD 充电宝）大约是 75 ～ 80wh ，考虑到输出因为 dc-dc 变压还要有损失，大约能充不到 70wh

@oroge 这个电源肯定行，它本来就是设计给 12 寸 MacBook 用的

提供 USB PD 供电协议的（意味着充电器上只能是 type-C 口，或者线路是焊在充电器上的），或者至少支持标准的 type-C 供电格式（通过 cc 线上拉电阻判断）的充电器就可以充电。

如果不提供 PD 协议且仅符合 type-C 标准，则最多只有 5V3A 的供应能力。

如 Nexus 5x/6p ， pixel/xl/C ， Google WiFi 的充电器都能给 mbp 16 充电

@changwei 硬件性能足够时， 60fps 每帧都有最大 16.7ms 延时，而 144fps 的显示屏把这个延时降低了一半。

结果就是 fps 时的鼠标变得跟手了

@changwei
你区分的出 30fps 与 60fps ，玩 fps 游戏时也区分的出 60fps 与 120fps ，可能也区分的出 120fps 与 240fps

@infun @sethverlo

ublock origin 最早就是 ublock
有一天作者不想开发了，就移交给别人
又过了几天，作者又反悔了，就换了 ublock origin 的名字。

adblock plus 的历史要久得多，已经不止十年了。

adblock 什么都不是

@herozhang ublock origin ，因为它就是 ublock

这是 chrome 在 md 化的一部分

@JohnChu

禁用 service 意味着 root （或者通过 xposed 也能解决问题），这样能接受吗？

相比之下绿色守护辅助模式下的休眠可能更简单，因为处于 force stop 状态的应用自身不能唤醒自身。

@JohnChu 这是 Android7.0 开始才有的项目

同步账号是一个很好的后台触发运行的方式。
尝试这些办法：

1 ，用 appops ，将 GET_ACCOUNTS 项目设置为 ignore ，如此应该可以做到在手机的账号设置中看不到微信一项。或许这就可以阻止其通过账号同步的进行后台唤醒的那一部分。

2 ，绿色守护的浅睡模式(不能阻止 wakelock)，这个主要用于强迫微信走 GCM 。

3 ，尝试把 RUN_IN_BACKGROUND 这个 op 也设定为 ignore 。这应该会导致微信完全无法在后台运行，也会导致收不到信息， GCM 到来时也无法唤醒微信。

如果不愿意 root 手机，可以用 adb 的 shell 控制 appops 的设定(仅限 Android 6.0 或更高版本)

就原始主题，一手机还在用 18 个月前就发布的系统，就算吃了药也不知道能不能救。

----------------
对大部分用户来说， Android 版本更新是最重要的一件事，我们是来用 Android 的， UI 可能也很重要。
Android 的碎片化就是厂商不愿意为旗舰机型以外的手机更新系统造成的。

公司老板？用户需要在乎他想什么吗，只要他的公司生产出品质良好有长期软件更新的手机，用户肯定喜欢。

----"就像这并不能说明某米良心"
类似的，我们关心的是什么时候有 Android 系统更新，怎么做可以让 ADUI 变成 no-ad UI 。 cancro 从发售到现在一直有软件更新。

----"现在 N 咋不给上了"
Nexus 5 也没有上(非常可惜，相同平台的 8084 的 N6 都有 7.1)，然而用 8974 的，有谁出过官方的 7.0/7.1 ？
有一种未经考证的说法，认为高通停止了 8974 的支持，但是我没有证据。

@xhslyf

考虑通过 ublock origin ， umatrix ， noscript ， greasemonkey 等扩展程序措施阻止网站的 anti-adblock 代码。

cnbeta 去年打得那么凶都被制地服服帖帖

1 ，是在某一个特定无线局域网内有问题，还是在多个不同的无线局域网内都有这个问题？后者的话考虑 1 楼提到的。
2 ，找客服要求他把这个错误号原封不动地报告至后台。
3 ，如有条件尝试通过 fiddler 等工具抓包。