Android 读取sql数据库并将数据显示在ListView中 急急急急急 没那么多悬赏值，但是问题确实棘手！！！

创建数据库
选择开始菜单中→程序→Management SQL Server 2008→SQL Server Management Studio命令，打开SQL Server Management Studio窗口，并使用Windows或 SQL Server身份验证建立连接。
在对象资源管理器窗口中展开服务器，然后选择数据库节点
右键单击数据库节点，从d出来的快捷菜单中选择新建数据库命令。
执行上述 *** 作后，会d出新建数据库对话框。在对话框、左侧有3个选项，分别是常规、选项和文件组。完成这三个选项中的设置会后，就完成了数据库的创建工作，
在数据库名称文本框中输入要新建数据库的名称。例如，这里以“新建的数据库”。
在所有者文本框中输入新建数据库的所有者，如sa。根据数据库的使用情况，选择启用或者禁用使用全文索引复选框。
在数据库文件列表中包括两行，一行是数据库文件，而另一行是日记文件。通过单击下面的添加、删除按钮添加或删除数据库文件。
切换到选项页、在这里可以设置数据库的排序规则、恢复模式、兼容级别和其他属性。
切换到文件组页，在这里可以添加或删除文件组。
完成以上 *** 作后，单击确定按钮关闭新建数据库对话框。至此“新建的数据”数据库创建成功。新建的数据库可以再对象资源管理器窗口看到。

常用的Android性能优化方法：
一、布局优化：

1）尽量减少布局文件的层级。

层级少了，绘制的工作量也就少了，性能自然提高。

2）布局重用 <include标签>

3）按需加载：使用ViewStub,它继承自View,一种轻量级控件，本身不参与任何的布局和绘制过程。他的layout参数里添加一个替换的布局文件，当它通过setVisibility或者inflate方法加载后，它就会被内部布局替换掉。

二、绘制优化：

基于onDraw会被调用多次，该方法内要避免两类 *** 作：

1）创建新的局部对象，导致大量垃圾对象的产生，从而导致频繁的gc，降低程序的执行效率。

2）不要做耗时 *** 作，抢CPU时间片，造成绘制很卡不流畅。

三、内存泄漏优化：

1）静态变量导致内存泄漏   比较明显

2）单例模式导致的内存泄漏 单例无法被垃圾回收，它持有的任何对象的引用都会导致该对象不会被gc。

3）属性动画导致内存泄漏  无限循环动画，在activity中播放，但是onDestroy时没有停止的话，动画会一直播放下去，view被动画持有，activity又被view持有，导致activity无法被回收。

四、响应速度优化：

1）避免在主线程做耗时 *** 作 包括四大组件，因为四大组件都是运行在主线程的。

2）把一些创建大量对象等的初始化工作放在页面回到前台之后，而不应该放到创建的时候。

五、ListView的优化：

1）使用convertView，走listView子View回收的一套：RecycleBin 机制

主要是维护了两个数组，一个是mActiveViews,当前可见的view,一个是mScrapViews，当前不可见的view。当触摸ListView并向上滑动时，ListView上部的一些OnScreen的View位置上移，并移除了ListView的屏幕范围，此时这些OnScreen的View就变得不可见了，不可见的View叫做OffScreen的View，即这些View已经不在屏幕可见范围内了，也可以叫做ScrapView，Scrap表示废弃的意思，ScrapView的意思是这些OffScreen的View不再处于可以交互的Active状态了。ListView会把那些ScrapView（即OffScreen的View）删除，这样就不用绘制这些本来就不可见的View了，同时，ListView会把这些删除的ScrapView放入到RecycleBin中存起来，就像把暂时无用的资源放到回收站一样。

当ListView的底部需要显示新的View的时候，会从RecycleBin中取出一个ScrapView，将其作为convertView参数传递给Adapter的getView方法，从而达到View复用的目的，这样就不必在Adapter的getView方法中执行LayoutInflaterinflate()方法了。

RecycleBin中有两个重要的View数组，分别是mActiveViews和mScrapViews。这两个数组中所存储的View都是用来复用的，只不过mActiveViews中存储的是OnScreen的View，这些View很有可能被直接复用；而mScrapViews中存储的是OffScreen的View，这些View主要是用来间接复用的。

2）使用ViewHolder避免重复地findViewById

3)快速滑动不适合做大量异步任务，结合滑动监听，等滑动结束之后加载当前显示在屏幕范围的内容。

4）getView中避免做耗时 *** 作，主要针对：ImageLoader来处理(原理：三级缓存)

5）对于一个列表，如果刷新数据只是某一个item的数据，可以使用局部刷新，在列表数据量比较大的情况下，节省不少性能开销。

六、Bitmap优化：

1）减少内存开支：过大，超过控件需要的大小的情况下，不要直接加载原图，而是对进行尺寸压缩，方式是BitmapFactroyOptions 采样，inSampleSize 转成需要的尺寸的。

