怎么查看手机架构是armv7还是x86 如何看手机架构

MVC？MVP？MVVM？JetPack？插件化？组件化？容器化？Android的移动端架构，每个人眼里的定义都不一样，但是每个公司的移动端架构都是演进来的，现在大公司在android架构上用到的技术，肯定是能用上都用，只要能提高生产效率的。

这里想记录一下现在这个时间点，移动端架构能做到什么程度？

既然是能用到的技术就用到，那么怎么组装一个Android移动端的架构呢？跟着思路走一下：

1. 原生基本开发模板：MVC？MVP？MVVM？对应的android开发的基本模式，这里就推荐google官方的MVVM去做，结合JetPack Component可以基本大致满足常用的原生研发需求场景，这些组件的很多思想还是非常好的，可以基于这些Component进一步根据自己的业务场景进一步封装，定制化出一些业务架构上的一些组件。

1. 混合架构容器：原生上面的最基本开发模式列完以后就是ReactNative、Flutter、H5这类混合开发模式，现在类似于这样的混合架构，我自己的命名就是容器化移动端架构，为什么这样去说就是因为如果你用了这些混合技术，通常它们都是类似一个引擎，你通过原生的RootView去装载以后，再给个其他语言（JS、Dart）的打包产物，就可渲染出来你要的页面。这里想到一个很好玩的东西，就是什么情况下我们要用原生开发？什么时候用ReactNative、Flutter来开发？因为他们都在一个架构里面，其实对于我们团队来说，基本上能用ReactNative来开发的就不建议用原生来开发需求页面，除了那些实在RN做出来的页面满足不了需求，但是目前看起来基本上没有什么满足不了的，因为实在不行就用原生实现一个RN的组件，这样就可以用RN来开发了，毕竟一套代码就两端。
2. 混合架构路由：因为是混合架构，不得不说会有这样的场景，支持所有容器的通信工具，比如RN的页面要启动一个原生开发的Activity，又或则原生的Activity页面要去打开一个Flutter的页面做一些操作后再取回一些值，那么就需要有这样的协议：RN<->原生、Flutter<->原生、Flutter<->RN，这样的互通协议，路由协议详细讨论的话还是有很多细节的，比如同步、异步调用Fucntion、路由页面（带参数、不带参数、处理返回参数、不返回参数），有了这样的路由，混合容器架构的最基础通信就有保证了。
3. 原生组件化：组件化在一个Android的原生架构上是必不可少的，通常用来划分不同的功能模块、组件、SDK，主要用于原生架构功能分层，在Android Studio工程上就是对应Module，这个划分的过程也是一个演变的过程，只有一些是比较基础的就可以马上划分出来的，比如基础的UI组件、网络分装库、持久成封装、日志库。

1. 组件化独立运行能力：这里对于组件化，单独拿出来说一下单独运行测试能力，这个其实是非常重要的，对于一个大型项目来说功能模块肯定是持续增加的，不能让这个影响研发过程中的编译效率，否则对于研发人员来说肯定是个负担，这也就是为什么ReactNative天天说的别傻傻的在那里去等编译，所以针对不同的业务模块在组件化里面要能够进行单独运行来说也是有不少细节的，但主要的点还是单独运行模型是基于同进程还是不同进程，市面上开源的组件化方案也是可以按照 同进程、不同进程划分，这个是我这边的一个划分标准，为什么这样划分，也是因为两种组件化的模块通信是有区别的，目前我比较看好不同进程的组件化单独运行能力，因为一个大型项目的模块划分就真的像微服务架构一样，有了组件化独立运行能力我们就不再担心项目代码量过大而引起的研发阶段编译耗时问题了，换句话说加强了架构的横向拓展能力。
2. 插件化：插件化这里指的是原生用Java代码开发的插件化，插件化的时候其实是会越来越少的，因为随着混合容器化架构的成熟，插件化的功能其实慢慢会退出移动端架构，之所以还存在是因为有些功能模块是以前原生Java开发的，这块功能不能丢失，但是又么有时间重构成RN或者flutter，所以还是持续用着，还有就是一切第三方的apk要做一些功能集成，就采用这样的方式进行扩展。
3. 热更新能力：用于修复原生Java开发的bug能力，也用于发布hotfix版本能力，。
4. 日志系统：主动上报、推送上报，这些都是基础功能，关键节点日志模块划分，如网络日志、崩溃日志、业务操作日志、性能日志等，日志系统最重要的就是能不丢失的情况下及时能回捞上报到自己的后台服务器快速定位生产问题，日志系统就怎么方便处理生产问题就怎么演变。
5. 性能监控：OOM、CPU、FPS、IO、电量、数据库、UI渲染等，有条件的可以将数据进行上报统计分析，进行下一步优化，条件差点的就把关键信息输出到日志系统，通过捞日志分析的方式查看APP的运行情况。
6. 混合架构持续集成：这个在混合架构里面也是一个大头，但是可以划分成，不同的打包产物在Jenkins上面对应不同的Job，移动端混合架构的持续集成核心就是并行，不同的打包产物、不同的功能、组件、模块尽可能的支持并行打包，这样基本能满足大部分的需求，一些特别大的项目，也基本上考虑的也是并行打包、能利用缓存的产物就不用重新构建、然后项目是在大的不行，性能跟不上的就花钱。
7. 业务架构演变组件、模块：这部分是所有公司根据自己的业务场景去定制化出来的一些功能，主要目的也还是保证业务功能的可扩展性、可维护性、业务可快速迭代性，这部分就是长期重构演变出来的核心功能，这部分也是比较难的，因为需要深入剖析业务场景，根据业务场景建模打造出来的功能模块，对于研发人员来说的表现能力就是，这类模块通常涉及到一些新的业务需求，通常只需要配置一些信息或者组装一些信息就可完成需求开发，这类就是定制化的一些业务模块与组件。

Andorid移动端架构，不同的人眼里有不同的结果，目前也很难定义出一些标准的规范出来，以上列出来的一些内容是自己觉得在Android移动端架构中比较重要的能力，持续学习，祝进步！