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可以轻松支撑多任务多进程的应用模型。
❷ 谁有stay的android架构设计方法，技巧与实践
Builder模式：比如AlertDialog.Builder；例简单模拟Android中AlertDialog的Builder设计模式
适配器模式：比如GridView、ListView与回Adapter；例Android设计模式系列(9)--SDK源码之适答配器模式
命令模式：比如Handler.post；例命令模式下的异步消息处理（Handler,Message,Looper,Thread）
享元模式：比如Message.obtain；例Android和设计模式：享元模式
单例模式：比如InputMethodManager.getInstance，例Android源码学习之单例模式应用
观察者模式：比如ContentObserver；例Android中内容观察者的使用-- ContentObserver类详解
抽象工厂模式：比如BaseActivity，例Android Ap 开发 设计模式第八篇：抽象工厂模式
❸ android架构设计需要注意什么
android架构设计需要注意的问题如下：
1.了解不同版本的特性包括IDE的。
如：AsyncTask3.0之后和之前的区别、Android 5.0的新的API、Android 6.0 不能用HttpClient 、AS2.0的新特性 等等。
2.掌握热门技术并了解其原理。
如：RxJava（响应式框架）、Retrofit（请求框架可以配合RxJava）、MVP（开发模式） hotfix（热修复）等等。
3.掌握测试工具（因为懂得测试查看才能更好的针对性去解决、每个方法都编写测试用例）。
如：查看布局层级、查看APP性能、查看APP安全 等等。
4.逆向工程（攻防兼备）。
5.有自己的开源项目（最好是MD风格的）。
6.熟悉gitflow更好的管理项目。
7.必须做笔记、可以写博客、最好写本书。
8.了解一些常用算法（做动画的时候还是有用的！）
9.关注最新技术、IT行业信息。
10.对于技术要有足够的深度和热情
❹ 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，先简单了解下，文中会有例子到时候可以直观的感受下。
❺ 求完整android项目框架设计思路，结构
目标需求->拆分成需求模块->各模块考虑采用何种实现方式（技术可行性）->测试->
签名发布
自己想的勿喷
❻ Android MVP架构中的Presentation层应该怎么设计
先区分一下Android View、View、界面的区别
Android View： 只是继承android.view.View的Android组件。
View：接口，用于由presenter向View实现类通信，你可以在Android组件中实现它。有时最好直接使用Activity，Fragment或自定义View。
界面：界面是面向用户的概念。比如要在手机上进行界面间切换时，我们在代码中可以通过多种方式实现，如Activity到Activity或一个Activity内部的Fragment/View进行切换。所以这个概念基于用户的视觉，包括了所有View中能看到的东西。
切换界面
界面间的切换可以是两个Fragment、两个Activity、打开对话框、启动新Activity等等。当然切换的具体实现原理不属于这篇文章的内容，而进行切换操作则是Presentation层的职责。Presenter应该知道要做什么，而它的实现类要知道怎么完成。在这个例子中，要做的就是切换界面，完成方式就是启动新的Activity。
但这样会有一个问题。Presentation层是纯java代码，所以Presenter中不应该有任何与安卓相关的代码。那怎么完成界面的切换呢？通过抽象。这里可以写一个只有一个navigate()方法的接口NavigationCommand。在需要时我们在Presenter中调用这个接口的navigate()方法，然后在Activity中实现这个接口。
代码长这样：
View层
ActivityA.java
public class ActivityA extends Activity {
@OnClick(R.id.someButton)
public void onSomeButtonClicked() {
presenter.onSomeButtonClicked();
}
ToActivityB.java
public class ToActivityB implements NavigationCommand {
private final Activity currentActivity;
public ToActivityB(Activity activity) {
currentActivity = activity;
}
@Override
public void navigate() {
currentActivity.startActivity();
}
}
Presentation层
NavigationCommand.interface
public interface NavigationCommand {
public void navigate();
}
PresenterA.java
public class PresenterA {
private final NavigationCommand toBNavigation;
public PresenterA(NavigationCommand toBNavigation) {
this.toBNavigation = toBNavigation;
}
public void onSomeButtonClicked() {
toBNavigation.navigate();
}
}
这样我们就可以将VP两层解耦。这里将切换到一个Activity的代码提取出来，可以复用，我们可以通过注入NavigationCommand方法来测试Presenter，而且就算要跳转的页面变了，Presenter的代码也不变。这也符合Open Close原则。
另一个问题就是当一个Presenter中出现多个NavigationCommand时，构造方法就开始变得诡异了。
public class PresenterA {
private final NavigationCommand toBNavigation;
private final NavigationCommand toCNavigation;
public PresenterA(NavigationCommand toBNavigation, NavigationCommand toCNavigation) {
this.toBNavigation = toBNavigation;
this.toCNavigation = toCNavigation;
}
}
在这里初始化Presenter的类很难搞清楚两个NavigationCommand之间的顺序，似乎只能通过名字来辨识，这里其实可以再写一个接口继承NavigationCommand来专门管理一类特定的切换，或者如果你使用依赖注入框架的话也可以指定参数的类型。
有时需要在切换界面时传递一些参数，这时就要改动一下NavigationCommand的代码：
public interface ToScreenBNavigationCommand extends NavigationCommand {
void setMyParameterToNavigate(String parameter);
}
❼ 为什么android项目结构下src和gen文件夹有相同的包 这样子设计的好处是什么 这两个同名包
1、gen里边是编译出来的R文件。里边带有你的各个资源的id。你代码里取或者布局里要引用的时候都要用到那些id.
2、编程的时候需要注意：如果资源文件(比如图片命名、XML等)有错就不会生成R文件。
3、在一个包下是因为，你打包生成apk的时候就是把这个包里的所有东西打包了。这个包具体在你的workspace工程目录里面可以看到。其实就是一个文件夹。包名相同说明它们都放在同一个文件夹里边。
❽ app设计，app开发(包括安卓和iOS)，网页设计，网页开发，后台管理系统开发，后台架构搭建等等技术服务！
应该很多提供这样服务的相关技术人员和公司
❾ 学习android架构的步骤
一般而言，人们大多先学开发(代码)的技术，随后才学(架构)设计的方法。然而，在实际做事时，却是先设计，随后才写出代码来。敏捷过程则让设计与写码迭代循环下去，一直到完成为止。而android架构师就是从程序员转化为设计师。
岗位职责:
1. 负责Android 软件的架构分析、设计和核心代码的编写；
2. 负责相关技术的评审把关，控制项目产出质量，负责技术团队技术管理工作。
任职资格:
1、具有5年以上移动设备的软件开发经验；
2、熟悉Android系统架构，3年以上Android平台开发设计经验；
3、精通C/C++/Java，具备独立解决问题的能力；
4、熟悉面向对象开发，熟悉常用设计模式
5、对新技术持有敏感性以及愿意致力于新技术的探索和研究；
6、自学能力强，具有良好的沟通协调能力，具有一定的技术团队领导能力；
7、有Android源码二次开发经验者优先；
❿ Android即时通讯系统的设计与实现 结构图
这是AnyChat音视频引擎的结构图，希望能够帮到你，如果有什么问题也可以进入其网站论坛进行提问。
请在此输入您的回答