android模型,mobile模型

为什么 Android 的 UI 框架使用单线程模型，比多线程模型有什么优点

·如果有大量的线程,会影响性能,因为操作系统需要在它们之间切换。·的线程需要的内存空间。·线程可能会给程序带来“bug”，因此要小心使用。·线程的中止需要考虑其对程序运行的影响。·通常块模型数据是在多个线程间共享的，需要防止线程死锁情况的发生。一些线程模型的背景可以重点讨论一下在Win32环境中常用的一些模型。·单线程模型在这种线程模型中，一个进程中只能有一个线程，剩下的进程必须等待当前的线程执行完。这种模型的缺点在于系统完成一个很小的任务都必须占用很长的时间。·块线程模型（单线程多块模型STA）这种模型里，一个程序里可能会包含多个执行的线程。在这里，每个线程被分为进程里一个单独的块。每个进程可以含有多个块，可以共享多个块中的数据。程序规定了每个块中线程的执行时间。所有的请求通过Windows消息队列进行串行化，这样保证了每个时刻只能访问一个块，因而只有一个单独的进程可以在某一个时刻得到执行。这种模型比单线程模型的好处在于，可以响应同一时刻的多个用户请求的任务而不只是单个用户请求。但它的性能还不是很好，因为它使用了串行化的线程模型，任务是一个接一个得到执行的。·多线程块模型（自由线程块模型）多线程块模型（MTA）在每个进程里只有一个块而不是多个块。这单个块控制着多个线程而不是单个线程。这里不需要消息队列，因为所有的线程都是相同的块的一个部分，并且可以共享。这样的程序比单线程模型和STA的执行速度都要快，因为降低了系统的负载，因而可以优化来减少系统idle的时间。这些应用程序一般比较复杂，因为程序员必须提供线程同步以保证线程不会并发的请求相同的资源，因而导致竞争情况的发生。这里有必要提供一个锁机制。但是这样也许会导致系统死锁的发生。进程和线程都是操作系统的概念。进程是应用程序的执行实例，每个进程是由私有的虚拟地址空间、代码、数据和其它各种系统资源组成，进程在运行过程中创建的资源随着进程的终止而被销毁，所使用的系统资源在进程终止时被释放或关闭。线程是进程内部的一个执行单元。系统创建好进程后，实际上就启动执行了该进程的主执行线程，主执行线程以函数地址形式，比如说main或WinMain函数，将程序的启动点提供给Windows系统。主执行线程终止了，进程也就随之终止。每一个进程至少有一个主执行线程，它无需由用户去主动创建，是由系统自动创建的。用户根据需要在应用程序中创建其它线程，多个线程并发地运行于同一个进程中。一个进程中的所有线程都在该进程的虚拟地址空间中，共同使用这些虚拟地址空间、全局变量和系统资源，所以线程间的通讯非常方便，多线程技术的应用也较为广泛。多线程可以实现并行处理，避免了某项任务长时间占用CPU时间。要说明的一点是，到2015年为止，大多数的计算机都是单处理器（CPU）的，为了运行所有这些线程，操作系统为每个独立线程安排一些CPU时间，操作系统以轮换方式向线程提供时间片，这就给人一种假象，好象这些线程都在同时运行。由此可见，如果两个非常活跃的线程为了抢夺对CPU的控制权，在线程切换时会消耗很多的CPU资源，反而会降低系统的性能。这一点在多线程编程时应该注意。C++11标准中，STL类库也实现了多线程的类std::thread，使得多线程编程更加方便。

相关问答

Q1: Android模块化设计方案之使用代理模式解耦

Android模块化设计方案系列文章：

1、 Android模块化设计方案模型图

2、 Android模块化设计方案之接口API化

3、 Android模块化设计方案之使用代理模式解耦

本篇是Android模块化设计方案的第三篇，也是对 第一篇 中ThridLibs Proxy模块进行说明。

很多人觉得对那些优秀的第三方依赖库再次封装是一件多余的事情，因为这些库可能出自大神/大厂，或有非常高的star并且使用起来十分稳定，可以在项目中直接拿来使用。当然每个开发者都有自己的态度，我也只是根据以往的经验，表达一下自己的看法。

作为从了解四大组件就不愁找不到工作的互联网大时代中一路走来的Android老鸟，经历了网路请求框架从HttpConnection到Volley再到OkHttp，也经历了图片加载框架从UniversalImageLoader到Picasso再到Gilde，技术的迭代随时都会发生。让项目架构具有良好的扩展性是在设计之初就需要考虑的东西。

那么接下来我用一个简单的demo来演示一下如何使用代理模式对第三方框架进行解耦。

现在我们有一个名为 thirdlib 的模块，为我们提供图片加载功能。

