V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  ShadowPower  ›  全部回复第 22 页 / 共 81 页
回复总数  1611
1 ... 18  19  20  21  22  23  24  25  26  27 ... 81  
166 天前
回复了 hgg12580 创建的主题 计算机 2024 年了,求推荐静音 Win 笔记本
小新 Pro14 7840HS ,开静音模式。
玩原神可以阴影中其余高,0.6 渲染倍率 2880P 分辨率,开 FSR2 ,绝大多数场景 50FPS 玩。
很安静,安静到不会打扰别人睡觉的程度。
167 天前
回复了 okevin 创建的主题 MacBook Pro 淘汰下来的 macbook pro 2015 款还能干啥?
装 Win10 可以重获新生
167 天前
回复了 TESTFLIGHT2021 创建的主题 宽带症候群 PCDN 和 BT/PT 本质一样
如果一个协议更方便监管、审查,或者必须配套内置审查的私有客户端,或者运营成本很高,平台需要足够的利润作为支撑,那么看起来就比较“正规”,不怎么会用于“侵犯版权”。

HTTP 协议就是如此,因为服务端逻辑可以检查用户有没有合法授权。提供 HTTP 下载服务器也需要高昂的带宽成本,盗版网站如果自己提供服务器,没几天就因为成本太高而倒闭了。


BT 协议坏就坏在太自由了,客户端都不会自带审查、监管(迅雷除外),用户只需要知道 Hash 就可以取得文件,资源提供方不好阻止。

美国审查 BT 协议下载盗版的手段,其实就是架设假 Tracker 服务器,当用户连上它并请求一个盗版资源时,就能定位到这个用户在下盗版。


自由软件比较特殊。这些软件大多不需要付费即可直接下载。下载的人越多,自己支付的成本越高,而用户都没付费。
虽然有公益性质的镜像站,但是他们的资源依然有限,运营也需要成本。下的人多,只会增加成本,不会带来更多收入。

于是 BT 协议就非常适合分发比较大的自由软件,例如 Linux 发行版。软件本身允许用户自由传播,BT 协议本身也自由,各种平台( iOS 这种封闭平台除外)都可以找到这种 P2P 下载协议的下载器,用户之间互相传播不消耗软件作者的服务器带宽,有效降低成本。

如果把 BT 协议干死了,除了商业公司可以依靠卖服务或者公司其他业务获得盈利,其他的大型自由软件作者估计得找用户收费了。以各种名头收下载服务器带宽费……

付费视频网站的话,早就收过这笔费用了,算在视频会员/购买视频的费用里,还通过 CDN 或者私有 P2P 协议来进一步省成本。
现在 B 站不开大会员画质那么差,估计也是成本问题……
@poorcai 填这个表单:
https://codeium.com/waitlist/gpt-4

我等了一星期就可以用了
@haython 之前用 PDMan ,后来用公司内部的工具了(公司有做自己的 DevOps 平台,有这个功能……)
@weeei #102
我年轻的时候也信这个,现在不信了。

上班收入就不说了,无论用什么,其实收入都大差不差。
在公司里上班有不少好处,很多软件都是老板买,搞多个账号拼车,分给员工用,总体上还更划算了。像 GPT4 之类的,忽悠老板说能提升工作效率降低公司成本,老板也乐意买。

我平时自己鼓捣的玩意,其实也只能学学知识,因为没什么商业头脑,赚不到钱。买这些软件也不能解决这种问题。
除了上班的收入以外,有时候靠同学和同事接了点活,大多数是帮学弟做课程设计/毕业设计,或者公司项目缺人手外包点活出去这种,加起来收入也只有几万。

把最贵的那些软件订阅都买个 4 、5 年,那么工作之余的收入几乎都送给软件公司了。

指望花钱买这些软件来增加收入并不现实。不过,倒是可以在赚到很多钱以后,买这些软件用一用。

有些免费/廉价的软件可能比那些“最好”的软件缺少一部分功能,或者性能差了一点,界面丑一点。但是最核心的功能其实都大差不差,熟悉了之后都可以用来赚钱。

