如果都可以 adb shell 了，那么这一款应该你可以用。部分国内的 Android 系统，需要在开发者选项中打开 [USB 设置] 、 [USB 输入] 的选项后，才可以控制，否则只能看。

https://github.com/Genymobile/scrcpy

路由器一般来说，能获取到的信息就是二层了，主要应该是 mac 地址，如果需要解析三层，甚至#3 说的 UA ，解析到 7 层，小几百块钱的路由器，CPU 就炸了，性能完全不够。

赔偿可能性极低，民用（与之对应的是军用）基本上不保障可用性。

就像酒店里突发停电，导致用户无法入住，酒店也不太可能找国家电网赔偿一样。

刚开始工作的时候，占比 30%，去年开始占比 16%，但是房租的绝对值上涨了 200%

现在就没有房租了，管住，二室一厅，如果按市场价值来算的话，也是 16%左右的占比。

有些程序指的是哪些，给几个例子看，让人上来就猜是不是有点困难。

@ccyu220 #1 哈哈哈 也不能说手撸就安全，要是我手撸的话，估计就全是 bug ，内存泄漏，空指针了。高水平的开发人员，应该用什么语言，关系并不大。

@icy37785 #8 我的 xbox 看爱腾优，都可以 1080 以及 4K 呀。自己下载的话，我只尝试过下在 nas 里，通过 smb 访问，vlc 播放，也没什么问题，字幕也支持。是我们用的哪里不一样嘛。

从我自己体验来说，除了贵，没什么问题呀。本来买回来是想玩游戏，现在主要就是当作机顶盒用了。

我来打个岔，其实 Xbox 才是宇宙最强（最贵、最费电）机顶盒，除了看电视，甚至还可以玩游戏，超值。

@Uzuki #4 咨询客服。如果客服不知道话，建议换一家。这个从外观上看不出任何区别。如果产品的技术参数里没有提及，多半就是不支持了。

Netflix 一类的流媒体 如果需要看 4K ，需要显示设备支持 HDCP ，即输出端（盒子）、输入端（电视）都需要支持。同时盒子需要通过 Google DRM 的设备认证。（ AppleTV 就没有这个，毕竟没有第三方 apple 盒子）

山姆的定位是

价钱一样的，我比别人好
东西一样的，我比别人便宜

山姆的法式羊排，每次去都必买，空气炸锅 200° 10 分钟，翻面，再 10 分钟。嘎嘎香

个人觉得，线上交友，唯一能匹配的需求是约炮，其他都白扯。只有约炮可以不在乎其他的，上来迅速升温。并且双方天然具有话题性。也就是能聊起来。

和一个完全不知认识的，能有什么好掰扯的。要不查户口聊几句就嗝屁了。你说的，基本上一个陌生人也不感兴趣。

而且产品定位的目标人群是社恐人，但是社恐就是不想面对其他人，与软件的定位是有冲突的。

自认为社恐，但是同时愿意与人交流，这就不是社恐人群。

@shmilyin #20 这个方法也不是不可行

假设 stream 0 是视频，stream 1 是音频

ffplay -i <抖音 URL> -i <CCTV URL> -map 0:0 -map 1:1 -c copy

@arnosolo #66 我也是小公司，也是一个人干很多事情，但是你的简历中看不出你做了什么。抛开与应聘岗位不符的内容，几乎没有任何关于项目内容、实施方案、技术细节的描述。

多描述一些项目实施的技术细节。例如 AI 项目可以描述前端如何实时展现效果，是采用 canvas 还是 opengl 等等，这些细节可以让人知道，你确实做过，而不是顺嘴胡扯的。

ps4 现在肯定是不用考虑，没预算 xss ，有预算 xsx 、ps5 二选一

简单地说，简历上看不出你具体做过什么。

AiPassportPhoto 介绍中包含：
1.使用 Vite + Vue3 + TS + Unocss 构建
2.使用 Github Action 实现 自动部署
3.使用 vue-i18n 实现 多语言
4.使用 aws Cloudfront 和 aws S3 实现 全球 CDN
5.使用 vite-ssg 实现 静态站点生成(SSG)
6.使用 eslint 实现 代码自动格式化

1/5/6 是工具链的使用，2/4 是用的第三方平台功能与前端关系并不大。也就是说唯一能和你前端岗位匹配的介绍只有一条 i18n

Unblur Image 介绍也是差不多的问题

使用 Vite + Vue3 + TS + Tailwind css 构建, 适配各种屏幕尺寸
使用 Github Action 自动部署到 aws

两条都和前端关系不大。至于服务端部分，因为与你的前端不符，通常不会作为考虑因素。

也许你非常棒，但是通过这一份介绍来说，真的看不出来。至于后面的趣味项目，与你的前端岗位不符，可以直接忽略。

与岗位关联度不大的，可以不提，比如 GitHub action 、CDN 这种更偏向运维向，本质上和前端没什么关系。

所以你可以重新考虑一下你期望的岗位，到底是不是前端。

@julyclyde #3 一个是可能没法防止，另一个可能是没必要。因为 IPoE 阶段，设备并不能联网，进而无法授时，所以机顶盒是没有可靠时间戳的，如果需要防止重放，不依赖时间戳，那可能只能生成的随机值，但对端很难判断这个请求是否被重复使用，同时 DHCP Server 一般性能并不好。

另一方，通过了 IPoE ，也仅仅只是通过了设备认证，并不能访问任何资源。业务侧上还有二次认证，会再次检查设备与用户账号、宽带账号的绑定情况，如果验证不通过并不会下发视频信息。所以即使接入了网络层，影响也有限。

当然，原则上现在运营商大多采用组播下发视频（除部分由于资源限制的用户，多数为机顶盒公网用户，仍然采用点播），所以如果 A 用户成功通过授权拿到组播地址，B 用户可以在仅接入网络，但不通过业务层认证的情况下，访问组播资源。

@julyclyde #1 作为研究，当然可以深入进去，了解其具体的算法。我只是作为使用目的，因此并未研究，并且实际抓包中发现，option 60 每次并不相同，可能与其采用的 DES 算法有关，也可能其中包含时间戳。实际测试中发现，重放并没有问题，所以就没有深入研究。IPoE 阶段并未实质验证用户账号，仅仅验证了接入设备是否可信，根据现有实验，这一步应该是纯算法认证，尝试过把 A 家里的机顶盒拿到 B 家庭中（同地区同运营商，不同区县），一样可以通过认证，即设备号与宽带账号并无绑定关系。IPTV 的业务层认证是通过 HTTP 协议承载的。