请问下，能不能不要一直置顶这个帖子啊，其他人要置顶都没办法了……

@Lituby 谢谢支持，比心

给 cook 写信是最没有用的……直接去天才吧说明情况比较快处理。

我上次带了在逛商场看到的非常可爱的小糕点。

缺点：贵

1. Apple 应该把之前的受害者的款都退了。
2. Apple 应该排查和处理这个 App 的提交方及其相关主体在 App Store 的另外的账号。
3. 盗刷的那些 IAP 所归属的 App 及相关方也应该进行处理，这是绝对的欺诈参与方。
4. Apple 应该修正 Apple ID 输入密码 UI 样式、Apple ID 授权登陆流程，避免一不小心就钓鱼。
5. Apple 这种弱鸡到不行，死板低效的客服系统应该全面检讨重新设计。

从 iOS 开发角度上看，这个是个挺蠢的想法。你调研得也相当外行。

“已经安装 的 app ，通讯录，通话记录，短信记录” 就算给你通讯录权限，这里面也就只能拿一个通讯录。

注定没法实现的想法，死了这条心吧，用其他地方的信息搞定吧。

作为做过几年的 IM 相关的 iOS 程序员稍微说一下，其实像 Telegram 这种用服务器保留了所有未被删除信息的 IM 服务而言，先天上对那些架构上（不考虑审核目的）没有存储用户的聊天内容导致不支持从最开始拉取消息的 IM 服务（比如微信而言），在很多方面是有很大优势的。主要说 IM 部分，微信的其他各种服务塞进来以及技术含量很高的小程序不在讨论范围。

简单的说其实也是一种钞能力，用服务器成本来换来多端客户端的任务的简易性，最终靠简易性省掉了很多麻烦：

1. 每次打开只需要拉取少量的数据，就能让用户大致了解群组的情况。

- 比如用户在上次使用到下次使用期间，他有十个 500 人的群组，每个群组本来里面原来有 500 人 -> 550 人，其中一些人改了昵称，也不需要下载群组变化的 550 人的信息，只需要获取一个群组消息就可以，然后获取消息的时候把对应说话的用户信息也返回过来，而那些不说话的用户信息，有需要点击进群组的时候再依次加载。但是类似微信，他要下载 550 人的信息。

- 如果这些群组产生了 2W 跳未读，这时候，其实他只需要拉取每个群组最老的 10 条未读和最新的 10 条未读，就能满足点击进去能看到好像都加载下来的数据，如果消息显示完了，就再请求服务器。这里只需要你和服务器的通讯速度够快，预加载的时机合适就行。但是类似微信，他必须把所有的 2W 条信息基本都下载下来。这也是为什么很多人的微信打开在转圈的时候，因为很多人特地把微信的“后台 App 刷新”给关了。

2. 客户端职责简单

- 主要的内容就是做几个 list ，把大家的聊天内容展示出来，处理未读/已读，根据更新 ID 请求数据等等。

- 而微信，就特别需要有很强的投入在数据库优化上。因为聊天记录都在本地，又要在手机可能不太好的性能条件下，加载搜索之类的行为卡顿不能太明显的前提下，尽可能保证用户体验。

3. 多端效果比较一致

- 毕竟每个客户端只是拉取信息，虽然可能和“同步”的概念有点不一样，但是用户感受到的就是数据对得上。

4. 遇到版本升级，历史垃圾文件清理的时候，Telegram 会有更大的余裕来处理，毕竟用户数据如果损坏了？再拉就好。微信则会面临垃圾越堆越多，一不小心弄坏用户记录可就很头疼的状态。

但是微信这种没有服务器从头拉取数据的选择有什么好处呢？

我个人觉得主要是几点：

1. “省钱”，如果用拉取服务器模式，那么现在腾讯可能要 10x 倍的服务器投入，按照国内这个使用频率和覆盖率。那你可能除了朋友圈/公众号的广告外，应该也会看到 Telegram 那样子的群组广告/会员模式之类盈利的操作。

