Selasa, 14 Juli 2015
Sabtu, 11 Juli 2015
Nokia lumia 625 mic problem ways jumper solution
replace this mic. If you have no four pin mic then repair your phone with two pin mic following by below picture.
Kamis, 09 Juli 2015
M Developer Preview Gets Its First Update
By Jamal Eason, Product Manager, Android
Earlier this summer at Google I/O, we launched the M Developer Preview. The developer preview is an early access opportunity to test and optimize your apps for the next release of Android. Today we are releasing an update to the M Developer Preview that includes fixes and updates based on your feedback.
What’s New
The Developer Preview 2 update includes the up to date M release platform code, and near-final APIs for you to validate your app. To provide more testing support, we have refined the Nexus system images and emulator system images with the Android platform updates. In addition to platform updates, the system images also include Google Play services 7.6.
How to Get the Update
If you are already running the M developer preview launched at Google I/O (Build #MPZ44Q) on a supported Nexus device (e.g. Nexus 5, Nexus 6, Nexus 9, or Nexus Player), the update can be delivered to your device via an over-the-air update. We expect all devices currently on the developer preview to receive the update over the next few days. We also posted a new version of the preview system image on the developer preview website. (To view the preview website in a language other than English, select the appropriate language from the language selector at the bottom of the page).
For those developers using the emulator, you can update your M preview system images via the SDK Manager in Android Studio.
What are the Major Changes?
We have addressed many issues brought up during the first phase of the developer preview. Check out the release notes for a detailed list of changes in this update. Some of the highlights to the update include:
- Android Platform Changes:
- Modifications to platform permissions including external storage, Wi-Fi & Bluetooth location, and changes to contacts/identity permissions. Device connections through the USB port are now set to charge-only mode by default. To access the device, users must explicitly grant permission.
- API Changes:
- Updated Bluetooth Stylus APIs with updated callback events. View.onContextClickListener and GestureDetector.OnContextClickListener to listen for stylus button presses and to perform secondary actions.
- Updated Media API with new callback InputDevice.hasMicrophone() method for determining if a device microphone exists.
- Updated Bluetooth Stylus APIs with updated callback events. View.onContextClickListener and GestureDetector.OnContextClickListener to listen for stylus button presses and to perform secondary actions.
- Fixes for developer-reported issues:
- TextInputLayout doesn't set hint for embedded EditText. (fixed issue)
- Camera Permission issue with Legacy Apps (fixed issue)
Next Steps
With the final M release still on schedule for this fall, the platform features and API are near final. However, there is still time to report critical issues as you continue to test and validate your apps on the M Developer Preview. You can also visit our M Developer Preview community to share ideas and information.
Thanks again for your support. We look forward to seeing your apps that are ready to go for the M release this fall.
The App Developer Business Kit: Now available in 10 languages
Posted by Sean Meng, a Product Marketing Manager on the AdMob team
Today we’re excited to launch The App Developer Business Kit in 10 more languages. The website includes tips for new app developers on building, promoting and monetizing your app. Check out the Business Kit in your language:
- French
- German
- Italian
- Japanese
- Korean
- Portuguese
- Simplified Chinese
- Traditional Chinese
- Spanish
- British English
To help you make decisions about growing your app business in other regions, we’ve added 6 new market reports providing great insights about app users in Italy, Spain, Germany, Brazil, France, and Russia. Did you know that Brazilian smartphone users engage with ads more frequently than users in the US and Japan? Or that while nearly 2/3rds of French users exclusively download free apps, only 31% of Brazilian smartphone users do? Check out statistics like these about exciting regions around the world here.
Stay connected on all things mobile apps by following us on Google+ and Twitter.
Kamis, 02 Juli 2015
Game Performance: Data-Oriented Programming
Posted by Shanee Nishry, Game Developer Advocate
To improve game performance, we’d like to highlight a programming paradigm that will help you maximize your CPU potential, make your game more efficient, and code smarter.
Before we get into detail of data-oriented programming, let’s explain the problems it solves and common pitfalls for programmers.
Memory
The first thing a programmer must understand is that memory is slow and the way you code affects how efficiently it is utilized. Inefficient memory layout and order of operations forces the CPU idle waiting for memory so it can proceed doing work.
The easiest way to demonstrate is by using an example. Take this simple code for instance:
char data[1000000]; // One Million bytes
unsigned int sum = 0;
for ( int i = 0; i < 1000000; ++i )
{
sum += data[ i ];
}
An array of one million bytes is declared and iterated on one byte at a time. Now let's change things a little to illustrate the underlying hardware. Changes marked in bold:
char data[16000000]; // Sixteen Million bytes
unsigned int sum = 0;
for ( int i = 0; i < 16000000; i += 16 )
{
sum += data[ i ];
}
The array is changed to contain sixteen million bytes and we iterate over one million of them, skipping 16 at a time.
A quick look suggests there shouldn't be any effect on performance as the code is translated to the same number of instructions and runs the same number of times, however that is not the case. Here is the difference graph. Note that this is on a logarithmic scale--if the scale were linear, the performance difference would be too large to display on any reasonably-sized graph!
Graph in logarithmic scale
The simple change making the loop skip 16 bytes at a time makes the program run 5 times slower!
The average difference in performance is 5x and is consistent when iterating 1,000 bytes up to a million bytes, sometimes increasing up to 7x. This is a serious change in performance.
Note: The benchmark was run on multiple hardware configurations including a desktop with Intel 5930K 3.50GHz CPU, a Macbook Pro Retina laptop with 2.6 GHz Intel i7 CPU and Android Nexus 5 and Nexus 6 devices. The results were pretty consistent.
If you wish to replicate the test, you might have to ensure the memory is out of the cache before running the loop because some compilers will cache the array on declaration. Read below to understand more on how it works.
Explanation
What happens in the example is quite simply explained when you understand how the CPU accesses data. The CPU can’t access data in RAM; the data must be copied to the cache, a smaller but extremely fast memory line which resides near the CPU chip.
When the program starts, the CPU is set to run an instruction on part of the array but that data is still not in the cache, therefore causing a cache miss and forcing the CPU to wait for the data to be copied into the cache.
For simplicity sake, assume a cache size of 16 bytes for the L1 cache line, this means 16 bytes will be copied starting from the requested address for the instruction.
In the first code example, the program next tries to operate on the following byte, which is already copied into the cache following the initial cache miss, therefore continuing smoothly. This is also true for the next 14 bytes. After 16 bytes, since the first cache miss the loop, will encounter another cache miss and the CPU will again wait for data to operate on, copying the next 16 bytes into the cache.
In the second code sample, the loop skips 16 bytes at a time but hardware continues to operate the same. The cache copies the 16 subsequent bytes each time it encounters a cache miss which means the loop will trigger a cache miss with each iteration and cause the CPU to wait idle for data each time!
Note: Modern hardware implements cache prefetch algorithms to prevent incurring a cache miss per frame, but even with prefetching, more bandwidth is used and performance is lower in our example test.
In reality the cache lines tend to be larger than 16 bytes, the program would run much slower if it were to wait for data at every iteration. A Krait-400 found in the Nexus 5 has a L0 data cache of 4 KB with 64 Bytes per line.
If you are wondering why cache lines are so small, the main reason is that making fast memory is expensive.
Data-Oriented Design
The way to solve such performance issues is by designing your data to fit into the cache and have the program to operate on the entire data continuously.
This can be done by organizing your game objects inside Structures of Arrays (SoA) instead of Arrays of Structures (AoS) and pre-allocating enough memory to contain the expected data.
For example, a simple physics object in an AoS layout might look like this:
struct PhysicsObject
{
Vec3 mPosition;
Vec3 mVelocity;
float mMass;
float mDrag;
Vec3 mCenterOfMass;
Vec3 mRotation;
Vec3 mAngularVelocity;
float mAngularDrag;
};
This is a common way way to present an object in C++.
On the other hand, using SoA layout looks more like this:
class PhysicsSystem
{
private:
size_t mNumObjects;
std::vector< Vec3 > mPositions;
std::vector< Vec3 > mVelocities;
std::vector< float > mMasses;
std::vector< float > mDrags;
// ...
};
Let’s compare how a simple function to update object positions by their velocity would operate.
For the AoS layout, a function would look like this:
void UpdatePositions( PhysicsObject* objects, const size_t num_objects, const float delta_time )
{
for ( int i = 0; i < num_objects; ++i )
{
objects[i].mPosition += objects[i].mVelocity * delta_time;
}
}
The PhysicsObject is loaded into the cache but only the first 2 variables are used. Being 12 bytes each amounts to 24 bytes of the cache line being utilised per iteration and causing a cache miss with every object on a 64 bytes cache line of a Nexus 5.
Now let’s look at the SoA way. This is our iteration code:
void PhysicsSystem::SimulateObjects( const float delta_time )
{
for ( int i = 0; i < mNumObjects; ++i )
{
mPositions[ i ] += mVelocities[i] * delta_time;
}
}
With this code, we immediately cause 2 cache misses, but we are then able to run smoothly for about 5.3 iterations before causing the next 2 cache misses resulting in a significant performance increase!
The way data is sent to the hardware matters. Be aware of data-oriented design and look for places it will perform better than object-oriented code.
We have barely scratched the surface. There is still more to data-oriented programming than structuring your objects. For example, the cache is used for storing instructions and function memory so optimizing your functions and local variables affects cache misses and hits. We also did not mention the L2 cache and how data-oriented design makes your application easier to multithread.
Make sure to profile your code to find out where you might want to implement data-oriented design. You can use different profilers for different architecture, including the NVIDIA Tegra System Profiler, ARM Streamline Performance Analyzer, Intel and PowerVR PVRMonitor.
If you want to learn more on how to optimize for your cache, read on cache prefetching for various CPU architectures.