太酷了

支持独立开发

d

参加一下

其他朋友其实已经讲的差不多了，我给一些具体的建议

一. 个人优势建议缩短一些，单列一下独特优势，并把技术栈的部分单起一个栏目，例如这样
个人优势:
1. 在团队在担任过产品职责，有较好的产品能力和项目落地经验。
2. 有过全栈研发经验
3. blablabla

技术能力:
1. 精通 Laravel ，是早期 Laravel 的推广者和 laravel-China.org 的维护者(加上一些证明,比如具体的 title 啊,项目的成员列表啊)
2. vue....

二. 在工作经历和项目经历中的很多描述过于口语化，带有不必要的背景信息，应当精简

例如这一句就不太合适，读起来摸不着头脑
出身于 LaravelChina 社区的技术外包公司，在职期间主要是作为项目负责人对接与完成项目。大部分时间为 Remote work ，主
要负责了如下任务：

完全可以改成这样，并在面试的时候再进一步解释具体情况:
作为项目负责人对接项目需求，拆解任务到团队，推动项目如期交付:
1. xxx
2. xxx

三.项目经历里的一些描述过于"水"了
例如这个描述，绝大多数文字都在描述业务，而没有讲技术点

2. 使用 Wepy 完成小程序用户端 /店家端开发。支持动态生成门店小程序，前端编写 Render 方法，支持生成自定义海报图，支
持玩家在线付费，组局，储值，积分兑换。支持查看剧本、主持人详情评价及交互。店家端支持动态权限分配，支持配置门
店会员等级规则、自定义装修、剧本、组局、储值管理。支持查看财务报表、流水。支持动态生成独立小程序。

除非是同行，否则面试官和 hr 是不会关心你的具体业务的，大部分这种描述完全可以简化成"使用 xx 技术解决 xx 问题、搭建 xx 系统"
然后在面试的时候再解释为什么要用 xx 技术，比如是行业惯例？满足了你们某些特殊的需求？
在应用开发的过程中遇到了什么技术难题？可以挑核心的往上写一写

cXVpbl8xMDI0

@jeesk @unco020511
这个限制的意义是这样的
如果一个应用声明需要 camera 权限，那么它通过 IMAGE_CAPTURE 调起相机的时候也需要权限
如果一个应用声明不需要 camera 权限，那么它就可以不需要权限通过 IMAGE_CAPTURE 直接调起系统相机

举个例子来说
假设有一个美颜相机 app ，其中既有美颜相机的功能(基于 camera 权限)，又有调起系统相机拍照的功能(基于 IMAGE_CAPTURE)
用户当然希望这两个权限在设置中对应一个相机权限，可以一起关闭和打开

而如果这个 app 是一个笔记 app ，其中只有调起系统相机拍照插入图片的功能(基于 IMAGE_CAPTURE)
那么对用户和系统来说，这个调用是绝对安全的，没有泄漏隐私的风险
就可以不要求 app 声明和申请 CAMERA 权限

我个人理解这是在一个权限管理，开发者适配成本，用户体验之间的妥协方案
不过安卓的权限确实是一言难尽，只能建议别想太多

MIUI14 现在好像只有开发版
社区的反馈好像没有比较专业的人跟进，在设置-问题反馈里提个反馈吧

目测，更可能是 PackageInstaller 那块用的不对，比如你没有 apk 文件的读写权限或者安装 app 的权限。
可以打个 log 看看。

另:你们是手机厂商么，还是嵌入式什么的，prod os 咋会没有 adb 。

fNNxsB 已用，感谢

支持，做个分母

对 BeanUtils 不是很熟悉，推测你这个问题应该是因为 Java 的泛型擦除
Java 的泛型只在编译期进行类型检查，而 BeanUtils 的 Set 是通过运行时反射，不需要经过类型检查

所以执行的时候就相当于给 courseCategoryResponse 的 List<Object> children(原本声明要求 List<CourseCategoryResponse>) 赋值了一个 List<Object> (实际上是 List<Category>), set 时都是 List<Object>不会报错，但是 get 时你可能通过指定变量类型做了一个类型转换，就会报错。

你这个在题里没问题，但实际场景这么干肯定不行

参考 git 文档, 由于 branch 本质是对 commit 的引用，所以光从语法上来说，很多时候 branch 和 commit 是可以相互替代的
https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell

但是实际上你这种写法只是给自己添了没必要的麻烦，建议好好按他的教程学吧

老板加下我细聊吧，两年 Hybrid 经验, 比较熟悉移动端
和楼上一样，看 result
https://s.api.enetapi.com/api/Base64?jiemi=cXVpbl8xMDI0

开发者真的是找死啊。。。做这种玩意风险太大了
就算他的代码没问题，如果被 V 社检测封号，算谁的责任？如果有人在代码里下毒再分发怎么办？如果被定性为外挂怎么办？