Android 零基础, 现在要负责公司的一个项目, 还望老手给一些建议

我也是安卓零项目起手，一边做一边看文档一边问 LLM ，仅要理顺架构，数据流就问题不大

1 如果你会 Java ，那就直接 Java 算了，否则选 Kotlin
2 因为界面不多，要考虑兼容性和性能，直接用原生的 View 实现
3 日志收集和崩溃上报集成个第三方的框架

你还没考虑到这里最大的坑，就是不同安卓版本机型的 NFC 可能会有各种兼容性的问题，尽量找个别人封装好的 star 最多的库吧

可以试试 uniapp
bug 上报的话 bugly 或者其他 APM 平台，搜一搜就有了。

特别是大部分老年人使用的低端机。

低端机哪来的 NFC ，先跟领导讲清楚。

零基础新项目的话，直接用 flutter 好了，可能用到的插件：
https://pub-web.flutter-io.cn/packages/flutter_nfc_kit
https://pub-web.flutter-io.cn/packages/sentry_flutter
https://pub-web.flutter-io.cn/packages/flutter_inappwebview

1. 现在都推荐 Kotlin ，原因就是官方基于 Java 的库不打算更新新特性了，后续基本就没有 Java 这东西了。现在查资料基本都是用的 Kotlin 的，你有 Java 基础，Kotlin 对你来讲应该犹如开挂切菜。
2. 你的页面比较简单，View 和 Compose 都差不多，但是你的前端经验是 Vue ，而不是老式的 Jquery ，可能用 Compose 更加适合你。官方后续也只可能推 Compsoe 。
3. 集成第三方的 SDK ，例如腾讯的 Bugly ，这个还是挺好用的。
4. 这个就是你 App 的架构设计问题了，和 Android 没关系。通常比较简单的做法是先拉取一个配置文件。然后直接用配置文件里面的资源。你把资源拉下来做对比, 有更新就替换，这个步骤听起来很扯，你都拉下来了，直接用最新的不就行了？这里一定要注意，图片资源一般你都是使用第三方库加载的，因为缓存问题，你最好不要使用同一个 URL 。更新了的图片要使用不同的 URL 。

kotlin 和 java 都无所谓，但是原生安卓起手肯定是 kotlin ，java 已经不是优先选择。kotlin 语法基本上和 js 也差不太多，写简单的东西不会碰到语言障碍。

直接用 传统 view + xml 也许对界面少的更加方便。

在线更新会把你简单的 App 搞复杂了。

我也是安卓新手，岗位前端，年初开始依靠 Ai 维护更新着公司的安卓 App ，如果是我的话考虑到兼容性的问题

1：语言无所谓，Java 和 Kotlin 本来就是兼容的
2：页面绘制建议用 View ，因为要兼容老安卓机型，新手遇到兼容性问题是很头疼的，别给自己上强度，没苦硬吃
3：第三方 SDK
4：6 楼的建议足够了

最后，别用 uniapp

kotlin+view
弄个友盟收集下 log 齐活了

https://ex.noerr.eu.org/t/1141873?p=1#reply2 妈的我也有遇到类似的问题的困惑，最大的问题永远是各个厂家的调用是不一样的,vivo 写好的代码在三星就不正常，匹配好这两个华为也抽风，吐了

会 Java 就 Java ，用 Java 就用 View ，compose kotlin 写的，（推荐原由：没必要没苦硬吃），你又不是以后要搞这个，这东西学习成本很高的，想对 Java 来说

推荐 tauri 支持 NFC

可能编译问题比较麻烦，尤其是 Gradle 的使用，各种版本兼容性等，这玩意很依赖经验，需要耐心尝试

下载一个 cursor ，解决所有 UI 问题

首先我非常建议用 kotlin ，而且是 full kotlin ，本身 kotlin 经过优化已经和 Java 原生没啥性能差别了，而且 full kotlin 还可以不用考虑 Java 的空安全问题了。Java 你如果用了某些高版本特性或者函数必须 desuger 。而且某些机型魔改 ART ，未实现 JVM 中的某些函数（此处指某国产自研品牌），你用 kotlin stblib 中自己实现的同功能函数就不会遇到这个坑。
至于框架的话，考虑到设备兼容性和性能较低，首先排除 flutter ，在老低端机上性能较差，而且新版本用的 vulkan 和 Impeller 对老设备兼容性很差。uniapp 性能较差，uniapp-x 虽然是编译到原生，但其可用的插件很少，需要根据业务慎重考虑。所以基本就是 compose 和 view 里选。
你提到的 compose 性能问题，在多个版本的优化后，基本是早期才有的问题了。目前最多就是在长列表加载复杂数据这种场景，可能在某些极端场景下不如 recycleview 了，毕竟 recycleview 是优化了很多年的东西了。而且 compose 的一个好处就在于和原生 view 无缝兼容，具体使用中可以和原生 view 混合编写。原生那堆东西写起来非常折磨人，不如 compose 写起来舒服多了，你是前端的话应该更有体会。但是 compose 也不是说没有别的问题了，比如最新版本 1.8.x 我记得在某些 Android p 设备上会闪退，需要一点魔法，太旧的版本性能又太差，我个人建议图稳定先 1.5.x-1.6.x ，等熟悉了再升级。还有就是 compose 最低兼容到 Android 5 ，你要是需要兼容 Android 4.x 这种极老的设备的话，那就只能选择原生 view 了。
原生 view 是兼容性最强的，但也是坑最多的，写起来最折磨人的，上限极高下限极低，完全看你水平了。我反正能不用原生就不用原生写，太折磨人了。原生 view 除了写法折磨人，主要坑点在于不同版本兼容性适配，style 系统，还有不同系统对于 view 的魔改上。其中 style 系统折磨人的地方在于，它会因为你用的不同 SDK 版本，不同真机系统而出现不同的 bug ，还有 IDE 大多时候识别不出来 xml 中的问题，你需要在编译时甚至运行时闪退才知道有问题，而且很不好排查问题出在哪里。还有不同品牌系统多多少少都会魔改 view 系统，你得替他们擦屁股。

@1una0bserver 你如果要用原生 view 写的话，我建议用 anko ，Contour 之类对 view 的 dsl 封装写，尽量避免用 xml ，一是更加接近声明式的写法，写起来更舒服点，二是避开 xml 中写 UI 的一堆坑。

话说老年人使用的低端机会配备 NFC 么

@kaicity
@LittleFox 早几年确实有些运营商定制的低端机是有 NFC 的，甚至是全功能的 NFC ，不过目的不是给老人用的，是给营业厅的工作人员开卡用的

这个简单，用 Java 跟原生 view 就行，可以兼容老机器，你自己都说了，不需要华丽的 UI ，那就是有个结果反馈跟读写进度显示就行了，就一个 image 跟 button 就能完成功能了 甚至都不需要 button ，直接在启动的时候，开个后台线程用来读写数据，然后把结果反馈到主界面的 image ，就行了。

本来想说新手还是 xml 吧，但是 ai 时代，compose 不是问题