1：android分为四个层，从高层到低层分别是应用程式层、应用程式框架层
开发一个程式，android系统框架是层层相扣，不能分开的。 应用程式层： 这个层主要指的就是用java语言编写的执行在虚拟机器上的程式，Google在最开始时就 在android系统中捆绑了一些核心的应用（核心应用的编写必须使用应用层序框架层的API框架
2：android 开发框架有四个层，从高层到低层分别是应用程式层、应用程式框架层
android应用开发框架是 Application Framework 其系统架构由5部分组成，分别是：Linux Kernel、Android Runtime、Libraries、Application Framework、Applications。
开发什么应用？
硬体还是软体？
硬体的话，看看这个：
:m2mtemolin/doc/62/m100wu-lian-mo-kuai
软体的话，看看这个：
:jb51/article/51052htm
对于作业系统来言，不存在C/S,B/S一说。
java的确执行效率不如C/C++,但任何开发语言都有其各种特点，有缺点必有优点，否而只能被淘汰。
java有很多过人之处，要不然android也不会看上java作为其应用层的开发语言。
android相比IOS，的确存在距离，但我始终相信以LINUX为核心的android在几百万开发者的磨练下，将会越来越完美，“开源”永远值得人们去琢磨，精益求精！
Solaris支援多种系统架构: SPARC, x86 and x64 x64即AMD64及EMT64处理器。在版本251的时候，Solaris曾经一度被移植到PowerPC架构, 但是后来又在这一版本正式释出时被删去。与Linux相比，Solaris可以更有效地支援对称多处理器、即SMP架构。Sun同时宣布将在Solaris 10的后续版本中提供Linux执行环境, 允许Linux二进位制程式直接在Solaris x86和x64系统上执行。
Solaris传统上与基于Sun SPARC处理器的硬体体系结构结合紧密, 在设计上和市场上经常捆绑在一起，整个软硬体系统的可靠性和效能也因此大大增强。然而SPARC系统的成本和价格通常要高于PC类的产品，这成为Solaris进一步普及的障碍。可喜的是，Solaris对x86体系结构的支援正得到大大加强，特别是Solaris 10已经能很好地支援x64(AMD64/EMT64)架构。Sun公司已推出自行设计的基于AMD64的工作站和伺服器，并随机附带Solaris 10。
dalvik是执行的时候编译+执行，安装比较快，开启应用比较慢，应用占用空间小
ART是安装的时候就编译好了，执行的时候直接就可以执行的，安装慢，开启应用快，占用空间大
用个比喻来说就是，骑脚踏车
dalvik 是已经摺叠起来的脚踏车，每次骑都要先组装脚踏车才能骑
ART 是已经组装好的脚踏车，每次骑直接上车就能走人
系统架构方案有哪些
系统架构属于系统设计阶段，系统架构图只是这个阶段一个产物，要正确的、合理的画系统架构图需要全面的理解使用者需求以及业务流程，当理解了这些东西后，剩下的就是如何进行表达了，一般而言，可以参照RUP的用例驱动来进行逻辑架构，开发架构等设计工作，你的系统架构图可以反应在各个视图里面，我估计你所说的系统架构图是属于逻辑架构里面，比如分多少层，每层分多少模组等。
至于，绘制的工具，有很多很多。可以选择微软的visio,或者EA,rose,power designer等UML建模工具，当然，你甚至可以用PPT,Word来绘制。
当然，系统架构不是一日之功，需长期努力，跟经验和技术都有很大关系。
今天兴致来了，回复了这么多，不知满意不。
我不是高人，也谈不上指点，我只是一个很普通的程式码工人发表一下自己的看法哈~~
一个activity上多个surfaceview切换的做法是做游戏开发的，现在市面上大多数游戏都是采用的这种做法，并没有什么不妥，surfaceview使得画面更自由，拿到canvas后就不局限于安桌提供的控制元件了，纯自由发挥，各种游戏特效表现得更精彩。只是切换surfaceview时稍微麻烦点，需要写程式码来手动判断游戏状态和控制切换。
如果你只是做普通的应用，安桌提供的控制元件能满足你的需求，你就用普通的activity呗。用surfaceview多麻烦啊。把切换丢给系统来管理，省去不少事儿。如果你愿意麻烦，使用surfaceview来相互手动切换，也没什么问题的，放心去做吧。毕竟记忆体管理机制用的是JАVΑ的那一套，自动回收，用哪种架构都差别不大。
个人拙见，手动拼音打字，非ctrl+c/ctrl+v之流。望诸位看官别笑话俺哈~~
一个好的IT架构师,眼光不会仅仅停留在写程式码的层次上,在做开发的时间里，他们会积极学习各种知识，经验，培养自己的商业头脑，包括扩充套件自己各方面的资源，这些积累会为他们未来成为管理者或创业打下牢固的基础。
对于学习来说我们都是希望可以全面综合的掌握技术，这样才有助于你今后的整体发展。目前企业需要的不再是理论型人才了，而是实用技能型人才。
首先我们需要全面掌握专业实用的技术，其次加强个人整体素质的提升，这样才能符合目前企业的用人需求。如果我们选择了单科学习无疑是在起跑线上局限了我们的个人发展，或许短期内你觉得只是需要某项单独的技术，但是你有没有想过今后你不可能一直从事底层的程式设计师，看着和你同意时间进入公司的同事虽然技术和你不相上下，但是由于掌握的比较全面而被提升为专案主管、专案经理，或许到那个时候你又要为此再一次走进培训机构，这样也是耽误你个人的时间和精力，我相信你也希望自己今后可以步入管理层工作，有一个更好的发展。最好 是 掌握全面的技术,资料库,JAVANET客户端技术。
就我接触到的说一下，我第一家公司专案比较小型是 springmvc + spring + hibernate （也有mabatis的） ，第二家公司，专案是大型的，所以好多是分散式的框架，spring、spring integration、dubbo、zookeeper、redis、mybatis等都有用到
“系统架构”是什么意思？都有哪些架构？JDE属于分散式架构,人和系统恕我孤陋寡闻,没听过阿
将一个单体应用拆分成一组微小的服务组件，每个微小的服务组件运行在自己的进程上，组件之间通过如RESTful API这样的轻量级机制进行交互，这些服务以业务能力为核心，用自动化部署机制独立部署，另外，这些服务可以用不同的语言进行研发，用不同技术来存储数据 。
通过以上的定义描述，我们可以基本确定给出微服务的节特征：
用微服务来进行实践到生产项目中，首先要考虑一些问题。比如下图的微服务业务架构：
在上图图表展示的架构图中，我们假设将业务商户服务A、订单服务B和产品服务C分别拆分为一个微服务应用，单独进行部署。此时，我们面临很多要可能出现的问题要解决，比如：
1、客户端如何访问这些服务？
2、每个服务之间如何进行通信？
3、多个微服务，应如何实现？
4、如果服务出现异常宕机，该如何解决？
以上这些都是问题，需要一个个解决。
在单体应用开发中，所有的服务都是本地的，前端UI界面，移动端APP程序可以直接访问后端服务器程序。
现在按功能拆分成独立的服务，跑在独立的进程中。如下图所示：
此时，后台有N个服务，前台就需要记住管理N个服务，一个服务 下线 、 更新 、 升级 ，前台和移动端APP就要重新部署或者重新发包，这明显不服务我们拆分的理念。尤其是对当下业务需求的飞速发展，业务的变更是非常频繁的。
除了访问管理出现困难以外，N个小服务的调用也是一个不小的网络开销。另外，一般微服务在系统内部，通常是无状态的，而我们的用户在进行业务 *** 作时，往往是跨业务模块进行 *** 作，且需要是有状态的，在此时的这个系统架构中，也无法解决这个问题。传统的用来解决用户登录信息和权限管理通常有一个统一的地方维护管理（OAuth），我们称之为授权管理。
基于以上列出的问题，我们采用一种叫做网关（英文为API Gateway）的技术方案来解决这些问题，网关的作用主要包括：
网关(API Gateway)可以有很多广义的实现办法，可以是一个软硬一体的盒子，也可以是一个简单的MVC框架，甚至是一个Nodejs的服务端。他们最重要的作用是为前台（通常是移动应用）提供后台服务的聚合，提供一个统一的服务出口，解除他们之间的耦合，不过API Gateway也有可能成为 单点故障 点或者性能的瓶颈。
最终，添加了网关(API Gateway)的业务架构图变更为如下所示：
所有的微服务都是独立部署，运行在自己的进程容器中，所以微服务与微服务之间的通信就是IPC（Inter Process Communication），翻译为进程间通信。进程间通信的方案已经比较成熟了，现在最常见的有两大类： 同步调用、异步消息调用 。
同步调用
同步调用比较简单，一致性强，但是容易出调用问题，性能体验上也会差些，特别是调用层次多的时候。同步调用的有两种实现方式：分别是 REST 和 RPC
基于REST和RPC的特点，我们通常采用的原则为： 向系统外部暴露采用REST，向系统内部暴露调用采用RPC方式。
异步消息的方式在分布式系统中有特别广泛的应用，他既能减低调用服务之间的耦合，又能成为调用之间的缓冲，确保消息积压不会冲垮被调用方，同时能保证调用方的服务体验，继续干自己该干的活，不至于被后台性能拖慢。需要付出的代价是一致性的减弱，需要接受数据 最终一致性 ，所谓的最终一致性就是只可能不会立刻同步完成，会有延时，但是最终会完成数据同步；还有就是后台服务一般要实现 幂等性 ，因为消息发送由于性能的考虑一般会有重复（保证消息的被收到且仅收到一次对性能是很大的考验）。最后就是必须引入一个独立的 Broker，作为中间代理池。
常见的异步消息调用的框架有：Kafaka、Notify、MessageQueue。
最终，大部分的服务间的调用架构实现如下所示：
在微服务架构中，一般每一个服务都是有多个拷贝，来做负载均衡。一个服务随时可能下线，也可能应对临时访问压力增加新的服务节点。这就出现了新的问题：
这就是服务的发现、识别与管理问题。解决多服务之间的识别，发现的问题一般是通过注册的方式来进行。
具体来说：当服务上线时，服务提供者将自己的服务注册信息注册到某个专门的框架中，并通过心跳维持长链接，实时更新链接信息。服务调用者通过服务管理框架进行寻址，根据特定的算法，找到对应的服务，或者将服务的注册信息缓存到本地，这样提高性能。当服务下线时，服务管理框架会发送服务下线的通知给其他服务。
常见的服务管理框架有：Zookeeper等框架。
如上的问题解决方案有两种具体的实现，分别是： 基于客户端的服务注册与发现 、 基于服务端的服务注册与发现 。
优点是架构简单，扩展灵活，只对服务注册器依赖。缺点是客户端要维护所有调用服务的地址，有技术难度，一般大公司都有成熟的内部框架支持。
优点是所有服务对于前台调用方透明，一般小公司在云服务上部署的应用采用的比较多。
前面提到，单体应用开发中一个很大的风险是，把所有鸡蛋放在一个篮子里，一荣俱荣，一损俱损。而分布式最大的特性就是网络是不可靠的。通过微服务拆分能降低这个风险，不过如果没有特别的保障，结局肯定是噩梦。
因此，当我们的系统是由一系列的服务调用链组成的时候，我们必须确保任一环节出问题都不至于影响整体链路。相应的手段有很多，比如说：
其实开发不同的App，所需要的技术也是不一样的！
1比如WebApp：
iOS/Android的内置浏览器是基于webkit内核的，所以在开发webApp时，多数使用html或html5、CSS3、JavaScript技术做UI布局，使其在网站页面上实现传统的C/S架构软件功能，服务端技术用java、php、ASP。
现在也有很多一键生成webApp的平台，如百度siteApp/移动开发平台APICloud，APICloud平台提供基于腾讯x5浏览器引擎生成webApp，因为移动端的超级流量入口微信/手机qq等用的也是腾讯x5内置浏览器，所以用腾讯x5浏览器生成的App在移动页面展示时适配于微信的浏览体验，这样可以帮助webApp引流。
2比如NativeApp：
开发NativeApp需要根据运行的手机系统采用不同的开发语言，开发AndroidApp需要的开发语言是java，还需要熟悉Android环境和机制。
NativeApp主要知识点有下面这些：
1开发环境，AndroidStudio、eclipse如何搭建Android开发环境可以去百度。
2数据结构，App的某些功能涉及到做算法，所以要有一定的数学基础
3AndroidSDK，会API接口开发，包括自行开发API的能力和调用第三发API的经验。
4熟悉tcp、IP，socket等网络协议
5如果涉及到服务器，你还需要了解webservice相关知识和相应的开发语言，常用有PHP、JSP、ASPNet
6除了这些功能基础，App开发还涉及到UI设计、框架、性能优化、调试适配等。
3比如HybridApp：
混合开发中主流的是以web为主体型的开发，即以网页语言编写，穿插Native功能的hybridApp开发类型，网页语言主要有html5、CSS3、JavaScript。Web主体型的App用户体验好坏，取决于底层中间件的交互与跨平台的能力。
国内外有很多优秀的开发工具，如国外的AppmAkr、Appmobi，国内的APICloud，APICloud的底层引擎用DeepEngine，使用半翻译式原理，将运行中的web翻译成NativeAPI，并且支持扩展API，开发时可调用用原生语言开发的功能模块，以此达到媲美原生App的用户体验，同时节省开发时间。
温馨提醒：针对公司或者工作室来讲，制作什么类型的app，需要结合自己各自的业务需求而定制，然后根据需求选择不同的开发类型和工具。当然最后找什么样的发公司预算多少，需求多少，工期多少，还是希望大家接下来和app开发公司沟通协调决定。
开发不同类型的App需要用到哪些技术？WebApp：iOS/Android的内置浏览器是基于webkit内核的，所以在开发webApp时，多数使用html或html5、CSS3、JavaScript技术做UI布局，使其在网站页面上实现传统的C／S架构软件功能，服务端技术用java、php、ASP。现在也有很多一键生成webApp的平台，如百度siteApp／移动开发平台APICloud，APICloud平台提供基于腾讯x5浏览器引擎生成webApp，因为移动端的超级流量入口微信／手机qq等用的也是腾讯x5内置浏览器，所以用腾讯x5浏览器生成的App在移动页面展示时适配于微信的浏览体验，这样可以帮助webApp引流。NativeApp：开发NativeApp需要根据运行的手机系统采用不同的开发语言，开发AndroidApp需要的开发语言是java，还需要熟悉Android环境和机制。主要知识点如下：
1开发环境，AndroidStudio、eclipse如何搭建Android开发环境可以去百度。
2数据结构，App的某些功能涉及到做算法，所以要有一定的数学基础
3AndroidSDK，会API接口开发，包括自行开发API的能力和调用第三发API的经验。
4熟悉tcp、IP，socket等网络协议
5如果涉及到服务器，你还需要了解webservice相关知识和相应的开发语言，常用有PHP、JSP、ASPNet
6除了这些功能基础，App开发还涉及到UI设计、框架、性能优化、调试适配等。Objective-C是开发iOS系统App的主流编程语言，开发者一般用苹果公司的iOSSDK搭建开发环境，iOSSDK是开发iOS应用程序中不可少的软件开发包，提供了从创建程序，到编译、调试、运行、测试等多种开发过程中需要等工具。学习iOS开发可以去看苹果官方文档，这是最权威的ios教程。HybridApp：混合开发中主流的是以web为主体型的开发，即以网页语言编写，穿插Native功能的hybridApp开发类型，网页语言主要有html5、CSS3、JavaScript。Web主体型的App用户体验好坏，取决于底层中间件的交互与跨平台的能力。国内外有很多优秀的开发工具，如国外的AppmAkr、Appmobi，国内的APICloud，APICloud的底层引擎用DeepEngine，使用半翻译式原理，将运行中的web翻译成NativeAPI，并且支持扩展API，开发时可调用用原生语言开发的功能模块，以此达到媲美原生App的用户体验，同时节省开发时间。对企业来说，可以根据自己的需求选择不同的开发类型和开发工具，目前来看，HybridApp已经成为移动开发趋势，一方面HybridApp开发时不采用或者大部分不采用原生语言，却能拥有原生应用的特性，一方面随着web技术的发展，HybridApp技术已经成熟，很多大型App淘宝、微信、携程都属于这种开发模式，HybridApp给企业移动应用的开发、维护、更新都带来了极高的便捷性，从成本投入用户体验考虑，HybridApp都是首选。
BS结构是 Browser/ Servere的简称,翻译成汉语则是览器服务器模式。BS结构归根结底是一种网络结构模式,以
WEB形式为基础。所谓的WEB是一种浏览器模式,用户在
电子计算机等客户端中安装一款浏览器软件,比如说 tenet
Explorers等和类似于 MYSQL等为主的数据库作为服务器,那
么所有的数据交换就可以通过浏览器和服务器来完成。这样
不仅能够将分散的系统功能集中起来,而且可以将形式多种
多样的客户端相统一,使得所有的系统变得更加便捷简单,
同时也有利于日后的使用与更新。
基于APP很显然是手机终端上的应用，可以实现在任何地点移动式办公，但是会有占手机内存，用户需要下载等缺点基于Android的牙齿健康科普App设计与开发简析
国民生活品质不断提升,越来越多的国人开始关注自己的口腔健康，且我国儿童患龋情况已呈上升状态, 中年人牙周健康状况仍有待提升。为了增强大众口腔健康意识, 自发关注牙齿护理,文章介绍的是一款牙疾病科普类App。
一、App的设计与开发
1、总体设计
本App采用 C/S (客户端/服务器)架构 ,基于 Java 语言开发 ,运行于Android平台上。客户端主要基于 Android Studio 平 台 开 发 , 服 务 器 端 采 用 MySQL 与 Android 相连接 ,进行数据存储和处理。
2、界面设计
利用Axure RP进行App全界面设计,配色方面具有强烈的秩序性 ,以白、蓝为主色调 ,关注界面中控件、字体及图标 ,使界面协调、细致 。设计前 ,本团队在用户角度设问“用户能够干什么”,解决了诸如此类的问题,再持续性挖掘用户更深层次的需求。
3、数据库设计
对于数据库的设计,本设计建立了6张数据表，共36个属性字段 ,继而整理完成数据字典。
4、功能开发
App的功能较为完善 ,包括牙齿健康知识科普、口腔保健用品销售、牙齿自检问卷、社区交流等 。本团队选择移动端而非PC端进行设计 ,大大提高了用户使用的智能性和便利性。在兼顾便捷性的同时,也更注重用户的使用安全,用户登录时除输入用户名和密码外,还设置了验证码 ,防止机器人程序恶意破解。
二、模块设计
1、科普视频模块的设计
科普类视频播放通常由两种方式实现 。第一种方式即通过 MediaPlayer 与 SurfaceView 相结合的模式进行播放 ,使用 MediaPlayer 控制视频的播放、暂停、进度等功能 ,使用 SurfaceView 显示视频内容 。此方法虽然灵活性高 ,方便自定义使用 ,但难度比较大。本系统使用 第 二 种 方 法 , 即 通 过 继 承 SurfaceView 类 , 使 用 VideoView 进行视频播放 。MediaPlayerController 接 口 可以控制媒体播放 ,另外在 VideoView 上还有一个面板用于对媒体播放进行控制 ,可以快捷使用快进、快退、 播放、暂停等按钮。
2、购物车模块的设计
用户点击进入商城 ,可以查看商品、搜索商品并且购买。对于商城购物车结算功能 ,本团队尝试了两种方式 :(1)通过 LinearLayout 嵌套 LinearLayout 实现 ,但这种方式在数据过多时会造成页面卡顿。(2)通过 ExpandableListView 实 现 购 物 车 分 店 铺 功 能 , 由 于 ExpandableListView 是系统原生控件 ,因此由系统底层 维护并提供了更多的方法供本团队使用 , *** 作简单、页面流畅且代码量较前一种小了很多。实际开发中，本设计仍然用 ScrollView 嵌套 ExpandableListView 控件保证页面的正常滑动。本设计主要使用 onItemClick( ) 函数选 中 结 算 物 品 , sumPrice ( ) 函 数 计 算 商 品 价 格 总和。
3、牙齿健康知识科普模块的设计
针对牙齿健康知识科普,本团队推送大量的科普视频和护牙小知识,用户可选择各种牙疾病的相关介绍并查看注意事项。在口腔保健用品销售模块中,用户可查看相关的口腔用品并购买。本团队通过调查牙齿护理的相关知识 ,设计牙齿自检问卷 , 可供用户定期评估牙齿健康 ,例如“龋齿占牙齿的比例”“牙龈出血次数”等常见口腔问题皆有涉及。
4、社区模块的设计
社区为用户推送热门的牙齿健康话题、热门的用户动态以及热门的牙齿专题,展示用户关注的好友发布的动态信息 ,用户具有点赞、关注和评论的权利。同时,用户也可以搜索自己感兴趣的话题或其他用户。系统根据用户的爱好为他推荐他可能感兴趣的好友 ,并且推荐点赞和分享综合性较高的用户。
在研究阶段 ,本团队查阅大量资料 ,进行初步分析,通过对口腔 健康知识科普类 App 用户的需求进行剖析 ,综合分析界面设计、交互开发、功能设计等多个方面 ,对设计目的、设计理念全面梳理后 ,完成 App 开发。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）