搭建一个应用程序框架-做点什么(如何搭建应用服务器)

推荐整理分享搭建一个应用程序框架-做点什么(如何搭建应用服务器)，希望有所帮助，仅作参考，欢迎阅读内容。

文章相关热门搜索词:创建一个软件app,软件搭建教程,搭建自己的应用商店,如何搭建应用服务器,如何搭建应用服务器,搭建一个应用程序怎么做,搭建一个应用程序怎么做,如何搭建一个软件,内容如对您有帮助，希望把文章链接给更多的朋友！

以前只做过模块功能的开发，在开源项目或者别人搭建的项目框架下敲码。突然让我来搭建一个app的框架，竟然不知道如何下手了！郁闷，好吧先从网上收集了一些资料看看。好吧，拿来主义一篇来自csdn的博客

模式的定义：

每个模式都描述了一个在我们的环境中不断出现的问题，然后描述了该问题的解决方案的核心。通过这种方式，你可以无数次地使用那些已有的解决方案，无需在重复相同的工作。

什么是设计模式？

设计模式是在某种特别的情况下，针对某种问题的某种典型、通用的解决方法。

我们是需要适当了解并学习一些设计模式，在程序开发过程中，总是会涉及到一些框架设计，模块设计之类的东西，如果能很好理解并运行设计模式，你所设计的模块或框架将会要稳定得多，因为这些设计模式它们都是通用的解决方案，是经过实践经验了的。

比如说，在程序里，可能会有通知模块，A模块的数据发生变化，B模块需要得到通知，对于这样的需要，你可能会想到用"广播"，"消息"或者"回调"的方式来解决，的确，刚才我所说的那三种也能解决，但是，这三种都是存在一些缺点，比如说广播，用Intent来传输数据很困难，对于"消息"，无法很好的跟踪，对于"回调"，有可能你A与B模块根本不可相互访问。此时，如果你会用观察者模式的问题，这种问题可以很轻松解决。

当然，这里是需要具体问题具体分析的，我主要的意思就是说，要适当利用模式，我们不能为了用模式而去用模式，我们是要用模式来解决我们实际的问题。

（ps,应为对设计模式知道的也不多，程序中会设计单例模式&#;观察者模式。。其他的模式还需要学习后再用）

概念完整性

关于概念完整性，在《人月神话》一书在有大量的阐述，这里，我把我的理解写出来，与大家分享。

1）概念完整性是系统设计中最重要的考虑因素。当你的系统规模越大，这一点体现得越明显。

2）为了获取概念的完整性，设计必须由一个人或者具有共识的小型团队来完成。这一点很好理解，关于设计，可以让所有的人参与，但是决定权在少数人手里，如果大家都想参与设计，这是根本没有办法保证系统设计是统一完整的。

3）要获得概念上的完整性，就必须有人控制这些概念，类&#;于贵族的专制统治。这里，对于团队中的项目经理或架构师必须对项目有绝对的权威，不然，这个项目里面的就无法统一号令。

4）概念完整性表现有：（ps:这个还真没有，需求目前是对比项目经理要求和web端功能添加）

- 开发过程中，需求、设计、编码的一致性 - 整个程序具有统一的风&#;，比如对话框样式，按钮风&#;，色调等UI元素 - 整个程序具体统一的结构，比如不同模块访问网络，它们的调用方式一致，例如异步访问都用回调方式通知结果，相同的功能应该提取成共通模块。 - 开发人员能很好的执行需求人员和设计人员的意图。 - 有完整的文档，需求文档，设计文档，测试文档，处理流程的文档等。

如何保持概念完整性

- 在制度上给予保证，产品的负责人必须建立技术上的绝对权威 - 技术负责人员（SE，SL）必须严&#;执行项目的需求，设计，必须深入到编码细节 - 在不同阶段，保持与所有人员的持续沟通，鼓励开发人员提意见。 - 让开发人员参与设计，但不决定设计 - 通过持续的反馈和沟通来实现模块重用