对于开发相关的工具,因为几乎没什么专有格式,相比别的行业软件,算是相当开放、自由了。
不花钱也能解决绝大多数的需求。花钱几乎只为了一些特色功能,例如 Navicat 的特色功能就是跨数据库的数据备份、迁移。但对于个人项目来说,很少用得上。

其实 Navicat 也不是特别好,我在公司用来导出过千万记录的表数据,结果发现 Navicat 这功能有内存泄露的问题。
而代码智能提示,数据展示(查看数据库里存储的 JSON 数据)等功能,Navicat 就没有优势了,反而是劣势。


其他娱乐相关的订阅,倒是没什么问题,也不算贵,只是这些跟“赚钱”没关系了。
我订阅最多的时候和 OP 差不多,不过现在几乎没有了。
这里面最不值得的是 Navicat ,除非经常使用数据备份、数据迁移(跨数据库的)等功能。目前我用了将近 5 年的 DBeaver 社区版。
GitHub Copilot 我用 Codeium 替代了,顺便申请了这玩意的 GPT-4 ,也通过了,都是免费的。
JetBrains 全家桶可以用 VSCode+IDEA 社区版。当然,不能完全替代。不过我所需要的功能靠这些刚好可以满足,甚至觉得 VSCode Remote 有优势。
@wangxiaodong 我支持你的诉求。但是你的想法其实在 Android 上还比较麻烦:
如果用户只是单纯地安装了应用而不做任何配置,在 Pixel 上,电池优化和自适应电池的设计对这种自建推送渠道并不友好,因为会被识别为滥用,然后开始加大限制。
这已经是 AOSP 的“默认行为”了。FCM 实际上有特权,包括 APP 里的 FCM SDK 里接收推送消息的 Service 也有电池优化的特权。

要想实现你的各种诉求,Google 也得改。但显然不会让 Android 回到那个 APP 一天 24 小时在后台偷偷做事情的时代。
现实总是会充满妥协的,完全理想的世界并不存在。

无论如何,今天的各种海外安卓 APP 几乎只接入 FCM 推送。
减少电池优化功能(无论是温和的还是激进的)对推送的影响,这一点已经很现实,很合理了。

至于你的诉求,如果谷歌不想让“电池优化”功能形同虚设,只能针对这种需求专门设计一套机制。就类似无障碍服务一样,单独授权,给一些特别的权限,也给一些防止滥用该功能的限制。


我追求的一直都很简单,用户的权力应该高于 APP 的权力。想用的功能都应该正常使用,不想用的功能都可以不允许 APP 去做。
如果 APP 在后台做我不知道的事情,而我不需要它,我应该能彻底关闭它。
但我还需要收取这个 APP 的推送通知,目前 iOS 和国产 ROM 的推送都可以做到这一点,可惜 FCM 做不到。

只要能做到,就可以了。

我追求的不是苹果那种“苹果觉得你不需要”,然后全都不让做,用户没有选择权。
而是用户可以根据自己的意愿,来掌控自己的设备而已。
@wangxiaodong 你举的例子都不恰当,诉求只不过是想让 FCM 通知改为合理且可靠的设计,而不是想剥夺 Android 现有的功能。回想一下,你是不是一开始也觉得 FCM 就是系统框架负责显示通知的。

在我接触过的例子中,几乎所有对 FCM 了解不多的人,一开始都会这么想。我在几年前一些探讨如何让微信走 FCM 推送的帖子里(酷安上面),还发现有人觉得微信没了后台就收不到 FCM 推送,是因为微信自己没适配好。

当然,那时我也不知道,直到我真的去做了相关的开发才知道这些细节。原来 FCM 设计成了这样。


另外你的回复总是想讲阉割系统功能,增加更多限制之类的东西。我还是得说一下,和它有关的都不是“诉求”本身,而是“我对这些功能的看法”和为了说明“为什么会有这种需求”。

你说的阅读理解的问题,跳出这个问题,考虑这段对话:

A:你觉得他这次考试考得怎样?
B:他还得再加把劲。

这段对话里 B 可不一定希望他努力,也许只是委婉地表达“考得不怎么样”而已。是人物 B 对“他”的评价。虽然评价是消极的,但又不想直接说出来。

如果一直都在想着“诉求就是阉割系统功能”,那么理解就会有偏差了。

