移动端架构师都需要具备怎样的技术栈和能力

主要的能力

技术深度

技术广度

动手能力: 比如说造轮子的能力, UI(高级自定义UI, 通用UI组件库), LibrarySDK(通用基础库, 项目框架/架构)

经验丰富

辅助的能力

领导力

沟通能力

洞察与前瞻

赋能业务

技术栈

T字形技术栈

语言

语言高级特性

多线程与并发

Andorid高级技术

网络

数据持久化

图片

路由与导航

架构技术

构建与打包

性能优化

扩展技术

开发工具

混合架构技术(动态化容器)

运维

三方技术

技术全栈

深度广度

主要语言: java, Kotlin

辅助语言: javascript, TypeScript, Dart

泛型,

注解,

反射,

高阶函数,

闭包,

扩展,

Lambda

线程/线程池, java.util.concurrent, kotlin协程

消息机制,

虚拟机原理,

类加载机制

HttpURLConnection,

OkHttp,

retrofit,

RESTful,

网络调试与抓包

File&I/O, SharedPreferences,

SQLite, ORM(Room等)

Bitmap,

LruCache/三级缓存,

Glide/Fresco

ARouter,

Navigation component

Jetpack架构组件: Lifecycle,LiveData,ViewModel...

架构模式:MVC,MVP,MVVM

设计模式:单例模式,建造者模式,适配器模式....

工程架构:模块化,组件化,插件化,容器化

IOC架构:Dagger2

Gradle:构建优化,插件开发,插件发布,

APK打包原理

持续集成: Jenkins, GitLab Cl,

Travis Cl,

一体化: 打包上传(私服/蒲公英)

机器人通知(钉钉)

安全与逆向: 混淆/加固, 逆向/反编译

启动速度优化,加载耗时优化,流畅度FPS优化,内存优化,

网络优化,包大小瘦身

Android X适配与升级,大厂多屏幕适配,Android Q黑暗模式,AppBunle,权限治理

主要:Android

辅助:webStorm,VScode,IDE

协作: 开发规约, Git

构建:Gradle,Maven,Jcenter

调试工具:开发支持工具,云真机平台

web Debugging:Charels,Fiddler,Wiresshark

扩展工具:Xmind,Axure,UML

Flutter,

RN,

小程序,

快应用

监控(Crash监控):自建, Firebase,Bugly,友盟

日志系统:HiLog

热修复:Tinker,Robuse,Hotpatch

支付,埋点统计,推送,分享,扫码

后端技术:SpringBoot2,MuBatis,MySQL,Redis,Tomcat,Nginx

前端技术:javascript, TypeScript,react.js,less,AntDesign

小程序/快应用技术

如何从0开始架构一个中大型APP

需要考虑的事情

业务理解: 首先是业务理解，架构是服务于业务的，脱离业务谈架构，就是纯粹的耍流氓

赋能业务: 架构要能够赋能业务，比如业务是否有动态性的需求，以及灵活配置的一些需求，这些不能仅靠业务方来想，作为架构师要能够发掘业务潜在的一些诉求，从技术角度帮助业务更好更快的发展。有人会说，技术不能代替业务方。但技术能够帮助业方更好的去向前冲，如果说理解业务会让架构师走的快，那么赋能业务则会让架构师走的更久.

研发效率:

多人多团队协作: 我们需要考虑架构之间的解偶/模块间相互独立/ 单独仓库/jar/arr依赖
复杂度控制: 复杂度控制在组件内部, 对外简单可以依赖
复用: 为矩阵产品输出轮子, 一个中大型公司, 他的产品不仅仅单单是一个APP,有可能是很多APP的一个矩阵, 那么我们做架构的时候在考虑加工每个组件或者某个框架的时候，我们要能考虑能够横向的为其他的一些矩阵的产品输出这些轮子,而不是只服务于我们当前的这个APP。
编译速度提升: 组件单独编译, Maven私服, 构建加速

技术选型:

开发语言: 反面案例是单JAVA或单kotlin的模式, 正面案例是使用kotlin和java的混合方式进行开发,因为有很多第三方库是使用Java开发的, 所以单独使用kotlin过于时髦
架构模式: 架构模式方面的反面案例是MVC, 这对一个单工程小应用来说还是可以的,对于较大的工程应用就需要在架构模式上应用我们的MVP或者mvvm来
工程架构: 工程架构方面的反面案例是单一工程, 会显得我们的项目特别的庞大, 难以维护,不利于多人协作, 这个时候我们就需要应用到我们的模块化/组件化/容器化
混合架构: 混合架构方面的反面案例是Native+H5, 因为H5的性能跟不上, 所以说我们只用native+H5的方式的话, 显然不是最优的一些方案, 好的方案推荐使用Native+Flutter/RN+H5,既能体现我们flutter rn的一个动态信号, 又能够兼顾native的相关的体验和性能
网络: 网络方面的反面案例是直接拿网络库(OkHttp/retrofit)来使用, 正面案例应该封装统一的网络层接口, 我们的业务层不直接依赖网络库, 而是依赖我们统一的网络接口,然后我们底层提供可插拔的一些设计,比如哪一天我们决定不用OKHttp了,我们要切成其他的一些网络库, 这个时候只需要我们网络层做一些相关的适配,我们的业务层不需要做任何的改动
数据持久化:数据持久化反面案例是SharedPreferences+SQLite, 正面案例是File+SharedPreferences+SQLite/Room

数据层设计

一款APP在动手写业务之前我们先要设计好它的数据层,因为市面上大部分APP无不需要和数据进行打交道,数据层设计的好坏,在整个APP的架构中起决定性的作用,为两个方面

网络层:RESTful风格,提供统一的API接口

本地数据:提供ORM数据操作框架,减少对SQLite的直接操作,提供统一的数据缓存框架