app优化建议（大学生对app的建议怎么写）

本文目录

• 大学生对app的建议怎么写
• 移动 app 从哪些 方面优化
• 滴滴出行app优化建议（原创）
• 你对员工之家app有何建议
• android 开发之app都可以进行哪些优化

大学生对app的建议怎么写

您好，非常感谢您对app建议的关注。作为一名大学生，我认为app应该更加注重用户体验，提供更加简单易用的界面，让用户更容易理解和使用。此外，app应该提供更多的功能，比如提供更多的搜索功能，让用户更容易找到需要的信息；提供更多的社交功能，让用户可以更容易的与他人交流；提供更多的游戏功能，让用户可以更容易的参与游戏；提供更多的安全功能，让用户可以更安全的使用app。总之，app应该更加注重用户体验，提供更多的功能，提供更安全的环境，让用户可以更容易的使用app。

移动 app 从哪些 方面优化

定了四个方向：
- 响应时间（Response Time）
- 界面卡顿（ANR）
- 耗内存（Memory）
- 内存泄露（Out of memory)
响应时间
这里指的是客户端与服务端交互，拿到数据、解析、再到显示到界面整个过程耗费的时间。
这个部分涉及客户端的优化，也涉及服务端的优化，这里只讨论客户端。
HTTP请求方式
我们的app一般离不开网络，请求接口是最平常的操作了，如何请求，请求什么我们在开发初期就要定好，服务端给我的提供的接口，大致可以通过GET、POST、HEAD、PUT、DELETE这几种请求方式，不同的请求方式有不同应用场景，比如GET请求，应当用来请求返回结果，参数是作为url的一部分；POST请求，用于请求会更改服务端数据或状态；HEAD请求跟GET一样，只是服务器不能在响应里返回消息主体；PUT请求，用于将网页放置正确的地方；DELETE请求用于删除服务器指定文档。
使用优秀的开源Http框架是我们比较好的选择，它的优点是经过市场的验证，很多坑都被填过，缺点也是我们需要去深究它才能对其进行扩展，遇到坑也不一定能填。
如果自己造轮子的话，还需要我们花时间去验证去适应我们的业务需求，但好处是我们可以自己去扩展可把控，不过这很考量开发者的素质。
数据解析
实际开发当中服务端的返回数据格式无非就两种：
- JSON
- XML
这两种格式数据格式各有优劣，从可读性来看，xml略微好一点，不过JSON也有规范的标签，从解析难度和速度来看，大家都比较倾向使用JSON，目前JSON也是主流的数据格式。
在Android中均可以使用优秀的解析库来加快我们的解析速度，XML中有dom4j，JSON有Jackson、Gson，我们通过这些库实现我们更快的完成数据解析，提高我们的开发效率。
数据存储
上一节讲的是数据解析，我们解析完后的数据，可能就需要将数据存储在某个地方，Android的五种存储方式：
- Content Provider（主要用来向其他应用程序共享数据）
- SQLite（存储数据到数据库中）
- File（本地文件保存）
- SharedPreference（主要用来保存简单的配置信息）
- 网络存储（WebService返回的数据或是解析HTTP协议实现网络数据交互）
为了提高应用程序的响应时间，数据缓存是一个比较好的方式，我们可以预处理服务器返回的数据，对数据进行缓存刷新。
优化点：
- 异步请求网络数据
- 预处理服务器返回数据
- 异步进行数据存储操作
- 数据缓存刷新
- Timeout超时重试
- 在主线程中操作UI
界面卡顿
ANR表示”应用程序无响应”，这个是需要我们避免发生的事情，出现这个异常的原因：
- 主线程 (“事件处理线程” / “UI线程”) 在5秒内没有响应输入事件
- BroadcastReceiver在10秒内没有执行完毕
导致ANR的原因有很多，一般情况就是在UI线程做了耗时的操作，例如”网络请求”、数据库操作。
那么如何避免？
- UI线程只做界面刷新，不做任何耗时操作，耗时操作放在子线程来做
- 可以使用Thread+handle或者AsyncTask来进行逻辑处理
耗内存
每部手机的内存有限，我们这里所说的内存指的是手机的RAM，它是Ramdom Access Memory的缩写，我们应用程序的需要随机读写的数据就存在RAM中，Android手机之所以会比较耗内存，这跟Android后台的处理有关，我们知道Android应用是使用Java开发的，运行Java需要有虚拟机，说明每开启一个应用都会创建一个虚拟机，而这是需要内存的，所以我们开的应用越多，后台进程越多，内存都分配出去了，才导致内存消耗的严重。
其实这个问题我们是没得破的，只要内存不够，我们的应用还是会卡。我们开发的应用依赖与系统给我们分配的堆内存，一般上限在16M~48M，但我们可以通过在AndroidManifest设置Application属性largeHeap=“true”来申请更多的堆内存。
通过以下代码获取可用堆内存限制：
mActivityManager = (ActivityManager) this.getSystemService(Context.ACTIVITY_SERVICE);
mMaxMemory = mActivityManager.getMemoryClass();1212
内存泄露
内存泄露这个问题已经被说烂了，大家都知道有内存泄露这个问题存在，但为什么会发生内存泄露？
这里的内存泄露并不是真正意思上的泄露，而是因为内存不足不能进行GC操作，从而导致占用内存过大，抛出out of memory异常，而被系统Kill掉。
JVM回收机制
是时候讲讲JVM的回收机制了，看下图：
JVM对Java对象分了三个代进行管理，分别为年轻代、年老代、永久代。
年轻代（Young Generation）：绝大多数的Java对象会在年轻代被分配，也会在年轻代被回收。
年老代（Old Generation）：在年轻代长期存在没有被回收的Java对象会转移到年老代，这个堆空间通常会被比年轻代的堆空间要大。
永久代：存放VM和Java类的元数据，以及interned字符串和类的静态变量。
这里涉及到JVM的相关知识，这里不继续深入探讨。
但我们应该可以知道垃圾回收器的作用:
- 分配内存
- 保证所有正在被引用的对象还存在于内存中
- 回收执行代码已经不再引用的对象所占的内存
对象引用
Java的引用类型可以分为以下几种：
- 强引用（Strong Ref）：强可达，去掉强可达，才会被回收。
- 软引用（Soft Ref）：内存够用，就保持，内存吃紧，则回收，主要用来做缓存。
- 弱引用（Weak Ref）：比Soft Ref弱，即使内存不吃紧也会被回收。
- 虚引用（Phantom Ref）：不会在内存保持任何对象。

