位置: 编程技术 - 正文

Developing for Android, III: The Rules: Performance

编辑:rootadmin

推荐整理分享Developing for Android, III: The Rules: Performance,希望有所帮助,仅作参考,欢迎阅读内容。

文章相关热门搜索词:,内容如对您有帮助,希望把文章链接给更多的朋友!

On Android, performance and memory are closely intertwined, since the memory footprint of the overall system can affect the performance of all of the processes, and since the garbage collector can have a significant impact on runtime performance. But the items in this section are targeted more specifically at runtime performance that is not necessarily memory-related.

Avoid Expensive Operations During Animations and User Interaction

As mentioned in the UI Thread section in the Context chapter, expensive operations which happen on the UI thread can cause hiccups in the rendering process. This, in turn, causes problems for animations, which are dependent on this rendering process for every frame. This means that it is even more important than usual to avoid expensive operations on the UI thread while there are active animations. Here are some common situations to be avoided:

Layout: Measurement and layout is an expensive operation, and the more complicated the view hierarchy, the more expensive it can be. Measurement and layout happens on the UI thread (as does any operation that needs to manipulate the views of an activity). This means that an application that is currently trying to run a smooth animation and is then told to layout will do both things on the same thread, and the animation will suffer.Suppose your application is able to achieve an overall rendering duration of milliseconds during a particular animation, which is within the ms requirement for frames per second (fps). Then an event occurs that causes layout to occur, which takes 5 ms. This layout will occur before the next frame is drawn, which will push the overall frame drawing time to ms, and your animation will noticeably skip a frame.To avoid this situation when layout needs to occur, either run the layout operations before animations start or delay them until the animations are complete. Also, try to animate only properties that do not trigger layout. For example, View’s translationX and translationY properties affect post-layout properties. LayoutParams properties, on the other hand, require a layout to take effect, so animating those properties will cause jank in reasonably complex UIs.Inflation: View inflation can only happen on the UI thread, and it can be a expensive operation (the larger the view hierarchy, the more expensive the operation). Inflation can happen by manually inflating a view or view hierarchy, or by implicitly inflating it by launching a separate activity. This will happen on the same UI thread as your main activity, and will cause animations to halt while that new activity is inflated.To avoid this situation, wait to inflate the views or launch the activities until the current animation is finished. Or for avoiding inflation-related jank while scrolling a list with different view types, consider pre-inflating views of those types. For example, RecyclerView supports priming the RecycledViewPool with item views of specific types.Launch Fast

View inflation is not cheap. It’s not just the parsing of the resource data, but also the instantiation of potentially many views and their potentially expensive content along the way, including decoding bitmaps, running layout, and drawing for the first time. The more complicated your UI and the more views that are in your view hierarchy, the more expensive this inflation operation will be.

All of this contributes to slow startup time for applications. When the user launches an application, they expect near-instant feedback that the application is running. Android achieves this by displaying a “Starting Window,” which is a blank window constructed with the application’s theme, including any specified background drawable. This is all done in the system process while the application is being loaded and inflated in the background. When the activity is ready to display, the starting window transitions to that real content and the user can begin to use the application.

While this use of the starting window can give much-needed fast feedback to the user that something is happening, it is not enough to cover for applications that take two, three, or even more seconds to launch; the user will be forced to sit there and stare at the empty starting window until the app is completely ready to go.

Avoid this problem by launching as fast as possible. If you have parts of your UI that do not need to be visible on first launch, don’t inflate them. Use ViewStub as a placeholder for sub-hierarchies that can be optionally inflated later. Avoid expensive operations like decoding large bitmaps whenever possible. Avoid memory churn due to allocations and garbage collections when possible. Use the tools to monitor your startup time and eliminate bottlenecks when you find them.

Also, avoid initialization code in your Application object. This object is created each time your process is started, potentially causing much more work to be done than is actually needed to get the initial UI shown to the user. For example, if the user is looking at a picture, decides to share it, and selects your app, all your app needs to do is show its share UI, nothing more. Application subclasses tend to become repositories for the full set of potential things an app may need to have initialized, doing a lot of wasted work in common cases. Instead, it is recommended that you use singletons to hold common global state, which are initialized only the first time they are accessed. On a related note, never make a network request in your Application object. That object may be created when one of the app’s Services or BroadcastReceivers is started; hitting the network will turn code that does a local update at a specific frequency into a regular DDoS.

