订阅制现在相对还行合理的几种情况：
情况一：订阅时可以使用软件，软件可以不是最新版，可以选择自己想要的版本（适合线上功能不多的软件）
情况二：订阅时解锁当前版本的所有需订阅功能，过期后这些功能不过期，想要之后的新功能，需要继续订阅（也是适合线上功能不多的软件）
情况三：订阅提供的权益基本稳定，没有较大变动。新功能需要升级账号或订阅额外的功能包，如：普通会员 /黄金会员 /钻石会员这样的多级订阅。
情况四：订阅提供的权益只做增量，不对原有功能进行修改。

我在官网上看到的时候，以为会有优惠活动的...看来只能等我的教育授权到期后拿 75%的折扣了。

薪资期望可以高一点。工作城市有要求么？

如实说就行。

（不过 A 公司需要帮你交的公积金和社保什么的也因为这个操作可以少交了不少。）

emmmm，看你刚需软件有哪些。如果 Mac 上有刚需，那就买 MacBook Pro 或者 Mac mini。如果没刚需就组一台台式机，拓展性和性能上比较好。

不需要这么麻烦，你去了解一下 APP 广告联盟，有专门的不同类型的广告 SDK 文档的。

当然，如果不需要后端存储的话，前端处理压缩图片就行。（但这种工具已经很多了）

实际应用的时候还是前端限制原图大小，后端压缩裁剪图片比较好。

有一个常见的场景：我需要压缩与裁剪出不同尺寸的图片并存储在服务器上。

后端处理：图片上传到文件服务时，后端会将其裁剪或压缩成不同比例的图片，对不同尺寸的图片进行存储。此时服务器后端计算资源被占用的相对较多。

前端处理：前端做裁剪与压缩后上传到后端，需要上传多次，网络相对来说可靠性一般，可能你传了 3 个尺寸的图片，后面 2 个尺寸的传输失败。这时候图片传输的失败率会大大增加，而且服务器带宽资源被占用的会比较多。

Java 一般要用 IDEA、用 git 或者查资料开个 Chrome 浏览器。

我个人建议内存 16GB 及以上，CPU 和 GPU 别太过分就行的。

自己在用的是 LG gram 14，没有独显（玩游戏一点也不行），自己加了一根内存，总内存 24GB，Java Dubbo 微服务开发。

如果你要涉及 Dubbo 微服务开发的话，Windows 不适合作为开发运行环境。因为 windows 多张网卡的问题，经常出现 zookeeper 找错网卡，需要等一段时间才找到正确网卡。（ macOS 没有出现，Linux 不会出现）

1.安全

2.可移植性
- 除了 UI 有关的部分外，其它 Java 库能很好的支持平台 duli 性。
- Java 的基本数据类型的大小和有关传递的行为都有明确的说明。
（例如，Java 的 int 类型永远是 32 位的整数。在 Java 中，数值类型有固定的字节数。二进制数据以固定格式进行存储与传输，消除了字节顺序（大端小端）的困扰。字符串采用 Unicode 存储）


3.多线程
- Java 是第 1 个支持并 发 程序设计的主流语言。

4.高性能
- 字节码可以（在运行时）动态地转换成对应运行这个应用的特定 CPU 的机器码。

5.动态性
- Java 相比 C/C++来说更具有动态性。
- 库中可以自由地添加新方法和实例变量，对客户端却没有任何影响。
- 在 Java 中找出运行时类型信息十分简单。

页面设计上有一些问题：滚动页面的时候经常因为鼠标停在某个榜单上滚动到榜单，需要把鼠标移到细小的间隙里。

个人建议有两种改进方案：
方案一：各个榜单不要做滚动条，显示条数截取前 5-10，点击榜单后在网页中央 60%的区域显示 Modal 框展开榜单。
方案二：榜单可以做滚动，但网页的所有榜单聚集在中间 60%的区域内，两边留空让鼠标放。（但是鼠标移到中间的体验还是很差）

返工统计和健康打卡这一块，阿里的杭州健康码在杭州已经投入使用，并让很多企业已经复工了。各地应该会选择直接使用阿里的全国健康码了，并且健康码可以直接关联企业员工健康码。

这一块的需求……基本已经没了。

@rosu
这样解析我用 fastjson 写过的，甚至还解析了 List 里套 List。可以参考我的开源项目的 CatContainer 对象的 put 方法的调用链： https://github.com/lychs1998/CatMock

@wwwjf
Map 转换成实体的时间复杂度和 Map 无关，和目标类型含有的字段数有关。

假设 Map 里有 n 个键值对，目标类型里有 m 个属性。转换的时间复杂度是 O(m)，逻辑是查询 m 次属性名对应的值。

假设 List 里有 n 个键值对，目标类型有 m 个属性。转换的逻辑是提出每一个属性名，去 list 中遍历是否存在这样的 key 值，时间复杂度应该是 O(m*n)。

@serge001
其实我觉得这样的数据结构设计没啥问题。jsonObject 本来就是一个特殊的键值对的 list。
获取指定 key 的键值对是最快的，每个语言都提供了遍历键值对的方式，只不过你们的安卓开发不会而已。

@jinhan13789991
你这样设计有一个很明显的问题，假设数据里一共有 n 个键值对，我获得某个键值对的时间复杂度是 O(n)，而使用楼主的存储方式哈希映射下时间复杂度是 O(1)。

公司里的大致流程：
1.讨论需求（业务逻辑先理清楚）
2.原型设计（把前端界面的原型和交互逻辑定下来，这些会影响后续接口的逻辑）
3.数据结构设计（考虑数据的拓展性和向下兼容性）
4.接口设计（一般用 mockjs 的语法设计，mockjs 能部署虚拟的 mock 服务器，方便前后端分离开发）
5.前后端分离开发（按照先前设计的接口进行开发，避免前端等后端的情况）
6.逻辑性和功能性测试（单元测试，一般与业务流程关系不大）
7.验证网部署测试（业务流程测试，期间产生的 BUG 通过 issue 指派给相应人）
8.测试完成，合并到 release 分支进行部署