第一步：我们创建了一个新的模块 thridlibproxy ，并且该模块依赖于 thirdlib ，我们在该模块中创建包私有的接口ImageLoaderInterface，这个接口中把thirdlib模块中提供的功能抽象为接口：

第二步：创建包私有的接口的实现类ImageLoaderOneImpl，类中图片加载的业务逻辑是通过调用 thirdlib 中的ImageLoader类实现的：

第三步：我们提供一个供外部调用的ImageLoaderOneImpl接口代理类ImageLoaderProxy：

最后我们就可以通过ImageLoaderProxy中提供的loadImage方法进行图片的加载了。

看到这里有些盆友就会问了，在第二步的时候，我们就完成了 thirdlib 的封装工作，为什么还要有第三步？还有我写一个单例类直接对 thirdlib 进行封装不就行了，为什么还要抽象出接口？

原因很简单，为的就是尽可能的满足软件设计七大原则中的第一个： 开闭原则 。

一个好的软件设计，需要对拓展开放，对修改关闭。我们在设计之初就要想到，在更换图片加载框架之后如何最大程度上满足开闭原则。

如果直接对 thirdlib 进行封装，是面向类的开发而不是面向接口。如果此时更换图片加载类库，那必然会对封装出来的类进行大量的修改，把原来的实现替换为新的实现。

使用代理模式的好处就是，我新创建一个被代理的类ImageLoaderTwoImpl：

然后只需要对第三步中的被代理类进行替换就行了。

在想要达到相同效果的时候，最大程度的满足了开闭原则。

我们业务层模块也和第三方库实现了完全的解耦，我不需要知道 thridlibproxy 是如何帮我完成图片加载工作的，但是只要调用它提供的方法就完事儿的，这也符合软件设计七大原则中的： 最少知道原则 。

关于为何以及怎么通过代理调用第三方依赖库，到这里就介绍完毕了，赶快动手试试吧~

我只想说： 原则是死的，人是活的?

如果觉得有收获的话，欢迎点赞评论以及关注~

Q2: 一、Android 虚拟机内存模型

jvm运行时数据区域解析

刘望舒的BLOG

虚拟机的内存模型

1.程序计数器: 确定程序指令执行顺序的,是唯一一块不会发生内存溢出的区域

2. Java虚拟机栈

**它也是线程私有的,负责存储方法内的局部变量,方法出口等。每执行一个方法都相当于压如一个栈帧,方法执行完比后这个栈帧从Java虚拟机栈中弹出。

3.本地方法区

负责管理虚拟机用到的 C 的方法。

4.堆内存区域

Java堆是一块被所有线程共享的区域，用来存放对象的实例。它不需要物理上连续,只需要逻辑上连续就可以。

5.方法区

方法区是被所有线程共享的的内存区域,用来存放已经被Java虚拟机加载的类的结构信息：运行时常量池,字段,方法信息，静态变量等数据。

class文件的内容

Q3: Android OpenGLES2.0（十六）——3D模型贴图及光照处理（obj+mtl）

在Android OpenGLES2.0（十四）——Obj格式3D模型加载中实现了Obj格式的3D模型的加载，加载的是一个没有贴图，没有光照处理的帽子，为了呈现出立体效果，“手动”加了光照，拥有贴图的纹理及光照又该怎么加载呢？

本篇博客例子中加载的是一个卡通形象皮卡丘，资源是在网上随便找的一个。加载出来如图所示：

obj内容格式如下：

mtl文件内容格式如下：

关于Obj的内容格式，在上篇博客中已经做了总结，本篇博客中使用的obj，可以看到f后面的不再跟的是4个数字，而是 f 2/58/58 3/59/59 17/60/60 这种样子的三组数，每一组都表示为顶点坐标索引/贴图坐标点索引/顶点法线索引，三个顶点组成一个三角形。而头部的 mtllib pikachu.mtl 则指明使用的材质库。

而mtl格式文件中，主要数据类型为：

模型加载和之前的模型加载大同小异，不同的是，这次我们需要将模型的贴图坐标、顶点法线也一起加载，并传入到shader中。其他参数，有的自然也要取到。

模型加载以obj文件为入口，解析obj文件，从中获取到mtl文件相对路径，然后解析mtl文件。将材质库拆分为诸多的单一材质。obj对象的 加载，根据具使用材质不同来分解为多个3D模型。具体加载过程如下：

顶点着色器

片元着色器

完成了以上准备工作，就可以调用 readMultiObj 方法，将obj文件读成一个或多个带有各项参数的3D模型类，然后将每一个3D模型的参数传入shader中，进而进行渲染：

Q4: Android如何更改手机模型

在工具选项中更改。更改方法。

1、首先打开VisualStudio进入软件主界面。

2、进入软件主界面，点击工具。

3、进入工具选项，选择选项。

4、选择IntelliCode，常规。

5、找到AndroidXML基础模型。

6、更改选项。然后点击确定即可。