滴滴出行app优化建议（原创）

版本号：5.2.4

滴滴出行的整体设计界面清晰、操作流畅、使用便利，极大的改善用户出行体验，本篇主要针对滴滴的优化提出一些建议：

主要有三个：

背景：滴滴出行涵盖服务越来越多，后面的新添功能无法很好露出展示；

           每个人出行方式不同，虽然大多数人出行选择快车，也有部分追求中高品质的专车／豪华车用户，喜欢骑行的单车用户，默认选择“快车”，其他选择需要向后翻找。

优化建议：实用算法根据用户选择次数对Tab栏的出行方式做个性化排序，开启默认显示上次使用的出行方式。

好处：缩短操作流程，开启即所需，提升用户粘性；  

           因为专车／豪华车展示考前，提升中高端用户对其使用率。

界面展示：

背景：“敬老出租”非常人性化，大的字体和简洁的界面也符合老年人使用，但位置过于靠后不易被发现，使用频次低。

           老年人普遍视力不佳，需要更简洁的功能操作和更大的字体显示，等待接驾页面字体较小。

优化建议：老年人默认显示“敬老出租”，放在Tab栏最前面；

                  等待接驾页面重点功能和信息字体放大（车牌号、称呼、打电话，取消订单），发消息和更多操作不是基础功能，文                           字性内容也不适合老年人识别，故可以考虑删减。

好处：方便老年人操作，提升用户量。

背景：针对滴滴出行“单车”功能，地图体现车辆密集程度及地理位置，但无法准确定位到单车位置。

优化建议：增加短途步行导航功能，点击“到这去”自动导航到附近单车位置。
（ofo+百度地图）

目前想到这么多，望交流指正。

你对员工之家app有何建议

我没有直接使用员工之家 app 的经验，以下是一些常规的优化建议：
1. 优化界面和交互设计：员工之家 app 用户体验和视觉效果方面都需要从用户使用习惯和视觉上思考，提高界面美感、易用性及视觉效果，增强用户黏性。
2. 加强功能和服务的及时性和实用性：不断丰富功能和服务，提供实际的解决方案，增强用户体验，简化流程，促进学习、交流和员工沟通等。
3. 安全性优化：采取有效的防范措施，保证用户登录操作的安全性，承诺保护个人隐私和权益，有效防范用户数据泄露和隐私泄露等安全风险。
4. 继续完善用户服务体系：针对用户反馈的问题和建议，认真分析、回应和解决问题，提升用户知情权、参与度和满意度，从而不断增强用户对员工之家 app 的信任和忠诚度。
通过上述建议和细节优化，员工之家 app 可能会更具吸引力和竞争力，使其成为员工日常工作中不可或缺的便捷工具。

android 开发之app都可以进行哪些优化

1.在后台取消一些线程中的动作

我们知道App运行过程中所有的操作都默认在主线程（UI线程）中进行的，这样App的响应速度就会受到影响。会导致程序陷入卡顿、死掉甚至会发生系统错误。