2.1 共通类的设计（ps:这个很有必要）

2.1.1 Widget设计

为什么要提供这些共通控件？

2.1.2 Adapter Items

数据驱动

下面代码示例了Adapter#getView()方法的实现，它返回BookView，BookView提供方法来接收数据，至于BookView的显示，则根据设置的数据来显示，这就是数据驱动UI。

2.1.3 Dialog

2.1.4 Utility

2.2 Task管理

线程只是一种机制，保证我们要完成的任务不运行在UI线程（也就是说不阻塞UI），完成的任务才是我们关注的核心，因此，我们可以通过设计，把线程封装，让使用者根本感觉不到是线程，他只用关心他要做的事情就行了。这里，我们可以设计一种"异步链式调用"的框架，把线程进行了封装。使用都只需要这样用：

这里，task1, task2, task3是顺序执行的，举个例子：我们要访问网络，取得一个图片，使用这个TaskManager我们需要3个task，

task1:显示一个ProgressDialog。

task2:访问网络，创建bitmap。

task3:关闭对话框，显示bitmap。

这一点，可以参考CoreLib工程中的task.TaskManager类。

关于TaskManager，有以下几点需要注意：

2.3 缓存设计（ps:根据之前项目经验，避免oom，我打算选择imageLoad开源库）

关于缓存的更多详细细节，请参考[ 请参考CoreLib工程中的cache包 ]。

这样做，有什么好处， 不用再手动释放bitmap内在，该操作有风险，因为该bitmap是否有View引用，如果当一个View在试图绘制一个已经回收的bitmap，这里会抛出异常。

2.4 线程管理

无消息循环的线程：

什么情况下使用这种线程：

在使用线程，最好给线程加上名字，这样利用高度与跟踪。

有消息循环的线程：

这样的线程拥有消息循环，当消息队列中没有消息时，这个线程会被挂起。我们要做一件事情时，只需要给它发送一个消息就行了。

这种情况通常是为了复用线程，不用频繁创建线程，比如音乐播放器程序，专门启动一个有消息循环的线程来获得音乐的专辑图片。

我们通常还要创建一个与这个线程的消息循环（Looper）相关联的Handler，由它来处理消息，注意，这做的事情是运行在后台线程的。

Android程序的结构

下面，我试着画了一个Android程序的结构，如果有不好的地方，欢迎指正。

下面列出一些通常的原则，我们应当在开发过程中遵循，欢迎补充与指正。

4.1 提供initialize()方法

在Activity.onCreate()或者View的构造方法中调用，在以后看代码时，人们通常首先会去找initialize()这样的方法。

4.2 封装点击事件

把View的点击事件，提成方法，这样在listener处只是一个方法调用者，一般的事件封装为：onXXXClick(View v)。

4.3 设计一个BaseActivity类

让所有的Activity都继承自BaseActivity类，这样，我们可以做很多有用的事情

4.4 设计Application类

4.5 异常处理

4.6 标注的使用

4.7 注册与反注册

4.8 封装Bitmap操作

我们应当把Bitmap操作封装起来，比如从文件加载，保存，网络下载，动态计算sample size等。有了封装后，我们可以对其集中优化。

4.9 绘制处理

一定要注意绘制方面的东西，不要在onDraw()/onTouchEvent()中创建新对象。

Android 自定义RadioGroup布局 前段时间项目中需要这种效果，自定义RadioGroup布局，但是前提是要找到RadioButton。我搜集各种资料，尝试各种测试。终于有了自定义RadioGroup布局。自定

android(5) 等待窗口 一.等待窗口实现:记录一下，有时候我们下载数据的时候为了提高用户的体验，加一个等待窗口还是有必要的，有两种等待窗口：第一种旋转的ProgressBar

Android ViewPager+Fragment滑动选项卡，tab点击选项卡 有一段时间一直再研究这个，自Android3.0以后，很少开发者再用以前的TabWidget控件了。那种效果不是很好，也不能滑动。后来陆续出现了各种各样滑动选