我还是得强调一下,关于禁止自启动、后台限制等,现在已经有了选择(无论是国产 ROM ,还是借助第三方工具),是“已经解决”的需求。因此,尽管我会提到,我对谷歌现在的设计有些看法,但这件事就不是“需要 Google 去做的事情”。

只是为了回复你之前提到的 AOSP 和 Pixel 都是这种设计,所以 FCM 这样设计没什么影响这个观点。
如果 FCM 只能在谷歌自己的设备上使用,其他手机上运行的 APP 都只能接入其他推送平台。那么确实没什么影响。

可是谷歌掌控着大多数海外 APP 推送……无论你用什么 ROM ,使用习惯是怎样的,想收这些应用推送,你都逃不过它们。

我的态度则是,两者在我的评价里都是不太好的设计,只是恰好正常使用的情况下互相兼容罢了。
为什么我觉得“让系统直接显示通知内容”更好,在前面都讲过了。
@mxalbert1996 快下班了,写得有点乱。不过,我在倒是没在装理中客,只是并不想像一些回复那样仅仅单纯地输出观点,而是希望写的东西能把事情都讲清楚。
@mxalbert1996 这两者其实不冲突,前者是愿景,后者是现状。

进一步讲,从我的立场出发,我感觉现在的 Android 部分权限设计和 FCM 推送机制设计都不合理。
我当然会表明我认为权限设计不合理这一点,来回应上面的“AOSP 和 Pixel 里都没有这个东西”。因为前提不存在,则后面的诉求就失去了意义。

但现状是,其实 Google 不做的权限管控,甚至国内厂商也不做的(例如存储隔离),已经可以通过使用某些 ROM 或者安装特定的软件来达到目的了。

因此,Google 做不做,这一点不在诉求范围内,毕竟我已经用上了,但不妨碍我认为原生安卓的权限管理设计不如一些国内 ROM 完善。
但我觉得那是个好设计。用户的权限比 APP 开发商更高是一件好事,因此 Google 要是做了会更好。并非强制,而是留给有需要的用户。

当 Google 考虑到“有这样使用的用户”时,才能意识到 FCM 设计的问题在哪。实际上目前开着优化电池使用都已经觉得体验不太好了。

我现在就处于“既能用上 FCM ,又严格限制应用后台活动”的情况。哪怕我用的是类原生……

Android 本身是开放的,它就不应该“专为 Google 自己的手机设计”,尤其是非 Google 手机上面运行的 APP 其实都严重依赖 Google 的生态的情况下(接了 FCM ),那么 Google 就有必要考虑整个生态内的各种情况,使用一个让大家都满意的方案。


所以,真正需要 Google 做的,就只有改 FCM 推送设计。因为这玩意完全掌握在 Google 手里,需要推动应用开发者对升级后的 FCM 做一些兼容,不是 Google 亲自去做,那就没什么好办法。
@mxalbert1996
> 杀掉应用,并切断所有唤醒途径的话,大多数时间里,这款应用后台的资源占用就像没安装它一样。而这时候,你又能通过系统服务来查看来自这个应用的推送。这难道不是更好吗?

这倒不是默认开启或者默认关闭的问题。目前的情况是,想要的人早已用上了,而不想要的人可以永远不用。它并不是一项需要“新增”的功能。
哪怕是类原生或者 Pixel ,也可以用 Thanox 这种插件,或者其他的东西来实现。我自己的类原生( crDroid )也整这玩意……

这里讨论的从来都不是“需要加切断唤醒禁止后台”的问题,相关的内容只是为了详细说明:
1. 为什么会有这样的需求;
2. 是不是真的耗电:当然,而且耗电的原因不是推送机制,只是解决耗电问题的做法都会影响推送;
3. 电池优化是不是能解决问题:能缓解,不能根治,而且依然影响推送机制。举个例子,微信虽然不接国内推送,但是接了 FCM 。然而开了“优化电池使用”之后,微信电话再也接不到了,因为收到推送的时候对方已经挂断好久了;

只是我看了帖子开头几个回复,要么觉得 OP 的需求是伪需求,要么可能真的觉得 FCM 的原理和苹果 APNs 完全一样……
所以我觉得,有必要把需求的来源和相关的技术细节都讲讲,希望能从“有这种需求的用户”的角度,去看待“修改 FCM 设计”这种想法。