2）减少流量开销：对进行质量压缩，再上传服务器。有三种存在形式：硬盘上时是file，网络传输时是stream，内存中是stream或bitmap，所谓的质量压缩，它其实只能实现对file的影响，你可以把一个file转成bitmap再转成file，或者直接将一个bitmap转成file时，这个最终的file是被压缩过的，但是中间的bitmap并没有被压缩。bitmapcompress(BitmapCompressFormatPNG,100,bos);

七、线程优化：

使用线程池。为什么要用线程池？

1、从“为每个任务分配一个线程”转换到“在线程池中执行任务”

2、通过重用现有的线程而不是创建新线程，可以处理多个请求在创建销毁过程中产生的巨大开销

3、当使用线程池时，在请求到来时间 ，不用等待系统重新创建新的线程，而是直接复用线程池中的线程，这样可以提高响应性。

4、通过和适当调整线程池的大小 ，可以创建足够多的线程以使处理器能够保持忙碌状态，同时还可以防止过多线程相互竞争资源而使应用程序耗尽内存或者失败。

5、一个App里面所有的任务都放在线程池中执行后，可以统一管理 ，当应用退出时，可以把程序中所有的线程统一关闭，避免了内存和CPU的消耗。

6、如果这个任务是一个循环调度任务，你则必须在这个界面onDetach方法把这个任务给cancel掉，如果是一个普通任务则可cancel，可不cancel，但是最好cancel

7、整个APP的总开关会在应用退出的时间把整个线程池全部关闭。

八、一些性能优化建议：

1）避免创建过多对象，造成频繁的gc

2)不要过多使用枚举，枚举占用的空间比整型大很多

3）字符串的拼接使用StringBuffer、StringBuilder来替代直接使用String,因为使用String会创建多个String对象，参考第一条。

4）适当使用软引用，（弱引用就不太推荐了）

5）使用内存缓存和磁盘缓存。

通过Intent对象来传值。
Intent（意图）主要是解决Android应用的各项组件之间的通讯。
Intent负责对应用中一次 *** 作的动作、动作涉及数据、附加数据进行描述，Android则根据此Intent的描述，负责找到对应的组件，将 Intent传递给调用的组件，并完成组件的调用。
因此，Intent在这里起着一个媒体中介的作用，专门提供组件互相调用的相关信息，实现调用者与被调用者相互联系。

你可以把从服务器中获取的数据封装到一个类中间中，然后通过Parcelable打包一下。
再把封装的类装到一个ArrayList中，在通过Intent 和bundle把你打包的ArrayList传过去。

你在另一个Activity中接受就ok了。

我曾经在做一个音乐播放器的时候就是把listview中就是这样把音乐信息都传过去

引用来自“预兆师”的答案
引用来自“石头哥哥”的答案
嗯 channel实际就是一个客户端和server的一个抽象的管道 ，netty封装了网络的底层 所以 你不必太多去掀开一些它封装的东西来处理 对于还不熟悉的开发者来讲的 话；你可以这样处理 在连接上来的时候 你创建一个session会话来持有这个channel ，每一个session有一个ID ，那么 你在业务层就可以通过这个ID拿到session 从而将这个数据发送出去，你这里 其实在服务器端就是sessionA sessionB ,A,B两个客户端连接服务器了 ，那么 就创建sessionA sessionB ，并产生一个ID （ID 保持唯一就可以了），A向B发送，那么实际就是通过服务器来转发A的消息到B，那么你必然拿到B的ID，几在A的消息中发送B的ID，这样就可以拿到sessionB ，然后channelwrite(); 消息的转发 与消息的推送 关键就在与知道sessionID，顺利得到相应的session 这样就可以解决问题了；
创建session的位置在channelActive(ChannelHandlerContext ctx)；标记channel的方式很多 ，上面的和你描述的一样 只是 封装了一个session来持有channel罢了；
谢谢你的回复。
你的回复里面没有提到如何绑定用户和channel的对应关系。我对此的大致想法是这样的：客户端与服务端建立连接的时候，也就是在channelActive(ChannelHandlerContext ctx)，服务端用RSA算法生成一对公私钥，并把公钥返回给客户端；客户端使用公钥加密登录信息发送到服务器，服务器解密后，将用户信息与channel对应起来，记录在链表里面。然后当A发送信息给B的时候，服务器从链表里面找到B的信息，并通过B对应的channel传送信息给B。
不知我这样的连接流程有没有问题，请指教。
ID--session--channel 它们是一一对应的， map;
class session{
ID;//session持有ID
channel;//session持有channel
}
任何一个客户端链接上来，你就把服务器现在在线的ID同步给链接上来的客户端，这样就好像是qq，向谁发送？ 只需 ID（目标）+message； 额 你这个是可以的 变相的其实本质一样 ，ID 就是一个纽带；

这个问题。android存储方式有很多 SharedPreferences ，SQLite,Content Provider等等，如果是服务器的话可以用Mysql，你输入框的数据可以采用以上任意一种方式,至于在ListView中无非就是讲你Edtext的内容用getText()toString()trim();方法付给一个变量。然后再你的ArrayList<变量类型>对象中调用add方法将那个变量传进去在调用ListView的notifyDataSetChanged()方法进行刷新。希望可以帮助你

---