Also, note that there is a big difference in startup time depending on what state the application is in prior to starting. If an application has not yet been started at all, this is the worst-case scenario: the process needs to be started, all state needs to be initialized, and the application needs to perform all inflation, layout, and drawing. On the other extreme, an application can already be started and active in the background, in which case starting it can be as simple as bringing that window to the foreground — even much of the layout and rendering steps of the application may be avoided in this situation. Between these extremes are two other situations. In one, which an app may be in after the user has backed out of it, the process may be running, but the task needs to be created from scratch (via a call to Activity.onCreate()). In the other situation, which occurs after the system has evicted a task from memory, the process and the task need to be started, but the task can benefit somewhat from the saved instance state bundle passed into Activity.onCreate(). When you test your application’s startup time, make sure to optimize the worst case, where the process and the task need to be started from scratch. You can do this by swiping-out the task in the Recents list, which will kill the task and the process and ensure that everything starts from scratch the next time that it is launched.

Avoid Complex View HierarchiesDeveloping for Android, III: The Rules: Performance

The more views that are in your hierarchy, the longer it will take to do common operations, including inflation, layout, and rendering (in addition to the potentially expensive memory implications of unused content; Views are expensive by themselves, in addition to any additional data brought in by custom views). Find cheaper ways to represent nested content. One approach to avoiding complex nested hierarchies is to use custom views or custom layouts in some situations; it may be cheaper for a single view to draw several pieces of text and icons rather than have a series of nested ViewGroups to accomplish this. One rule of thumb for deciding how to combine multiple elements lies in the interaction model: if the user can interact with an element (e.g., via touch, focus, etc.), then that element should be its own view rather than being combined with other, separate elements.

Avoid RelativeLayout Near the Top of the View Hierarchy

RelativeLayout is a very convenient layout to use, because it allows developers to specify how content should be placed relative to other content. In many situations, this is necessary and may be the best solution for the job. However, it is important to understand that RelativeLayout is an expensive solution, because it requires two measurement passes to ensure that it has handled all of the layout relationships correctly. Moreover, this problem compounds with every additional RelativeLayout throughout the hierarchy. Imagine a RelativeLayout at the top of your view hierarchy; this essentially doubles the measurement work on your entire view hierarchy. Now imagine another RelativeLayout as one of the children of that first one — this doubles again the measurement passes that happen under it, requiring four measurement passes for all of the views in its sub-hierarchy.

Use a different type of layout for situations that do not require the capabilities of RelativeLayout, such as LinearLayout or even a custom layout. Or for situations in which relative alignment of child views is necessary, consider the more optimized GridLayout, which pre-processes the child view relationships and avoids the double-measurement problem.

Avoid Expensive Operations on the UI Thread

Stalling the UI Thread leads to delays in animations and drawing, which causes visible jank for the user. Avoid doing known-expensive operations while on the UI thread (such as during onDraw(), or onLayout(), or any of the other View-related methods that are called on that thread). Good examples of what not to do include calling a web service, executing other network operations (which will throw a NetworkOnMainThreadException), and doing database transactions. Instead, consider using Loaders or other facilities for performing the operations on other threads with the information feeding into the UI later as it comes in. One tool to help indicate this source of jank is StrictMode.

Another reason to avoid accessing the file system or database on the UI Thread is that Android device storage is often not good at handling multiple, concurrent reads/writes. Even if your app is idle, there might be another application doing expensive disk I/O (e.g., Play Store updating apps) and this may cause an ANR, or at least significant delays, in your application.

In general, anything that can be done asynchronously should be; the UI Thread should be used just for core UI Thread operations, like manipulating View properties and drawing.

Minimize Wakeups

BroadcastReceivers are used to receive information and events from other applications that your application may want to respond to. But responding to more of these items than your application actually needs will cause your application to wake up too often, causing overall system performance problems and resource drain. Consider disabling BroadcastReceivers when your application does not care about the results, and carefully choose the Intents that your application really needs to respond to.

Develop for the Low End

This relates to the earlier discussion in the Context chapter on Low-End Devices. Most of your users will have lower-end devices than you probably carry for your everyday phone, by virtue of their being either older or cheaper than yours. It is important to develop for this market, and not miss important performance nuances due to higher performance metrics of your development device glossing over elements of your application that would be hard to miss on lower-end devices. Your primary device should not be the fastest/latest one available, and you should always have a variety of devices to be able to try out different speeds and form factors to ensure that your application runs adequately across all of them.

Other factors of low-end devices that are important to test against include small RAM sizes and small screen sizes. For example, MB is a common low-end configuration, and many Android devices have screen resolutions of x or less.

