官网下，并不繁琐。
很大程度上，你只需要登录三个官网，分别是：芯片组、主板、显卡（ NV/AMD ）

如果你要使用外设的特殊功能（比如罗技），那么其实就已经脱离了“驱动”的范畴。

怎么看都是必然的。
1 、当前架构肯定有前任 CTO 的个人偏好。而新 CTO 未见得熟悉与擅长。
2 、当前架构肯定有各种妥协和取舍，甚至是雷。新 CTO 肯定不为此负责。

所以即便是客观角度看，也一定会调整的。

目前，你能听说过的技术，其实都挺完美的。
JAVA 界的 SSH ，web 界的 JQuery 、ExtJS ，他们都没有什么硬伤。

技术的流行趋势改变，不是因为老模式、老框架、老库不行了，而是整个软件工程产业的玩法、趋势、需求变了。（楼主可以搜索下关键词“康威定律”）

如果你有一个契合的需求，选择“过气”的技术实现选型来实现功能的角度讲，并没有什么问题。

问题主要在后期维护时，框架本身的 bug 没人支持，以及后续的维护者上手难度高。

部分软件如果选择“仅为我”，有可能会影响开机自启的服务在未登录时的有效性。
比如串流软件 parsec 。

薄膜标准 87 键的很少

要么选 104 键。
要么选择轻便键盘（非标准 87 键）。
要么选择静音红轴。

不知道国产安卓的找回逻辑。
iphone 的查找还是比较有用的。

1 、最大限度的降低了手机内信息被盗的可能性。
2 、最大化的降低已经丢失的手机的可用价值。

这都给手机找回提供了正向条件。
当然，你指望靠一个软件功能来实现《天下无贼》，明显就是不可能的。

直接 native+webview （也就是原教旨主义的 hybrid app ）是最佳方案。

1 、网页程序修改的内容极少（只需要修改和微信 JSAPI 交互相关的内容）。
2 、native 部分需要做的功能不多，甚至都不需要带界面的 Activity ，只需要做屏幕适配+JavaScript Interface （或者叫 JSBridge ）所以开发门槛很低。并不需要特别专精的人员。

一个 UI 都不需要的 native app ，选型 flutter 实在是大炮打蚊子。
而且即便使用 flutter ，native 逻辑的实现（调用硬件，鉴权等）也是少不了的。

没听说过“不让收集数据”这个说法。

微信小程序对于手机号的管控也非常严格，需要 button 特殊声明才能启动事件。
最近对于隐私也升级了，你不声明隐私获取范围和用途不能审核新版本。头像和昵称也变成了输入法 hint 的方式。（不再走服务器端逻辑了）。
所以收集这个角度没问题。

除非你的产品涉及到未脱敏展示（多条且大范围的显示个人信息，单条没关系），才会有问题。

不太理解楼主的用意。

1 、假设要是手肘放在前面，那普通的桌面就可以实现。除非楼主肚子特别大。
2 、假设要是手肘放在侧面，那这个弧度得多严苛？量身定做？

界面功能设计有了么？

如果没有，确实估不出来精确的工期。
如果有，那么每个页面做多长时间你没法估计？如果没法估计，你就不怕做着做着发现某页实现不了？

问题就一点：“不好意思”。
不好意思派活，不好意思沟通，不好意思验收。

1 、“以前没感觉，现在看到他们玩手机，有一点点不开心吧”
都能玩手机了，你的工作任务是怎么安排的？既然担心代码质量和业务达成率，宁肯让组员玩手机，也不搞单元测试与 code review ？

2 、“上一点造成的结果就是很多工作堆到了我自己手上”
为何不把工作分配出去？那么多现成的自动化工具和流水线策略。

3 、“我确实缺少一些大局观，不太能把控整体进度”
工作量预估和大局观无关。
如何保证最大限度的提高业务达成率？多测试。
如何保证 deadline 的有效性？多使用“曳光弹”式的开发流程，多验收。
仅此而已。

如果一个功能，你无法预估出工期，说明你对目前小组采用的技术选型，以及小组成员的能力完全没有把握。
在此基础上你自己做什么都没用。唯有三点，沟通、测试和验收。

因为无论如何，你自己也不可能给 10 个人擦屁股。

能够讨论的点是楼主为什么觉得好用，论据是什么。

楼主定义谁好用这个结论本身，没人操心。