panbeta

京东京造，便宜大碗直接拉满。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 来关联提交记录到工单就可以了。后期回溯直接从工单系统找就行了。

缺乏监管的情况下防不胜防，选择一个可信的渠道购买食物（例如山姆？）。 减少外食尽量自己做饭。

我的经验是，去掉相同功能的东西，每种功能的东西只留一样最好的，反复使用，就够了。

买东西的时候，要根据当前的行为轨迹去买，而不是想象“买了之后我就会开始...”，因为根本不会开始，最后买来的东西除了吃灰占地方难搬之外没有任何价值

感谢，字体非常精美，已经在 Xcode 中使用

如果候选人没准备过这题，也不能说明候选人不行。
恰恰好这是考察候选人编码实力的最佳时机。
作为面试官你可以从 LRU 的概念开始，给出提示，然后看候选人思考的广度和深度。