Measure Performance

There is a plethora of tools available on Android. Use them to track important performance-related information about your application, including rendering performance (are you able to hit fps?), memory allocations (are constant allocations triggering garbage collections leading to jank during animations?), and startup performance (are you doing too much at startup leading to long wait times for the user when your app first comes up?). Find the problems. Fix them.

AsyncTask 转载自

android中解析doc、docx、xls、xlsx格式文件 解析doc,要tm-extractors-0.4.jar这个包解析xls,要jxl.jar这个包下载jxl.jarpublicstaticStringreadDOC(Stringpath){//创建输入流读取doc文件FileInputStreamin;Stringtext=null;//Envir

Android提权漏洞分析——rageagainstthecage Androidadbsetuid提权漏洞由SebastianKrahmer在年公布,并发布利用工具RageAgainstTheCage(rageagainstthecage-arm5.bin)。该工具被广泛用于SuperOneClick、z4root等root工具和T

标签: Developing for Android, III: The Rules: Performance

本文链接地址:https://www.jiuchutong.com/biancheng/384186.html 转载请保留说明!

上一篇:Developing for Android, IV: The Rules: Networking

下一篇:AsyncTask(asynctask优缺点)

  • 普通增值税有什么用
  • 税额怎么调整
  • 什么是税额和计税金额
  • 计提房产税要含税吗
  • 金税四期正式启动
  • 投资性房地产递延所得税资产怎么算
  • 水利建设基金一定要交吗
  • 企业所得税预缴少申报案例
  • 建筑业确认收入的时间是按进度计量么
  • 所得税季度交吗
  • 个体户经营税收政策
  • 企业与政府土地合作开发模式
  • 企业所得税的常设机构
  • 小规模纳税人财务报表是按季还是按月申报
  • 多层股权结构设计控制法
  • 实收资本与账簿不一致
  • 财政拨款申请格式怎么写
  • 补贴收入需要缴纳增值税吗为什么
  • 手撕发票怎么粘贴平整
  • 现金流量表编制依据和方法
  • 委托代收款
  • 记账凭证和转账凭证可以装订在一起吗
  • 对员工的罚款怎么做账
  • 收到未知款项如何做账
  • 房地产开发公司注册资金要求
  • 计提印花税会计分录怎么写
  • 企业支付水电费属于什么费用
  • 个人租赁汽车给公司怎么开发票
  • win10如何设置右键
  • 笔记本cpu天梯图苹果
  • 简单才能极致
  • 房地产企业按揭款到账后增值税
  • php aop
  • 发行股票的手续费、佣金如何会计处理?
  • un system
  • php中construct
  • 详解php实现执行任务
  • 什么情况下增长率是0
  • php随机生成1到3的数字
  • 普通发票被退回怎么处理
  • 2023最新最全的祈祷视频
  • 金税盘减免税款留抵
  • php中实现文件上传需要用到哪几个函数
  • vscode写前端代码,如何运行
  • css元素居中的几种方法
  • 文件不小心删除了怎么恢复
  • gcm文件
  • 本月损益类未结转为零的一级科目6603
  • 中小企业估值
  • 资产减值损失是费用吗
  • 个人名字的发票可以报销吗
  • 小企业如何核算成本费用
  • 工程施工的主要经济指标包括哪些
  • 会计继续教育的发票在哪里打
  • 城建税及教育附加税税率是多少
  • 增值税申报表和企业所得税申报表的关系
  • 法人借给公司钱怎么写情况说明
  • 关于财务报销的法律
  • 企业购买黄金有限制吗
  • 在docker中使用service命令
  • sqlserver日期计算年龄
  • mysql联合索引生效原则
  • sql2008r2镜像
  • mysql中汉字用什么类型
  • Mac借助其他电脑做系统
  • win7 win8.1
  • 网页制作颜色搭配
  • 批处理计算的特点
  • 服务器安全设备
  • unity3d基本操作
  • jquery 鼠标悬浮显示文字
  • python神奇的小海龟
  • jquery.form
  • python调用python脚本
  • python 设计
  • js实现的功能
  • jquery怎么设置样式
  • 写给小白的情书
  • 买药开税票多少税率
  • 湖北省税务局官网电话
  • 免责声明:网站部分图片文字素材来源于网络,如有侵权,请及时告知,我们会第一时间删除,谢谢! 邮箱:opceo@qq.com

    鄂ICP备2023003026号

    网站地图: 企业信息 工商信息 财税知识 网络常识 编程技术

    友情链接: 武汉网站建设