而不应该一上来就否定整个帖子。


其实真的有不少用户有这种需求,甚至这就是一些人用 iOS 的理由。
但我觉得 iOS 走向了另一个极端……其实不是所有人都能接受。
@wangxiaodong
关于“为啥用户都不能决定某个 APP 的启动,而是厂商来决定”这一点。

除了上文提到的 ColorOS 这种无论如何设置都会半小时钟后无脑杀后台的蛋疼 ROM 外,其他厂商的 ROM (例如 MIUI )在用户自行决定要允许某个 APP 开机自启+驻留后台的时候,都可以做到。而且运行表现和类原生 ROM 基本一致。把自启动打开,省电策略改为“无限制”就好了。

唯一不能关闭的功能可能是划掉最近任务时强制终止。国产手机的海外版 ROM 默认行为和类原生一样,国内版 ROM 则和 iOS 一样。
Python 的简单是指入门简单。能让新手很快地实现自己的想法,而且还能满足各种各样稀奇古怪的需求。
给非程序员用再合适不过了。
@wangxiaodong 白名单只是给 APP 默认自启动/后台无限制而已……
至于怎么设置都不能让应用在后台存活(像类原生一样)的情况,我只在一个 ROM 上遇到过:ColorOS 。避开这个就好了,当初我用这玩意确实杀后台杀麻了(我在 2019~2020 年的时候用,当时 OPPO Reno ACE 性价比很高)。


@mxalbert1996 这么做并不会牺牲应用功能,只是在增加功能,因为改动只有一个:
把原本由 APP 显示通知内容,改为由系统服务负责显示。

除此以外,其他功能没有任何区别。
没什么功能是强制的,都是根据个人意愿自行设置启用和禁用。

至于要不要杀掉应用,是否允许应用被唤醒,是用户的“额外选择”。而上面的改动,只是为了在这种选择下,依然不牺牲“消息推送”功能。

目前的情况是,你只能在“无法及时收到推送,甚至收不到推送”和“允许应用本身的后台功能”之间二选一。

前面已经提到过了,并不是“推送”本身导致耗电,而是应用里与推送无关的后台 Service 导致耗电。如果现实情况不是如此,那么 Google 也不需要推出那些电池优化功能。

把电池优化开到受限的话,推送也会受影响,会被推迟。策略是攒一段时间一起唤醒来减少唤醒次数。还有“对齐唤醒”优化技术,会让多个 APP 的后台在同一时间点唤醒,以减少整个设备的唤醒时长。

给 tg 、discord 等应用开限制后台,体验就不好。

但如果由系统来显示通知内容的话,当你 [确实想要] 彻底禁止某个应用在后台活动,你就可以强制停止,禁止后台启动,同时依然正常接收消息推送。

如果你不需要推送,还可以把通知权限关了。

---

打个比方:
这就好比你去一个餐厅吃饭,这家餐厅一旦点了米饭,必须同时点面条,面条还要付钱(指应用本身的后台功能带来的内存和电量影响),否则什么都吃不到。
而 OP 觉得这样不好,希望做一个改动,可以只点米饭,不点面条。改动内容是“米饭可以单独供应”,理由是“我不想吃面条,强制我点面条是浪费我的钱”。

你反驳 OP 的理由是“这个改动会影响你吃面条”。

然而现状是:米饭一直都可点可不点(即:通知权限可以自由开关)。
想点米饭,就得顺带点一些面条,可以点得少一点(指:限制后台),但不能不点。
如果经常吃米饭,还希望第一时间吃上(指:及时的通知推送),这家店会多给你一些面条,而且要多付钱(指:自适应电池)。

所以,“在不要面条的情况下,希望可以单独供应米饭”的要求,我感觉十分合理。也不影响你吃面条。
对于本身就喜欢吃面条的人(不限制应用后台活动的人),一直都可以只点面条,还能顺便来点米饭。
1 ... 18  19  20  21  22  23  24  25  26  27 ... 81  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1010 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 29ms · UTC 18:41 · PVG 02:41 · LAX 11:41 · JFK 14:41
Developed with CodeLauncher
♥ Do have faith in what you're doing.