位置: 编程技术 - 正文

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优缺点)

  • 企业税后利润留用比例怎么算?
  • 汇算清缴时纳税调整表调增金额是怎么算出来的
  • 会计中管理费用和财务费用的区别
  • t3怎么查资产负债表
  • 应收应付账务处理工作具体做哪些
  • 来料加工出口免税不退税
  • 存根联给了客户怎么办
  • 设计费用计入产品成本吗
  • 个体工商户能否转让
  • 指定会计科目是
  • 打车发票丢了怎么办
  • 所有的企业都能采用免费策略
  • 冲销去年费用
  • 纯出口企业要交税吗
  • 什么叫社保人员
  • 开票资料电话可以查到吗
  • 开错的发票正常入账吗
  • 土地的契税和印花税记入什么科目
  • 个人收到支票如何做账
  • 不计提盈余公积可以分红吗
  • 应付利息在资产负债表中属于什么项目
  • 投资性房地产转为存货
  • 建筑企业预收的工程款会计分录
  • 原材料账户期末贷方余额反映
  • 非企业性单位包括哪些单位
  • 办公用品收据可以入账吗
  • 华为手机hms提醒
  • 王者荣耀中墨子的最强出装
  • 广告补贴申请报告
  • 汇票线下清算什么时候能到账
  • 用系统自带命令行安装WIN10
  • 曼哈顿2021
  • 小规模纳税人冲红发票怎么报税
  • 肚子胀气怎么办 4个方法快速排气很轻松
  • PHP:file_get_contents()的用法_Filesystem函数
  • 转让子公司产生的投资收益在合并层面是不是全部抵消
  • 海恩斯科普简介
  • php获取指定日期的时间戳
  • 销售地下车库缴纳哪些税
  • 无法偿还的应付账款计入什么科目
  • 视频监控接入方式有哪几种
  • 小程序项目开发流程
  • ai运行环境
  • 合并会计报表的编制
  • 现金流量表的附表如何编制
  • <四>2:掌握Const 与一二级指针结合应用
  • 如何查询以前申请的新西兰签证记录
  • 辞退员工补偿金计入什么科目
  • 报关单保费率怎么填
  • 发票验旧后还要缴销吗
  • 销售折让怎么写分录
  • 增值税发票上注明的价款包含增值税吗
  • 企业所得税留抵税额
  • 运费账务怎么处理
  • 收到党支部经费如何做账
  • 小规模公司房租发票税率是多少
  • mongodb与mysql相比的优缺点
  • centos6.9安装教程详细
  • 怎么解圧
  • Win10双显卡怎么切换到独立显卡
  • win8.1开机自启项目在哪里
  • win7连接VPN时提示800错误怎么办 连接VPN时提示错误800解决方法
  • 环境篇-幸福家庭是孩子心灵健康的关键.mp3
  • easyui折叠面板默认折叠
  • ssh登录后自动执行命令
  • 关于jquery的描述错误的是
  • Python中time模块中的方法
  • 单例 python
  • rsa python3
  • javascript Math.random()随机数函数
  • 浏览器判断手机品牌
  • android实现侧边栏
  • 国家税务总局公告2022年第9号
  • 税盘注销了怎么申报增值税
  • 税务局开蔬菜普票需要几个点
  • 住房公积金交纳的原则
  • 电子税务局申领的发票怎么读入
  • 契税计税依据含装修费吗
  • 出成效的意思
  • 税务局诉讼
  • 免责声明:网站部分图片文字素材来源于网络,如有侵权,请及时告知,我们会第一时间删除,谢谢! 邮箱:opceo@qq.com

    鄂ICP备2023003026号

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

    友情链接: 武汉网站建设