panbeta

当你使用 Sony A95J 电视 + Sound Bar + （ 4K + 杜比音效 + 杜比视界）的片源看电影的时候，你会发现和在电脑手机上看爱优腾完全是不同的体验。 体验的差距大到你会感觉你看的不是同一部片子

楼主有 8 年的缓冲期，不用焦虑，要相信你不可能 8 年 0 收入的。楼主能有这个积蓄说明你的能力和判断力已超过大多数人，无论做什么都可以做出来的

播放器是 Native 写的。 通过包装成 WKComponetView 注入到 WKWebView 的层级里面。 挺 Hack 的，不过性能好体验佳。

我的第一台 Macbook Pro 是 2015 mid ，借钱买的。当时工资只有 8000 ，这电脑水货都要 1.2w 。

公司电脑是 MacMini ，卡得开 Xcode 都费劲。我理解工具不应该成为发展的最大阻碍，所以向朋友借钱买了。

电脑到手后，靠业余时间接私活，第二个月赚回了这台电脑的钱，很快就还了。

我想说，想一想这些问题可以帮你理清要不要买：
1. 平时下班后写代码多吗？
2. 如果多，这些代码给你带来什么价值？用公司的电脑能不能实现？
3. 买这台电脑和不买这台电脑，带来的变化是什么？和投入对比，值得吗？

想清楚了自然就知道该不该买了

京东京造，便宜大碗直接拉满。23 年买的到现在用下来没啥问题

楼主分享得非常细致，我也对楼主说的许多点非常认同。我也来分享一下我的想法吧。



我的 App 目前收入还可以，我认为首要的原因是做了用户真正需要的东西，从而用户愿意付费。
这很自然：用户花一点小钱，我帮他节约时间。
楼主说的需要一开始就付费这点我非常认同。我的 App 从一开始就是付费应用，刚上线的一周定价 1 元，用来排除免费用户，后来随着功能的增加逐步提升至 15 元。其实中间为了获取用户我也做过实验，限免一周，然后看数据，结果发现免费进来的用户（无论美国的还是中国的）都是冲着白嫖来的，几乎没有任何的应用内转化。而且他们使用应用的频率也不高。反而是付费用户，由于付费墙的存在，在购买之前他们会仔细考虑自身是否有这种需求，购买后的存留和使用也更好。

我们做技术的习惯性地会觉得某个新技术出现了，就一定会有商机，其实不然。WWDC 看到小组件发布后，我其实也想过做这种小组件美化 App 的。但是它充满限制的 API 让我意识到，这不是一个刚需，这应该是 App 本体的延伸，重要的是 App 自身带给用户什么价值。

关于应用体验，我认为应该是在解决硬需求的基础上，使你脱颖而出的部分，而不是一开始就依赖优秀的体验。用户最终的付费动力始终是来源于解决了硬性需要，而不是审美 -- 除非是服务富豪们，单个付费可以 cover 好几年的收入，否则审美、流畅度等指标应当是第二需要考虑的事情。

当你的 App 可以解决用户真正的痛点，同时设计和体验在同类中脱颖而出时，你的 App 自然而然就成功了。

@helloizl 现在开始做有点晚了。3 年前我折腾 Nas 的时候关注到 iOS 上 Infuse 一家独大，而且没有好用的播放软件，觉得是个机会，只是当时工作比较忙抽不出时间来。 后来 fileball, vidHub 等一众软件起来了，到现在已经相当成熟，没必要再入场了

这个题目挺好，贴近日常工作，也能考察面试者对边界条件的考察。
首先这个 Map 是非单一对象的，里面包含 Integer String Map Array 。

题目是替换所有的 100 -> 200, 其实我们只需要处理 String 和 Integer 类型的数据就可以了。遇到 Map 和 Array 的话递归调用即可。
假设只替换 "100" -> "200"，不考虑 "100100100" -> "200200200" 这种情况。

差不多一个递归函数 遍历 Map 的 AllKeys ，if 判断 Value 类型，然后 replace 就行。

对于小于 10 人合作开发的 Git 来说没必要如此复杂。 实际上 issue tracker 系统和 Git 可以通过其他方式结合。例如：每个版本发布前的 bugfix 阶段，拉 bugfix 分支统一修复本版本需要修复的 bug 。 每个 bug 单独一个 commit ，commit 中添加 「 fix: #ID 」的描述，issue tracker 系统收到 hook 通知后解析 commit message 来关联提交记录到工单就可以了。后期回溯直接从工单系统找就行了。