为 了加快响应速度，需要把费时的操作（比如网络请求、数据库操作或者复杂的计算）从主线程移动到一个单独的线程中。最高效的方式就是在类这一级完成 这项操作，可以使用AsyncTask或者IntentService来创建后台操作。如果选择使用IntentService，它会在需要的时候启动起 来，然后通过一个工作线程来处理请求（Intent）。

使用IntentService时需要注意以下几点限制：

• 这个类不要给UI传递信息，如果要向用户展示处理结果信息请用Activity；

• 每次只能处理一个请求；

• 每一个处理请求过程都不能中断；

2.保持响应不发生ANR

从UI线程中移除费时操作这个方式还可以防止用户操作出现系统不响应（ANR）对话框。需要做的就是继承AsyncTask来创建一个后台工作线程，并实现doInBackground()方法。

还有一种方式就是自己创建一个Thread类或者HandlerThread类。需要注意这样也会使App变慢，因为默认的线程优先级和主线程的优先级是一样的，除非你明确设定线程的优先级。

3.在线程中初始化查询操作

当查询操作正在后台处理时，展示数据也不是即时的，但是你可以使用CursorLoader对象来加快速度，这个操作可以使Activity和用户之间的互动不受影响。

使用这个对象后，你的App会为ContentProvider初始化一个独立的后台线程进行查询，当查询结束后就会给调用查询的Activity返回结果。

4.其它需要注意的方面

• 使用StrictMode来检查UI线程中可能潜在的费时操作；

• 使用一些特殊的工具如Safe.ijiami、Systrace或者Traceview来寻找在你的应用中的瓶颈；

• 用进度条向用户展示操作进度；

• 如果初始化操作很费时，请展示一个欢迎界面。

优化设备的电池寿命

如果应用很费电，请不要责怪用户卸载了你的应用。对于电池使用来说，主要费电情况如下：

• 更新数据时经常唤醒程序；

• 用EDGE或者3G来传递数据；

• 文本数据转换，进行非JIT正则表达式操作。

5.优化网络

• 如果没有网络连接，请让你的应用跳过网络操作；只在有网络连接并且无漫游的情况下更新数据；

• 选择兼容的数据格式，把含有文本数据和二进制数据的请求全部转化成二进制数据格式请求；

• 使用高效的转换工具，多考虑使用流式转换工具，少用树形的转换工具；

• 为了更快的用户体验，请减少重复访问服务器的操作；

• 如果可以的话，请使用framework的GZIP库来压缩文本数据以高效使用CPU资源。

6.优化应用在前端的工作

• 如果考虑使用wakelocks，尽量设置为最小的级别；

• 为了防止潜在的bug导致的电量消耗，请明确指定超时时间；

• 启用 android:keepScreenOn属性；

• 除了系统的GC操作，多考虑手动回收Java对象，比如XmlPullParserFactory和BitmapFactory。还有正则表达式的Matcher.reset(newString)操作、StringBuilder.setLength(0)操作；

• 要注意同步的问题，尽管在主线程中是安全的；

• 在Listview中要多采用重复利用策略；

• 如果允许的话多使用粗略的网络定位而不用GPS，对比一下GPS需要1mAh（25s * 140 mA），而一般网络只用0.1mAh（2s * 180mA）；

• 确保注销GPS的位置更新操作，因为这个更新操作在onPause()中也是会继续的。当所有的应用都注销了这个操作，用户可以在系统设置中重新启用GPS而不浪费电量；

• 请考虑在大量数理运算中使用低精度变量并在用DisplayMetrics进行DPI任务时缓存变量值；

7.优化工作在前台的应用

• 请确保service生命周期都是短暂的，因为每个进程都需要2MB的内存，而在前台程序需要内存时也会重新启动；

• 保持内存的使用量不要太大；

• 如果要应用每30分钟更新一次，请在设备处于唤醒状态下进行；

• Service在pull或者sleep状态都是不好的，这就是为什么在服务结束时要使用AlarmManager或者配置属性stopSelf()的原因。

8.其它注意事项

• 在进行整体更新之前检查电池的状态和网络状态，等待最好的状态在进行大幅度装换操作；

• 让用户看到用电情况，比如更新周期，后台操作的时候；

实现低内存占用UI

9.找到布局显示问题

当 我们为布局单独创建UI的时候，就是在创建滥用内存的App，它在UI中会出现可恶的延时。要实现一个流畅的、低内存占用的UI，第一步就是搜索 你的应用找出潜在的瓶颈布局。使用Safe.ijiami和Android SDK/tools/中自带的Hierarchy Viewer Tool工具。

还有一个很好的工具就是Lint，它会扫描应用的源码去寻找可能存在的bug，并为控件结果进行优化。

10.解决问题

如果布局显示结果发现了问题，你可以考虑简化布局结构。可以把LinearLayout类型转化成RelativeLayout类型，降低布局的层级结构