2. 在性能同样的情况下，搜索的体验可能比 Telegram 必须调用服务器 API 请求历史数据来得好。

3. 宣传点可以多一个隐私，而且用户需要担心自己历史聊天记录丢失的同时，哪天被哪个脚本小子盗号导致十多年来的聊天记录被传播开来的风险也降低，如果微信用的是 Telegram 的模式，我相信这几年很多吃瓜事件，怕是会有一大堆更没必要更详尽的聊天记录流出。

4. 微信也能省去很多麻烦，比如聊天数据库被拖库之类的情况。

整体而言，各家有各家的实际和困难，用不同的代价，换来不同的优势。

其实很多事从一开始的选择就会导致一些必然的结果。有人说技术到一定程度就跟魔法一样。我觉得其实很多时候，App/互联网对一些不太熟悉的人而言，就是这类魔法的存在。比如楼里的很多人，基本都处于这种状态。

感兴趣愿意折腾可以去看他们的代码。

https://github.com/TelegramMessenger/Telegram-iOS

还有好几百个 issue 没关呢……

我个人觉得要 3 个月回本才值得做……

现在看着是挺高，但是这个市场如果没什么门槛的话，其实很容易价格就卷起来的，你拿现在的盈利来算未来很容易翻车的。

整个计划挺扯淡的，其他不说，365 天，你只要每天维护一下，然后天天能有人租，一年回本的生意你只搞 20 台？

第六集属于有共识的差。

首先你要意识到结婚或者同居对象的选择是很重要的。这是一项影响你未来几十年的人生的事情，请认真对待。

其次你要意识到对方和你一样，是一个拥有自由意志的人，TA 不是你订购的商品，你也不是 TA 订购的商品。

所有感情开始的时候，就该有一个结束的打算，什么时候止损，什么时候退出都是要考虑的。

抱怨是很合理的，这些 SNS 网站，本来就是靠一个个用户汇聚起来的。

不让抱怨才是奇怪。从这点看，很多人不太能正确认识“自由”的定义。

回到主题，在合法范围内只有“离开 Twitter”这唯一路径。

更大的范围，你用任何方式终结掉马斯克对 Twitter 的管理，也能解决很大程度上的问题。

iOS 开发来说一下为什么会有这个问题。

灵动岛本质上是提供了额外的一个地方显示信息，而“显示信息”这种工作流程里，有着一个最核心的几个问题：显示什么信息，以及信息如何更新。

我现在技术角度回答一下这两个问题：

- 灵动岛只允许 App 处于前台的时候能够启动它，启动的时候就能设置灵动岛里的信息。只不过你得对应 App 进入后台才能看到这个 App 的灵动岛信息。

- 而信息如何更新，其实有两条路径，一个是 App 处在活动状态（前台/后台持续运行），另外一个是 Push Notification 进行通知。

因为多数 App 没有必要在后台持续运行（滴滴有定位这个需求自然可以），那么像灵动岛里显示的信息有些是派送信息，骑手取货、位置变化、订单完成这些时间点灵动岛里的信息都是需要更新的，从技术选择上，也只有通过 Push Notification 了。

@Gadmin Show me the code

@allinschroe 你自己主动操作当然屏幕里的内容都是能截屏……

但是从 iOS 第三方 App 角度，是无法截屏的。

日记本 App 开发路过～

我开发的 iOS 日记本 lemon （正在上架中）是支持免费导出 CSV 的，这也是多数日记类软件如果支持导出记录会选择的格式。

这个格式虽然各家的字段支持可能不一样，但是可以用 Numbers 或者 Excel 打开，然后根据目标调整 CSV 里的字段名和数值就能导入到另外的 App 了。

你说的应该是《北京浮生记》吧

截屏应该是截不到系统弹窗的。不然这个漏洞太大了。

估计你输入正确的密码之后，有额外的诱导二次验证信息的登记入口。