一个是苹果官网的这个时间并不准确，甚至有趋势相反的情况。（ 13pro 说视频播放 22 个小时，13 视频播放 19 小时，但实际使用 13 的续航比 13pro 更强）

另外一个就是核心变强了，苹果说了“使用电池和电源有相同的性能释放”，所以必然续航会缩水。

首先，说一个电子产品公司是“美学权威”这种话就很奇怪。
卖设计不假，但凡是设计，必然有其针对性受众。

钱就是最好的投票工具。

没有必要说有刘海就不好、丑。

一个 RTX3090，如果他卖 5000 块钱，做成骨灰盒我都买。

再填一份合同就行了，只要信息真实就不怕。
和我媳妇儿结婚前，就是靠这个办的。

但问题是有可能要房主签个声明，这要看派出所政策。

一般来讲，首屏无响应 3 秒钟，就足以让用户放弃了。
但你可以通过其他方法去优化“无响应”这个事儿。

比如业界常做的：假 loading，假进度（一些无关痛痒的 Text 快速滚动），广告页，等等。

干了 7 年多了，你也应该明白，所谓“技术氛围”，“办公环境”，“公司福利”其实都是公司忽悠你加班的借口。

所以我个人认为，真正决定工作选择的，其实就两点。
1 、工作压力。2 、时薪。

剩下的都是扯淡。

这东西其实挺鸡肋的。

1 、原生 native 使其有很强的性能表现，但使用场景与官方又限制了其体量大小。
2 、原生意味着不能跨平台，开发者使用意愿低。
3 、原生意味着需要首次加载，导致首次打开体验差。

比如楼主的这个时钟，从我第一次扫描》（延迟一两秒）锁定框出现 app 名称，点击》（延迟一秒）弹出“轻 app”》点击打开，最起码过程中 ios 无响应了 3 秒钟。

这三秒钟足矣让我放弃了。

开源、组件化是趋势不假，但不要真的把自己弄成调参侠，引包侠。

1 、定时刷新为何会“会引入新的框架，存在的风险未知，可用性不高！”？？？
2 、可以每次请求接口的时候检查 token 的申请时间，然后判断是否需要刷新 token 。并不需要计时刷新。

btw：
在内存中保存一个 token，以及其有效期两个变量有这么难么？还需要“新框架”？？
至于说并发问题，给全局变量加锁即可。

理论上讲支付本身应该没问题。

问题在于：
1 、B 小程序如何通过审核（内容欺骗？）。
2 、如何精准确定 A 、B 两个小程序的不同 openID 对应同一人（用 unionID ？）

只有抢首发有用，给同事挂过很多票，都是只有首发才有机会。

@NoUltimate #79 你说的“其他 app 中要选取图片”的问题，ios 也有解决方案。

在其他 app 获取相册的过程中，默认是“最近图片”。也就是以图片文件的创建日期倒序。（图库是 exif 日期为准）
点击“最近图片”，就可以选取相簿了。

相当于你所谓的“不重要的在图库，特定的只要去特定文件夹里面找就好了”，在 ios 中可以变换为“不重要的在不重要相簿，特定的只要去特定相簿里面找”

ios 的“图库”，你可以只理解为是一种浏览向的娱乐功能即可，实际也是这样。

@LudwigWS #77 不想显示在“图库”中的图片可以用“隐藏”功能隐藏，会自动归类到“已隐藏”中。

不太理解楼主所谓的“混乱”的准确定义。

1 、ios 的“图库”，是给你翻着玩的（你可以理解为是一个 AI 加持的 viewer ）。你可以根据日、月、年三个维度看他通过算法筛选出来的精选照片。“所有照片”则是图片的罗列，方便你快速的浏览、归类、删除你不需要的照片。

2 、真正实现手工分类的是相簿，相簿只是对照片打了一个 tag 标签。

3 、在图库中删了，就是真的删了。

4 、在相簿中删，可以选删除了这张照片的特定 tag，还是彻底从资料库中删除。

5 、更加 AI 的功能是“为您推荐”中的“精选照片”和“回忆”。

所以正确的使用方法是：

平日看一乐的话，就看“为您推荐”，翻翻“图库”。
想找照片的时候善用搜索，比如“生日”、“水族”、“毕业”、“xxx （姓名）”、“7 月 25 日”，“北京”，以及通过自己手动归纳的相簿。

这其实是见仁见智的问题。个人认为单独讨论个体没有普世的意义。
统计数据相对于个人体验可能还更有意义一些。

同样是月入一万，不同的家庭财富积累，不同的资产配置，不同的受教育程度，不同的三观，都会导致支出 /储蓄比例的不同。

光聊自己铮多少，花多少，攒多少，也就平添以己度人的口水仗而已。

两米车宽有点恐怖(A8L 才 1945)，标准停车位未见得打得开门。

看了一下，如果说的是 avatar 的话，应该是<a>标签纵向位置导致 td 的高度变高。（正常 tr 应该是 48px，a 标签靠下，导致 tr 高度变成 53px ）

当 a 标签内的 img 向下对齐的时候，反而会和 a 标签重合，导致高度回归正常。

具体原因的话，在 W3C 标准中，a 标签默认是 display:inline，这会导致 a 标签和内联元素的高度不一致。
可以将 a 标签的的样式改为 display:block，然后正常设置 a 标签的高宽来解决。

搜索了一下，也有人问类似的问题，链接如下：
https://segmentfault.com/q/1010000000156955

这种私有云情况，如果有条件，走云校验。

如果没有条件，则每次续费下发加密的库文件。库文件最好夹杂业务，越复杂越好。

当然，如果死心塌地的走逆向破解，怎么防都没用。

看了一下，揣测就是监听了 input 框（ textarea ）的 change 事件，然后不断的给服务器提交数据。
第一次 get 的时候是服务器端渲染。

优化空间还是很大的，提交频率太高了。