android设计架构设计

⑴ Android架构设计的思想与原则是什么

rlei分析了Android的设计哲学：
理解好Intent，就可以理解Android哲学(所有应用生来平等)的一部分。举个简单的例子，iOS里面应用要集成SNS如facebook/twitter/sina weibo等，都需要应用自己实现（iOS5也只是集成twitter一家）；Android上只需要广播一个share内容的intent。从理解Intent如何工作开始，你就在慢慢理解Activity Manager, Package Manager, Services这些Android的重要组件是如何工作的。
另外Binder是Android架构里非常核心的一块。Android基于Intent的消息传递和组件/应用解耦，下面的基础都是Binder IPC。在这一点上，Android实际上是光荣的传承了BeOS和Palm OS 6（悲催的OS6...）未能发扬光大的一部分。
MVC(Content Provider, Activity, Layout, Adapters)这个比较基础，也不算Android特有的。
Content Provider对数据访问的抽象也是比较有意思的一块。理想情况下，content provider可以让客户端用URI以语义化的方式访问数据(URI本身即表示数据层次结构和查询条件），而下面数据库表的结构可以任意变动，不影响客户端代码。当然实做的时候content provider还是会被各种复杂的where子句暴露出SQL的实现细节
至于Android的权限管理，其实比较简单，主要是利用现成的linux安全模型，进程之间相互隔离。API级别的权限管理和JVM类似。
Billy Cui重点解析了权限系统的设计：
Android的权限系统是基于Linux，但又增加了很多自己的控制模块。
总体上来说，其分为以下几部分权限系统：
1. userid : 继承于linux，对于多个app，通过shareuid的方式可以使用同一个userid，主要承担一些目录访问权限之类的工作，比如私有目录只能由同一uid应用访问。
2. 安装level：system level or app level，这个是根据应用的安装位置决定的，在system/app下安装的应用就是system level，在权限访问中会得到更多的权限，比如静默安装应用的权限等。
3. permission : 这个是最主要的权限控制，一般开发者开发应用主要是接触这个部分，在这部分中，会根据应用在AndroidManifest.xml中声明的use-permission而在访问相应api或资源时判断其是否有访问权限，比如常用的android.permission.INTERNET等。
4. signature: 签名，是Android权限系统中的重要组成部分，对于系统签名的应用，会有一些特殊的功能，而shareuid等特性也是需要同一签名作为基础。此外，permission在设置/自定义其权限时也经常会使用到签名，比如控制只有我自己的应用才可以访问我自己定义的公开API。
除此以外，其实Android在uid的里面设置了一些预定义有特殊功能的uid，比如system/media等，在配置其system level的services的时候会用到。
董兆辉则认为Android主要是基于组件搭配思想：
说到Android架构的设计思想和原则，按我的理解主要是组件搭配，即在用户看来，所有的mole或者组件，都是可以重复利用和简单组合的。想法是好的，不过有得必有失，或者说Android现在做的还不够好，在性能方面是很低的，否则的话Android也不会推出补丁（NDK之类的，dalvik的不断升级）。
我觉得所有Framework或者平台或者语言都想给应用开发者最方便使用的接口，最人性化的体验，同时又要争取最大的性能，两者权衡折中吧。不过随着硬件速度的飞速增长，性能的权重会变低。
范怀宇还谈到了资源体系：
Android架设在Linux之上，因此，继承了Linux可移植性、用户管理机制、文件系统，等等。
Android的核心在Framework层，本质上，这是一个基于组件的应用开发系统，组件间通过消息（Intent）进行通信。一方面，Intent是通信信息的载体，另一方面，Intent也定义了Android组件的通信协议。
Android可以对组件所运行的进程做托管，在Android中，进程概念相当薄弱。依赖于进程托管，Android可以轻松支撑多任务多进程的应用模型。

⑵ Android MVP架构中的Presentation层应该怎么设计

对于MVP（Model View Presenter），大多数人都能说出一二：“MVC的演化版本”，“让Model和View完全解耦”等等。本篇博文仅是为了做下记录，提出一些自己的看法，和帮助大家如何针对一个Activity页面去编写针对MVP风格的代码。
对于MVP，我的内心有一个问题：
为何这个模式出来后，就能被广大的Android的程序员接受呢？
问了些程序员，他们对于MVP的普遍的认识是：“代码很清晰，不过增加了很多类”。我在第一次看到MVP的时候，看了一个demo，看完以后觉得非常nice（但是回过头来，自己想个例子写，就头疼写不出来，当然这在后文会说）。nice的原因还是因为，这个模式的确让代码的清晰度有了很大的提升。
那么，提升一般都是对比出来的，回顾下，没有应用MVP的代码结构。很多人说明显是MVC么：
View：对应于布局文件
Model：业务逻辑和实体模型
Controllor：对应于Activity
看起来的确像那么回事，但是细细的想想这个View对应于布局文件，其实能做的事情特别少，实际上关于该布局文件中的数据绑定的操作，事件处理的代码都在Activity中，造成了Activity既像View又像Controller（当然了Data-Binder的出现，可能会让View更像View吧）。这可能也就是为何，在该文中有一句这样的话：
Most of the modern Android applications just use View-Model architecture，everything is connected with Activity.
而当将架构改为MVP以后，Presenter的出现，将Actvity视为View层，Presenter负责完成View层与Model层的交互。现在是这样的：
View 对应于Activity，负责View的绘制以及与用户交互
Model 依然是业务逻辑和实体模型
Presenter 负责完成View于Model间的交互
ok，先简单了解下，文中会有例子到时候可以直观的感受下。